Re: Firewall-troubleshooting

[Daniel Pittman <daniel@rimspace.net>]

On 4 Jul 2005, Paul Gear wrote:
> Daniel Pittman wrote:
>> ...
>>> Am i right in understanding that you consider accepting
>>> RELATED/ESTABLISHED packets a bad thing?
>>
>>
>> No. Accepting *any* RELATED/ESTABLISHED packets is, though, if someone
>> finds an attack to generate entries in the conntrack table.  Like, say,
>> the active FTP NAT PORT bug from quite some time ago, which would allow
>> remote attackers to do just that. :)
>>
>> Limiting the RELATED/ESTABLISHED packets to what you actually expect
>> (part of an established connection to a service you actually use) is a
>> more secure policy.
>
> I mustn't be understanding you here.  Isn't the very definition of
> RELATED/ESTABLISHED that the packet is part of an established connection
> to a service actually used?

I think I explained very badly:  firehol restricts, by default, to
matching on E/R packets *and* the permissible service ports, so that
even if someone trick the system into expecting connections on a port
you didn't open, the packets are not allowed through.

The FTP 'PORT' bug I talk about above did allow this:  by sending an
appropriately formatted PORT string through an FTP connection,
*anything* could be made into a 'RELATED' connection.

So, if they wanted to talk to your SMB service, connect to FTP, send the
string, then the blanket allow of RELATED packets would allow them to
connect to the SMB server.


Firehol would, by default, not have permitted that -- they could have
created the 'RELATED' entry in the conntrack table, but the firewall
would (probably[1]) still have refuse it, because RELATED packets to
that specific port were not allowed.


I hope that is clearer, and you can see where the difference in approach
comes from now.

> How would you expect a RELATED/ESTABLISHED rule to be used, and how does
> this contrast with the way that shorewall or the OP's script works (i'm
> not sure which one you're inferring is not using RELATED/ESTABLISHED in
> the preferred way)?

I can't comment on how shorewall works, because I have not looked at its
code in the last year, or longer.  Some of the similar scripts still
stick a single allow for any E/R packet at the top, though.

Most iptables documentation suggests the same, so I don't think it is
particularly bad of the authors of these scripts.  God knows I didn't do
anything different when I had to write it all out by hand.

	Daniel

Footnotes: 
[1]  Some services you allow might have made it possible by allowing
     connections to this port.

-- 
We do not talk--we bludgeon one another with facts and theories gleaned
from cursory readings of newspapers, magazines, and digests.
        -- Henry Miller, _The Air-Conditioned Nightmare_ (1945)