Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a strange problem with a Linux box running kernel 2.4.20 and
iptables 1.2.7a:
I am setting up a firewall using three interfaces: eth0-2
eth0 is attached to the router (untrusted) zone, eth1 to
the internal (trusted) zone and eth2 to the DMZ.
I have a rule that allowes traffic from the untrusted
zone (eth0) to a box in the DMZ (eth2). I do NOT have
a corresponding rule that allows traffic back from the
box in the DMZ to the untrusted zone. I only have a
rule that allows connections that are in the related or
established state back.
eg:
iptables -A untrusted_dmz -p tcp -d $ssh_box --dport 22 -j ACCEPT
iptables -A dmz_untrusted -m state --state RELATED,ESTABLISHED -j ACCEPT
Default policy on all chains/tables is DROP.
For some very weird reason, the resulting connetion from my $ssh_box
is allowed back through the firewall, and according to
/proc/netip_conntrack the state of the connection is ESTABLISHED.
This is clearly contra to the iptables documentation that states that a
tcp connection reaches the ESTABLISHED state once the complete 3-way tcp
handshake is completed. Or is syn+ack replies on syn packets also considered
by the state machine to be RELATED??
This is clearly problematic when trying to write a tight ruleset, and will leave
me with a situation of a stateless FW like ipchains.
1. What do you mean writing "the resulting connetion from my $ssh_box" ?
2. I believe your iptable rules set is long. So it is very difficult to consider what is wrong not seeing them. On the other hand I don't ask about all of them since nobody reads a long listing. Try to extract and post the most important subset.
3. What is more you are using user-define chains "untrusted_dmz" & "dmz_untrusted" without information when they acts.
So sorry, I think nobody will be able to help you.
I have never studied the iptables very deeply. So my knowledge is based on docs & current experience. On the other hand I've never had problems and doubts with iptables therefore there was no necessity for me to make any investigations with this subject.
Regarding your questions:
-ESTABLISHED is like the name states: connection established in tcp meaning
-RELATED - all the connections being initiated by accepted connection or being established as a result of existing connection
As you know for instance ftp uses passive or active mode; using state RELATED you can allow active mode to be serviced correctly;
I believe this state service has to be (and it is) implemented not in general way (like ESTABLISHED which can be detected by packet content trace) but for each protocol separately and currently is implemented for well known ones only since 'related' can mean everything (but for well known protocols is defined very precisely).
A SYN-ACK in response to a connection originating SYN would be considered an ESTABLISHED connection. RELATED connections are a little something different, like the example Doriann33 used with a ftp control channel handing off the connection to a data channel.
To qualify as an ESTABLISHED connection, a packet does not have to follow a complete 3-way TCP handshake, everything from the first SYN-ACK response on would be considered to be part of the ESTABLISHED connection. The terminology is a little confusing as in TCP networking-speak a 3-way handshake is necessary for a connection to be considered ESTABLISHED. Hope that helps.
The only source I've known is a Rusty's netfilter description. Over there is a very little definition for both interesting 'states'. Let me quote it:
Quote:
ESTABLISHED
A packet which belongs to an existing connection (i.e., a reply packet, or outgoing packet on a connection which has seen replies).
RELATED
A packet which is related to, but not part of, an existing connection, such as an ICMP error, or (with the FTP module inserted), a packet establishing an ftp data connection.
Capt_Caveman: I would be obliged if you post something more about the source of the information you presented above. I would be nice to learn much more...
In the RedHat Firewall book (sorry, don't have it here at work for the proper credits) it states that the ESTABLISHED state does NOT have the same meaning as "established" in TCP. What it does mean is that SYN and SYN/ACK packets have been exchanged. (This is what Capt Caveman said).
To repeat...
The state ESTABLISHED has a different definition in IPTABLES than it does in normal TCP networking.
Connection tracking's perspective on the state table
We just talked a lot about tcp connection states. Now let's think about this from the perspective of the connection tracking:
Connection tracking only knows about NEW, ESTABLISHED, RELATED and INVALID, classified as described above and in the iptables manpage. To quote Joszef Kadlecsik, who helped me out with a confusion I had initially about this very subject:
When a packet with the SYN+ACK flags set arrrives in response to a packet with SYN set the connection tracking thinks: "I have been just seeing a packet with SYN+ACK which answers a SYN I had previously seen, so this is an ESTABLISHED connection."
The important point here is that the conntrack states are not equivalent to tcp states. We have already seen that a connection doesn't achieve the tcp connection status of ESTABLISHED until the ACK after the SYN+ACK has been seen by the connection tracking module.
There's also a good (though basic) description in the book "Red Hat Linux Firewalls":
Quote:
The state of a connection is changed from NEW to Established whenever the server responds. The term established does not have it's usual TCP/IP meaning, which is a TCP connection having completed a three-way handshake <SNIP>. Instead, the first datagram that establishes two-way communication is deemed to have established the connection.
Doesn't seem to be well documented overall. My guess is it's one of those things that you kind of take for granted and don't put much thought into. For kicks, you can play around with the state table and a packet generator like hping. See what sending various combinations of packets through does to the connection state. It does make sense in terms of network control, otherwise you'd have to explicity write a rule to allow incoming SYN-ACK packets in response to outgoing SYNs on top of allowing ESTABLISHED connections through.
---EDIT---
I believe that last quote is from the same book JordanH is talking about. He got that one in while I was digging it up. Looks like great minds do think alike or at least buy the same books
Last edited by Capt_Caveman; 11-17-2003 at 08:10 AM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.