Hi Robert, We're running a linux-based firewall for years now. Below I've tried to reflect our experiences so far - see the >> parts.
-----Original Message----- From: Petty, Robert [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 5:55 PM To: Petty, Robert; [EMAIL PROTECTED] Subject: Linux firewall/IDS/NAT suggestions I am a seasoned admin, working with Solaris, AIX and the fluffy penguin now for 8 years or so.... I have learned quite a lot about the trade, including to be very cautious about proclaiming a system to be secure if I don't absolutely positively kinda believe it is.... Thus my question: I want to setup a Linux firewall for a small network of 15 machines connected live to the internet via broadband. I don't want to put something in place that has a glaring hole I don't know about that makes the installation more insecure with a false sense of security. Which kernel would be best? 2.0.x, 2.2.x, or 2.4.x? >> We've used 2.2.x in the past (with ipchains), but netfilter (and its companion iptables) in the 2.4.x series is far superior. We use 2.4.19, stability wise no problems at all (current uptime 151 days, no glitches whatsoever), security wise also no problems so far. Terry White mentioned the recent security problems with 2.4.x series, however to my best knowledge (and bugtraq's) these were all local, not remotely exploitable. And imho a firewall should have only 1 account and 1 only: the admin account. >> As a long time sysadmin I don't have to tell you to stay away from the 2.5.x series for now, so to make a longer story short: 2.4.19 or 2.4.20 Should snort be running on the firewall machine or another machine? If on another machine, should I put the firewall and IDS box on a hub as the first hop so they both see the same traffic? The customer's router is not manageable (linksys) and they have no budget for a Cisco Router or PIX. >> If you're only deploying one IDS sensor, how about putting it _behind_ the firewall? If the firewall successfully blocks an attack, how interesting is it to know it happened (in your apperently simple setting that is)? Putting it behind the firewall makes it a second layer of defense. The Linux box will serve as a secondary NAT layer, any pitfalls with this? >> If you use netfilter (i.e. 2.4.x series) there's not much you can't do. As long as you don't go too fancy with protocols you should be allright. Should SSH go to the firewall machine or be passed through to an internal Linux box? >> Depends on what you want to use it for. If you want to use SSH to reach the internal box, it should go to there. I think you're question has to do with management of the fw. In that case, I'd propose a setup where you do NOT make the fw directly accessible, but have a management station which is. Allow connections to the fw only from there, do not allow connections to the mgmt station except from specific IP's. Should the NAT and Firewall rules be written and maintained on CD-R media so a malicious attacker cannot hide rule changes? Should the firewall be re-initialized on a schedule to ensure the live rules are those from the read-only media? >> That's one way to go - and perhaps not a bad one either. We do it a lot simpler, rules are just stored in a CVS repository on the management console and after each update a checkout is done on the FW. We are running tripwire though on the FW, and its db _is_ stored on readonly media. Tripwire does not monitor the rulebase though (each update would require an update to tripwire and the ro media), but pretty much all other files. Goal is to detect a compromise, not necessarily a change in rules (before someone can change the rules they have to break in first ...) Last, but not least, what's a good HowTo that can be used as a basis? I would prefer one that starts off a little more strict so I can simplify rather than have to bone up on all of the current vulnerabilities. >> If you're not running any services on the box, except SSH which you make only available from the mgmt station, I'd say start with a linux install that's as minimalist as possible (there're various minimalist installs on the 'net). Without any services terminating on the box there's not that much to worry about (at least not for the fw). >> For the current reincarnation of our fw we've taken a RH7.2 as the basis, stripped everything we could without cripling the system, compiled a custom kernel and added the most recent SSH, Qmail as mailrelay, Djb-dns as dnsserver/cache, a http-proxy for outbound http access and tripwire, all compiled from scratch. Since its installation I've only had to update SSH. >> As a practical note, we've set the following kernel parameters, you might consider them as well echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_all echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_intvl echo 1 > /proc/sys/net/ipv4/tcp_syncookies echo 0 > /proc/sys/net/ipv4/tcp_ecn >> Another practical note: use a least privilege policy both for inbound AND outbound traffic. Consider using a http-proxy for granting outbound HTTP(S) access and using a mailrelay for mail (e.g. qmail. That way there's mostly no need anymore to have direct outbound access. Makes reverse shell attacks, spreading of most worms etc. a lot harder. Thanks for any replies! >> You're welcome Robert >> Regards, Jeroen
