Bookmarked for future reference. I had been thinking about a way to "load balance" traffic across multiple Snort instances and thought about applying something like Cisco's etherchannel load-balance srt-dst-ip hashing algorithm.

Lo and behold, I found this great BPF kludge!

In our example, there will be four nodes monitoring traffic, so the BPF looks like this for the first node:
(ip[14:2]+ip[18:2]) - (4*((ip[14:2]+ip[18:2])/4)) == 0
So, in /etc/bro/local.bro, we have this:
redef cmd_line_bpf_filter="(ip[14:2]+ip[18:2]) - (4*((ip[14:2]+ip[18:2])/4)) == 0";
On the second node, we would have this:
redef cmd_line_bpf_filter="(ip[14:2]+ip[18:2]) - (4*((ip[14:2]+ip[18:2])/4)) == 1";
Third:
redef cmd_line_bpf_filter="(ip[14:2]+ip[18:2]) - (4*((ip[14:2]+ip[18:2])/4)) == 2";
And fourth:
redef cmd_line_bpf_filter="(ip[14:2]+ip[18:2]) - (4*((ip[14:2]+ip[18:2])/4)) == 3";

Special note: If you are monitoring a link that is still vlan tagged (like from an RSPAN), then you will need to stick vlan && in front of each of the BPF's.

Multi-node Bro Cluster Setup

"Are the droids taking our jobs?"

Race Against The Machine

Our argument, in brief, is that digital technologies have been able to do routine work for a while now. This allows them to substitute for less-skilled and -educated workers, and puts a lot of downward pressure on the median wage. As computers and robots get more and more powerful while simultaneously getting cheaper and more widespread this phenomenon spreads, to the point where economically rational employers prefer buying more technology over hiring more workers. In other words, they prefer capital over labor. This preference affects both wages and job volumes. And the situation will only accelerate as robots and computers learn to do more and more, and to take over jobs that we currently think of not as ‘routine,’ but as requiring a lot of skill and/or education.

...

computers are now doing many things that used to be the domain of people only. The pace and scale of this encroachment into human skills is relatively recent and has profound economic implications. Perhaps the most important of these is that while digital progress grows the overall economic pie, it can do so while leaving some people, or even a lot of them, worse off.

The Great Decoupling of the US Economy

AT&T, Verizon Wireless, Sprint, and other wireless providers would be required to record and store information about Americans' private text messages for at least two years, according to a proposal that police have submitted to the U.S. Congress.

CNET has learned a constellation of law enforcement groups has asked the U.S. Senate to require that wireless companies retain that information, warning that the lack of a current federal requirement "can hinder law enforcement investigations."

They want an SMS retention requirement to be "considered" during congressional discussions over updating a 1986 privacy law for the cloud computing era -- a move that could complicate debate over the measure and erode support for it among civil libertarians.

As the popularity of text messages has exploded in recent years, so has their use in criminal investigations and civil lawsuits. They have been introduced as evidence in armed robbery, cocaine distribution, and wire fraud prosecutions. In one 2009 case in Michigan, wireless provider SkyTel turned over the contents of 626,638 SMS messages, a figure described by a federal judge as "staggering."

Chuck DeWitt, a spokesman for the Major Cities Chiefs Police Association, which represents the 63 largest U.S. police forces including New York City, Los Angeles, Miami, and Chicago, said "all such records should be retained for two years." Some providers, like Verizon, retain the contents of SMS messages for a brief period of time, while others like T-Mobile do not store them at all.

This is just laziness on LEA's part. You want text messages for someone? Get a warrant and start tapping. This is as stupid as "ISP's have to keep 100% of all logs for years in the event that we need 0.01% of the logs, well, maybe at some point... or not, and who cares what it costs them!"

Cops to Congress: We need logs of Americans' text messages

Script-kiddies when a new public exploit appears

“We use base64 encryption”

When someone tells us a vulnerability is unexploitable

Infosec Reactions

Sure is hot

Hot weather in Richmond this weekend

SevOne discussing different ways of deduplicating netflow:

Netflow Deduplication Demystified

Plixer blog about flow stitching and RFC 5103 (bidirectional netflow)

Bidirectional NetFlow or NetFlow Stitching: Implementing RFC 5103

When I was messing around with this stuff the trickiest part to get right was accounting for drift between exports from multiple hops in the path. The export times and bytes of each flow are always going to vary slightly at each hop. My experience is with V5. For TCP packets you get a hint about connection state from the ANDed flags field. UDP was more complicated because you don't get those connection state hints and have to make other assumptions like seeing the source port change on a "different" flow, but not every protocol obeys that. IKE come to mind with both source and dest port being 500. Good luck making any sense of TFTP or some of the RPC protocols with only V5 records.

Deduplication and stitching are fun engineering problems and I think Lancope gets it right for the most part.

Best aha moment for me was discovering how ICMP is reported in flows. The source port field is set to 0 and the high and low bytes of the destination port field are used to encode the type/code tuple: 256*[Type] + [Code]. Clever. A play out of the old FTP protocol book ;)

Good blog about tying together tools like Bro, CIF, ELSA, Sphinx, etc. to do security analysis on a shoestring budget.

Open-Source Security Tools

Here's that decentralized social media project I was talking about at Shmoo

Diaspora

A Muslim businessman in Canada became a terror suspect for telling his sales staff in a text message to "blow away" the competition at a New York City trade show, a religious association said Friday.

Moroccan-born Saad Allami, who works as a telecommunications company sales manager, was arrested three days after he sent the message in January 2011 and detained while police searched his home, said the Muslim Council of Montreal.

Add this to that guy who was refused entry into the US because of a twit that he was going to "destroy" Los Angeles (meaning he was going to party hard.)

The FBI also wants you to report specific ethnicity of people doing suspicious things like using encryption, shielding their screens, using VOIP, paying in cash, and signing into Comcast while at a cafe that provides Internet access.

The global bureau of pre-crime is coming together quite nicely.

'Blow away' text lands Muslim in Canada jail