Re: External IP addresses on internal network

[Chris Brenton <cbrenton@chrisbrenton.org>]

Greets all,

Jeffrey Laramie wrote:
> 
>> On Tue, 26 Aug 2003, Jeffrey Laramie wrote:
>>  
>>
>>> George, here is the log entry I got:
>>>
>>> Aug 26 15:39:46 NS2 kernel: Filter_INPUT: IN=eth1 OUT=
>>> MAC=00:c0:f0:69:26:49:52:54:00:de:46:c7:08:00 SRC=172.144.233.136
>>> DST=192.168.0.24 LEN=73 TOS=0x10 PREC=0x00 TTL=128 ID=1755 PROTO=UDP
>>> SPT=137 DPT=53 LEN=53
>>>   
>>
>>
>> It looks to me that 172.144.233.136 is a nameserver, and 192.168.0.24 
>> asked
>> it for name resolution, and we're looking at its answer.
>>
> This entry is generated by the built-in filter INPUT chain so I would 
> read this as a DNS request coming from 172.144.233.136 (SRC) and 
> destined for the host at 192.168.0.24 (which is the firewall's LAN 
> facing IP).

This obviously is not a legit DNS request because the source port is 
wrong (should be 53 or >1023). My guess is a brain dead Windoze system 
or even more likely, a load balancer.

> The firewall host is also a DNS server for my LAN so this 
> would be a normal request coming from the LAN **except** for the client 
> IP address.

I've seen this before. An internal client goes to access a Web site (say 
www.fubar.org) and the authoritative NS is actually a load balancer. It 
spews suspicious looking traffic at the requesting NS in order to 
generate performance metrics to figure out what IP to serve back 
(assumption being the client is close to the NS).

So if this is the case, you should see a query for a host within the AOL 
domain (owner of the address space) just prior to this traffic.

As for seeing the firewall's private IP in the log entry, are you 
running DNAT on the reply traffic? If so that would explain why it shows 
up as private.

> This is actually pretty interesting (if you don't have a real life).

LOL! :-)

> On 
> further investigation it appears that these packets only occur when a 
> LAN Windows client is connected to AOL. The SRC IPs change for each AOL 
> "session" but they are always the IP of an AOL server. It appears the 
> AOL server is using the LAN client to query the LAN nameserver and 
> signing the packets with its own IP. This seems pretty farfetched but I 
> don't have a better explanation.

I would sniff the internal network and _verify_ the above. My guess is 
its actually coming in from the true IP address, not the internal 
client. Your above log entry shows a TTL of 128 which is normal for a 
Windows box connected to the same LAN as the firewall's internal 
interface. Then again, the source MAC is that of a Cisco router, not a 
PC NIC card.

As mentioned I would verify by capturing the traffic. Something like:

windump -nn -s 1500 -w weird-dns.cap "src port 137 and dst port 53"

from a system inside of your firewall. If you get the log entry but no 
capture, you know its received from outside.

> A point of interest for list members. Most sample scripts and some 
> production configurations do little if any filtering of traffic from the 
> LAN out to the Net. The theory being that the LAN is trusted. IMHO this 
> is a mistake.

I *totally* agree. I write the material and teach SANS perimeter 
security track and one thing I am uber big on is filtering outbound as 
well. Stuff like echo-replies, type 3's, type 11's, NetBIOS/IP, SNMP, 
TFTP, etc. etc. should never be allowed to leave your network. Defense 
in-depth and all of that. If the attacker's stimulus gets in, at least 
you have a shot at blocking the reply.

HTH,
C