On a random day I was googling iptables rules to harden my desktop, and came across this post[1]. At some point the guide mentions blocking invalid TCP packets using tcp-modules with these rules;

iptables -A INPUT -p tcp -m tcp --tcp-flags ALL FIN,PSH,URG -j DROP

iptables -A INPUT -p tcp -m tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

iptables -A INPUT -p tcp -m conntrack --ctstate NEW -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -j DROP

I pressed return on the above commands and the rules were applied successfully. Then I tried replacing the tcp portions on each of the commands with udp for eg, in case of the 3rd command I'd do,

iptables -A INPUT -p udp -m conntrack --ctstate NEW -m udp ! --udp-flags FIN,SYN,RST,ACK SYN -j DROP

Which returned me an error saying these rules are not valid for udp packets. I am on a Debian OS, Kernel version 4.9.x

The article I was reading online

  1. https://www.booleanworld.com/depth-guide-iptables-linux-firewall/
  • Also see this article. – Aaron D. Marasco Sep 22 '20 at 22:52
  • 1
    UDP is a little like throwing a stone over a wall and then walk away. UDP is datagram so one single blob while TCP is a stream (ie like a stream of water.) The other thing is that TCP uses a three-state protocol to establish and verifying integrity of transfer including notifying if something is missing. – Stefan Skoglund Sep 22 '20 at 23:06

TCP is a stateful protocol, UDP is stateless, so you cannot use ctstate with it.

Either you let traffic for a particular port for UDP or you don't.

Also --udp-flags FIN,SYN,RST,ACK SYN is just pure nonsense.

In short familiarize yourself with TCP/IP and UDP a bit before rushing to set up iptables.

  • One can use --ctstate with UDP packets. That's how one allows for example a DNS reply to a DNS query using -m conntrack --ctstate ESTABLISHED. conntrack keeps a state also for UDP. Of course the rest is correct. – A.B Nov 1 '20 at 20:37
  • @A.B I'm not sure --ctstate for UDP packets actually works - have you tested it? – Artem S. Tashkinov Nov 1 '20 at 21:13
  • Of course, did you? – A.B Nov 1 '20 at 21:20
  • I haven't as I've no idea how it can be tested in the first place especially for services which use protocols other than what's known and can be easily tested, e.g. DNS. – Artem S. Tashkinov Nov 1 '20 at 22:24
  • Just know that conntrack keeps udp (or icmp or any other protocol) states just like tcp. The difference is that the state is destroyed only with a timeout (initially 30s then more if traffic was seen both directions), while, still in conntrack's point of view, tcp's connection can be closed by a valid tcp fin or tcp rst. tcp's timeout once established, defaults to several days, so it's rarely the cause of the end of a connection state in conntrack. – A.B Nov 1 '20 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.