Re: [RFC] Re: another netfilter ICMP bug
Hi, It looks like the Netfilter has problems with the NATed icmp-administration messsages. The original IP can be leaked into the public network from the protected area. [...] don't forget that ICMP error messages only quote the first 64 bytes of the original packet. Adding up IP and TCP headers (both 20 bytes without options), you only have 24 bytes of original payload. This might be somewhat more in UDP though due to its shorter header. A full length PORT command is 28 bytes, though a common scenario fits into 24 bytes. I see two solutions: * truncate the packet, and remove the payload area of deNATed ICMP messages, if the inner header is either TCP or UDP (because in this case we _KNOW_ what is header and what is payload) * don't use packet filtering if separating the two zones is so important The first one could also be implemented using an ICMPTRIM target in your mangle table, which could also trim ICMP echo request/reply payloads. (which can easily be used to tunnel a whole IP stack through a firewall) Ok, I didn't know the IPv4-ICMP RFC. I just sent a special packet with TCP payload and I got back the payload. It was only a first check. (In IPv6-ICMP the length-limit is ~1298 bytes, ...) kisza -- Andras Kis-Szabo Security Development, Design and Audit -/Zorp, NetFilter and IPv6 [EMAIL PROTECTED] /-Member of the BUTE-MIS-SEARCHlab--
Re: [RFC] Re: another netfilter ICMP bug
On 30 May 2002, Andras Kis-Szabo wrote: don't forget that ICMP error messages only quote the first 64 bytes of the original packet. Adding up IP and TCP headers (both 20 bytes without options), you only have 24 bytes of original payload. This might be somewhat more in UDP though due to its shorter header. A full length PORT command is 28 bytes, though a common scenario fits into 24 bytes. I see two solutions: * truncate the packet, and remove the payload area of deNATed ICMP messages, if the inner header is either TCP or UDP (because in this case we _KNOW_ what is header and what is payload) * don't use packet filtering if separating the two zones is so important The first one could also be implemented using an ICMPTRIM target in your mangle table, which could also trim ICMP echo request/reply payloads. (which can easily be used to tunnel a whole IP stack through a firewall) Ok, I didn't know the IPv4-ICMP RFC. I just sent a special packet with TCP payload and I got back the payload. It was only a first check. (In IPv6-ICMP the length-limit is ~1298 bytes, ...) Sidenote: ICMPTRIP could not be used to trim ICMP echo requests/replies: The data received in the echo message must be returned in the echo reply message. 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
Re: another netfilter ICMP bug
On Thu, May 23, 2002 at 10:18:23AM +0200, Balazs Scheidler wrote: Hi, I've encountered another ICMP translation problem in netfilter. This time it occurs when a process initiates a connection and it is translated on the same host. are you sure this problem persists, even after applying the icmp nat fix? Bazsi -- Live long and prosper - Harald Welte / [EMAIL PROTECTED] http://www.gnumonks.org/ GCS/E/IT d- s-: a-- C+++ UL$ P+++ L$ E--- W- N++ o? K- w--- O- M+ V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
Re: another netfilter ICMP bug
On Thu, May 23, 2002 at 07:03:52PM +0200, Harald Welte wrote: On Thu, May 23, 2002 at 10:18:23AM +0200, Balazs Scheidler wrote: Hi, I've encountered another ICMP translation problem in netfilter. This time it occurs when a process initiates a connection and it is translated on the same host. are you sure this problem persists, even after applying the icmp nat fix? yes, I've forgotten to mention that I first applied the patch, and the problem persisted. (btw: a plain .diff file for the mentioned fix would make it much easier to apply the patch, I had to cut paste it from the .html) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
