Firewalls | Chakraborty Software

Stop DDoS and Worms at ISP Level?

Architecture & Design, Firewalls, Network Security No Responses »

Sep 212009

I had a workshop at the offices of a major international backbone provider today, on the subject of security logging/monitoring/response and DDoS defense for large companies.

1. Tarpits

In the course of providing managed security service, part of the problem faced by these guys is the proliferation of custom exploits and attacks, according to their research up by 59% this year (I’d link to the pdf, but since I’m under NDA with the client I was representing, I’m not entirely sure if it’d be appropriate. You figure it out.) As it turns out, part of their mitigation strategy for quickly identifying new attacks is to set up all non-allocated netblocks they own as gigantic honeynets, for research purposes.

I asked one of their sales guys why they didn’t allocating a small portion of these IPs as tarpits? It’s not a new technology by anyone’s estimation, and given the sheer scale of IPs they’re using as honeypots, it wouldn’t be a big sacrifice, considering that a single LaBrea installation can trap hundreds of worms and stop older beasties from clogging up the tubes. His response? ”Our mission isn’t to save the Internet.”

Honestly though, it should be — it’d be in everyone’s interest, including their own, to minimize capacity used by worms and bots, bandwidth that could be used productively for other purposes. To this end, I had an idea; I hadn’t been aware of the huge amount of unused IP space available to providers of this size. I also recall various organizations and individuals having excessive IP allocations removed and thrown back into the pool (a good move, considering that the total filling up of IPv4 space has been predicted with clockwork regularity every year since at least 2000.)

So, why not have IANA and the regional RIRs set it as a condition that 5% of any unused IP space an organization owns must be allocated for the public good — i.e. sticky honeynets / tarpits?

2. Stopping DDoS at the Edge

We started discussing DDoS mitigation strategies for big customers; this particular ISP’s service consists of a cloud-based solution. Which brings me back to the idea that, since counter-attack is kind of a silly idea when you’re fighting 100,000+ hosts, (plus, do you really want companies / governments deciding whom they get to actively knock off the net?) why don’t we unearth the concept of stopping DDoS at the edge?

This has been around as a concept for some time; it would require a fair amount of coordination on the part of ISPs, and, potentially, governments, considering the magnitude of attacks suffered by Estonia in 2007, as well as China’s and North Korea’s burgeoning military / government-sponsored cyberwar capabilities. However, it seems to make sense to me that figuring out how to stop baddies getting in is a far more sensible goal than stopping them on the way out.

Remotely Triggered Black Hole Routing is a reasonably fresh approach to this, allowing the remote reconfiguration of BGP routes to drop malicious DDoS traffic. Older concepts include Diadem, a combination of software and dedicated hardware.

There are a few major problems with the idea:

a) It would require a massive amount of CPU power.

Considering how much time and money is being invested by Cisco and the likes in deep packet inspection technologies (not always for good purposes — caveat, very one-sided article, but the point holds), I wouldn’t find it to be such an insane development goal to create and deploy dedicated edge routers capable of on-the-fly reconfiguration.

b) It would require large amounts of co-operation and coordination

Well, yes. The Internet is supposed to work on the basis of this.

c) It has the potential to knock innocuous sites offline

This is the biggie; using spoofed source origin IPs, it’s conceivable that anyone could be falsely accused of launching a DDoS and in turn be knocked off. The ISP I spoke with today actually had the tools to deal with this; they worked on the basis of source IP trust levels for customer IPS deployments. Roughly speaking, every dodgy-looking connection is checked by the provider against a dynamic database of activity emanating from that IP / IP range over its backbone network. Connections (not contents) are archived for around two weeks; the security management service informs customers of the trust level of that IP.

This could conceivably be adapted to prevent false accusations of DDoS traffic — for example, by placing modified, heavily audited IDS probes at company networks’ egress points which match “real” traffic emanating from the company with the ISP’s database of traffic claiming to come from this company — bogus connections would thus not be attributed to the innocent victim. It’d be quite tricky with individual users, but it would make it fairly difficult for a botnet to indirectly knock a company or edge ISP offline by getting backbone carriers to drop its traffic due to spoofing.

d) Would you trust a consortium of governments / ISPs to decide whom to blackhole?

Obviously this is a problem, but I believe that the distributed nature of the Internet is proof against such shenanigans.

Comments?

Windows vs. Unix Traceroute

Firewalls, Network Security 1 Response »

Mar 192009

Subtle hint:

Windows tracert uses ICMP by default.

*nix/MacOS traceroute uses UDP by default. UDP is blocked by more firewalls than ICMP.

Use traceroute -I to mimick Windows traceroute behavior on a Unix box.

Why the hell do I always forget this?

Blatant Plug: m0n0wall + PCEngines WRAP / ALIX

Crypto, Firewalls No Responses »

Feb 182009

One of my recent projects had me shepherd the development and rollout of an embedded firewall for medical / clinical diagnostic devices in compliance with U.S. HHS / FDA rules on patient data privacy. Without going into details, a number of new, long-awaited requirements have sprung up within the past few years requiring data protection technology and processes in environments handling sensitive patient information.

This creates a bit of a conundrum for medical device and software manufacturers, insofar as all medical products, not just drugs, must undergo a massive, periodic set of verification and validation tests in order to ensure that they actually do what they’re supposed to, and will not result in minor side effects like genital herpes, limb removal or spontaneous combustion. Validation is expensive — bringing a drug to market can cost nearly $1 billion; any changes, upgrades or additions must go through punishing testing procedures. The same applies to clinical devices — MRI scanners, blood testers, and the myriad of associated machinery — plugs, cables, batteries — anything that somehow processes or plays a role in the processing of patient data. Fine.

For IT systems, this is a bit of an issue, especially in light of increased connectivity of hospital and other medical products. When to re-validate? Software upgrade? New feature set? Security patch? Antivirus pattern udpate? As we all know, bugs lurk everywhere, and even innocuous changes could bring about unwanted effects in poorly privilege-separated systems. This becomes worse when consumer operating systems start being used to run task-specific machinery; common development platforms keep costs down and allow for faster and broader-ranging feature implementation, but despite the inevitable whining about security-through-obscurity-is-not-real-security, having an off-the-wall operating system cuts both ways, in that it may hide flaws less likely to be spotted by peer review, but also often requires targeted intrusion attempts in order to break.

So given that clinical validation and revalidation of upgraded software so as to ensure continued reliability can cost anywhere around $500,000 a pop in time, resources and grief, offloading network security is a good thing. Despite the discrediting of eggshell models of network security (I still firmly believe that any system should be able to survive if exposed on an open network, even if this is not necessarily wise), if it’s simply not feasible to secure everything, you might as well protect it. The difficulties in validating and maintaining such systems, though, make it desirable to keep things as simple as possible.

Enter m0n0wall and WRAP / ALIX. This is the most killer hardware/security platform combo I’ve seen. I have a few of these on the older WRAP board running for years now without a hitch. They are incredibly robust, simple, without moving parts, and tolerant; my WRAP boards have been dropped, drenched, plugged into massively off-spec power supplies and otherwise abused. There’s a mini-PCI slot for a wireless card, and newer ALIX boards have VGA-out, sound, USB and serial.

M0n0 has a friendly interface, a great support community and a tremendously motivated developer behind it. Anyone familiar with basic firewall or crypto terminology will figure it out instantly; it’s fast, lightweight and has never crashed on me. My only bitch is that changing an inbound NAT rule does not automatically adjust associated firewall rules, but that’s a pretty minor thing. Best of all, it’s FreeBSD-based and conducive to hacking.