IPTABLES Log Files

Hello,

I have a redhat box protecting my network and I log my iptables rules. In particularly I log for outbount traffic. I see some entrys that would appear to be spoofs but I am uncertain of this. I have not been able to find much documentation on the logging process so if any one could take a look at the entry below and confirm this, I would greatly appreciate it.


Jul 26 03:57:45 XXXX: security_checkIN= OUT=eth0
SRC=192.168.XX.XX DST=67.XXX.102.167 LEN=106 TOS=0x00 PREC=0xC0 TTL=255
ID=63974 PROTO=ICMP TYPE=3 CODE=1 [SRC=67.XXX.102.167 DST=192.168.XX.XX
LEN=78 TOS=0x00 PREC=0x00 TTL=118 ID=40343 PROTO=UDP SPT=137 DPT=137 LEN=58 ]

I added the X's in place of some IP's and the "security_check" is for grep.

What I mostly do not understand is the info between the brackets. The rest of my logs do not have brackets.

Thanks

Hum, is this a single log entry or two? Was the stuff in brackets like that in the log? If so the log seem "corrupted" in some way... (Although I'm no iptables expert...)

Anyways, ICMP type 3 is a destination unreachable.
UDP port 137 is microsoft networking..

Ammo

why dont you check out that 198 machine on your network and see if anything weird is going on there. that entry doesnt seem to strange to me....especially if thats the only entry like that.

Thanks AngryBob,

Unfortunately this is not the only entry. Within the span of a few seconds, four lan computers appear in the log, and this is not an isolated incident. I get the creepy feeling that someone is looking to see who exists on the other side of the box. The thing that bothers me about the entry, is that it appears AT ALL! If I am only logging packets originating from my box, and I did not send these packets, who did? I am able to weed out events that I am aware of, DNS, broadcasts, ect. This event (and the others like it) baffles me. Since the source IPs and destination IPs swap in the log, I am leaning towards some kind of spoofing, but I just dont have the experience yet to feel 100% about it. If it is spoofing then I just dont have the iptables rules perfected yet either. If only my boss knew... :-)

It's hard to help without more information...
Can you provide us with a more complete log,? Is the 67.XXX.102.167 ip yours? (Is it your external IP?) What os do you run on the boxes behind that firewall? Do you run samba?

Ammo

Well , maybe some ont is trying to gain access to your local share by spoofing it as local network address.
put passwords on your shares and add rule which deny any from source ouside to dest inside

Jul 26 03:57:45 XXXX: security_checkIN= OUT=eth0 SRC=192.168.XX.XX DST=67.XXX.102.167
/\ /\
| |
MY WAN Possible Intruder
(lots of ISP routing)

LEN=106 TOS=0x00 PREC=0xC0 TTL=255 ID=63974 PROTO=ICMP TYPE=3 CODE=1 [SRC=67.XXX.102.167 DST=192.168.XX.XX
/\ /\
| |
Same Intruder IP IP Of Machine on LAN behind firewall

LEN=78 TOS=0x00 PREC=0x00 TTL=118 ID=40343 PROTO=UDP SPT=137 DPT=137 LEN=58 ]

100% Microsoft Network Behind Firewall

Netfilter.org will probably not answer email on setting up Iptables, but i do not see this as a setup issue. I will email them and if I get a response within a reasonable amount of time, I will post the answer.

Thanks

wow, that didnt work! let me clarify that jumbled mess...
The first 192. IP after eth0 is my WAN address. The 67.XX.... IP is the possible intruder (which always comes from some home broadband network, damn cable modems!) The second 192. address is a machine behind firewall on my LAN. If the brackets were not there, including the information between the brackets, it would simply look like I was pinging the 67.XX address. It instead looks like someone pinged the firewall and then tricked it into pinging a machine on the LAN. I have never done something like that so I dont know. I do know that there are some stealth modes on programs like NMAP that might be able to do this, though I have never tried.

that was a bad attempt at an ASCII illustration. I worked in theory ;-)

the thing is that that 192.168 isnt a real address. i dont understand why someone would spoof that.....i assume that you are using a router, can you look at that log?

The box *is* my router. I am using an old Quantex that was upgraded to an AMD 450 something or other. This box is NATing 30+ computers. We were using a Linksys router provided by our ISP, but this had limited administration. I needed the flexiblity of ipchains/tables to keep our own employees from chat/stream/etc. plus I wanted to learn more about *nix. With this box I can route outsiders into our intranet, video conference, and more. But to stay on the topic, I may be making some headway on the log entry. Netfilter.org, the keepers of iptables, has some patches that I have not upgraded to yet. One of them involves ICMP errors and exposing open ports on computers from the inside of the firewall. I have some more reading to do but I think I am getting closer. The link is http://netfilter.gnumonks.org/securi...icmp-dnat.html
For clarification, in my case the 192.168 is a real number in a way. My ISP is getting the most bang for their buck. My WAN 192.168 is part of their LAN. They are a wireless provider. When I say wireless, we have a tranciever on our roof that *line of site*s to their network. They have a couple hops of NAT before I get to their backbone. So when I use 192.168 as my WAN, our real pulic ip for this is two or three hops upstream in NAT. It can really slow things down on a busy day. Luckily, they are filing for bankruptcy as I post this, which means I get to go shopping for some DSL.

Ok, I see it now...

First of all, the packet logged is not a ping packet: as I said before, ICMP type 3 is an "destination unreachable" message, not an "echo" or "echo request" message (which would be ping packets...)

Destination unreachable messages is used by routers to tell a remote host that the packet or datagram it sent could not be delivered (for some reason).

Now, what wasn't clear to me is the log format of iptables...
The stuff in brackets is the heather of the UDP datagram (sent by 64.blah... ) that could not be delivered (to 192.168.x.x) that caused the router to send back an ICMP unreachable message (to 64.blah...).

So, in brief, the analysis of that log entry is that host 67.XXX.102.167 sent you an UDP packet destined for host 192.168.x.x on port 137 (netbios-ns (ms networking...)). Your firewall/router REJECTED the UDP datagram and returned an ICMP error to indicate that it was blocked (DROP would not have caused a ICMP error to be returned).

So in conclusion, there wasn't any real intrusion besides a possible probe for microsoft networking.

Ammo

PS: While researching this, I found this interesting tool on netfilter's site:
http://logi.cc/linux/NetfilterLogAnalyzer.php3

Thanks Ammo,

That link is great. It still is odd to me that it appeared to originate from my router. I have statefull rules in place and the packet originated from 67.xx.... Its confusing to me why that would log to my OUTPUT chain. Its like the box disregarded its connection and just decided to send the packet to the 67.xx address.

???

The ICMP packet DID originate from your router. Re-read my last post. The icmp packet is an error message sent to 67.blah saying that the previous UDP datagram it sent isn't allowed through...

Ammo

During a review of the hospital facilities, the Director and Doctor walking down the ward notice a man jerking off. The Director asks the Doctor, you wanna explain that.... The Doctor then explains that the patient has a rare disease where sperm fills in his testicals and that he needs to ejaculate once an hour to releave the pressure or he can die. Well, the Director says, that sounds logical. As the Director and Doctor continue down the ward, they happen by a nurse giving a patient head.... The Director turns to the Doctor, "How you gonna explain that", the Doctor calmly turns to the Director and says."Same disease, better health care plan".

Just Some Humor For Your Day. Smile =)~

Perhaps originate was the wrong choice of words. I understand that the packet was sent from my router. Given the nature of statefull rules though, my router did not initiate communction therefore it should not have logged in my OUPUT chain. The 67.XX IP make initial communication. This is why I said... "Its like the box disregarded its connection and just decided to send the packet to the 67.xx address." Iptables might need to be tweeked to handle timeouts with regards to STATE and ESTABLISHED. All of the ports in question have been filtered to the WAN with DROP, not REJECT. It should not have sent back an ICMP type 3.

put if you ping something that message goes to your router and then it goes out. so someone inside pings and that ping goes out from the router. if whats trying to get pinged isnt there then you will get the ICMP=3. does that make any sense?

if you are 100% pos that the router didnt init that sequence then i agree, it COULD be a spoof.

The OUT chain only pertains to processes running on the box, ie a logged in user, an automated task via cron, etc. There are technically packets going OUT of the box all day long. Its got to start from the box to be really be considered OUT. I still havent upgraded to the latest version to see if it corrects itself. And no, that didnt make any sense. ;-)

addon: I swear AO adds grammatical errors when the replys upload. They sneak extra words into your sentences. I just know they do.