• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1118
  • Last Modified:

iptables Log Interpretation - Invalid rule

I'm hoping someone can help me interpret some log entries that show up in my logs a couple of times a day.  These systems are on an internal network and are not directly connected to the Internet.  The rules that generate the log entries are:

iptables -A INPUT -i $EXT_INTERFACE -m state --state INVALID -m limit -j
LOG --log-prefix "Invalid: " --log-level 6
iptables -A INPUT -i $EXT_INTERFACE -m state --state INVALID -j DROP

The log entries are something like this (the Internet IP changes):

Apr 28 22:45:00 hostname kernel: Invalid: IN=eth0 OUT= MAC=XX:XX . . SRC=Internet_IP DST=192.168.100.100 LEN=76 TOS=0x00 PREC=0x20 TTL=53 ID=15756 PROTO=ICMP TYPE=3 CODE=2 [SRC=192.168.100.100 DST=Internet_IP LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=766 DF PROTO=32 ]

I'm not sure what it is telling me.  These systems are internal servers and shouln't have any reason to contact the Internet except maybe for patching.  Is this trying to tell me that my system (192.168.100.100) tried to talk to Internet_IP and got back a ICMP protocal unreachable.
This doesn't seem likely given what they are used for and the fact that there are no users or services on the servers that make any connections to the Internet.  The square bracket info has me confused especially with PROTO=32.  My thought is somehow a site on the Internet  has crafted a packet that finds it's way inside the internal network.   I am unsure how to interpret the log entry to figure out what's going on.
0
credog
Asked:
credog
  • 5
  • 4
1 Solution
 
Robert Sutton JrSenior Network ManagerCommented:
Need more Info.... Os and software being used, and Hardware involved would be a plus! Thanks in advance.
0
 
Robert Sutton JrSenior Network ManagerCommented:
Sorry, your tags didnt display whilist reading your issue. Whats the source address? Is it a trusted net? It appears to be invalid SYN packets from whatever source address it shows. This is sometimes done to flood a server. If its not a trusted network, you can use any of the following to have them automatically dropped.

/sbin/iptables -A INPUT -i eth0 -p tcp --tcp-flags ALL ACK,RST,SYN,FIN -j DROP
/sbin/iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
/sbin/iptables -A INPUT -i eth0 -p tcp --tcp-flags SYN,RST SYN,RST -j DROP

0
 
credogAuthor Commented:
I have the rules you mentioned in my firewall script before the invalid rule and none of them fires.  The source address is from a untrusted network.

I can somewhat duplicate the the packet using hping3 by crafting a icmp packet and setting the ICMP type to 3 and the ICMP code to 2.  I get the following in my log:

 Invalid Packet: IN=eth0 OUT= MAC=X.X.X.X..... SRC=10.0.0.1 DST=192.168.100.100 LEN=56 TOS=0x00 PREC=0x00 TTL=64 ID=37237 PROTO=ICMP TYPE=3 CODE=2 [SRC=1.2.3.4 DST=5.6.7.8 LEN=28 TOS=0x00 PREC=0x00 TTL=64 ID=15129 PROTO=32 ]

I'm not sure why inside the brackets I get a SRC=1.2.3.4 and DST=5.6.7.8. Is that the IP header in the ICMP packet that hping did not change?  A tcpdump of the same crafted packet looks like this:

20:50:44.152624 IP (tos 0x0, ttl  64, id 18782, offset 0, flags [none], proto: ICMP (1), length: 56) 10.0.0.1 > 192.168.100.100: ICMP 5.6.7.8 protocol 32 unreachable, length 36
        IP (tos 0x0, ttl  64, id 15295, offset 0, flags [none], proto: unknown (32), length: 28) 1.2.3.4 > 5.6.7.8:  merit-inp 8

I'm not sure if that helps, but crafting a packet helps to be able to try and see the traffic without waiting for the actual attemp to happen.

Another thought.  Could this be a way to get past a firewall by setting the ICMP packet with a unreachable protacol and the firewall would let it through becouse it thinks that someone on the inside sent a request?  Just a thought.

0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
Robert Sutton JrSenior Network ManagerCommented:
I think hping by design is meant to change Ip values(for user security) in output info.. I remember reading something similiar to this awhile back also associated with Apple's Mail.app server doing the same thing. Make sure you put ALL 3 statements in from above. I failed to mention that before.
0
 
Robert Sutton JrSenior Network ManagerCommented:
Are you using APF? j/c
0
 
Robert Sutton JrSenior Network ManagerCommented:
And after applying the new rules did you rerun your iptables.sh script to apply the rules?
0
 
credogAuthor Commented:
My script flushes the rules everytime it's run and I did have all three rules you mentioned in my ruleset.  It's fairly easy to block the traffic, the invalid rule will do that.  I'm concerned with why I'm seeing it on my internal network to systems that are servers with no users on them at all.

No APF installation.
0
 
credogAuthor Commented:
Still unsure what someone would gain by crafting a packet (which I was able to reproduce) to evade a firewall and get nothing returned, but interesting nonetheless.  I'll have to do some work to stop these packets on the main firewall (Cisco) for the internal net.  The invalid iptables rule will stop the packets on individual hosts.

Thanks for the input.
0
 
credogAuthor Commented:
Although the answer did not provide a complete solution to the original question, it was helpful to get some feeback on possible ways to mitigate the issue.
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now