Last Day to Save $200 on SANS Cyber Defense San Diego 2014

Intrusion Detection FAQ: Why Egress Filtering Can Benefit Your Organization

David Hoelzer, GCIA
May 3, 2000

Editor's note:

we all know that egress filtering can be used to protect our organization from attacking others. This note, originally published in GIAC May 4, 2000 shows how it helps us as well.

This one is interesting from the point of view of intrusion detection because it turns out to be an internal user doing something that they shouldn't be and setting off all sorts of internal alarms in the process. When I first saw this detect, my thought was that we had a multihomed machine on our network and dialed into netcom that seemed to see us as a shorter route to what should have been the "local" (from the dial up machine's point of view) netcom network. I realize this is unlikely, but routing weights can create such an effect. This seemed the most likely cause since who in their right mind in a network engineering company would choose to use an address like this for testing? Well, here's the detect and the story:

192.168.53.52 > 199.182.162.1
16:01:32.004664 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 138 unreachable [tos 0xc0]
(ttl 63, id 34707)
16:01:32.067150 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 138 unreachable [tos 0xc0]
(ttl 63, id 34708)
16:03:13.775809 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 138 unreachable [tos 0xc0]
(ttl 63, id 35018)
16:03:13.819098 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 138 unreachable [tos 0xc0]
(ttl 63, id 35019)
16:11:07.978028 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35787)
16:11:08.007757 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35788)
16:11:08.728425 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35789)
16:11:08.805470 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35790)
16:11:09.479441 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35791)
16:11:09.503519 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35792)
16:11:09.610743 firewall.my.com > 199.182.162.1: icmp:
199.182.162.255 udp port 137 unreachable [tos 0xc0]
(ttl 63, id 35793)
.
.
.


This actually repeats about 120 times each hour for the entire weekend. We see the internal interface of the firewall sending and ICMP port unreach -out- to a mystery host (199.182.162.1) on the internet. What this means is that the original request from this host (199.182.162.1) must have originated from somewhere in our internal network. Sniffing our internal network is a sensitive topic, at the moment, so it was necessary to get a VP to approve the research.

Since the address is not a part of our network scheme, tracking it down took some time, but I managed to isolate the machine by sniffing each of our 40+ internal networks for this host address. Fortunately, it was on the third subnet I sniffed.

A bit of time with my network map identified the owner of the machine and off I went. It turns out to be (yet again) an engineer testing a piece of hardware. He picked this address out of the air and configured his test machine with it and then plugged it into our live network. Naughty, naughty, but it could have been worse.

I send this because it is a good illustration of the benefits of egress filtering (these packets were dropped on their way out of our network) and configuring your sensors carefully for any unusual internal