IPtables uncommon packet dropping

user22395539

8/15/24, 8:46 PM

I'm setting up a basic iptables firewall on a Rocky Linux-based server with kernel version 5.15.103-1. The primary requirement is to establish specific access rules for different groups of servers. The goal is to allow full access for administrative workstations and a restricted form of access for production servers while denying access for any other requests.

My firewall script currently looks like this:


K1="10.0.51.31-10.0.51.41"
K2="10.0.51.91-10.0.51.101"
ADMIN="10.0.51.21,10.0.51.22"

# Clear rules and set default policies
iptables -F
iptables -X
iptables -N admin; iptables -N prod

# ACCEPT connections initiated from host itself
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# ACCEPT from loopback
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT ! -i lo -d 127.0.0.0/8 -j DROP

# Allow ICMP echo requests (ping) and related ICMP messages
iptables -A INPUT -p icmp --icmp-type 8 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 3/4 -j ACCEPT

iptables -A INPUT -j admin
iptables -A INPUT -j prod

# Allow all except ssh
iptables -A prod -p tcp ! --dport 22 -m iprange --src-range $K1 -j ACCEPT
iptables -A prod -p tcp ! --dport 22 -m iprange --src-range $K2 -j ACCEPT

# Allow all
iptables -A admin -p tcp -s $ADMIN -j ACCEPT

# Log and drop all other connections
iptables -A INPUT -m limit --limit 10/sec -j LOG --log-prefix "iptables " --log-level 4
iptables -A INPUT -j LOG --log-prefix "iptables " --log-level 4
iptables -A INPUT -j DROP

This server doesn't have public interfaces, and internet access is routed through a Linux-based NAT gateway. However, I'm noticing dropped packets in the logs like, Aug 15 14:35:50 prod2 kernel: iptables IN=em2 OUT= MAC=41:fb:72:ff:94:7e:15:f3:2b:1c:1b:b6:18:01 SRC=52.218.197.1 DST=10.0.51.153 LEN=40 TOS=0x00 PREC=0x00 TTL=237 ID=13818 DF PROTO=TCP SPT=443 DPT=8418 WINDOW=12284 RES=0x00 ACK URGP=0

This traffic is related to upload/download from S3. These packets should only be able to reach my server through the NAT gateway, implying that they are part of a session initiated from my server. Notably, not all of these packets are being dropped, and I can successfully curl this IP address without issues.

Despite the dropped packets, I haven't encountered any other problems with the server, (download/upload to S3). I attempted to cross-reference those logs with the conntrack table and tcpdump, but I didn't achieve much success. Is there a way to further investigate and determine why these packets are being dropped, especially when they are likely part of a session initiated from my server?

0 + 5

iptables

A.B

8/16/24, 2:35 AM

This might be an INVALID packet. Read the *Warning:* below the manual for the [`REJECT` target](https://manpages.debian.org/bookworm/iptables/iptables-extensions.8.en.html#REJECT_(IPv4-specific)) (that you're not using, so that's not an issue for you).

user22395539

8/16/24, 9:37 AM

Good point, thanks. I will try this.

A.B

8/16/24, 10:09 AM

I'm also telling that you might have nothing to do at all. The same logs might also show attacks (a-la Christmas tree) classified as INVALID. Perhaps you could duplicate the log rules to specifically log invalid matches with their own log tg and drop them befor the "main" log.

user22395539

8/16/24, 12:28 PM

Ok, actually according to man pages from link, I made some small adjustmens, all drop command has been changed with ```iptables -A INPUT -m conntrack --ctstate INVALID -j DROP iptables -A INPUT -j REJECT``` and hopefully counters from "iptalbes -L-n -v" command will show how many INVALID packets has been dropped ``` 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable ``` didn't cross my mind to log INVALID packets :)

A.B

8/16/24, 2:12 PM

If you weren't using REJECT, don't use it. That wasn't the reason I showed this warning. The warning is only relevant when using REJECT, but is good enough to explain why you might get random invalid (if REJECT were in use, that would perhaps have killed a legitimate connection)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: IPtables uncommon packet dropping

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.