3

I have the following setup: in /etc/iptables/rules.v4

# Generated by iptables-save v1.4.21 on Mon Jul  1 11:32:00 2019
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [3:620]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -s 192.168.35.107/32 -p icmp -m icmp --icmp-type 8 -j DROP
-A INPUT -s 192.168.35.0/24 -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -s 192.168.35.0/24 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -j DROP
COMMIT
# Completed on Mon Jul  1 11:32:00 2019

from above we see that I want to block ping from specific IP. After I save rules with iptables-restore < /etc/iptables/rules.v4, and I list rules with iptables -L, I can conclude that computer with ip 192.168.35.107 is unable to ping the server.

However, the computer with that IP is able to ping indefinitely until I break the session. Even after I break the ping I still need to make ~60 seconds pause until I am unable to ping again. If I make 5-10 seconds pause between ping command the firewall let me through.

Funnily enough when I enable ping through the iptables it works immediately. I have tried with the Samba port 445 as well. Same.

Is there a way to make iptables dropped ports immidiately effective?

spaceman117X
  • 370
  • 2
  • 6
  • 17
  • 2
    `-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT` is to blame. This rule allows any established (running) connection as well as any related ones to run even if another rules prohibit. removing this line should give you desired result. – Bart Jul 01 '19 at 14:01
  • 4
    Well not remove, but move it below the DROP rules that should take priority, as explained in the answer below.. – Jonas Berlin Jul 01 '19 at 14:10
  • Works! that line is of course "Allow related and already established connections" – spaceman117X Jul 05 '19 at 14:51

2 Answers2

5

You're experiencing that behavior because your system has the netfilter's connection tracking system (the nf_conntrack* family of modules) enabled and your --state RELATED,ESTABLISHED rule (obviously set to ACCEPT) is placed before the ping's specific DROP rule.

The -m state rules, as well as the more fine-grained -m conntrack rules, rely on the connection-tracking system which also tracks protocols such as UDP and ICMP even though these are technically not connection-oriented. It tracks those protocols by building a "connection" entry in its list with a default expiry timeout. These default values can be queried and set through the specific files under /proc/sys/net/netfilter/, typically those named nf_conntrack_*_timeout.

Being ICMP a connection-less protocol, the connection-tracking system has no way to detect when any such "connection" really has finished, and thus can only rely on a timeout-driven heuristic. Therefore, as long as there is an entry in the connection-tracking-list matching your source-ip/destination-ip icmp "conversation", any -m state --state ESTABLISHED rule will match that traffic, in your case ACCEPTing it as per your particular rule.

The "~60 seconds" timeout you notice should actually be 30 seconds as this is usually the default value for /proc/sys/net/netfilter/nf_conntrack_icmp_timeout. However it may have been changed by just echoing a different value into that file.

Note also that values in those files are for new "connections" from then on. To see current entries as known by the connection-tracking system, along with their current expiring timeout, you can use the conntrack command, which you may need to install. Using that command you can also modify or delete the entries.

Is there a way to make iptables dropped ports immidiately effective?

The simplest way is to always place DROP rules before the -m state ACCEPT rule.

One alternative might be: each time you add a DROP rule, also run a respective conntrack command to delete currently active entries.

LL3
  • 5,270
  • 7
  • 20
1

That happens because you still have an entry in the connection table for that host, and the iptables utility will not flush it or mess with it in any way when adding or removing its rules.

For that, you should install the conntrack(8) utility, which can be used to manipulate the kernel's live connection tracking table. It's using a netlink socket interface for that, which offers functionality not available via /proc or other means.

For example, conntrack -F will flush all connections, conntrack -D --dst=8.8.8.8 will delete all entries with that destination, conntrack -D --src=192.168.35.107 will delete all entries with that source, etc.

It's readily installable on most distros with eg. apt-get install conntrack, yum install conntrack, etc.