Internet kill switches

Archive for January, 2011

Internet kill switches

Posted by

January 27: the day the Internet died.

Protests have been ongoing this week in Egypt. There has been a significant amount of press coverage on the political situation. The riots began on the January 25 and then, on January 27, President Hosni Mubarak unplugged Egypt from the Internet.

The reasons given for going dark are that the rioters were using the Web and Internet to coordinate. This makes sense, as we have seen Twitter and other social media sites used in recent unrests. The main concern for InfoSec is the precedence that Mubarak has set.

Will other countries, faced with similar situations, choose to unplug? It seems likely. For example, at the same time Egypt was unplugged, the U.S. re-introduced the “Internet kill switch” bill. (Read the bill at Thomas or see Wired’s kill switch coverage.) Of course, killing the Internet will have economic repercussions.

And that’s what I am thinking about today. Should the Internet be disabled, how would my firm continue to do business? How would we send and receive communications? In terms of InfoSec and engineering, what mitigations could be deployed for this risk?

J Wolfgang Goerlich


How did they do it? Both Ars Technica and Wired have articles on the technical aspects of unplugging. How are people coping? The old standby is modem dialup, although some are calling others to post information, or faxing information out to the Internet. Wired also posted a Wiki on how to communicate if your government shuts off your Internet.

Netflows Simplified (Part 2)

Posted by

There are two drivers for NetFlow might not be immediately obvious.

The first is that NetFlow requires significantly less throughput than full packet capture. For example, see this discussion on how much bandwidth is needed to capture all the packets in a typical business. Let’s say 100 Gbps span port for typical SMB (100-1000 employee) company. NetFlow takes <5% of the bandwidth that full packet capture requires. So you could get by with five 1 Gbps span ports, which is a huge cost savings on the switching side.

The second driver is statistical analysis. Let’s assume you did not want the complexity of five 1 Gbps mirror ports (and the corresponding grunt work on the NSM to avoid duplicate entries.) If you only want 1 Gbps port, you have two options. The first option is to watch one-fifth of your servers. This poses a problem if your infected computer(s) are in the four-fifths of the LAN you are ignoring. The second option is to statistically select 1 in 5 packets from the stream. Your NSM will now have full coverage on the network, greatly improving your chance at identifying infections.

Netflows Simplified (Part 1)

Posted by

For any given office computer at any given time, numerous network communications are ongoing. There may be Kerberos authentication and ticketing occurring between the computer and the domain controller. Streaming audio from, say, Pandora leaves many packets. ARP and DNS packets will be interspersed with application layer packets for files and websites. In sum, there are many thousands of packets to work through.

Like separating spaghetti strands from a bowl of pasta, separating packets into sessions allows us to separate and study the communication from end-to-end. Session data presents the packets for a single communication. That is, for a source host, a destination host, and a given application layer protocol. The InfoSec analyst can then follow the packet trail thru the session to see what transpired and how.

Now there are two ways to read a session: in detail and in summary. The detail of a session includes all the bytes of the packets. This is available from a switch mirror port. The summary of a session includes the packet headers (IP, UDP, TCP). There are a few ways to get this information, including the Cisco NetFlow protocol. NetFlow can be all of all packets or of statistically relevant packets (sampled NetFlow).

Picture all network traffic for a given office computer as a big bowl of pasta. Pull out individual strands to get your session data. Keep statistics on the strands to get your NetFlow.