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.
> (boxb was using ipchains in my case therefore the ipchains command line)
> boxb# ipchains -s 10.0.0.0/24 -d 0/0 80 -j REJECT
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.
The ICMP DNAT advisory fixed one of them, and there's an another one.
My question is:
what's about the internal information?
The ICMP administration packets contain the original packet in their
payload area. There're several core protocols (and newer ones, too)
which contain IP information in their payload area (ex.: ftp, irc/dcc).
These addresses are changed when the helper of the protocol is loaded,
but what happens when the packet causes a problem? The changed packet
will travel back to the original host (it's in the payload of the icmp
error message!). In this scenario the ICMP administration protocol
family acts as a tunnel :(
Example (wild) scenario:
an attacker and a protected ftp server (netfilter and an IDS).
The atatcker starts a connection to the FTP server. He logs in with
user/pass. The u/p pair valid on the ftp server, but the connection
denied by the NIDS (or policy enforcer, ...) and the IDS adds a REJECT
rule to the FW of the server.
Then the attacker sends a 'PORT ip,ip,ip,ip,port,port'. The outer
Netfilter will translate the ips into an internal one, but the server
will reject with the modified IPs.
(It1s only an example, i know the ftp works in different way [but it can
be work with malicious ftp server and SNAT])
Regards,
kisza
--
Andras Kis-Szabo Security Development, Design and Audit
-------------------------/ Zorp, NetFilter and IPv6
[EMAIL PROTECTED] /-----Member of the BUTE-MIS-SEARCHlab------>
