IPTABLES Log Files
Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: IPTABLES Log Files

  1. #1
    Junior Member
    Join Date
    Jul 2002
    Posts
    9

    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

  2. #2
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

  3. #3
    Banned
    Join Date
    Apr 2002
    Posts
    149
    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.

  4. #4
    Junior Member
    Join Date
    Jul 2002
    Posts
    9
    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... :-)

  5. #5
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

  6. #6
    Junior Member
    Join Date
    Jul 2002
    Posts
    7
    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
    Unix, Network Security Engineer

  7. #7
    Junior Member
    Join Date
    Jul 2002
    Posts
    9
    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 ;-)

  8. #8
    Banned
    Join Date
    Apr 2002
    Posts
    149
    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?

  9. #9
    Junior Member
    Join Date
    Jul 2002
    Posts
    9
    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.

  10. #10
    Senior Member
    Join Date
    Sep 2001
    Posts
    1,027
    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
    Credit travels up, blame travels down -- The Boss

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •