All of lore.kernel.org
 help / color / mirror / Atom feed
From: /dev/rob0 <rob0@gmx.co.uk>
To: NetFilter <netfilter@lists.netfilter.org>
Subject: Re: Firewall feature recommendation
Date: Fri, 24 Jun 2005 08:26:14 -0500	[thread overview]
Message-ID: <200506240826.14769.rob0@gmx.co.uk> (raw)
In-Reply-To: <fad9d48405062403562537f546@mail.gmail.com>

On Friday 24 June 2005 05:56, Kenneth Kalmer wrote:
> I've built several iptables-based firewalls for some clients and
> personal use. Some of them are horrors, now that I look back on

I can identify with that. :) But none of my firewalls (the ones that 
worked, I mean) were as bad as the ones they replaced.

I was forced to learn iptables, because some of the sites I managed 
couldn't get by with something off-the-shelf. Slowly over the years, 
the light came on for me.

> them... I want to build my own 'all-in-one' firewall for the most
> common network setups I use...

I wrote a pretty simple one aimed at home SNAT/MASQ users. I also wrote 
a grotesque, complex one which tried to implement DNAT support and a 
*relatively* simple config file.

> I've used various other GPL'ed scripts 
> for references in past firewalls and they do tend to open one's eyes

Some of them are good. Some are horrid, ipchains-style, or worse. 
Unfortunately Sourceforge and Freshmeat do not have a "Clue filter" to 
prevent incompetent people from posting their wares.

> a bit, thanks for everyone who released their scripts under the GPL.

Thanks to those who released GOOD scripts. :)

> I understand iptables, so that's covered. I'm constantly researching
> security cause it's so damn interesting to see the precautions some
> people take, and the level of protection you yourself would never
> even have dreamed about...

The nice thing about iptables is that a very strong firewall can be 
quite simple. Deny everything by default, allow in just what you want.

> Now, these are the features (independent of implementation) that I've
> considered to put into my firewall:
> - Support for multiple interfaces on both LAN & WAN

Is this common? It's very complex. I have 3 sites now with dual 
redundant and load-balanced external interfaces. At these sites I've 
abandoned the idea of maintaining a script. I built the initial rules 
with a script and then edited the iptables-save(8) output to suit.

I find this much easier to manage. A slight drawback is that some DNS 
names might resolve to different IP's, and iptables-save uses IP's 
only. But iptables-restore(8) can use hostnames, so I just change them 
in the rules file.

> - NAT & DMZ

Yes.

> - Black lists for inbound & outbound traffic

We don't do much of this. We *do* use DNS poisoning for certain known 
"ratware"/virus domains such as gator.com.

> - Host services (global or per interface, allows seperation between
> LAN & WAN services)

Separation is important. My older firewalls didn't do that.

> - Access control on MAC, IP, or MAC-IP pairing
> - Administrative services (SSH) access control on MAC or MAC-IP
> pairing

I have dabbled in this, but it's not worth a lot of effort. Determined, 
capable attackers can easily bypass this, security through obscurity 
notwithstanding. An incompetent attacker is easily defeated with either 
MAC or IP controls.

> - Managed logging

I do little or no logging, usually only for specific temporary 
debugging. Too much noise, even with --limit.

> - Expansion through custom chains*
>
> * Expansion through custom chains might help those often found
> scenarios that render your standard firewall inoperable. By creating
> say, a PREINPUT chain or POSTINPUT chain, another script can modify
> that chain for any function not covered by the standard firewall
> features.

Even so, misplaced rules could be ignored, or worse, break it. :)

> Please remember, this discussion is intended to be about features,
> not implementation. I'll cross that bridge when I get there...
>
> Any suggestions & advice would be appreciated.

Perhaps I'm not really understanding what you're after. Personally, I 
gave up on the idea of one-size-fits-all firewalls. I haven't been 
there in a long time, but I used to read news:comp.os.linux.networking, 
and the number of users whose problems would be solved by "service 
iptables stop" was very high.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header


  reply	other threads:[~2005-06-24 13:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-24 10:56 Firewall feature recommendation Kenneth Kalmer
2005-06-24 13:26 ` /dev/rob0 [this message]
2005-06-24 13:36   ` Carl Holtje ;021;vcsg6;
2005-06-24 13:45     ` /dev/rob0
2005-06-24 14:04       ` Carl Holtje ;021;vcsg6;
2005-06-24 14:12         ` Seferovic Edvin
2005-06-24 14:12         ` /dev/rob0
2005-06-24 14:32           ` /dev/rob0
2005-06-24 14:37             ` Jan Engelhardt
2005-06-24 14:53               ` /dev/rob0
2005-06-24 15:20                 ` Carl Holtje ;021;vcsg6;
2005-06-24 15:23             ` Carl Holtje ;021;vcsg6;
2005-06-24 17:49               ` /dev/rob0
2005-06-24 15:12   ` Kenneth Kalmer
2005-06-24 13:44 ` John A. Sullivan III

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=200506240826.14769.rob0@gmx.co.uk \
    --to=rob0@gmx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.