[CLUE-Tech] iptables not allowing the ACCEPT target?

Jed S. Baer thag at frii.com
Fri Nov 29 17:14:55 MST 2002


On Fri, 29 Nov 2002 12:08:17 -0700
David Anselmi <anselmi at americanisp.net> wrote:

> Jed S. Baer wrote:
> [...]

> No, this is unnecessary.  Here is Rusty's example for just the input
> chain:
> 
> iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
> iptables -A INPUT -m state --state NEW -i ! ppp+ -j ACCEPT
> 
> This says established/related always allowed, new only allowed from 
> non-ppp interfaces (and covers your eth0 case).  Of course you need the 
> policy set to drop:
> 
> iptables -P INPUT DROP
> 
> or
> 
> iptables -A INPUT -j DROP (after the above two lines).
> 
> You can argue that this is more complicated than your method, but it is 
> more complete as well (covers all protocols not just tcp).

But I came here for an argument!

No, you didn't.

Yes, I did!

(That's from Monty Python, in case anyone didn't get it.)

...

> Now you're back to one line and this is what you really meant to do. 
> The difference in the approaches is "drop what isn't explicitly allowed"
> or "accept what isn't explicitly denied".  The first might be marginally
> better because if you mess up allowing things they don't work (which you
> should notice).  If you mess up denying things, they come through (which
> you don't want and are less likely to notice).  For such a simple case 
> neither is much of a risk--do what suits your perspective.  But beware 
> if you start mucking with things and making them more complicated.

Well, that should teach me to try to think after consuming the requisite
quantity of turkey dinner. Yes, I see the value of using the much
simplified rulesets. I should have thought of inverting them.

Thanks, Dave.
jed

-- 
We're frogs who are getting boiled in a pot full of single-character
morphemes, and we don't notice. - Larry Wall; Perl6, Apocalypse 5



More information about the clue-tech mailing list