Firewall structure and more (Newbie)

Firewall structure and more (Newbie)

[Erik Wikström]

Hi there

I've got a small home network of 4 computers plus one acting as
router/firewall using iptables. The way it's set up today is very
simple: Masquerading and some forwarded ports.

I've read quite a number of guides and tutorials on using iptables and
netfilter but they all fall in one of two groups, an explaination of all
the parameters and arguments for iptables or a walkthrough of the script
that the author uses. The first kind is good in so much that I now feel
more or less familiar with iptables and the workings of netfilter and
the other kind might be good for those who doesn't want to bother too
much.

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?

How many rules should there be in a chain to compensate for the chain?
(Cause there are some overhead for each chain right?)

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.

--
Erik Wikström

Re: Firewall structure and more (Newbie)

[Antony Stone]

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.

Re: Firewall structure and more (Newbie)

[James Sneeringer]

On Thu, Jul 08, 2004 at 07:10:16PM +0200, Erik Wikstr?m wrote:
> 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

How you structure your rules and chains is entirely up to you, and depends
on your specific needs.  However, in general you should set up your rules
and chains so the kernel has to do as little work as possible.  Sometimes
this isn't possible, but in practice, you can usually break up large chains
into smaller ones.  For example, this isn't a long chain, but it illustrates
the point.

    iptables -A FORWARD -p tcp -s 10.0.0.2 --dport 80 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.0.0.2 --dport 25 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.0.0.2 --dport 110 -j ACCEPT

    iptables -A FORWARD -p tcp -s 10.0.0.3 --dport 80 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.0.0.3 --dport 25 -j ACCEPT
    iptables -A FORWARD -p tcp -s 10.0.0.3 --dport 110 -j ACCEPT

Instead, you might do something like this:

    iptables -N CHECK_PORTS

    iptables -A FORWARD -s 10.0.0.2 -j CHECK_PORTS
    iptables -A FORWARD -s 10.0.0.3 -j CHECK_PORTS

    iptables -A CHECK_PORTS -p tcp --dport 80 -j ACCEPT
    iptables -A CHECK_PORTS -p tcp --dport 25 -j ACCEPT
    iptables -A CHECK_PORTS -p tcp --dport 110 -j ACCEPT
    iptables -A CHECK_PORTS -j RETURN

For a case where 10.0.0.3 wants to go to port 25, the first set of rules
requires the kernel to evaluate 5 rules.  The second example only requires
evaluation of 3 rules.  It's also a bit more modular and makes it simpler
to grant the same access to another IP in the future.

> Which leads to my questions: What do you think of this structure? What
> would you do?
> 
> How many rules should there be in a chain to compensate for the chain?
> (Cause there are some overhead for each chain right?)

Unless you're doing this on a 386 with 4 MB RAM, the overhead of each
individual chain isn't worth worrying about.

> 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.

Personally, I use the state module, and I block all inbound traffic by
default.  The only permitted inbound traffic is stuff that matches state
ESTABLISHED,RELATED, and thinks like tcp/25 to my mail server.  For what
ut's worth, I have no custom chains on my firewall (486dx2/66, 32 MB RAM).
My FORWARD chain has about 60 rules in it, and performance is just fine.

-James

Re: Firewall structure and more (Newbie)

[Erik Wikström]

On Thu, Jul 08, 2004 at 06:28:49PM +0100, Antony Stone wrote:

> On Thursday 08 July 2004 6:10 pm, Erik Wikström wrote:
> 
> 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.)

My thought was that by sorting the packets by type at first and then
make a more througout filtering I would avoid the overhead of having,
for example, a UDP packet go through a lot of rules concerning TCP-
packets. But, as you say it leads to a quite complicated structure, but
since the firewall is quite old (75MHz) and a lot of P2P traffic is
passing through I thought that it might have some value.

--
Erik Wikström

Re: Firewall structure and more (Newbie)

[Antony Stone]

On Thursday 08 July 2004 7:07 pm, Erik Wikström wrote:

> On Thu, Jul 08, 2004 at 06:28:49PM +0100, Antony Stone wrote:
> > On Thursday 08 July 2004 6:10 pm, Erik Wikström wrote:
> >
> > 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.)
>
> My thought was that by sorting the packets by type at first and then
> make a more througout filtering I would avoid the overhead of having,
> for example, a UDP packet go through a lot of rules concerning TCP-
> packets. But, as you say it leads to a quite complicated structure, but
> since the firewall is quite old (75MHz) and a lot of P2P traffic is
> passing through I thought that it might have some value.

Well, a good policy is to have the rules which match the most packets at the 
top of the ruleset (so that most packets pass through a small number of rules 
before being matched).   This is why the stateful rule "-m state --state 
ESTABLISHED,RELATED" is the very first rule in most people's rulesets.

A good way to find out what order to put the rules in is to guess, and then 
after some reasonable amount of traffic has passed through the firewall, use 
"iptables -L -nvx" to see the packet / byte counters in the first two 
columns.   Rearrange your rules so that the ones with the highest packet (not 
byte) counts come first, and you have a pretty optimum design.

Regards,

Antony.

-- 
There's no such thing as bad weather - only the wrong clothes.

 - Billy Connolly

                                                     Please reply to the list;
                                                           please don't CC me.