Re: External IP addresses on internal network

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jim-

Jim Carter 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). 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.

 However, at
present, this machine is refusing connections to port 53, so it's possible
that there used to be a virus on it that tried to use port 53 for some evil
purpose.  Suggestion: do a virus scan on 192.168.0.24.

This is actually pretty interesting (if you don't have a real life). 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.

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. Malware can get in from e-mail, laptops, wireless connections, floppies, etc. and there's no way we can stop all of it. IDS is great but pretty pricey for SOHO use. I recently found a worm on a client that had gotten in despite our best efforts. The only way I knew it was there was by iptables logging (and rejecting) outgoing traffic on unauthorized ports. I'll never know if the worm was able to find an open port to reach the net, but internally it was contained to one box and no harm was done. Just my 2 cents.

Jeff

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA  90095-1555
Email: jimc@xxxxxxxxxxxxx    http://www.math.ucla.edu/~jimc (q.v. for PGP key)






[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux