Michael Stone wrote: > On Mon, Jul 04, 2005 at 07:45:47PM +1000, Paul Gear wrote: > >> 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? > > > RELATED and ESTABLISHED are two different things. You've defined > ESTABLISTED. You're missing my point. I understand the difference between related and established. I was oversimplifying for the sake of clarity. What i'm trying to work out is what Daniel is meaning when he says: > It also tends to encourage "shortcuts" in the firewall, like accepting > any RELATED/ESTABLISHED packets, because each option in the > configuration file is actually an "if" statement around a bit of hand > crafted firewall. and: > 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. Or more to the point, how is Daniel suggesting to structure rules to make more secure use of RELATED/ESTABLISHED? Is it something to do with the ordering of rules, or perhaps splitting related and established and putting them at different points in the chains? -- Paul <http://paulgear.webhop.net> -- Did you know? Email viruses spread using addresses they find on the host computer. You can help to reduce the spread of these viruses by using Bcc: instead of To: on mass mailings, or using mailing list software such as mailman (http://www.list.org/) instead.
Description: OpenPGP digital signature