Re: Firewall-troubleshooting
On 5 Jul 2005, Michael Stone wrote:
> On Tue, Jul 05, 2005 at 10:00:53PM +1000, Daniel Pittman wrote:
>> /sbin/iptables -t filter -A in_world_http_s1 -p tcp --sport 1024:65535
>> --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT /sbin/iptables
>> -t filter -A out_world_http_s1 -p tcp --sport 80 --dport 1024:65535 -m
>> state --state ESTABLISHED -j ACCEPT
>
> IMHO, this is fairly redundant (and inefficient) unless you don't trust
> your firewall. (And in that case, why use it?) The examples of things
> that might require additional checking (e.g., ftp data connection) are
> arguably valid valid, but those are *RELATED* sessions, not
> *ESTABLISHED* sessions.
I probably should have posted an example that actually used RELATED
connections, I guess.
As to trusting the firewall, or not, there has been at least one bug
where attackers could manipulate the content of the conntrack expect
table remotely. Other bugs, local or remote, are not out of the
question.
> If you're going to do something like the above you're better off just
> unloading the state module and setting up port filters (which is
> effectively what you're doing).
An example with RELATED involved would have been more helpful, I guess.
Anyway, I think we disagree about the value of this - I have less faith
in the implementation than you do, which is fine, and see an advantage
in the extra work to check ESTABLISHED things are going to the right
place.
Regards,
Daniel
--
When you are a Bear of Very Little Brain, and you Think of Things, you find
sometimes that a Thing which seemed very Thingish inside you is quite
different when it gets out into the open and has other people looking at it.
-- A.A.Milne, _The House at Pooh Corner_, 1928
Reply to: