Are these INVALID packets?

Berhanie · 07-11-2007, 04:25 PM

Hello, everyone.

I'm trying to figure out why certain packets destined for port 80 get dropped. This is a typical one from my logs:

Code:

Jul 11 14:07:30 mymachine kernel: DROP -- TCP: IN=eth0 OUT= MAC=xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx SRC=xxx.xx.xx.xx DST=xxx.xxx.xxx.xxx LEN=52 TOS=0x00 PREC=0x00 TTL=48 ID=3498 PROTO=TCP SPT=41066 DPT=80 WINDOW=65535 RES=0x00 ACK FIN URGP=0

These are the relevant rules:

Code:

...
iptables -N bad_tcp
iptables -A bad_tcp -j LOG --log-level DEBUG --log-prefix "NO SYN -- DROP: "
iptables -A bad_tcp -j DROP

iptables -N tcp_chain
iptables -A tcp_chain -p tcp ! --syn -m state --state NEW -j bad_tcp
iptables -A tcp_chain -p tcp -m tcp --syn  -m multiport  --dports 443,80,53  -j ACCEPT
iptables -A tcp_chain -p tcp -m tcp --syn  --dport 22  -j ssh_chain
iptables -A tcp_chain -j LOG --log-level DEBUG --log-prefix "DROP -- TCP: "
iptables -A tcp_chain -j DROP
...
iptables -A INPUT   -m state --state ESTABLISHED,RELATED -j ACCEPT
...
iptables -A INPUT  -p tcp -j tcp_chain
iptables -A INPUT  -p udp -j udp_chain
iptables -A INPUT  -p icmp -j icmp_chain

The machine is a busy web server, and such packets appear regularly. Besides the ACK/FIN packets (as above), I've also seen ACK/RST, RST, and ACK packets which have been similarly logged.

The thing I'm trying to figure out is how the packet made it so far down the rules.

The packets cannot be any of NEW, ESTABLISHED, or RELATED -- if they
were either of the last two, they would be accepted; and if they were NEW, then since they're not SYN, they would be rejected by an earlier rule. So, this leads me to think that all such packets are INVALID.

Do you see anything wrong with my reasoning?

acid_kewpie · 07-12-2007, 09:01 AM

not really sure what extra detail you're after, but unless there's some obscene load on the box or the network elsewhere which could be causing packets to go awol, then yes they look dubious... are you maybe seeing retransmissions get through? does the packet match a live connection at that time? not too sure the best way to find that... sounds painful unless you've somethign predictable or identifiable to narrow it down to.

farslayer · 07-12-2007, 09:59 AM

Did you consider using wireshark to get a better look at the contents of one of those packets ?

nx5000 · 07-12-2007, 11:19 AM

Add the rule for INVALID packets before any other rule?
I don't see why they would get through otherwise, your reasoning makes sense to me.

iptables -A INPUT -m state --state INVALID -m limit --limit 3/s -j LOG --log-prefix "INVALID INPUT: "
iptables -A INPUT -m state --state INVALID -j DROP

acid_kewpie · 07-12-2007, 12:33 PM

oh i think i see the question now... why do packets reach that "DROP" log as opposed to the earlier "NO SYN"? that "NO SYN" rule won't ever match as "NEW" = syn, so p match of not a syn but a new packet will never occur.

Berhanie · 07-12-2007, 01:11 PM

Thanks for all your responses. To address some of your questions, the source IP address of those packets correspond to addresses requesting web pages around that time. It appears that certain clients continue to send packets for as long as 10 minutes after requesting their last web page. The large number of these packets gave me a scare, but I feel better after reading this. According to the data there, 10% of clients are faulty.

acid_kewpie · 07-12-2007, 01:31 PM

interesting thread, yeah.

nx5000 · 07-12-2007, 01:41 PM

MSIE, MSIE, ...

Actually how did they really determine that the client is faulty ? It would be good to go on with analysis.

Quote:

"NEW" = syn

I'm not using iptables so I'm not sure of the terminology but are you sure this is the case?

If I send a syn/ack or fin/ack as the first packet, will it be NEW? I guess yes? And --syn means SYN&&!FIN&&!RST&!ACK so that's a bit different.
And then if I'm correct, the rule !syn should match new packets wich are without syn or with any other flag up.

Hum

Berhanie · 07-12-2007, 02:12 PM

Quote:

Actually how did they really determine that the client is faulty ?

Not sure about that, but something's going on. In less than 4.5 days, I have more than 13,700 packets logged with "DROP -- TCP: " and destined for port 80.