On Thursday 08 July 2004 6:10 pm, Erik Wikström wrote:
> But what I do lack is a guide on how to structure your firewall, what
> chains to create and what to put in them. So far the best structure I've
> come up with considers 3 (or 5) senarios. The first being packets arive
> from the net with the firewall as destination. Second being packets from
> the firewall, then you have to consider different rules depending on the
> destination (LAN or not). And the third scenario, of course, is packets
> passing through on their way to or from the LAN, again different rules
> depending on destination.
>
> My idea is to create 3 chains for each scenario, one for tcp, one for
> udp and one for icmp. And maybe some more like one for port forwarding
> or so. But that's an awful lot of rules and some of them might contain
> only one or two rules
>
> Which leads to my questions: What do you think of this structure? What
> would you do?
I think this structure is more complex than needed, and the complexity won't
make it easier to understand.
What would I do? I would put the rules for packets entering the firewall
into the INPUT chain, I'd put the rules for packets leaving the firewall in
the OUTPUT chain, and I'd put rules for packets going through the firewall
into the FORWARD chain :)
I know that may sound trite, but that is what I would do. If one or more of
the chains then ended up looking overly-complicated, I would consider
breaking out some of the rules into user-defined chains, but I would base
those chains on the source or destination of the packets, not on whether they
were TCP, UDP, ICMP or something else.
I would turn the question around to you: why do you think it is better to have
the rules arranged into different chains as you have suggested? Do you
think that is easier to understand? (If you *do* find it easier to
understand, then go ahead and do it, don't do what *I* find easy to work
with.)
> I'm also open to suggestions for things to block, and maybe suggestions
> on rules to do so, like ping of death and other known problems.
What to block? Everything you don't know you want to allow. That is
standard security practice - don't think about what to DROP in the firewall;
DROP everything (default policy) and then ACCEPT what you want (with the
rules).
Ping of death? Well, why allow ping packets at all? Why should anyone out
on the Internet be able to ping your firewall or your internal machines?
The same principle applies to many vulnerabilities - if a service isn't
needed, just block it completely.
Hope this helps,
Antony.
--
The difference between theory and practice is that in theory there is no
difference, whereas in practice there is.
Please reply to the list;
please don't CC me.
