iptables: using ESTABLISHED and RELATED together seems dangerous
Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
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.
SDN 101: An Introduction to Software Defined Networking
Discover the advantages of SDN.
SDN has quickly become one of the hottest trends in IT. But not all SDN solutions offer real software-defined functionality. As more enterprises consider SDN, they want to know, “What is SDN? And what are the real benefits?” If you're ready to explore the advantages of SDN, and want to know how it should be implemented within your enterprise, start by reading our introductory white paper.
Click Here to receive this Complete Guide absolutely free.
iptables: using ESTABLISHED and RELATED together seems dangerous
I've seen packets coming to my computer through a DD-WRTv24s2 gateway above port 32K several times. I have iptables (using fwbuilder locally) both places. My desktop stops the packets. But I'm guessing the problem is as I described in the title for this post. Yes?
If you ESTABLISH a connection to some webpage, and you just accept ESTABLISHED or RELATED datagrams in rule 1 of your iptables, what will keep incoming TCP from that (presumably nefarious) site from going straight to your desktop like the building firewall isn't there?? If the site wants to connect to you above 32k, or portscan you, its RELATED correct? They know your IP. You've ESTABLISHED a connection.
If my guess is correct, it would seem wiser to NEVER use these together. Better to ACCEPT all ESTABLISHED. And if something is RELATED, then ACCEPT it only if its the data connection on FTP or individually by service or protocol.
Could someone disabuse me of my paranoia on this
...or even better, tell me I'm right
Thanks to all commentators.
Click here to see the post LQ members have rated as the most helpful post in this thread.
I'm afraid your guess is incorrect, in that you've not got what a "RELATED" packet specifically is. Merely having the same source does not make it related in any way, it's for specific protocols which require multiple ports which are assigned dynamically. The best example is FTP where incoming traffic initially hits port 21 on a server, and so a rule says "allow incoming port 21 requests" however this connection is *ONLY* for controlling the ftp session, not transferring data, and part of that control is to agree a separate pair of ports acros which to actually transfer the data. As these ports can be anything, there is no way to make a *SPECIFIC* rule for the ftp data. As such conntrack modules inspect this type of traffic and see what ports are agreed within the traffic flow. That agreed rule is then tracked by iptables and allowed as a "RELATED" stream. Now you've mentioned FTP but as above, how do you know that the incoming TCP SYN to port 4827 is FTP? At that stage it's nothing at all, just a SYN, what do you do with it? You're either expecting it via conntrack or it's just random traffic to ignore. Note that once a SYN that is allowed from a "RELATED" connection, and the handshake completes, that stream is now no longer "RELATED" but "ESTABLISHED" so can in principle sever knowledge of the connection tracking.
Last edited by acid_kewpie; 04-16-2011 at 01:37 AM.
Hmmm...so I think I need a list of RELATEDness for all or many of the various protocols/services. I guess this is the purpose of the helper functions in /etc/xtable/ .
Funny thing is that I've seen these packets from various places waltzing through the DDWRT like its not there. On one occassion, I saw a multitude of DROPped packets, possibly in response to NTP traffic go right through the firewall (but not my custome iptable).
Also, these immune packets stop coming as soon as I leave an "infected" site (or advert), if that is the correct word. Something seems broke.
I wish I could duplicate the phenomenon for you.
TBH, there is no such gaping whole in iptables logic. You may well be seeing things you don't understand, but there will be reasons for it that someone else can probably explain very easily. If iptables is running then traffic will ONLY get through if there is a suitable rule to permit it (unless you have a default ACCEPT policy which is not the norm at all), so if you're seeing traffic get through, your rule base is permitting it somewhere.
The more I think about this, the more I think I need some doc(s) describing exactly what "RELATED" means.
e.g. is ICMP "RELATED"? So if I have ping turned off, the fact I've visited some site means they could try to explore my my net topology...if ICMP is RELATED.
What about SCTP? SNMP? IGMP broadcasts? What's related to DNS? etc.
Yeah do you need more explanation huh? It doesn't make sense to say that "ICMP is RELATED", related to what? There has to be some form of traffic which either defines within its payload that other form of traffic are expected, or (I think) is implicitly covered. The other good example, after FTP, are various VoiP protocols, where, for example, Cisco's SCCP protocol runs on port 2000 and is used to *control* the establishment of RTP audio streams. The streams themselves can run on all sorts of ports, and a firewall, be it iptables or a hardware firewall like a Cisco ASA of a Juniper ISG needs to look at the data *inside* the SCCP traffic, which is permitted using a standard port based rule, and then extract the end points relevant to the audio stream. A further subtlety of the VoiP example is that the RTP sessions are going to and from a central server (the PBX) whereas the RTP audio stream will actually go direct between two IP phones. So not only do all relevant firewalls need to know the ports for the RTP but the two endpoints which until the voice data is being sent will never have actually communicated directly at all. So the audio can only flow between the devices if the RTP streams are known to be related to the RTP control data. The alternative if this knowledge can not be known, e.g. firewalls uncapable of reading the SCCP data, or a device between the two phones that just never sees the RTP data (as the three devices make a triangle, there could well be devices unable to know due to not being on the route of either RTP stream), then such applications are often forced to used a more restrictive range of ports, so permanently allowing only 10 listed ports for RTP instead of a possible 50,000, or use alternative setup flows, e.g. Active vs Passive FTP where the establishment of the data flow is in a different direction - from the server instead of from the client, meaning you can decide to allow your server to always go out instead of an anonymous client coming in.
As far as ICMP does go, it might be relevant to related traffic, although I'm not actually sure (it may be more engrained and low level...) as if you attempt to establish a UDP traffic stream to a remote point and something fails, e.g. a firewall deny or a lack of anything listening at the other end on the port, then you'll often get certain forms of ICMP messages (e.g. ICMP unreachable) sent back from the end device. This is not UDP traffic, so is not a simple reply to what would be deemed to be an ESTABLISHED connection by all relevant devices. So I assume that within iptables land these ICMP messages would be accepted as RELATED to the UDP stream. (But that might not be true and could well be so deep inside how UDP is specified it's done differently).
For your other examples, nothing is ever related to snmp, dns. THey are simple transactional request / response protocols (mostly) so never need additional streams. As for SCTP I don't actually know squat about it so won't comment.
Note that it's pretty uncommon to require knowledge of related traffic. FTP was, coincidentally, 40 years old this week so is pretty archaic in its design and has additional streams due to the simplicity of it's design (in a time where there was no such thing as a firewall) whereas a modern replacement, SFTP just uses a single connection on TCP port 22, so requires no such special treatment. As above, VoiP is a different thing as different systems are involved in different parts of the call, so can't share a single point to point connection.
Last edited by acid_kewpie; 04-16-2011 at 11:47 AM.