Re: ssh connection survives reboot of stateful iptables router
Hi All! On Tue, 2006-07-04 at 09:56 +0200, martin f krafft wrote: Many people have rules like -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT I've done research and found that -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT is the same, meaning that the INVALID state matches all non-SYN packets at this point. For the same, you must replace the second line with this: -A INPUT -m conntrack --cstate NEW ! --syn -j DROP Or for sure, use both line. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
--On Dienstag, Juli 04, 2006 18:56:44 +0200 martin f krafft [EMAIL PROTECTED] wrote: [...] I understand the fundamental issue very well. The things that can go wrong here are: - I accidentally delete or comment out one of the drop rules - drop ! NEW doesn't do the same as !drop NEW due to a bug - the universe folds in on itself Are there any other ones I am overlooking? How about One rule fails to load for obscure reasons. ? There might be a syntax change in a future release which conflicts with one of your rules. Or an extension might not be available after a kernel upgrade and cause one rule to fail to load. The invocation of iptables loading one rule might fail because some other process temporarily consumes to many ressources. This is no exhaustive list ... Ralf Döblitz
Re: ssh connection survives reboot of stateful iptables router
also sprach Ralf Döblitz [EMAIL PROTECTED] [2006.07.05.0835 +0200]: The things that can go wrong here are: - I accidentally delete or comment out one of the drop rules - drop ! NEW doesn't do the same as !drop NEW due to a bug - the universe folds in on itself Are there any other ones I am overlooking? How about One rule fails to load for obscure reasons. ? iptables-restore, which is what I used, fortunately uses a transaction to commit new rules. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system the only real advantage to punk music is that nobody can whistle it. signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
--On Montag, Juli 03, 2006 23:52:38 +0200 martin f krafft [EMAIL PROTECTED] wrote: I was surprised today to find an SSH connection from my LAN to the 'Net surviving a power cycle of my router -- a laptop running sarge with kernel 2.6 and iptables. I have the following two rules first thing in the FORWARD chain: -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP to me, this means that SYN packets may pass to the actual rules, and packets belonging to a connection known to the router are accepted. Any packets not belonging to an stablished connection or opening a related connection fall through to the actual filtering rules. During the reboot, the router surely forgot about the existing connections, so why can the SSH connection persist? Is there some Linux magic going on? After reboot the packets of your SSH connection were not known to belong to an established connection but fell through to your set of filter rules. I am sure that they were accepted there, resulting in acceptance of further packets of this connection as ESTABLISHED. Ralf Döblitz
Re: ssh connection survives reboot of stateful iptables router
also sprach Ralf Döblitz [EMAIL PROTECTED] [2006.07.04.0927 +0200]: After reboot the packets of your SSH connection were not known to belong to an established connection but fell through to your set of filter rules. How? I load the DROP rules before the ACCEPT ones. I can't think of a way this would be possible. am sure that they were accepted there, Yes, if they ever got there. Many people have rules like -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT I've done research and found that -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT is the same, meaning that the INVALID state matches all non-SYN packets at this point. Still surprised, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system in a country where the sole employer is the state, opposition means death by slow starvation. the old principle: who does not work shall not eat, has been replaced by a new one: who does not obey shall not eat. -- leon trotsky, 1937 signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
Am Monday 03 July 2006 22:52 schrieb martin f krafft: I was surprised today to find an SSH connection from my LAN to the 'Net surviving a power cycle of my router -- a laptop running sarge with kernel 2.6 and iptables. I have the following two rules first thing in the FORWARD chain: -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP to me, this means that SYN packets may pass to the actual rules, and packets belonging to a connection known to the router are accepted. During the reboot, the router surely forgot about the existing connections, so why can the SSH connection persist? Is there some Linux magic going on? That must be connection pickup. At http://iptables-tutorial.frozentux.net/iptables-tutorial.html search for pickup. with best regards, Rene -- - Gibraltar firewall http://www.gibraltar.at/ pgpljNpclx1bA.pgp Description: PGP signature
Re: ssh connection survives reboot of stateful iptables router
--On Dienstag, Juli 04, 2006 09:56:26 +0200 martin f krafft [EMAIL PROTECTED] wrote: also sprach Ralf Döblitz [EMAIL PROTECTED] [2006.07.04.0927 +0200]: After reboot the packets of your SSH connection were not known to belong to an established connection but fell through to your set of filter rules. How? I load the DROP rules before the ACCEPT ones. I can't think of a way this would be possible. am sure that they were accepted there, Yes, if they ever got there. Many people have rules like -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT I've done research and found that -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT is the same, meaning that the INVALID state matches all non-SYN packets at this point. ACK, the packets should have been dropped by the INVALID match, my mistake. Ralf Döblitz
Re: ssh connection survives reboot of stateful iptables router
also sprach Rene Mayrhofer [EMAIL PROTECTED] [2006.07.04.1013 +0200]: That must be connection pickup. At http://iptables-tutorial.frozentux.net/iptables-tutorial.html search for pickup. Excellent pointer, and yet another reason why we should really be looking for alternatives to the Linux kernel. The default, without the tcp-window-tracking patch, is to have this behaviour, and is not changeable. So what's the point of iptables and statefulness in the end? It keeps track of connections and lets packets belonging to established connections passed, but if there's an ACK packet that doesn't belong anywhere, iptables is kind enough to invite it to the club? So then, if I run e.g. cups on 0.0.0.0 and used the firewall rules to make sure that no external clients can connect to it (say, because I was too lazy to modify cupsd.conf), an attacker just has to send an ACK packet to the socket, iptables will throw open the doors, and let the connection in? Reminds me of Microsoft Bob, which would, after three invalid password entries, ask you whether you wanted to change your password. Or is there some actual benefit I am overseeing? The FAQ does say it's after a failover only, but no mention over how long. So, NetBSD... one step closer... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system i never travel without my diary. one should always have something sensational to read on the train. -- oscar wilde signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
On Tue, 4 Jul 2006, martin f krafft wrote: Many people have rules like -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT I've done research and found that -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT is the same, meaning that the INVALID state matches all non-SYN packets at this point. That's plain false: the INVALID state does not match all non-SYN packets at that point. It's nowhere written or stated in any decent documentation. Best regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
also sprach Jozsef Kadlecsik [EMAIL PROTECTED] [2006.07.04.1130 +0200]: is the same, meaning that the INVALID state matches all non-SYN packets at this point. That's plain false: the INVALID state does not match all non-SYN packets at that point. It's nowhere written or stated in any decent documentation. Let me get this straight: http://www.faqs.org/docs/iptables/userlandstates.html The INVALID state means that the packet can not be identified or that it does not have any state. From what I was told, a packet that is not ESTABLISHED or RELATED, but does not have the SYN bit set cannot be identified and thus has no state. I seem to recall it was actually an iptables developer who told me that INVALID = ALL - (ESTABLISHED + RELATED + NEW). -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system linux: because a pc is a terrible thing to waste signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
On Tue, 4 Jul 2006, martin f krafft wrote: also sprach Jozsef Kadlecsik [EMAIL PROTECTED] [2006.07.04.1130 +0200]: is the same, meaning that the INVALID state matches all non-SYN packets at this point. That's plain false: the INVALID state does not match all non-SYN packets at that point. It's nowhere written or stated in any decent documentation. Let me get this straight: http://www.faqs.org/docs/iptables/userlandstates.html The INVALID state means that the packet can not be identified or that it does not have any state. From what I was told, a packet that is not ESTABLISHED or RELATED, but does not have the SYN bit set cannot be identified and thus has no state. That is false, because from connection tracking point of view a plain ACK packet which does not belong to any existing connections has got a state, which is NEW. That is why connection pickup can work. I seem to recall it was actually an iptables developer who told me that INVALID = ALL - (ESTABLISHED + RELATED + NEW). And that is correct. Best regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
Hello, martin f krafft a écrit : Many people have rules like -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT I'd add a condition on state NEW in the second rule. I've done research and found that -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT This way of building rulesets, first blocking bad packets and then accepting good packets assuming that bad packets were already blocked, is wrong. What happens when, for any reason you might imagine, the rule which is supposed to block first is ineffective ? Your firewall has a hole. The right way is accepting the good packets first and then dropping the rest. is the same, meaning that the INVALID state matches all non-SYN packets at this point. No, it's not the same at all. - First ruleset : TCP packets with SYN flag are accepted whatever state they are in. - Second ruleset : TCP packets in state other than INVALID are accepted, whatever TCP flags they have. You must not assume that --syn and state NEW are equivalent. Depending on the TCP conntrack behaviour, they're not. Actually the old conntrack does not really care about the SYN flag. Actually, both rulesets are wrong. What you want is a combination that takes the best of each (state NEW *and* SYN flag) : -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -p tcp --syn --dport 22 -j ACCEPT -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
also sprach Jozsef Kadlecsik [EMAIL PROTECTED] [2006.07.04.1143 +0200]: That is false, because from connection tracking point of view a plain ACK packet which does not belong to any existing connections has got a state, which is NEW. That is why connection pickup can work. Yeah, and so it's not INVALID. I did not know about connection tracking, but other than that, the following two are equivalent, no? accept ESTABLISHED,RELATED drop INVALID accept --dport 22 drop and accept ESTABLISHED,RELATED accept --dport 22 --syn drop -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system if you have built castles in the air, your work need not be lost; that is where they should be. now put the foundations under them. -- henry david thoreau signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
also sprach Pascal Hambourg [EMAIL PROTECTED] [2006.07.04.1143 +0200]: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 --syn -j ACCEPT I'd add a condition on state NEW in the second rule. What's the difference between state NEW and --syn? This way of building rulesets, first blocking bad packets and then accepting good packets assuming that bad packets were already blocked, is wrong. What happens when, for any reason you might imagine, the rule which is supposed to block first is ineffective ? Your firewall has a hole. The right way is accepting the good packets first and then dropping the rest. You are absolutely right. However, I wonder whether that hole you're mentioning doesn't already exist anyway, thanks to the feature of connection pickup. Actually, both rulesets are wrong. What you want is a combination that takes the best of each (state NEW *and* SYN flag) : -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -p tcp --syn --dport 22 -j ACCEPT Okay. So a good way to do this would be: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -p tcp --syn -j open-tcp-ports -A INPUT -m conntrack --ctstate NEW -p udp -j open-udp-ports -A open-tcp-ports --dport 22 -j ACCEPT ... ? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system i don't think so, said rene descartes. just then, he vanished. signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
On Tue, 4 Jul 2006, martin f krafft wrote: also sprach Jozsef Kadlecsik [EMAIL PROTECTED] [2006.07.04.1143 +0200]: That is false, because from connection tracking point of view a plain ACK packet which does not belong to any existing connections has got a state, which is NEW. That is why connection pickup can work. Yeah, and so it's not INVALID. I did not know about connection tracking, but other than that, the following two are equivalent, no? accept ESTABLISHED,RELATED drop INVALID accept --dport 22 drop and accept ESTABLISHED,RELATED accept --dport 22 --syn drop No. In the first case you drop INVALID packets (actually, broken ones: invalid flag-combinations, bad checksum, etc.) and accept any packet targetting port 22. In the second case you accept SYN packets sent to port 22. Best regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
martin f krafft a écrit : What's the difference between state NEW and --syn? NEW is based on the packet state as seen by the connection tracking system. --syn is based on the value of TCP flags in the packet header. So NEW and --syn must be considered independent, even though the TCP conntrack internally uses the TCP flags. You are absolutely right. However, I wonder whether that hole you're mentioning doesn't already exist anyway, thanks to the feature of connection pickup. No. The hole exist in your ruleset because you made wrong assumptions about how the TCP conntrack works. Okay. So a good way to do this would be: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -p tcp --syn -j open-tcp-ports -A INPUT -m conntrack --ctstate NEW -p udp -j open-udp-ports -A open-tcp-ports --dport 22 -j ACCEPT Yes. You just need to add the protocol match (-p tcp) again, because the --dport match is valid only with TCP and UDP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
also sprach Pascal Hambourg [EMAIL PROTECTED] [2006.07.04.1222 +0200]: -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -m conntrack --ctstate NEW -p tcp --syn -j open-tcp-ports -A INPUT -m conntrack --ctstate NEW -p udp -j open-udp-ports -A open-tcp-ports --dport 22 -j ACCEPT Yes. You just need to add the protocol match (-p tcp) again, because the --dport match is valid only with TCP and UDP. Right. One other question before I go and try out what I learnt today: on the basis that it's not okay to drop bad packets before accepting good packets, the following would not be okay even though they're logically equivalent? accept ESTABLISHED,RELATED drop INVALID accept NEW --dport ssh --syn drop and accept ESTABLISHED,RELATED drop INVALID drop ! NEW drop ! --syn accept --dport ssh drop ? Thanks guys for your patience. ... and I thought I had moderately understood this stuff. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system an intellectual is someone who has found something more interesting than sex. -- edgar wallace signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
also sprach Pascal Hambourg [EMAIL PROTECTED] [2006.07.04.1505 +0200]: accept ESTABLISHED,RELATED drop INVALID drop ! NEW drop ! --syn accept --dport ssh drop Very bad ! The accept rule relies on previous drop rules. I understand the fundamental issue very well. The things that can go wrong here are: - I accidentally delete or comment out one of the drop rules - drop ! NEW doesn't do the same as !drop NEW due to a bug - the universe folds in on itself Are there any other ones I am overlooking? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system a cigarette a day will make you fly away. signature.asc Description: Digital signature (GPG/PGP)
Re: ssh connection survives reboot of stateful iptables router
On Monday 03 July 2006 18:52, martin f krafft wrote: I was surprised today to find an SSH connection from my LAN to the 'Net surviving a power cycle of my router -- a laptop running sarge with kernel 2.6 and iptables. I have the following two rules first thing in the FORWARD chain: -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP to me, this means that SYN packets may pass to the actual rules, and packets belonging to a connection known to the router are accepted. During the reboot, the router surely forgot about the existing connections, so why can the SSH connection persist? Is there some Linux magic going on? Since I have experimented something similar, I add to the question: My ssh connections survived for some minutes if I dis-connected/reconnected with my old dialup days. It obviuosly changed IP address. How is that possible? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ssh connection survives reboot of stateful iptables router
Felipe Figueiredo [EMAIL PROTECTED] writes: On Monday 03 July 2006 18:52, martin f krafft wrote: I was surprised today to find an SSH connection from my LAN to the 'Net surviving a power cycle of my router -- a laptop running sarge with kernel 2.6 and iptables. I have the following two rules first thing in the FORWARD chain: -A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A FORWARD -m conntrack --ctstate INVALID -j DROP to me, this means that SYN packets may pass to the actual rules, and packets belonging to a connection known to the router are accepted. During the reboot, the router surely forgot about the existing connections, so why can the SSH connection persist? Is there some Linux magic going on? Since I have experimented something similar, I add to the question: My ssh connections survived for some minutes if I dis-connected/reconnected with my old dialup days. It obviuosly changed IP address. How is that possible? It isn't. You probably had the same IP address after reconnecting, so your session continued. If you changed IP address then the ssh connection would fail to work, but it may take some minutes for the TCP stack to give up on the connection, creating an illusion that it continued to be connected. I can't comment on the issue the OP raised, but I can note that I have had SSH sessions cut by having a stateful Linux firewall between the endpoints reset. Daniel -- Digital Infrastructure Solutions -- making IT simple, stable and secure Phone: 0401 155 707email: [EMAIL PROTECTED] http://digital-infrastructure.com.au/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
