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
--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
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
--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
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
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
--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
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
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
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
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
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
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
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?
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
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
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
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
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
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
20 matches
Mail list logo
