1

I don't understand some basic concepts of conntrack module.

First of all, I'm sure it's enabled in my system (Ubuntu 18.04), modinfo shows info about nf_conntrack and /proc/modules file tells nf_conntrack is "live".

Second, I have the following test setup:

Machine A (192.168.1.2) <-----> Router Machine (192.168.1.1 & 192.168.2.1) <----> Machine B (192.168.2.2)

On Router Machine I have the following iptables rule:
iptables -t filter -A FORWARD -m set --match-set BlackListPort dst -j DROP

BlackListPort is an ipset table.
Now I establish an SSH connection from Machine A (1.2) to Machine B (2.2). After I confirm it works, I add port 22 (SSH default) to BlackListPort table.

SSH connection freezes/hangs until I remove port 22 from that ipset table.

Now the question: Since conntrack is present in my system, why SSH block is successful? SSH connection was established before port 22 was added to ipset so conntrack should just skip all packets, allowing SSH to work.

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
Groosha
  • 285
  • 1
  • 2
  • 9

1 Answers1

3

SSH connection was established before port 22 was added to ipset so conntrack should just skip all packets, allowing SSH to work.

This is not correct.

All packets will be processed through the filter rules, whether they belong to tracked connections or not.

It is a very common optimization of iptables rules to put something like this near the beginning of the relevant rule chain (FORWARD in your example):

iptables -t filter -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

On older distributions, you might see this version instead:

iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

(I understand the conntrack match is now preferred over the state match. I think some kernel versions even nag at you about it.)

This will allow packets belonging to existing connections through, if a connection tracking information exists for them. But the point is, you can control where exactly you put that rule, or whether you use it at all. So you can make your firewall rules care about connection states as much - or as little - as you want.

telcoM
  • 87,318
  • 3
  • 112
  • 232
  • My iptables are empty (did a reboot, nothing is restored afterwards). I did 2 tests: 1) executed `iptables -t filter -A FORWARD -p tcp --dport 22 -j DROP` and 2) executed `iptables -t filter -A FORWARD -p tcp --dport 22 -m conntrack --ctstate NEW -j DROP` (tried with NEW,ESTABLISHED,RELATED as well). In all cases my existing SSH connection was frozen until I removed that rules. – Groosha Jun 03 '19 at 14:53
  • 2
    The order of the rules matters. If you want the existing connections to keep working, you must have the rule that `ACCEPT`s packets that are part of `ESTABLISHED` connections **before** the rule that targets all packets going to destination port 22 and `DROP`s them. – telcoM Jun 03 '19 at 15:09