Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Antony Stone <Antony@Soft-Solutions.co.uk>
To: netfilter@lists.netfilter.org
Subject: Re: Firewall structure and more (Newbie)
Date: Thu, 8 Jul 2004 18:28:49 +0100	[thread overview]
Message-ID: <200407081828.49545.Antony@Soft-Solutions.co.uk> (raw)
In-Reply-To: <20040708171016.GA16115@itstud.chalmers.se>

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.



  reply	other threads:[~2004-07-08 17:28 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-08 17:10 Firewall structure and more (Newbie) Erik Wikström
2004-07-08 17:28 ` Antony Stone [this message]
2004-07-08 18:07   ` Erik Wikström
2004-07-08 18:16     ` Antony Stone
2004-07-08 17:47 ` James Sneeringer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200407081828.49545.Antony@Soft-Solutions.co.uk \
    --to=antony@soft-solutions.co.uk \
    --cc=netfilter@lists.netfilter.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox