RELATED connections and the feeling of security

RELATED connections and the feeling of security

[Hugo Mildenberger]

Sifting through a workstation firewall log file some time ago, I stumbled on 
an ip-address translating to a webserver of a well known German newspaper 
(actually it was www.faz.net) which apparently had tried to intiate a 
connection to port 80 of my workstation, which itself was sitting behind an 
NATing router running an iptables based firewall on top of linux.

But it  was not iptables, who prevented this form of professional curiosity, 
it was the windows firewall running on the workstation itself, who stopped 
and disclosed it.

Looking at my iptables rule set, I asked myself, why all over the world nearby 
everybody suggests inexperienced users to allow connections based 
on "RELATED" state. You can find  literally thousands of such well-meant 
hints: oh, you need a firewall setup, here it is:

"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.

Also the "Shorewall" firewall ruleset actually builds upon "RELATED" state, 
and has dropped any provisions it made in earlier revisions to switch off 
this feature at least optionally. 

I felt alienated when I noticed a certain thread concerning that very same 
issue on Tom Eastep's "Shorewall" site. A user (not me), who had complained 
about this insecure prerequisite was informed by Mr. Eastep personally, that 
he had the choice either to use Shorewall and accept those related inbound
connections, or not to use shorewall at all.

The balance is: What kind of security a SPI firewall product provides, when 
each host you contact from inside is able to invade your private network 
within a few milliseconds? Most users are not aware that following the simple 
ruleset once proposed in a popular netfilter FAQ leads to a system showing 
the behavior of a molten polarity protection diode: you would not notice it 
just until the moment someone permutes the poles.


Best Regards

Hugo Mildenberger

Re: RELATED connections and the feeling of security

[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.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: RELATED connections and the feeling of security

[Hugo Mildenberger]

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.

Re: RELATED connections and the feeling of security

[Cedric Blancher]

Le vendredi 13 avril 2007 à 14:57 +0200, Hugo Mildenberger a écrit :
> 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?

There's a few conntrack helper around: FTP, IRC, H323, SIP, etc.

> 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.

No that's not.

> 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.

The very first step to me is reliably reproducing your issue.


-- 
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: RELATED connections and the feeling of security

[Pascal Hambourg]

Hello,

Hugo Mildenberger a écrit :
> should the ftp-conntrack helper expose arbitrary ports on 
> the originating host?

Yes it should, for the following two reasons :
1) The host explicitly asked for it over the FTP control connection.
2) The firewall administrator allowed it by loading the FTP conntrack 
module.

Re: RELATED connections and the feeling of security

[tom]

Hugo Mildenberger wrote:
> Sifting through a workstation firewall log file some time ago, I stumbled on 
> an ip-address translating to a webserver of a well known German newspaper 
> (actually it was www.faz.net) which apparently had tried to intiate a 
> connection to port 80 of my workstation, which itself was sitting behind an 
> NATing router running an iptables based firewall on top of linux.
>
> But it  was not iptables, who prevented this form of professional curiosity, 
> it was the windows firewall running on the workstation itself, who stopped 
> and disclosed it.
>
> Looking at my iptables rule set, I asked myself, why all over the world nearby 
> everybody suggests inexperienced users to allow connections based 
> on "RELATED" state. You can find  literally thousands of such well-meant 
> hints: oh, you need a firewall setup, here it is:
>
> "iptables -A INPUT -m state --state ESTABLISHED, RELATED - j ACCEPT"
>   
Could it be related to the syntax error above hehe
> 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.
>
> Also the "Shorewall" firewall ruleset actually builds upon "RELATED" state, 
> and has dropped any provisions it made in earlier revisions to switch off 
> this feature at least optionally. 
>
> I felt alienated when I noticed a certain thread concerning that very same 
> issue on Tom Eastep's "Shorewall" site. A user (not me), who had complained 
> about this insecure prerequisite was informed by Mr. Eastep personally, that 
> he had the choice either to use Shorewall and accept those related inbound
> connections, or not to use shorewall at all.
>
> The balance is: What kind of security a SPI firewall product provides, when 
> each host you contact from inside is able to invade your private network 
> within a few milliseconds? Most users are not aware that following the simple 
> ruleset once proposed in a popular netfilter FAQ leads to a system showing 
> the behavior of a molten polarity protection diode: you would not notice it 
> just until the moment someone permutes the poles.
>
>
> Best Regards
>
> Hugo Mildenberger
>
>   

Re: RELATED connections and the feeling of security

[Hugo Mildenberger]

Am Freitag 13 April 2007 16:31 schrieben Sie:
>There's a few conntrack helper around: FTP, IRC, H323, SIP, etc.

Clearly, but of these, I use only FTP, if any.

> The very first step to me is reliably reproducing your issue.

This is what I tried meanwhile. The result (gained manually by means of 
a telnet client while having established a ssh session in the opposite 
direction) is completely negative: netfilter actually turns down reverse 
directed packets even if RELATED state is configured as acceptable.

It's somewhat hard to admit, but for truth's sake: I must have misinterpreted 
an unusual windows firewall log entry. On  certain conditions, most probably 
when the loading of a web page is interrupted somehow, the receiving socket 
is already shut down while the server still continues sending. Apparently 
because the Windows firewall had started blocking the socket's associated 
port, he drops a message which roughly reads :

"2007-0X-0X 09:XX:XX DROP TCP 193.227.146.1 192.168.XXX.XXX 80 1369 XXXX A 
XXXX XXX - - - RECEIVE"

I probably  -- I don't have the old logs around -- saw only  the DROP, a known 
server's source address and port number 80. But this actually was the source 
port, and the local destination port the number behind it, that port, which 
was closed shortly before. Sorry for any inconvenience.


Best Regards

Hugo Mildenberger

Re: RELATED connections and the feeling of security

[Martijn Lievaart]

Pascal Hambourg wrote:
> Hello,
>
> Hugo Mildenberger a écrit :
>> should the ftp-conntrack helper expose arbitrary ports on the
>> originating host?
>
> Yes it should, for the following two reasons :
> 1) The host explicitly asked for it over the FTP control connection.
> 2) The firewall administrator allowed it by loading the FTP conntrack
> module.
>

No, not arbitrary ports. The port asked for in the port command should
be opened (and it is).

M4

Re: RELATED connections and the feeling of security

[Pascal Hambourg]

Martijn Lievaart a écrit :
>>
>>> should the ftp-conntrack helper expose arbitrary ports on the 
>>> originating host?
>>
>> Yes it should, for the following two reasons :
>> 1) The host explicitly asked for it over the FTP control connection.
>> 2) The firewall administrator allowed it by loading the FTP conntrack 
>> module.
> 
> No, not arbitrary ports. The port asked for in the port command should 
> be opened (and it is).

I took "arbitrary" as "arbitrarily chosen by the host".