Net security from one of the fathers of the biz

Bill Cheswick on firewalls, logging, DDOS, and the future of security

Interview Many people have seen internet maps on walls and in various publications over the years. Federico Biancuzzi interviewed Bill Cheswick, who started the Internet Mapping Project that grew into software to map corporate and government networks. They discussed firewalling, logging, NIDS and IPS, how to fight DDoS, and the future of BGP and DNS.

Could you introduce yourself?

Bill Cheswick: I am known for my work in internet security, starting with work on early firewalls and honeypots at Bell Labs in the late 80s. I coined the word "proxy" in its current usage in a paper I published in 1990. I co-authored the first full book on internet security in 1994 with Steve Bellovin. This sold very well and arrived in time to train the first generation of network managers.

In the late 1990s Hal Burch and I did some seminal research on IP traceback, and then started the Internet Mapping Project. This grew into software to map corporate and government networks. We were two of seven people who co-founded Lumeta, a spin-off from Bell Labs, to commercialise these capabilities. You have probably seen our internet maps on walls and in various publications over the years. I have served as chief scientist at Lumeta from Sept 2000 to Sept 2006.

I am an internationally-known speaker on computers, the internet, and security.

You wrote a famous book entitled "Firewalls and Internet Security", so I'd like to ask you a couple of technical suggestions on firewalls. What type of policy do you prefer for filtered TCP ports? Returning a RST or dropping packets silently?

Bill Cheswick: I prefer the silent drops: it makes an attacker wait for a timeout, and you can't use spoofed packets to point RSTs elsewhere. Returning an RST reveals information that really doesn't need to be disclosed.

I don't think choosing one way or the other is a big deal, however.

I was thinking of the fact that if you drop TCP packets for a particular port or range or ports, an attacker could spoof your IP. In fact, he would be able to send SYN packets to the victim, who will send SYN+ACK to your IP, but since your firewall will drop those packets instead of returning RST, the attacker will be able to send his ACK storm undisturbed...

Bill Cheswick: It's true, but that trick will also work with any unassigned or idle IP addresses, and there are many.

In any case, these bounced packets don't offer any amplification, so it isn't clear why they would bother. Also, I understand that with the botnets so common, a lot of attackers don't bother spoofing packets.

What type of logging would you suggest for a firewall filtering an internet connection? If the aim of a firewall is to block undesired packets, why should we log them?

Bill Cheswick: Back in the early 90s I used to log all the probes, and often send out emails warning the owners of probing machines that they might be compromised. Over time this became as pointless as counting bugs on a windshield, and I stopped.

The information is not entirely useless, and the firewall can become a small packet telescope. Most of the information revealed is statistical: worm infection rates, etc. But you can imagine combining information about firewall probes with other information about an attack on a company that could yield some additional information about the attack.

Disk space is cheap, and these logs aren't needed for very long, nor do they typically require being backed up. I like to put such logs into a large, cheap drop-safe, and make sure that if the safe fills up, the firewall still functions.

You didn't mention NIDS when talking about analysing data and discovering threats. What is your opinion about the core idea and current technology of Network Intrusion Detection Systems?

Bill Cheswick: It makes a lot of sense to watch your own network and interconnections to keep an eye on what's going on. The problem is that there is such volume and variety of data and protocols (a strength of the internet) that it is really hard for a human to understand his network traffic, unless it is highly constrained (in other words, "we only allow web traffic on this subnet...")

Not only is it hard to really monitor what's going on, subtle, slow stealth attacks and probes over, say, a period of months, are almost impossible to separate from the hue and cry of momentary traffic. Most people don't try, but that's where the real pros can eat your lunch.

NIDS are an ongoing attempt to watch the network. They all try to watch the net, summarise traffic, report anomalies, etc. They all have problems with false negatives and false positives. False positives quickly become a monotonous drumbeat, and tend to quash interest in the tool and its results. When a salesman tells you about a NIDS, or you read a paper about some new NIDS technology, always find out the details of false positive rates, and what they miss.

Another problem is the NIDS themselves may be subverted. We have seen buffer overflow attacks on the monitoring host, packets that were intended to subvert the eavesdropping software! This can turn your NIDS against you.

Deep down, network monitors have what Matt Blaze calls the "eavesdropper's dilemma." Is the eavesdropping software seeing the same data, and interpreting it the same way, as the destination hosts? This is a hard problem: perhaps packets don't make it all the way to the destination, or the end operating system can interpret overlapping data in two ways. The eavesdropper has to understand this, and state-of-the-art implementations actually understand the local network topology and actively probe endpoints to determine their operating system and version. It seems to me that this particular arms race will end badly.

This same problem exists for law enforcement and military, only on a much grander scale. They need to extract specific, small bits of data from vast torrents of data.