Jeffrey Laramie wrote:
On Tue, 26 Aug 2003, Jeffrey Laramie wrote: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).
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 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
