[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