Whitelisting Traffic: A practical Exercise for Network Defenders

Tuesday, September 04, 2012

Johannes Ullrich, Ph.D.

25c95f8b408153139da509683b7b6603

Network intrusion detection had its rough times. Back in 2003, Richard Stiennon shook up the IDS community with his famous statement that intrusion detection in its (at the time) current form, will be dead by 2005.

Back then the focus was on intrusion prevention, and the quote from the paper that "The underlying problem with IDS is that enterprises are investing in technology to detect intrusions on a network. This implies they are doing something wrong and letting those attacks in" [1].

This ignited a battle over the merits of automated intrusion prevention, and if the job of an intrusion analyst can be automated away. There certainly are analysts, sometimes referred to as "log monkeys", that can be replaced with a simple script. But I think the problem is deeper than that, and mirrors a similar discussion in host-based intrusion detection ("anti-virus").

Over the years, host-based intrusion detection has seen some significant advances and it has come to encompass a lot more than what we currently understand as "anti-virus" or "anti-malware". But all too often we still mirror network-based intrusion detection and are looking for signatures of "badness". This approach, rightfully so, has been included in Marcus Ranum's famous posts about the "six dumbest ideas in computer security" [2].

So how do we fix it? Let’s first talk about why we don't fix it; We don't have the slightest idea what traffic is supposed to be on our networks. Many network administrators never look at network traffic, and if they do, they do so to debug a specific problem and not just to learn what they got.

We have more or less tackled the idea of asset control on our networks. Progress is made to enumerate physical assets like workstations, network gear and people. Controlling software has made some advances too in the form of whitelisting, but is still not quite where it should be.

Next in line: configuration management. Ideally, if I know what systems are on my network, if I know what software is running on these systems, and if I know how it is configured, shouldn't I know what network traffic it generates? No. Sadly, we just don't know enough about how our networks operate.

As an exercise, let’s collect some traffic. I am running this on my Mac workstation. Please follow along on your own systems.

tcpdump -w test -s0 

I just kept this running for less then a minute; I ended up with 5MBytes. The output of tcpdump has been anonymized and a bit simplified below to make it easier to read.

Let’s look at the first packet

tcpdump -r test -n -c1
74.125.134.109.993 >workstation.51844: Flags [P.],

port 993 is imap over SSL. I do use imap, my mail client is open, but is this an "authorized" connection? Let's investigate further:

dig -x 74.125.134.109

leads to gg-in-f109.1e100.net. Ok... that's not very helpful, but from past experience I know this is a Google system (“whois” will help if you don't know). I do use a Google hosted e-mail account.  But does the connection actually terminate at my mail client?

lsof -iTCP -n | grep 74.125.134.109
Mail       3125 jullrich   30u  IPv4 0xf0f429549bc055e9      0t0  TCP workstation:51844->74.125.134.109:imaps (ESTABLISHED)

This confirms that "Mail", my e-mail client, is responsible for the connection. Of course by the time I got here, the connection may have been terminated. But this is good enough for now. Next step, let’s eliminate the imap ssl traffic to this host, and move on.

tcpdump -r test -n -c1 'host not 74.125.134.109 and port not imaps'

reading from file test, link-type EN10MB (Ethernet)

workstation.29440 > ipad.63600: UDP, length 3

My workstation is exchanging traffic with my iPad. This is okay. Why? The connection was already "gone" and it was too late for lsof. Therefore all I got is the packet capture. No way to figure out what is happening here. I suspect some kind of "apple signaling" or malware call home but I can’t tell. We hit our first problem packet, and aren't nearly done.

imac:~ jullrich$ tcpdump -r test -n -c1 'host not 74.125.134.109 and port not imaps and host not workstation'

reading from file test, link-type EN10MB (Ethernet)

IP6 fe80::aaaa:zzff:feyy:xxxx.546 > ff02::1:2.547: dhcp6 solicit

IPv6 traffic. I was wondering how long it would take us to get here. I do use IPv6 on my network, and use DHCPv6 to assign addresses, so this is normal. The host uses the usual MAC derived link local address (obfuscated here), so I can verify if the MAC address is legit and matches the packet.

By this time, I am going to move ahead a bit faster then I probably should, and I will eliminate all udp port 547 traffic:

tcpdump -r test -n -c1 'host not 74.125.134.109 and port not imaps and host not workstation and port not 547'

reading from file test, link-type EN10MB (Ethernet)

IP6 2001:470:xxxx:1::e40 > 2001:470:xxxx:1::1: ICMP6, neighbor solicitation, who has 2001:470:xxxx:1::1, length 32

More "normal" IPv6 traffic, in this case a simple neighbor solicitation.

eliminating ICMPv6 (again... being lazy here)

tcpdump -r test -n -c1 'host not 74.125.134.109 and port not imaps and host not workstation and port not 547 and not icmp6'

LLDP, name myswitch, length 155

LLDP is the Netgear packet my switch broadcasts to announce itself. Normally this is turned off, but I had it turned on to debug some network issues.

We are almost done now. Only 50 packets left (out of 26,877). So let's move through the remaining traffic:

2001:470:d846:1:aaaa:bbbb:cccc:dddd.53326 > 2001:4860:800a::64.443

An IPv6 https connection. The address points back to our good friends at Google (yx-in-x64.1e100.net) and I was using Google over https at the time.

somehost.45899 > 239.255.255.250.1900

UPNP... again nothing "bad" on the local network if we didn't disable it.

And that's it (with the exception of some ARP traffic I left out)!

If you followed along, how long did it take you? This is the once-a-week exercise everybody monitoring a network should undertake. Only if you understand your network traffic will you be able to protect it.

I was lucky in this example. Most of the traffic was part of the imap over SSL connection. But still, I have no idea what the workstation->iPad traffic is about. I can only guess that the traffic content inside the SSL connections is legit. Even looking at each packet as in this case, you don't know if you just saw all your company secrets stream right past you.  The expensive IDS, data leakage appliance or whatever gadget you have, won’t be any better.

----

[1] http://searchsecurity.techtarget.com/news/906645/Users-not-so-ready-to-declare-IDS-dead
[2] http://www.ranum.com/security/computer_security/editorials/dumb/

----

I will be teaching Intrusion Detection in Depth, as well as our IPv6 Security essentials class, at NS2012 in Las Vegas starting in two weeks: http://www.sans.org/info/112574

Possibly Related Articles:
7538
IDS/IDP Network->General
Information Security
Data Loss Prevention Network Security White Listing Intrusion Detection Network Security Monitoring
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.