iptables drop ACK/FIN as invalid

Is this normal?

I have iptables to drop INVALID in both INPUT and OUTPUT chain.

iptables -I INPUT -m state --state INVALID -j logblock
iptables -I OUTPUT -m state --state INVALID -j logblock

The log file looks like this

IN= OUT=eth0 SRC=67.18.*.*DST=140.211.*.* LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=1362 DF PROTO=TCP SPT=39659 DPT=80 WINDOW=126 RES=0x00 ACK FIN URGP=0

My sysctl

net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 2500
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.default.log_martians = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1

4 Replies

> Is this normal?

I don't know if it's normal, but I've seen it myself. My guess is the connection is removed from conntrack before the fin/ack arrives. So it appears as a new connection starting with fin/ack, which is invalid. (just a guess, I haven't been bothered to look into it)

Perhaps google has the answer?

@yejun:

The log file looks like this

IN= OUT=eth0 SRC=67.18.*.*DST=140.211.*.* LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=1362 DF PROTO=TCP SPT=39659 DPT=80 WINDOW=126 RES=0x00 ACK FIN URGP=0

It looks like a Maimon scan. Is the source IP known to you?

From the nmap man page:

> -sM (TCP Maimon scan)

The Maimon scan is named after its discoverer, Uriel Maimon. He

described the technique in Phrack Magazine issue #49 (November

1996). Nmap, which included this technique, was released two issues

later. This technique is exactly the same as null, FIN, and Xmas

scans, except that the probe is FIN/ACK. According to RFC 793

(TCP), a RST packet should be generated in response to such a probe

whether the port is open or closed. However, Uriel noticed that

many BSD-derived systems simply drop the packet if the port is

open.

It seems to be common to get all kinds of scans from just about everywhere on any internet IP.

The source ip is myself. It seems some client such as php will generate ack/fin but not others.

I googled around. This bug only briefly mentioned in ipfilter mailing list 2006, but it seems no one bother to fix.

I have got the same problem on CentOS 5.6 64 bit.

I'm suprised that it hasn't been fixed.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct