Slashdot Mirror
Internet Providers Band Together to Fight Evil
toadlife writes "A group of prominent Internet providers are teaming up with a security vendor Arbor Networks to form the Fingerprint Sharing Alliance. Through the use of Arbor Networks Peakflow SP internet appliance (which is an OpenBSD box with some secret sauce mixed in), members of the alliance can share internet threat information with each other in real time. It sounds a bit like Razor, doesn't it?"
The best example for collaborative evil fighting is www.barracudanetworks.com
This is my sig. There are thousands more, but this one is mine.
Powerful is he who overpowers his temptations.
Initiatives such as this one are part of a move toward an internet immune system -- active systems that watch for and halt undesirable activities. But like the mammalian immune system, it will doubtless be subject to false positives. This raises the potential for auto-immune diseases such as when someone's IP is inappropriately blacklisted.
The core of the problem will be a disconnect between the fast response time required for properly halting fast-spreading malware (e.g., a compact worm that attacks even just 1% of hosts will probably double its infected base every second and saturate the entire net within a minute) and the slower response times of human-mediated due-process procedures. The need to quickly halt infections will lead to a hair-trigger system that may shutdown innocent hosts or kill legitimate activity.
Internet auto-immune diseases are potentially quite serious as that actually create a serious new vulnerability. Criminals could try to trigger an immune response on a target and trigger an immunity-DOS response on the target by using the system against itself.
Two wrongs don't make a right, but three lefts do.
90% of the DDoS problem would be dealt with if ISPs used competent edge filtering on their networks. If traffic is leaving your florida-based network addressed from China, just drop it already. That'd stop most of the script kiddies with their stupid scripts that spoof from random IPs. Likewise, don't let pings come into your network to your broadcast address. These are simple things that don't even involve examining the contents of packets or throttling bittorrent/voip/yourfavoriteapp, yet across the whole planet, there are a ton of incompetently run networks.
Ok, Peakflow SP tracks and reports on network flows and the associated data gleaned from a flow such as src/dst IP addresses and ports, bytes transferred, duration of flow, etc. It does't capture packet data (though you can do that on a limited basis). A flow is a unique network transaction that starts with the first packet from a source to a destination and ends with either a time-out(no packet sent) or in the case of TCP, a close sequence (RST, FIN).
/. effect might trigger a DoS alert, but someone has to go investigate the cause. Besides, how many sites get /.ed on a daily basis? But in general, flash traffic would be seen.
What is interesting about this is that traffic like DoS/DDoS attacks port scans have unique network fingerprints. For example, a DDoS attack is a large amount of traffic to a single source, often without any return traffic. That is unusual. Sure, the
What this means for service providers, hopefully, is that they can more quickly respond to attacks and improve the general health of the networks they manage by locating the source of the malicious traffic more quickly.
If I read this correctly, if you take part in a DDOS attack also known as "Slashdotting",
/.ing. When a /. event occurs, the clients actually try to complete the TCP connections and HTTP transactions. The flow of data is two way. Think about what HTTP looks like from a packet perspective. From client to server, the initiation of the HTTP session, small packets to the server signifying GETs and POSTs or TCP ACK, and more data from server to client returning pages, images, etc. It's a pretty well known behavior.
/. event, what Peakflow will is a a spike in traffic but it will also see that clients are attempting transactions and they are coming from valid addresses (non reserved). That looks different.
No, a denial of service against a web server such as a syn flood or a resource attack doesn't look like
In a denial of service like a syn flood, there are a bunch of incomplete TCP handshakes, often from the reserved address space. In a resource starvation attack, the TCP may complete, but the client doesn't actually send any traffic to the host, in the case of an HTTP transation, would be a GET or a POST--so you get a TCP set-up and then nothing else.
In a
See?
First of all, some more details about this project can be found here.
There is nothing new about the idea, in fact, it's long overdue. There is however something new in the idea having a practical implementation. The problem so far was that various network operators use very different hardware and software to monitor their networks (if at all..), thus, the idea of a 'fingerprint' may vary. Sharing becomes difficult.
By standarlizing on one platform (Arbor Networks PeakFlow SP), this becomes possible. All operators have the same device, which, coupled with this functionality, can finally bring this idea to life.
PeakFlow SP are Intel/OpenBSD boxes with additional Arbor software. They do however retail for 120,000$ per collector unit, and a collector unit can only proccess data from up to 5 devices (usually routers which export NetFlow formatted data). This is quite a steep entrance fee to pay for the pleasure; and many of the smaller players will never be able to afford this.
In fact, it's all not much more than clever marketing for overpriced Arbor devices; without the initiative, you can easily look toward other products (Cisco GuardXT, ex-Riverhead, many others). With the initiative, you now have a bit more of a reason to send $120,000 to Arbour.
Expect every security vendor to have a similar central fingerprinting repository soon. Non-compatible with one another, ofcoure.