Firewall feature recommendation

Firewall feature recommendation

[Kenneth Kalmer]

Guys

I've built several iptables-based firewalls for some clients and
personal use. Some of them are horrors, now that I look back on
them... I want to build my own 'all-in-one' firewall for the most
common network setups I use... I've used various other GPL'ed scripts
for references in past firewalls and they do tend to open one's eyes a
bit, thanks for everyone who released their scripts under the GPL.

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

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
- NAT & DMZ
- Black lists for inbound & outbound traffic
- Host services (global or per interface, allows seperation between
LAN & WAN services)
- Access control on MAC, IP, or MAC-IP pairing
- Administrative services (SSH) access control on MAC or MAC-IP pairing
- VPN (IPSec, PPTP & SSL)
- QoS
- ICMP control
- Managed logging
- 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.

I've got the "Modular Firewall Product Certification Criteria version
4.1" from ICSAlabs, but I've not had any time to investigate it yet.

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.

Kind regards

-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com

Folding@home stats
http://vspx27.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer

Re: Firewall feature recommendation

[/dev/rob0]

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

Re: Firewall feature recommendation

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, /dev/rob0 wrote:

> On Friday 24 June 2005 05:56, Kenneth Kalmer wrote:
> > - 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.

Sorry to jump in half-way through, but how do you do this?

I'm looking for a solution better than editing /etc/hosts that I can apply
to a small network..

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don't."

Re: Firewall feature recommendation

[/dev/rob0]

On Friday 24 June 2005 08:36, Carl Holtje ;021;vcsg6; wrote:
> > > - 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.
>
> Sorry to jump in half-way through, but how do you do this?
>
> I'm looking for a solution better than editing /etc/hosts that I can
> apply to a small network..

BIND 9, transparent DNS proxying for clients to force them into our 
local nameserver, where we have a simple null zone file which is loaded 
as master for each blocked domain. It points a wildcard "A" at an 
internal IP.

Among other things, that internal machine runs a Web server. When we 
first started doing this, its apache logs were inundated with 404's as 
the now-stranded spyware attempted to phone home.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Firewall feature recommendation

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, /dev/rob0 wrote:

> On Friday 24 June 2005 08:36, Carl Holtje ;021;vcsg6; wrote:
> > > > - 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.
> >
> > Sorry to jump in half-way through, but how do you do this?
> >
> > I'm looking for a solution better than editing /etc/hosts that I can
> > apply to a small network..
>
> BIND 9, transparent DNS proxying for clients to force them into our
> local nameserver, where we have a simple null zone file which is loaded
> as master for each blocked domain. It points a wildcard "A" at an
> internal IP.

Would you be so kind as to post a randomly-selected zone file for our
enjoyment?

> Among other things, that internal machine runs a Web server. When we
> first started doing this, its apache logs were inundated with 404's as
> the now-stranded spyware attempted to phone home.

So you take a DNS (port 53) request and re-write it as HTTP (port 80)??

Wouldn't it just be easier to reply to the DNS request with a "host not
found"? Or where you trying to log the requests to find the infected
hosts..?

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don't."

RE: Firewall feature recommendation

[Seferovic Edvin]

Hi,

I doubt that he is rewriting DNS requests with HTTP. He is using his
nameserver to tell the clients that the ie. *.gmail.com -> some_local_IP and
when the real HTTP request is being sent out - it is being sent out to
some_local_IP ... it is like entering fix IP adresses in /etc/hosts file..

Regards,

Edvin Seferovic

PS: it would be interesting which domains you are poisoning :) a zone file
would be great !

-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Carl Holtje
;021;vcsg6;
Sent: Freitag, 24. Juni 2005 16:05
To: /dev/rob0
Cc: netfilter@lists.netfilter.org
Subject: Re: Firewall feature recommendation

On Fri, 24 Jun 2005, /dev/rob0 wrote:

> On Friday 24 June 2005 08:36, Carl Holtje ;021;vcsg6; wrote:
> > > > - 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.
> >
> > Sorry to jump in half-way through, but how do you do this?
> >
> > I'm looking for a solution better than editing /etc/hosts that I can
> > apply to a small network..
>
> BIND 9, transparent DNS proxying for clients to force them into our
> local nameserver, where we have a simple null zone file which is loaded
> as master for each blocked domain. It points a wildcard "A" at an
> internal IP.

Would you be so kind as to post a randomly-selected zone file for our
enjoyment?

> Among other things, that internal machine runs a Web server. When we
> first started doing this, its apache logs were inundated with 404's as
> the now-stranded spyware attempted to phone home.

So you take a DNS (port 53) request and re-write it as HTTP (port 80)??

Wouldn't it just be easier to reply to the DNS request with a "host not
found"? Or where you trying to log the requests to find the infected
hosts..?

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don't."

Re: Firewall feature recommendation

[/dev/rob0]

On Friday 24 June 2005 09:04, Carl Holtje ;021;vcsg6; wrote:
> > BIND 9, transparent DNS proxying for clients to force them into our
> > local nameserver, where we have a simple null zone file which is
> > loaded as master for each blocked domain. It points a wildcard "A"
> > at an internal IP.
>
> Would you be so kind as to post a randomly-selected zone file for our
> enjoyment?

[file: null.zone]
$TTL 86400      ; one day

@       IN      SOA     ns.local.lan.   hostmaster.local.lan. (
                        2004081000      ; serial number YYMMDDNN
                        28800           ; refresh  8 hours
                        7200            ; retry    2 hours
                        864000          ; expire  10 days
                        86400 )         ; min ttl  1 day

                        NS      ns.local.lan.
                        A       192.168.40.1

*               IN      A       192.168.40.1
[end file]

> > Among other things, that internal machine runs a Web server. When
> > we first started doing this, its apache logs were inundated with
> > 404's as the now-stranded spyware attempted to phone home.
>
> So you take a DNS (port 53) request and re-write it as HTTP (port
> 80)??

No. The spyware does a DNS lookup and then HTTP request to the IP 
returned.

> Wouldn't it just be easier to reply to the DNS request with a "host
> not found"? Or where you trying to log the requests to find the
> infected hosts..?

When I first did this I had no idea what was going to happen. :) Later 
on I decided to stick with the internal IP for that reason, yes, it 
does help us identify infected hosts.

DNS logging would have accomplished the same thing.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Firewall feature recommendation

[/dev/rob0]

On Friday 24 June 2005 09:12, I wrote:
> > Would you be so kind as to post a randomly-selected zone file for
> > our enjoyment?
>
> [file: null.zone]

I should clarify: this same zone is loaded for all blocked domains.
Please note that it's generic. And (just before I saw Edvin's request)
it occurred to me that you might want to see the blacklist of zones:

rob0@room101:/etc/named$ cat blacklist
# named/blacklist - modular BIND configuration file - 2005/03/31
# /dev/rob0 <rob@gmx.co.uk>
#
# This lists zones which will return the local server IP for *ALL*
# hostnames. The following is a list of known spyware domains which are
# blocked.
# NOTE: if you are using the domain blocking Webmin module we have
# provided, these comments will be lost, so we've also provided a copy
# as "named/blacklist.orig".

zone "180solutions.com" { type master; notify no; file "null.zone"; };
zone "2020search.com" { type master; notify no; file "null.zone"; };
zone "2nd-thought.com" { type master; notify no; file "null.zone"; };
zone "blazefind.com" { type master; notify no; file "null.zone"; };
zone "bonzibuddy.com" { type master; notify no; file "null.zone"; };
zone "clrsch.com" { type master; notify no; file "null.zone"; };
zone "cometcursor.com" { type master; notify no; file "null.zone"; };
zone "cometsystems.com" { type master; notify no; file "null.zone"; };
zone "coolsearch.biz" { type master; notify no; file "null.zone"; };
zone "date-manager.com" { type master; notify no; file "null.zone"; };
zone "doubleclick.net" { type master; notify no; file "null.zone"; };
zone "drsnsrch.com" { type master; notify no; file "null.zone"; };
zone "euniverse.com" { type master; notify no; file "null.zone"; };
zone "eyeblaster.com" { type master; notify no; file "null.zone"; };
zone "feedbackresearch.com" { type master; notify no; file "null.zone"; };
zone "flingstone.com" { type master; notify no; file "null.zone"; };
zone "funwebproducts.com" { type master; notify no; file "null.zone"; };
zone "gator.com" { type master; notify no; file "null.zone"; };
zone "gatoradvertisinginformationnetwork.com" { type master; notify no; file "null.zone"; };
zone "grandstreetinteractive.com" { type master; notify no; file "null.zone"; };
zone "hotornot.com" { type master; notify no; file "null.zone"; };
zone "incredifind.com" { type master; notify no; file "null.zone"; };
zone "match.com" { type master; notify no; file "null.zone"; };
zone "offeroptimizer.com" { type master; notify no; file "null.zone"; };
zone "plaxo.com" { type master; notify no; file "null.zone"; };
zone "pointroll.com" { type master; notify no; file "null.zone"; };
zone "precisionpop.com" { type master; notify no; file "null.zone"; };
zone "searchbrowser.com" { type master; notify no; file "null.zone"; };
zone "serving-sys.com" { type master; notify no; file "null.zone"; };
zone "shopnav.com" { type master; notify no; file "null.zone"; };
zone "sirsearch.com" { type master; notify no; file "null.zone"; };
zone "toprebates.com" { type master; notify no; file "null.zone"; };
zone "twain-tech.com" { type master; notify no; file "null.zone"; };
zone "webshots.com" { type master; notify no; file "null.zone"; };
zone "whenu-advertising.com" { type master; notify no; file "null.zone"; };
zone "whenu.com" { type master; notify no; file "null.zone"; };

Most if not all of the listed domains were personally researched by me.
That's the weakness of this, though: it's impossible to keep ahead of
the spammers and other ratware peddlers in this arms race. There are
perhaps millions of domains which belong on this list! I can't research
them all, and I wouldn't want to trust someone else to manage the list
outside our organisation.

The aforementioned Webmin module is custom-made and very simple. The
user has a text box control listing domains to block, one per line.
Upon submission of the form we rewrite the blacklist file (which is
part of named.conf by means of an include), "rndc reload", and signal
the slaves to update their configuration.

Note the philosophy here is that if a domain is bad it's ALL bad. You
could, however, specify a subdomain ...
zone "badboy.example.com" { type master; notify no; file "null.zone"; };
... and thus not block "goodguy.example.com."

We're way off topic here, but this is fascinating stuff. I need to find
someone to fund some ratware research; this could be a major project
with far-reaching benefits.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Firewall feature recommendation

[Jan Engelhardt]

>Most if not all of the listed domains were personally researched by me.
>That's the weakness of this, though: it's impossible to keep ahead of
>the spammers and other ratware peddlers in this arms race. There are

Just look into the named and/or squid logs and see what users (or programs 
acting on their behalf) request.


Jan Engelhardt                                                               
--                                                                            
| Gesellschaft fuer Wissenschaftliche Datenverarbeitung Goettingen,
| Am Fassberg, 37077 Goettingen, www.gwdg.de

Re: Firewall feature recommendation

[/dev/rob0]

On Friday 24 June 2005 09:37, Jan Engelhardt wrote:
> >Most if not all of the listed domains were personally researched by
> > me. That's the weakness of this, though: it's impossible to keep
> > ahead of the spammers and other ratware peddlers in this arms race.
>
> Just look into the named and/or squid logs and see what users (or
> programs acting on their behalf) request.

Yes, that would be the methodology, but it should be done in a 
controlled environment. Some, and now perhaps most, of our squid 
traffic is legitimate.

What is needed is a network "clean room". A fresh Windows install with 
monitored outbound access. Using Outhouse Distress, activate a known 
virus email, watch what it does. Using Internet Exploder, visit a known 
malicious IIS site, and see the results.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Firewall feature recommendation

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, /dev/rob0 wrote:

> On Friday 24 June 2005 09:37, Jan Engelhardt wrote:
> > >Most if not all of the listed domains were personally researched by
> > > me. That's the weakness of this, though: it's impossible to keep
> > > ahead of the spammers and other ratware peddlers in this arms race.
> >
> > Just look into the named and/or squid logs and see what users (or
> > programs acting on their behalf) request.
>
> Yes, that would be the methodology, but it should be done in a
> controlled environment. Some, and now perhaps most, of our squid
> traffic is legitimate.
>
> What is needed is a network "clean room". A fresh Windows install with
> monitored outbound access. Using Outhouse Distress, activate a known
> virus email, watch what it does. Using Internet Exploder, visit a known
> malicious IIS site, and see the results.

Heck.. just put the windows box behind a NAT-ting linux box.. just log the
NEW connections, and adjust from there.. probably be more likely than
having a non-infected windows box.. :)

Thanks for you insight!

Carl
- --

"There are 10 types of people in the world: Those who understand binary
and those that don't."

Re: Firewall feature recommendation

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, /dev/rob0 wrote:

> On Friday 24 June 2005 09:12, I wrote:
> > > Would you be so kind as to post a randomly-selected zone file for
> > > our enjoyment?
> >
> > [file: null.zone]
>
> I should clarify: this same zone is loaded for all blocked domains.
> Please note that it's generic. And (just before I saw Edvin's request)
> it occurred to me that you might want to see the blacklist of zones:
>
> rob0@room101:/etc/named$ cat blacklist

\{snip}

Also see [http://pgl.yoyo.org/adservers/index.php] for a list useful for
adblocking..

It seems to be updated fairly regularly (read: cron job), and fairly
complete.. available in many useful formats for many tools...

Um.. and I'll be expecting my advertising check sometime soon...

HTH..

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don't."

Re: Firewall feature recommendation

[/dev/rob0]

On Friday 24 June 2005 10:23, Carl Holtje ;021;vcsg6; wrote:
> > rob0@room101:/etc/named$ cat blacklist
>
> \{snip}
>
> Also see [http://pgl.yoyo.org/adservers/index.php] for a list useful
> for adblocking..

In fact I had that URL as a comment in the zone file; that was where I 
got some of my ideas. But I didn't want to trust that whole big list.

Another thing: he lists a lot of subdomains.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Firewall feature recommendation

[Kenneth Kalmer]

On 6/24/05, /dev/rob0 <rob0@gmx.co.uk> wrote:
> 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.

Certainly true

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

Even the bad ones, it helps to learn from other peoples mistakes...

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

Who would do it otherwise... :)

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

Point taken, I experimented with some clever bash scripting since my
earlier post on specifically this one, and ouch... I think I'm still
bleeding...

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

Clever, I must admit... Using a squid redirector is another way, but
not nearly as effective as this...

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

It's so simplistic, I know... But it stops the script kiddies, and for
most guys I think doing a nmap and not seeing the SSH at all might put
them off... I know, there's always exceptions...

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

Hence, "managed". A simple on/off flag to help you test and maybe turn
it on when suspecting some alien activity...

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

Understandably, allthough my idea was that I'd be the one configuring
the additional rules on a per-site basis. But you do have a point.

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

To be honest, since my post and several experiments in the last of
hours I've actually been put off this. I'm rather going to spend my
time now working on a framework for the basics and with some sound
notes on security issues. From this framework I can then assemble a
unique firewall for each site, tailor made...

It's amazing how great something sounds, until you go ahead and try it...

Thanks for your reply, it's been most helpful!


-- 

Kenneth Kalmer
kenneth.kalmer@gmail.com

Folding@home stats
http://vspx27.stanford.edu/cgi-bin/main.py?qtype=userpage&username=kenneth%2Ekalmer

Re: Firewall feature recommendation

[John A. Sullivan III]

On Fri, 2005-06-24 at 12:56 +0200, Kenneth Kalmer wrote:
> Guys
> 
> I've built several iptables-based firewalls for some clients and
> personal use. Some of them are horrors, now that I look back on
> them... I want to build my own 'all-in-one' firewall for the most
> common network setups I use... I've used various other GPL'ed scripts
> for references in past firewalls and they do tend to open one's eyes a
> bit, thanks for everyone who released their scripts under the GPL.
> 
> 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...
> 
> 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
> - NAT & DMZ
> - Black lists for inbound & outbound traffic
> - Host services (global or per interface, allows seperation between
> LAN & WAN services)
> - Access control on MAC, IP, or MAC-IP pairing
> - Administrative services (SSH) access control on MAC or MAC-IP pairing
> - VPN (IPSec, PPTP & SSL)
> - QoS
> - ICMP control
> - Managed logging
> - 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.
> 
> I've got the "Modular Firewall Product Certification Criteria version
> 4.1" from ICSAlabs, but I've not had any time to investigate it yet.
> 
> 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.
> 
> Kind regards
> 
May I suggest taking a look at ISCS (http://iscs.sourceforge.net) and
see if it gets you close to what you seek.  It's not a script but rather
a very flexible configurator that allows relatively easy management of
some of the complex features you cite - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

Financially sustainable open source development
http://www.opensourcedevel.com