* Firewall feature recommendation @ 2005-06-24 10:56 Kenneth Kalmer 2005-06-24 13:26 ` /dev/rob0 2005-06-24 13:44 ` John A. Sullivan III 0 siblings, 2 replies; 15+ messages in thread From: Kenneth Kalmer @ 2005-06-24 10:56 UTC (permalink / raw) To: NetFilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 10:56 Firewall feature recommendation Kenneth Kalmer @ 2005-06-24 13:26 ` /dev/rob0 2005-06-24 13:36 ` Carl Holtje ;021;vcsg6; 2005-06-24 15:12 ` Kenneth Kalmer 2005-06-24 13:44 ` John A. Sullivan III 1 sibling, 2 replies; 15+ messages in thread From: /dev/rob0 @ 2005-06-24 13:26 UTC (permalink / raw) To: NetFilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 13:26 ` /dev/rob0 @ 2005-06-24 13:36 ` Carl Holtje ;021;vcsg6; 2005-06-24 13:45 ` /dev/rob0 2005-06-24 15:12 ` Kenneth Kalmer 1 sibling, 1 reply; 15+ messages in thread From: Carl Holtje ;021;vcsg6; @ 2005-06-24 13:36 UTC (permalink / raw) To: /dev/rob0; +Cc: NetFilter 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 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; 0 siblings, 1 reply; 15+ messages in thread From: /dev/rob0 @ 2005-06-24 13:45 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 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 0 siblings, 2 replies; 15+ messages in thread From: Carl Holtje ;021;vcsg6; @ 2005-06-24 14:04 UTC (permalink / raw) To: /dev/rob0; +Cc: netfilter 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* RE: Firewall feature recommendation 2005-06-24 14:04 ` Carl Holtje ;021;vcsg6; @ 2005-06-24 14:12 ` Seferovic Edvin 2005-06-24 14:12 ` /dev/rob0 1 sibling, 0 replies; 15+ messages in thread From: Seferovic Edvin @ 2005-06-24 14:12 UTC (permalink / raw) To: netfilter 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 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 1 sibling, 1 reply; 15+ messages in thread From: /dev/rob0 @ 2005-06-24 14:12 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 14:12 ` /dev/rob0 @ 2005-06-24 14:32 ` /dev/rob0 2005-06-24 14:37 ` Jan Engelhardt 2005-06-24 15:23 ` Carl Holtje ;021;vcsg6; 0 siblings, 2 replies; 15+ messages in thread From: /dev/rob0 @ 2005-06-24 14:32 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 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:23 ` Carl Holtje ;021;vcsg6; 1 sibling, 1 reply; 15+ messages in thread From: Jan Engelhardt @ 2005-06-24 14:37 UTC (permalink / raw) To: /dev/rob0; +Cc: netfilter >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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 14:37 ` Jan Engelhardt @ 2005-06-24 14:53 ` /dev/rob0 2005-06-24 15:20 ` Carl Holtje ;021;vcsg6; 0 siblings, 1 reply; 15+ messages in thread From: /dev/rob0 @ 2005-06-24 14:53 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 14:53 ` /dev/rob0 @ 2005-06-24 15:20 ` Carl Holtje ;021;vcsg6; 0 siblings, 0 replies; 15+ messages in thread From: Carl Holtje ;021;vcsg6; @ 2005-06-24 15:20 UTC (permalink / raw) To: /dev/rob0; +Cc: netfilter 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 14:32 ` /dev/rob0 2005-06-24 14:37 ` Jan Engelhardt @ 2005-06-24 15:23 ` Carl Holtje ;021;vcsg6; 2005-06-24 17:49 ` /dev/rob0 1 sibling, 1 reply; 15+ messages in thread From: Carl Holtje ;021;vcsg6; @ 2005-06-24 15:23 UTC (permalink / raw) To: /dev/rob0; +Cc: netfilter 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." ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 15:23 ` Carl Holtje ;021;vcsg6; @ 2005-06-24 17:49 ` /dev/rob0 0 siblings, 0 replies; 15+ messages in thread From: /dev/rob0 @ 2005-06-24 17:49 UTC (permalink / raw) To: netfilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 13:26 ` /dev/rob0 2005-06-24 13:36 ` Carl Holtje ;021;vcsg6; @ 2005-06-24 15:12 ` Kenneth Kalmer 1 sibling, 0 replies; 15+ messages in thread From: Kenneth Kalmer @ 2005-06-24 15:12 UTC (permalink / raw) To: /dev/rob0; +Cc: NetFilter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Firewall feature recommendation 2005-06-24 10:56 Firewall feature recommendation Kenneth Kalmer 2005-06-24 13:26 ` /dev/rob0 @ 2005-06-24 13:44 ` John A. Sullivan III 1 sibling, 0 replies; 15+ messages in thread From: John A. Sullivan III @ 2005-06-24 13:44 UTC (permalink / raw) To: Kenneth Kalmer; +Cc: Netfilter users list 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2005-06-24 17:49 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-06-24 10:56 Firewall feature recommendation Kenneth Kalmer 2005-06-24 13:26 ` /dev/rob0 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
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.