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
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
On Tue, 4 Jul 2006, martin f krafft wrote: > 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. Oskar's tutorial is really excellent, alas at some point it's outdated. First, in the 2.6 kernel tree, you can disable connection pickup via sysctl. Second, you can setup your rules anytime, regardless of 2.4/2.6, which disables connection pickup. For example: iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -A INPUT -p tcp --dport 22 --syn -j ACCEPT 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
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: Connection states information tables
On Tue, 14 Sep 2004, Lorenzo Rossi wrote: > i have a question concerning the tables where are maintained the > informations about the connections state. > I configured my firewall script with the following lines, to permit the > SSH traffic originated from the protected zone to go to Internet. > > iptables -A TCP_IN -i $INTERFACE -p tcp --sport 22 -m state --state > ESTABLISHED -J ACCEPT > > iptables -A TCP_OUT -o $INTERFACE -p tcp --dport 22 -m state --state > NEW,ESTABLISHED -j ACCEPT > > The custom chain TCP_IN is listed in the default INPUT chain. > The custom chain TCP_OUT is listed in the dafault OUTPUT chain. > The dafault policy for the INPUT and OUTPUT chains, as you can imagine, > is to DROP. > > My question is: > How many state tables are used? one table for each main chain? > One for INPUT and one for OUTPUT? A single hash and not a table contains the connections. When you load in the ip_conntrack module or it is started by the non-modular kernel, the maximal number of connections which can be stored in the hash is logged: % dmesg | grep ip_conntrack or # grep ip_conntrack /var/log/kern.log kernel: ip_conntrack version 2.1 (2043 buckets, 16344 max) - 320 bytes per conntrack ^ 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
Re: how to 'dcc'(in IRC) with iptables
On Tue, 21 May 2002, Raffael Ferenc wrote: > > If you use NAT, you have to load in the IRC nat helper module with the > > same parameters as you used at the IRC conntrack helper. > > IMHO DCC uses random unprivports, so you have to enable all ports > between 1025 and 65535 for the target ip address. (which is quite > unsecure, so use it with care) The IRC conntrack/NAT helper is responsible to handle the requested data channels on the unprivileged ports together with the state matching in netfilter/iptables. (Therefore iptables is a big step ahead compared to ipchains.) There is no need to open up all unprivileged ports at all. Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec 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: how to 'dcc'(in IRC) with iptables
On Thu, 16 May 2002, Michael Renner wrote: > On Thursday 16 May 2002 14:24, Frederik Schueler wrote: > > Hi, > > > > On Thu, May 16, 2002 at 10:34:15AM +0200, Michael Renner wrote: > > > The module 'ip_nat_irc' is loaded, I gave the parameters > > > options ip_conntrack_irc ports=,,6667,6668,6669,7000 > > > in /etc/modules.conf > > > However: the transfer won't start, neither in one, not into > > > the other direction. > > > > Try not giving any parameters at all, simply load the module and connect > > to irc. the module should show an usage of 1 in the lsmod output (your > > connection), and it should work. > > OK, I did so, but lsmod shows > hyaden:~# lsmod | grep irc > ip_nat_irc 3104 0 (unused) > ip_conntrack_irc3008 0 [ip_nat_irc] > iptable_nat20916 2 [ipt_MASQUERADE ip_nat_ftp ip_nat_irc] > ip_conntrack 20972 4 [ipt_MASQUERADE ipt_state ip_nat_ftp > ip_nat_irc ip_conntrack_irc ip_conntrack_ftp iptable_nat] If you use NAT, you have to load in the IRC nat helper module with the same parameters as you used at the IRC conntrack helper. Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec 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: NAT and H323
On Sun, 24 Feb 2002, Kálmán Czibók wrote: > I work a multi-place wide network with windows clients, firewalling > Debian. My problem is to solve pass through the firewall H323 protocol > or any other video conferencing uses 3 ports (video,audio,commands) > the best way is Netmeeting. I use NAT. I have read the simple NAT > doesnt support the H323 protocol. Is there person who can give me the > simplest way to solve this problem. I think the one way could be an > internal microsoft proxy server what shares internet access between > the internal machines and pass the appropriate ports to internal > proxy. But I know this is not the best solution. I want to solve this > with only Linux. Note I never worked this yet. Pls. give me the best > solution if you have one. In the iptables cvs in patch-o-matic you can find a H.323 helper. It is simple, but for simple cases it works well. Regards, Jozsef - E-mail : [EMAIL PROTECTED], [EMAIL PROTECTED] WWW-Home: http://www.kfki.hu/~kadlec Address : KFKI Research Institute for Particle and Nuclear Physics H-1525 Budapest 114, POB. 49, Hungary
