- cypherpunks - lists.cpunks.org

FOIPA adventures [was: [tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")]
by coderman 16 Aug '15

16 Aug '15

On 8/13/15, grarpamp <grarpamp(a)gmail.com> wrote: > ... > Well, I'll speculate that by now they've lawyered up and silenced their > OP such that it's unlikely that we'll hear from them (short of coderman > firing a broadside FOIA at them ;) *grin* NetFlow added to future queue, for great justice... best regards,

2 2

test mail
by Anonymous Remailer (austria) 16 Aug '15

16 Aug '15

SO is Cari Machet the same as Rachel Dolezal.. ie is Cari a white lady in redface Small hint idiot machet is found on NON of the tribal rolls as a surname.. AND you DO look completely white! and it seems you ARE delusional! and white.. please STOP embarassing yourself in public as some of us who are on the tribal rolls are calling you on your shit.. talk about cultural appropriation by a delusional white girl who hates herself.. you need to get professional help quickly for these delusions.. anon

3 3

Is https://cpunks.org CERT expired?
by Georgi Guninski 16 Aug '15

16 Aug '15

Did the cert expire or the NSA is after me?

5 5

anybody know what came of t-fish cult of the dead cows work?
by Cari Machet 15 Aug '15

15 Aug '15

we are legion - https://youtu.be/bC1ex2zRCYA?t=8m53s some dude that was part of lopht -- Cari Machet NYC 646-436-7795 carimachet(a)gmail.com AIM carismachet Syria +963-099 277 3243 Amman +962 077 636 9407 Berlin +49 152 11779219 Reykjavik +354 894 8650 Twitter: @carimachet <https://twitter.com/carimachet> 7035 690E 5E47 41D4 B0E5 B3D1 AF90 49D6 BE09 2187 Ruh-roh, this is now necessary: This email is intended only for the addressee(s) and may contain confidential information. If you are not the intended recipient, you are hereby notified that any use of this information, dissemination, distribution, or copying of this email without permission is strictly prohibited.

7 12

Fwd: [Ntop-misc] PF_RING DAQ lowlevelbridge vs. tc? (UNCLASSIFIED)
by grarpamp 14 Aug '15

14 Aug '15

---------- Forwarded message ---------- From: Knick, Scott E CTR (US) <scott.e.knick.ctr(a)mail.mil> Date: Fri, Aug 14, 2015 at 9:16 AM Subject: [Ntop-misc] PF_RING DAQ lowlevelbridge vs. tc? (UNCLASSIFIED) To: "ntop-misc(a)listgateway.unipi.it" <ntop-misc(a)listgateway.unipi.it> CLASSIFICATION: UNCLASSIFIED I have a question someone may or may not be able to help answer. Basically, I have in the past used the "tc" utility of iproute2 to combine multiple network interfaces into one "dummy" interface for monitoring purposes. (Creating a bridge via brctl has led to broadcast storms in some network locations, so it's not an option.) Now that I've integrated PF_RING into my sensor build and integrated the PF_RING DAQ so that Snort uses it, I have the option to use the "lowlevelbridge" setting so that multiple interfaces are combined by PF_RING for Snort's purposes. The question is: Is there an advantage of using one over the other? If I stick with using iproute2 to create a dummy interface, am I losing capture performance that the PF_RING DAQ could otherwise provide? (I'm not 100% certain, but I believe that Snort is generally reporting more packet loss when using the "dummy" interface than when using the PF_RING DAQ's lowlevelbridge option.) If it helps, I'm following the approach d escribed here for making the dummy interface using the iproute2 package: http://backreference.org/2014/06/17/port-mirroring-with-linux-bridges/ -- Scott Knick CLASSIFICATION: UNCLASSIFIED _______________________________________________ Ntop-misc mailing list Ntop-misc(a)listgateway.unipi.it http://listgateway.unipi.it/mailman/listinfo/ntop-misc

1 0

Open Fabs
by grarpamp 13 Aug '15

13 Aug '15

On Tue, Jul 28, 2015 at 8:15 PM, jim bell <jdb10987(a)yahoo.com> wrote: > From: Seth <list(a)sysfu.com> > On Tue, 28 Jul 2015 15:40:55 -0700, oshwm <oshwm(a)openmailbox.org> wrote: >> >>> So is anyone working on building an 'openfab' or is it such a big task >>> that everyone just backs away in horror? :D Of course you're going to fail if you keep saying no and FUDding yourself. Is anyone building "cars" or is it such a big task that... http://www.teslamotors.com/ >>My understanding is that the capital costs involved with building and >>operating a chip fabrication plant are astronomical, although the >>situation may be getting better. > >>http://spectrum.ieee.org/semiconductors/design/the-new-economics-of-semicon… Competition, so what? Leech what's been done before you. > Even 30 years ago, there were custom fabs that were designed to allow small > organizations to get chips fabbed. This may be one of the modern version of > them: http://www.globalfoundries.com/manufacturing/manufacturing-overview You don't need a $50B 1Msqft setup to start making chips, you need a floor in a warehouse and some people who believe. > In the mid 80's, they typically purchased older fabs (not state of the art) > and allowed small companies to prototype their semiconductor designs. > Today, some of them apparently do near-state-of-the-art production. Universities have always had fabs too. The cost to get a basic line going at some tech level is not prohibitive, it's an adventure. Open is your differentiator and your ROI, even private runs will come paying to you because they know your ground up construction and monitored production process can't inject warez in their silicon. Can you as a reasonably learned hobbyist go observe an Intel run through GloFab from start to finish? What about for the chip inside your phone? Your makerbot? Your RPi? Your USRP? Your own mask? No? Well... that's a problem.

16 50

Re: anybody know what came of t-fish cult of the dead cows work?
by Softy 13 Aug '15

13 Aug '15

> > > > too long, didn't watch. > > > that explains the putrid discourse routinely being spewed via your email. the implicit "only watches what I agrees with" is a failure of intellect. question: how many comments from external, unaffiliated sources stating the same thing must one receive before one decides they "have a point there" ... for the exciting answer, stay tuned to this mailing list. alternatively: www.*youtube*.com/watch?v=xjfKteUBa_s

3 2

How are the August 2015 Ferguson unrests going?
by Georgi Guninski 13 Aug '15

13 Aug '15

How are the August 2015 Ferguson unrests going? https://en.wikipedia.org/wiki/Ferguson_unrest#August_2015

1 0

Re: [tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")
by grarpamp 13 Aug '15

13 Aug '15

On Thu, Aug 13, 2015 at 3:40 AM, Mike Perry <mikeperry(a)torproject.org> wrote: >> But consider looking at average flow lifetimes on the internet. There may >> be case for going longer, bundling or turfing across a range of ports to falsely >> trigger a record / bloat, packet switching and so forth. > > This interests me, but we need more details to determine what this looks > like in practice. NANOG list could link specific papers regarding nature of the internet. The various flow exporters have sensible default timeouts tend cover that ok for purposes intended. > I suspect that this is one case where the switch to one guard may have > helped us. In that various activities such as ssh, browsing, youtube, whatever are confined to being multiplexed in one stream, that makes sense. > However, Tor still closes the TCP connection after just one > hour of inactivity. What if we kept it open longer? The exporting host has open flow count limited by memory (RAM). A longer flow might be forced to span two or more records. The "flags" field of some tools and versions may not mark a SYN seen in records 2+, the rest of tuple would stay same. Active timeout gives periodic data on longer flows, typically retaining start time but implementations can vary on state. Here's an early IOS 12 default... Active flows timeout in 30 minutes (1~60) Inactive flows timeout in 15 seconds (10~600) Also consider what is wished to hide, big iso download, little http clicks, start time of some characteristic session rippling across or appearing at edges, active data pumping attack. And what custom flowish things and flow settings an adversary might be doing to observe those. Traditional netflow seems useful as idea base to form a better heuristic analysis system. > Or what if the first > hop was an encrypted UDP-based PT, where it was not clear if the session > was torn down or closed? In old netflow, UDP, where src/dst ip and port tuple is same, just times out into a record. Some new exotic DPI might form session context flow record based on application inside, crypto would stop the cleartext portion of DPI. Some flow tools don't reassemble so the frag game might slide by them in an arms race. > in this case I am worried it may end up silencing the people I'd really > like to hear from. I want real data from the field, here. There's no censor here. Other operators in the field can and should speak up on topic (and feel free to bash any my errors or lack of paper / code / data posting). > You can say that, but then why isn't this being done in the real world? > The Snowden leaks seem to indicate exploitation is the weapon of choice. The Snowden leaks and Bamford also indicate NSA-UTAH, gigawatts, massive international cable tapping, CARNIVORE, NARUS, X-WHATEVER, etc. Exploitation could use a few offices full of hackers and some good peering points and hosts, not that huge $billions level of infrastructure and outside your borders expenditure. Though blackbagging to stand up an IP in the target net via an active tap could be useful, the driver to localize due to cost. > I suspect other factors are at work that prevent dragnet correlation > from being reliable, in addition to the economics of exploits today > (which may be subject to change). These factors are worth investigating > in detail, and ideally before the exploit cost profiles change. Yes, bigdata still has to conform to at least some kind of cost benefit analysis and substantiation too. Where is the line on that these days... 2^40, 2^56, 2^80...? > As such, I still look forward to hearing from someone who has worked at > an ISP/University/etc where this is actually practiced. What is in > *those* logs? The questions were of a general "intro to netflow" nature, thus the links, they and other resource describe all the data fields, formation of records, timeouts, aggregation, IPFIX extensibility, etc. Others and I on these lists know what "360 gigs" of netflow looks like. *What* specific info are you looking for beyond that? Applicability to exploit? Should people print out flows from a degenerate client and exit use case and line them up? More tools and tech... http://www.cisco.com/c/en/us/products/ios-nx-os-software/ios-netflow/index.… nfdump, silk https://en.wikipedia.org/wiki/Network_Based_Application_Recognition More generally, netflow is not the only passive analysis tool or idea out there. So focusing on it may be narrow, though it is popular tool. > Specifically: Can we get someone (hell, anyone really) from Utah to > weigh in on this one? ;) Well, I'll speculate that by now they've lawyered up and silenced their OP such that it's unlikely that we'll hear from them (short of coderman firing a broadside FOIA at them ;) (We're speculating it's 360 gigs of netflow.) > Otherwise, the rest is just paranoid speculation, and bordering on > trolled-up misinformation. :/ https://www.youtube.com/watch?v=rh1Amz8s8MI http://www.multivax.com/last_question.html Everybody's now asking questions what is possible, my job is done ;)

1 0

Re: [tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")
by grarpamp 13 Aug '15

13 Aug '15

On Wed, Aug 12, 2015 at 7:45 PM, Mike Perry <mikeperry(a)torproject.org> wrote: > At what resolution is this type of netflow data typically captured? Routers originally exported at 100% coverage, then many of them started supporting sampling at various rates (because routers were choking and buggy anyways, and netheads were happy with averages), some only do sampling. Plug flow probes into network taps and you can do whatever you want (netsec loves this and other tools). > Are we talking about all connection 5-tuples, bidirectional/total > transfer byte totals, and open and close timestamps, or more (or less) > detail than this? > > Are timestamps always included? Are bidirectional transfer bytecounts > always included? Are subsampled packet headers (or contents) > sometimes/often included? > > What about UDP sessions? IPv6? > > Information about how UDP is treated would also be useful if/when we > manage to switch to a UDP transport protocol, independent of any > padding. All of the above depends on which flow export version / aggregation you choose, until you get to v9 and IPFIX, for which you can define your fields. In short... yes. Flow endtime is last matching packet seen, but a flow can span records when the time (therefore space, ie RAM) limited mandatory expiry timers hit. UDP goes via that, TCP usually via flags. Records can span flows for which other semantic keys may not exist, as often with UDP. But DPI can also be used in the exporter to do all sorts of fun stuff and enable other downstream uses (obviously TLS / IPSEC / crypto break some things there). Tor already bundles multiple logical flows (only TCP for user today) into some number of physical TCP flows, UDP transport there might not need anything special. But consider looking at average flow lifetimes on the internet. There may be case for going longer, bundling or turfing across a range of ports to falsely trigger a record / bloat, packet switching and so forth. > and having more information about what is typically > recorded in these cases would be very useful to inform how we might want > to design padding and connection usage against this and other issues. "Typical" is really defined by the use case of whoever needs the flows, be it provisioning, engineering, security, operations, billing, bigdata, etc. And only limited by the available formats, storage, postprocessing, and customization. IPFIX and https://en.wikipedia.org/wiki/NetFlow https://en.wikipedia.org/wiki/IP_Flow_Information_Export https://www.google.com/search?q=(netflow|IPFIX)+(probe|exporter|parser) http://www.freebsd.org/cgi/man.cgi?query=ng_netflow&sektion=4 > I think for various reasons (including this one), we're soon going to > want some degree of padding traffic on the Tor network at some point > relatively soon Really? I can haz cake nao? Or only after I pump in this 3k email and watch 3k come out the other side to someone otherwise idling ;) https://cdn.plixer.com/images/slider-3-icon.png ... and/or some other bigdata systems ...

1 0