65

Part of a firewall on a server :

iptables -A INPUT -p tcp --dport 22 -m state NEW --state -m recent --set

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 100 --hitcount 10 -j DROP

When I search online I always see NEW being used in that rule but I'm having a hard time understanding why ESTABLISHED and RELATED aren't being used.

Like this :

iptables -A INPUT -p tcp --dport 22 -m state NEW,ESTABLISHED,RELATED --state -m recent --set

iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED,RELATED -m recent --update --seconds 100 --hitcount 10 -j DROP

Can someone explain to me when exactly a NEW packet changes into ESTABLISHED and RELATED ?

EEAA
  • 108,414
  • 18
  • 172
  • 242
Kris
  • 1,347
  • 3
  • 15
  • 16

2 Answers2

67

Consider a NEW packet a telephone call before the receiver has picked up. An ESTABLISHED packet is their, "Hello." And a RELATED packet would be if you were calling to tell them about an e-mail you were about to send them. (The e-mail being RELATED.)

In case my analogy isn't so great, I personlly think the man pages handles it well:

NEW -- meaning that the packet has started a new connection, or otherwise associated with a connection which has not seen packets in both directions, and

ESTABLISHED -- meaning that the packet is associated with a connection which has seen packets in both directions,

RELATED -- meaning that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error.

iptables(8) - Linux man page

Aaron Copley
  • 12,345
  • 5
  • 46
  • 67
  • 15
    Out of curiousity, do you know how it determines RELATED packets? Is there some mechanism that applications can use to signal to iptables that a connection will be a related connection, or is it purely part of the stateful part of iptables? – Matthew Scharley Mar 19 '12 at 22:22
  • 11
    It's handled by a series of kernel modules called ip_conntrack_*, each written for a particular protocol that uses unrelated connections (such as FTP). To answer your question, I think you would need to load a similar module for your application. – Kyle Smith Mar 19 '12 at 22:34
  • 4
    Ok, thank you. But going back to the rule with NEW in it, isn't it possible a packet can be made to look like it's already ESTABLISHED and is therefor not blocked by the rule ? – Kris Mar 20 '12 at 08:13
  • 2
    @Kris: It's pretty hard to fake outgoing packets, so by the wording of the man page in the answer, I don't see how. You are correct that it's possible to fake a packet which looks like it's bound for an open connection, but even without a firewall, the TCP stack would just drop the packet on the floor if it didn't already know about an open connection from the sender. If this is on a firewall on a router, it's still possible to maintain this state by inspecting `SYN`/`ACK`/`RST`/etc packets as they pass through the router, and I'd expect iptables to do this. – Matthew Scharley Mar 21 '12 at 02:41
  • 3
    @Kris: Something similar to this (albeigit not technically identical) is used by VNC Software like TeamViewer to tunnel through firewalls/routers. The process is called **hole-punching**. In short you have a host PC (which might be behind a restricting firewall) that you want to connect to from a different device (via the internet). Both PCs open an individual connection to a separate server (e.g. the TeamViewer Server), which "mediates" between them, so it looks to their firewalls as if the packets are related, and thereby those PCs are able to establish a separate connection with each other. – Levite Jul 28 '14 at 10:21
  • 2
    Considering that protocols that resolve communication details of the lower layers within the higher layers (e.g. application), such as FTP, are becoming "out of fashion" and the "related" state opens many doors for possible exploits (*e.g. if any of the app specific moduls you mention, that figure out what "related" means for a given app, has an error in it, then that error can be exploited*) would it be safe to say that one should, by default, **not** allow related connections except when having a issue with a protocol (and then only allow "related" for that protocol)? – omni May 01 '18 at 17:33
  • 1
    would the entire tcp handshake fall under `NEW` or would acknowledge handshake packets fall under `RELATED`? – rassa45 Jun 27 '19 at 05:01
  • @ytpillai, the answe is here: https://www.linuxtopia.org/Linux_Firewall_iptables/x1414.html where it says only the incoming SYN packet is considered NEW, and everything that follows is considered ESTABLISHED. – Sam Sirry Mar 09 '20 at 19:46
24

Asumming for both server and client a restrictive INPUT and open OUTPUT, i.e.:

iptables -P INPUT DROP
iptables -P OUTPUT ACCEPT

And from iptables-extensions(8) over the example of FTP in active mode:

1. NEW

NEW The packet has started a new connection or otherwise associated with a connection which has not seen packets in both directions.

The client on port 50000 (any random unprivileged port) connects to FTP server on port 21, the server would need at least this to accept this incoming connection:

iptables -A INPUT --dport 21 -m state --state NEW -j ACCEPT

2. ESTABLISHED

ESTABLISHED The packet is associated with a connection which has seen packets in both directions.

Now on the client side, he opened an outgoing connection to server on port 21 using a local port 50000 and he needs the following iptables to allow the response to arrive from server (21) to client (50000):

sudo iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

3. RELATED

RELATED The packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer or an ICMP error.

Now after the FTP connection has been established and a data connection is about to be performed, client will open a server socket (yes, with active FTP client becomes a server for the data connection) on port 60000 (to my understanding client will mark this port 60000 as RELATED to the other connection from 50000->21) and will send this port number to server using the FTP PORT command. Then the FTP server will open a new connection from its port 20 to port 60000 on the client, and well, client now requires the following to allow this new connection to succeed:

sudo iptables -A INPUT -m state --state RELATED -j ACCEPT

Finally, for this to work you need to enable ip_conntrack_ftp kernel module to allow the system to mark connections/packages as RELATED (this is my understanding, I haven't digged on this too much):

modprobe ip_conntrack_ftp
Jaime Hablutzel
  • 416
  • 4
  • 10
  • established only requires previously locally originated unidirectional flow, not tcp 3-way handshake, is my understanding correct? – sdaffa23fdsf May 18 '17 at 15:19
  • 1
    Thanks for the answer, for established you said " iptables to allow the response to arrive from server (21) to client (50000)" if it is FROM server to client why is it INPUT and not OUTPUT ? – Medya Dec 25 '17 at 20:29
  • @Medya, because from the client perspective, packets sent from server(21) to client(50000) are incoming packets, so for the client it is an `INPUT`. – Jaime Hablutzel Jan 02 '18 at 17:49
  • This answer is talking about iptables rules on both sides of a connection, and this is confusing if the reader didn't pay attention. – Sam Sirry Mar 09 '20 at 19:41