RE: Linux firewall / web server
I'm going to build a Linux firewall web server at home (not necessarily the same box) and wondered if anyone can advise of the best route to go. On the firewall side of things I use a dual homed FreeBSD box[1]. Sure, I know you said Linux[2], but I'd recommend it because it's largely set and forget[3], and taking a 'standard' FreeBSD install to 'firewall' spec is frighteningly easy. I run it on an ol' P166 with bugger all memory and a tiny disk[4]. Oh, if you consider this a possibility, don't try FreeBSD 5.x yet, stay with the 4.x stable branch until 5.x is more mature. any ideas/tips welcomed. I gave up using Linux[2] a while back, and found FreeBSD to suit my needs better. But still, learning different flavours of *nix is my idea of fun[5] :) Lee [1] And I run Apache on a beefier machine, in my DMZ [2] No, I'm not trying to start an OS discussion/debate/flameware; lets not go there... [3] If you are suitably paranoid like me, you'll leave a terminal up, watch the log files closely, and ensure the source is regularly updated to fix holes/VULN's etc [4] Old hardware is cheap as chips. [5] Yes, really, I'm that sad.
Re: Linux firewall / web server
On Tue, 1 Jul 2003, Ben wrote: On Mon, Jun 30, 2003 at 07:38:12PM +0100, Chris Benson wrote: I had a lot of difficulty thinking about the f/wall rules for a system acting as f/wall and server until I separated the data streams (and setup a table/chain for each stream): inet- f/wall inet- internal network inet- dmz network [YADDA] f/wall - internal I've a perl script that writes a set of iptables commands from a simplified config file ... People might also be interested in filtergen (http://hairy.beasts.org/filter/ also comes as a Debian package and probably an RPM). It was written by a mate of mine, it handles more than just iptables as a backend and I'm reasonably happy with it. I do not understand the need for [the added complexity and perversion of] such packages since it is perfectly possible to write something almost syntactically identical in the shell anyway using a few shell variables. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: Linux firewall / web server
On Tue, Jul 01, 2003 at 12:47:40PM +0100, Shevek wrote: On Tue, 1 Jul 2003, Ben wrote: On Mon, Jun 30, 2003 at 07:38:12PM +0100, Chris Benson wrote: I had a lot of difficulty thinking about the f/wall rules for a system acting as f/wall and server until I separated the data streams (and setup a table/chain for each stream): inet- f/wall [YADDA] f/wall - internal I've a perl script that writes a set of iptables commands from a simplified config file ... People might also be interested in filtergen (http://hairy.beasts.org/filter/ also comes as a Debian package and probably an RPM). It was written by a mate of mine, it handles more than just iptables as a backend and I'm reasonably happy with it. I do not understand the need for [the added complexity and perversion of] such packages since it is perfectly possible to write something almost syntactically identical in the shell anyway using a few shell variables. I disagree. The syntax of something like filtergen is obvious at a glance, and greatly simplifies the audit process. The filtergen rules can be audited and seen to be correct by someone who is a great deal less competent and knowledgable than the person who wrote them (but who has to support them). I submit that the case where a system is maintained and supported by people less gifted / experienced than those who architected and built it is sufficiently common that tools that make this easier are useful. But, in any case, I'd be interested in seeing the shell stuff that you'd use to accomplish this task. Ben
Re: Linux firewall / web server
On Tue, 1 Jul 2003, Ben wrote: On Tue, Jul 01, 2003 at 12:47:40PM +0100, Shevek wrote: I do not understand the need for [the added complexity and perversion of] [firewall rule management] packages since it is perfectly possible to write something almost syntactically identical in the shell anyway using a few shell variables. I disagree. The syntax of something like filtergen is obvious at a glance, and greatly simplifies the audit process. The filtergen rules can be audited and seen to be correct by someone who is a great deal less competent and knowledgable than the person who wrote them (but who has to support them). I submit that the case where a system is maintained and supported by people less gifted / experienced than those who architected and built it is sufficiently common that tools that make this easier are useful. But, in any case, I'd be interested in seeing the shell stuff that you'd use to accomplish this task. The second point does rather destroy the validity of the first! Anyway, even having looked at filtergen, who really gives a toss if it came in on eth0? That's assembly programming for firewalls. What everyone really wants to say is, If it is going to our company web server, let it in. and eth0 is so far separated from any such concept that I disagree that eth0 should EVER appear in a firewall, regardless of how clever the syntax. IPADDR_EXT=62.49.9.94 NETDEV_EXT=eth0 NETWORK_EXT=62.49.9.80/28 BROADCAST_EXT=62.49.9.95 FROM_EXT=-i $NETDEV_EXT TO_EXT=-o $NETDEV_EXT # yadda - note -s/-d rather than -i/-o - but we don't have to think about # this from now on. We do have a standard validation chain somewhere, # don't worry. FROM_DMZ=-s $NETWORK_DMZ TO_DMZ=-d $NETWORK_DMZ # yadda FROM_INT=-s $NETWORK_INT TO_INT=-d $NETWORK_INT # yadda iptables -A FORWARD $FROM_INT $TO_DHCP-j intdhcp iptables -A FORWARD $FROM_INT $TO_DMZ -j intdmz iptables -A FORWARD $FROM_INT $TO_EXT -j intext iptables -A FORWARD $FROM_DHCP $TO_INT -j dhcpint iptables -A FORWARD $FROM_DHCP $TO_DMZ -j dhcpdmz iptables -A FORWARD $FROM_DHCP $TO_EXT -j dhcpext iptables -A FORWARD $FROM_DMZ $TO_INT -j dmzint iptables -A FORWARD $FROM_DMZ $TO_DHCP-j dmzdhcp iptables -A FORWARD $FROM_DMZ $TO_EXT -j dmzext iptables -A FORWARD $FROM_EXT $TO_DMZ -j extdmz And now we're into the realm of specific hosts, which can be handled in exactly the same way. Actually, with a few more shell variables, you could achieve considerably more. I'm sure that if you showed me the syntax of any filtergen-like package, I could construct suitable shell variables for something which was, as I originally claimed, almost syntactically identical. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: Linux firewall / web server
On Tue, Jul 01, 2003 at 01:21:03PM +0100, Shevek wrote: On Tue, 1 Jul 2003, Ben wrote: On Tue, Jul 01, 2003 at 12:47:40PM +0100, Shevek wrote: I do not understand the need for [the added complexity and perversion of] [firewall rule management] packages since it is perfectly possible to write something almost syntactically identical in the shell anyway using a few shell variables. I disagree. The syntax of something like filtergen is obvious at a glance, and greatly simplifies the audit process. The filtergen rules can be audited and seen to be correct by someone who is a great deal less competent and knowledgable than the person who wrote them (but who has to support them). I submit that the case where a system is maintained and supported by people less gifted / experienced than those who architected and built it is sufficiently common that tools that make this easier are useful. But, in any case, I'd be interested in seeing the shell stuff that you'd use to accomplish this task. The second point does rather destroy the validity of the first! Hardly. I'm always interested in alternatives to my current way of doing things to see if improvements can be made, or if I've missed out on interesting things. Anyway, even having looked at filtergen, who really gives a toss if it came in on eth0? That's assembly programming for firewalls. What everyone really wants to say is, If it is going to our company web server, let it in. and eth0 is so far separated from any such concept that I disagree that eth0 should EVER appear in a firewall, regardless of how clever the syntax. Nonsense. I am *very* interested in knowing which interface a packet that *claims* to come from my internal network was received on. [snip code example] Well, yes, you can do that, but for a rulebase of the complexity on the order of what I want, this is going to degenerate into an unmaintainable quagmire. In fact, when one of my SAs decided it would be good to try and remove filtergen and just have an rc.firewall script instead it *was* an unmaintainable quagmire. Ben
Re: Linux firewall / web server
On Tue, 1 Jul 2003, Ben wrote: On Tue, Jul 01, 2003 at 01:21:03PM +0100, Shevek wrote: On Tue, 1 Jul 2003, Ben wrote: Anyway, even having looked at filtergen, who really gives a toss if it came in on eth0? That's assembly programming for firewalls. What everyone really wants to say is, If it is going to our company web server, let it in. and eth0 is so far separated from any such concept that I disagree that eth0 should EVER appear in a firewall, regardless of how clever the syntax. Nonsense. I am *very* interested in knowing which interface a packet that *claims* to come from my internal network was received on. Note that I stated that there was a validation chain. This means that once a packet is validated to have come from a correct interface, you can and should then be forgetting entirely about interfaces and talking in logical terms only. Otherwise, we might as well all go back to programming in assembler. All these claims should be sorted out before proceeding with the firewall at all. S. -- Shevekhttp://www.anarres.org/ I am the Borg. http://www.gothnicity.org/
Re: Linux firewall / web server
Anyway, even having looked at filtergen, who really gives a toss if it came in on eth0? That's assembly programming for firewalls. What everyone really wants to say is, If it is going to our company web server, let it in. and eth0 is so far separated from any such concept that I disagree that eth0 should EVER appear in a firewall, regardless of how clever the syntax. Nonsense. I am *very* interested in knowing which interface a packet that *claims* to come from my internal network was received on. Note that I stated that there was a validation chain. Yes, of course you did. I missed that on first reading, sorry. Post-Glastonbury and all that *waves hands*. I'd still rather have all the rules in one place, than separate chains and so on. People have been known to become confused and have conceptual problems with chains, etc. This may say more about the people I have administering firewalls than anything, though. Ben
Re: Linux firewall / web server
On Tue, Jul 01, 2003 at 01:21:03PM +0100, Shevek wrote: # yadda - note -s/-d rather than -i/-o - but we don't have to think about # this from now on. We do have a standard validation chain somewhere, # don't worry. FROM_DMZ=-s $NETWORK_DMZ TO_DMZ=-d $NETWORK_DMZ [... sample script ...] I had several issues with the firewall (shell) scripts I looked at: * they approached/exceeded the length of the rules they output: not much saving in labour there. * one extra/missing quote and the script dies (and we're talking about scripts that are being edited by chimps): which led me to: * I wanted an input file I could validate and die() on error instead of half-way through creating the rules. Shevek's use of variable names makes his a lot more readable than one script I saw that looked like a shell obfuscation entry from a .BAT writer ... but still, one typo and you're dead. Not that I'll happy with my config-file, but I can say things like: define $INTERNAL eth0 define $EXTERNAL ippp+ define $DEMON_SMTP_NET 1.2.3.4/24 define $ANY all 0:65355 nat $EXTERNAL in_ext counts tcp http in_ext do connected in_ext accepts tcp smtp -s $DEMON_SMTP_NET; ssh; # be nasty - no-one should be trying me for these in_ext mirror all portmap; netbios-ns; netbios-dgm; netbios-ssn; ftp; printer; telnet in_ext log DROPPING:in_ext in_ext drop count_in counts tcp domain; smtp; http; count_in counts udp domain; on forward from $INTERNAL to $EXTERNAL do fwd_int_ext on forward from $EXTERNAL to $INTERNAL do fwd_ext_int on forward log DROPPING:forward # policy is drop on input from lo accept on input from $INTERNAL do in_int on input from $EXTERNAL do in_ext on input log DROPPING:input # policy is drop on output to lo accept on output to $INTERNAL do out_int on output to $EXTERNAL do out_ext on output log DROPPING:output # policy is drop That gives me gamma:~ # wc -l /etc/firewall.conf 130 /etc/firewall.conf gamma:~ # setup-firewall /etc/firewall.conf | wc -l 201 gamma:~ # -- Chris Benson
Re: Linux firewall / web server
On the subject of Linux firewalls, a friend who's a security wookie for a large insuranceco has been evaluating Astaro over the past few weeks. He is most impressed. http://www.astaro.com/. Some of his comments can be found in his journal here: http://blogs.ittoolbox.com/security/. -- David Cantrell
Linux firewall / web server
I'm going to build a Linux firewall web server at home (not necessarily the same box) and wondered if anyone can advise of the best route to go. I've seen smoothwall, but would I be better hardening a linux install ? if so, which flavour ? I'll be installing Apache, mod_perl, + db on the same box, so maybe this will influence your recommendation ? any ideas/tips welcomed. _ On the move? Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile
Re: Linux firewall / web server
On Mon, 30 Jun 2003, Martin Bower wrote: I'm going to build a Linux firewall web server at home (not necessarily the same box) and wondered if anyone can advise of the best route to go. I've seen smoothwall, but would I be better hardening a linux install ? if so, which flavour ? I'll be installing Apache, mod_perl, + db on the same box, so maybe this will influence your recommendation ? As far as I know none of the pre-cooked firewall distros are suitable if you want to install a fully functioning webserver on the box - certainly Smoothwall/IPCop are not. What the best approach will be depends, as ever, upon what you really want to do with it, what you want to protect and the level of protection you want. I suspect you'll need to roll your own. Jason Clifford -- UKFSN.ORG Finance Free Software while you surf the 'net http://www.ukfsn.org/ ADSL Available Now
Re: Linux firewall / web server
Martin Bower wrote: I'm going to build a Linux firewall web server at home (not necessarily the same box) and wondered if anyone can advise of the best route to go. I've seen smoothwall, but would I be better hardening a linux install ? if so, which flavour ? Hello, Martin. I know nothing about the smoothwall. I would tell you to harden a linux box. If I was you, I would use a Debian Linux distro. It have good maintenance facilities built-in, and is easier to set up as a server box (no X, nor other non-server services). I'll be installing Apache, mod_perl, + db on the same box, so maybe this will influence your recommendation ? Maybe you will have some trouble with Debian and X windows, I allways need about an hour to set up an X windows when I install a Debian linux from scratch. I don't think that this will hurt you that much. Just my two pence. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Luis Campos de Carvalho Computer Scientist, Unix Sys Admin Certified Oracle DBA http://br.geocities.com/monsieur_champs/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: Linux firewall / web server
On Mon, Jun 30, 2003 at 03:58:36PM +, Martin Bower wrote: I'm going to build a Linux firewall web server at home (not necessarily the same box) and wondered if anyone can advise of the best route to go. I've seen smoothwall, but would I be better hardening a linux install ? if so, which flavour ? I'll be installing Apache, mod_perl, + db on the same box, so maybe this Uhm, this sort-of contradicts (not necessarily the same box) above. If you want a minimal-maintenance, standalone firewall, ISTM that Smoothwall is as easy as it gets ... But as others have said, if you're putting a webserver on it, then you have to go with plan B. will influence your recommendation ? The distro you're most familiar with? I use SuSE because I'm used to it. But I'm forcing myself to try Debian again, again :-) Another suggestion:- There's a Knoppix-based (which is itself Debian based) distro, Knoppix-STD (nope, it stands for Security Tools Distribution) that has two sorts of firewall as well as honey-pots, ID-tools and so forth. It can run from CDROM which is nice from a recoverability PoV. http://www.knoppix-std.org/ any ideas/tips welcomed. I had a lot of difficulty thinking about the f/wall rules for a system acting as f/wall and server until I separated the data streams (and setup a table/chain for each stream): inet- f/wall inet- internal network inet- dmz network dmz - inet dmz - internal dmz - f/wall int'l - f/wall int'l - dmz int'l - inet f/wall - inet f/wall - dmz f/wall - internal I've a perl script that writes a set of iptables commands from a simplified config file ... -- Chris Benson
