I base this solely on my observation and did not descend into sources until now. But I am nearby sure that I had not tried to establish an ftp connection to the site named in my original post. Even if so, following your remarks, should the ftp-conntrack helper expose arbitrary ports on the originating host? Until today my understanding of this matter was, that the difference between related and established states would be, that within ESTABLISHED state ip-address and port are considered pairwise, while within RELATED state only ip-addresses are considered, making the described attack possible. When this should be principally wrong (id est: only describing a somehow messed reality but not the intention), then I would expect the rub whithin NAT helper code. Perhaps we could setup a test case? My equipment here has changed, and for the moment I have no shell access to my DSL router at the internet front. Best Regards Hugo Mildenberger Am Freitag 13 April 2007 13:30 schrieb Cedric Blancher: > Le vendredi 13 avril 2007 à 12:02 +0200, Hugo Mildenberger a écrit : > > "iptables -A INPUT -m state --state ESTABLISHED, RELATED - j ACCEPT" > > This means to allow inbound connections having nothing in common with the > > initiating outbound connection, except for the ip-address pair used by > > the initiating connection, leaving your nominal firewalled systems > > exposed to any malicious site you accidentally stumble on, whereas using > > "ESTABLISHED" alone here would restrict connections to be outbound only. > > On what ground do you base this statement ? AFAIK, RELATED state applies > to: > > . expectations created by protocol helpers such as FTP or IRC, > that therefore have "something in common with the initiating > outbound connection"; > . ICMP errors that match an existing conntrack entry, that again > have a relation with previously allowed connections. > > Behaviour you're referring to applies to the first category. As I have > not check the code recently, could you specificly point some modules > that create such unexpected and lax expectations ? Thoses would indeed > be a serious security issue to me.
