Well, two packets, right? ICMP_Echo_Request i.e. is an ICMP packet, that like, say, goes out from ure box to the one u're pinging. The pinged machine will reply with a 2nd packet ICMP_Echo_Reply So like, you will send out an ICMP packet and you will recieve an ICMP packet. Im no netfilter xpert but like I can imagine that if program tracks outgoing ICMP packets and like creates entries in some table, then it could look this table up to see if the ICMP packet coming in (say its an Echo_Reply) could have been triggered by the machine it is addressed to (through an Echo_Request, of course). If there is an entry in the table, then netfilter could let the ICMP packet pass. If theres no entry in the table, then either noone actually requested that packet or the ping simply took to long to complete (I guess theres a timeout removing table entries which havent been referred to in the past (n) minutes) and thus gets discarded. Correct me if Im wrong =P cheers gridrun .-. /v\ L I N U X // \\ >Phear the Penguin< /( )\ ^^-^^ Marco Ahrendt <marco.ahrendt@ad To: Bjoern Engels <bengels@lanworks.de> consys.de> cc: suse-security@suse.de Subject: Re: [suse-security] SuSEfirewall2 / iptables 03.04.2001 13:30 On Tue, Apr 03, 2001 at 08:18:21AM +0200, Bjoern Engels wrote:
Connection tracking doesn't use flags to determine
<... SNIP> I don´t think so. According to some threads in netfilter-ml the connection tracking code currently requires a udp packet in both directions before considering a connection to be established. Therefor how it is possible to conntrack icmp if there are only 2 packets? Ping and reply for example? Marco -- Marco Ahrendt phone : +49-341-98-474-0 adconsys AG fax : +49-341-98-474-59 Karl-Liebknecht-Str. 19 email : marco.ahrendt@adconsys.de 04107 Leipzig/Germany gnupg key at www.aktex.net/marco_work.asc --------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
On Tue, Apr 03, 2001 at 02:01:44PM +0200, christian.burri@synecta.ch wrote:
(through an Echo_Request, of course). If there is an entry in the table, then netfilter could let the ICMP packet pass. If theres no entry in the table, then either noone actually requested that packet or the ping simply took to long to complete (I guess theres a timeout removing table entries which havent been referred to in the past (n) minutes) and thus gets discarded.
Correct me if Im wrong =P
argl.. ;-) After reading the manpage 2-3 times I had found it. [...] no known connection, ESTABLISHED meaning that the packet is associated with a connection which has seen packets in both directions, NEW meaning that the packet has started a new connection, or other wise associated with a connection which has not seen packets in both directions, and RELATED mean ing that the packet is starting a new connection, but is associated with an existing connection, such as an FTP data transfer, or an ICMP error. [...] I assume, using --state ESTABLISHED is senseless on icmp packets. Only matching --state RELATED packets is the solve for accepting icmp-errors for an already outgoing icmp-packet like icmp-echo-request. ;-) Marco -- Marco Ahrendt phone : +49-341-98-474-0 adconsys AG fax : +49-341-98-474-59 Karl-Liebknecht-Str. 19 email : marco.ahrendt@adconsys.de 04107 Leipzig/Germany gnupg key at www.aktex.net/marco_work.asc
participants (2)
-
christian.burri@synecta.ch
-
Marco Ahrendt