iptables firewall script for linux

A workstation doesn't need a firewall in the first place. Just make sure you don't have any services listening on the external interface (netstat

-ntul). However, if you must have a packet filter you can go with the following:

----8 /proc/sys/net/ipv4/ip_forward

$ipt -P INPUT DROP $ipt -P OUTPUT ACCEPT $ipt -P FORWARD DROP

$ipt -F $ipt -X

$ipt -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $ipt -A INPUT -p tcp -j REJECT --reject-with tcp-reset $ipt -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable

---->8----

Fools should not be playing with firewalls.

One could start by reading the documentation [1]. Oh, well ...

[1] cu 59cobalt

Thanks a lot for the minimal script, 59cobalt (shouldn't that be 58.9332cobalt?:). Actually, I have a lan with several Slackware-based intel/amd "workstations", and several Digital VAXstations and a Compaq DS10 (all running VMS). They do run various and sundry services, e.g., telnet, ftp, http, sendmail, nfs, some decnet-for-linux (decnet on the VMS boxes) stuff, etc. And I don't know enough to configure this all safely. Usually the lan's offline, so it doesn't matter, but I do sometimes use a dial-up ppp connection. That's what the script's for, to be invoked inside ip-up when the connection's made. And I'm guessing the two lines $ipt -F $ipt -X inside ip-down will reset everything when I hang up.

Precisely. That's why I'm looking for something that can just be dropped in and run, with minimal configuration (i.e., with configuration requiring minimal knowledge).

Thanks for the reference. Checked it out, but it still looks like I'd have to learn how to use iptables, and to set up rules intelligently. That's a bit more than I wanted to learn. Similarly, for example, I want to turn on a light without understanding electrical engineering, or flush a toilet without understanding activated sludge.

Thanks again for the script,

IPCHAINS is rather old. Most people have been using iptables since it was introduced about six years ago. It's much more versatile.

Why not start out by running 'netstat -tupan' and determining why any port is shown as LISTENING. As it's not a server, the only thing that should be open is port 113, and that ONLY if you have determined that you need 'auth' or 'identd' to respond to queries from hosts you are connecting to. This means /etc/inetd.conf probably has no line uncommented (all should begin with a '#' character). Then look at your startup scripts and see that no unwanted daemons are being started there.

You _may_ want to allow SSH in - but at the very least you should tightly restrict what addresses are allowed to connect. As port 22 is targeted by skript kiddiez and worms, consider moving your daemon to a different port number. Some would call it security by obscurity, but all it's doing is avoiding nuisance from the totally clueless.

What's wrong with reading the HOWTOs? While some are a bit old, you could start with:

708351 Nov 14 2005 IP-Masquerade-HOWTO 17605 Jul 21 2004 Masquerading-Simple-HOWTO 155096 Jan 23 2004 Security-HOWTO 278012 Jul 23 2002 Security-Quickstart-HOWTO

and Rusty Russell's (the guy responsible for the firewall code itself as well as the tools like IPCHAINS and iptables that control it) fine documentation at

Masquerading is almost certainly unwanted, but those two HOWTOs are included for their basic firewall concepts. Your firewall should be no more than about a half dozen lines - basically

/sbin/iptables -P INPUT DROP /sbin/iptables -P OUTPUT ACCEPT /sbin/iptables -P FORWARD DROP /sbin/iptables -F /sbin/iptables -A INPUT -i lo -j ACCEPT /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

The first three set defaults. The -F flushes any _other_ rules. The next one allows traffic on the loopback interface, while the last allows _responses_ to traffic you initiate. No big deal. See the HOWTOs mentioned above, and the man page for any additional help.

Old guy

When Slackware first started using iptables as default, I looked for an iptables-based replacement for the ipchains script referenced above. Couldn't find one then, so I installed ipchains (from what Slackware calls its /pasture directory for old-but-still-useful stuff) and continued running the old but still useful script.

Thanks for the explanation, Moe. As mentioned in earlier followup to cobalt69, the machines on my lan do run some services that might create security holes. Although I tried to clean things up, I can't fool myself into thinking I know enough to do this securely. Hopefully, a canned firewall script will mostly protect me from my shortcomings.

Thanks for the references. I'd looked at a few when first running the canned ipchains firewall. Note that yours add up to 1.15MB, which is about 230 crammed-full printed pages (at 5KB/page leaving no white space at all). That's a lot to read just to install a script. I did look through the iptables man page, and even that's 1850 lines.

Thanks very much, Moe. That's exactly what I was looking for.

Moe's suggestion is basically the same as mine, with four minor differences.

1) echo "0" > /proc/sys/net/ipv4/ip_forward

Disables IP forwarding (because your box doesn't act as a router). Even though this is the default I usually add a line that explicitly disables it to my iptables scripts, so that everytime the script is executed it brings the box to a well-defined state.

2) iptables -X

Delete all user-defined chains. Included in my script for the same reason: to bring the firewall to a well-defined state whenever the script is executed.

3) iptables -A INPUT -i lo -j ACCEPT

Allow all incoming traffic on the loopback interface (lo). Should have been present in my script as well, but I forgot (it was late). My bad.

4) iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset iptables -A INPUT -p tcp -j REJECT --reject-with icmp-port-unreachable

Reject incoming connections rather than dropping them, so that the requesting host wouldn't have to assume packet-loss and retry the connection attempt.

Naturally I'd suggest to leave all of the above in place.

cu

59cobalt

I know Slackware added iptables in 8.0 though I'm not sure when they changed to using it by default. I think that was 8.1 in 2002. The unofficial HOWTOs predate that by about a year, and were originally on the samba.org website. The Security-Quickstart-HOWTO also predates the Slackware change.

Your original post stated it was a workstation, not a server, but knowing what port needs to be open, and to "who" can let you set up any rule that may be needed.

Actually, 'wc -l' shows it to be just over 20,000 lines, or about 334 pages, but given that there are currently about 450 HOWTOs with 3.8 million words for about 11,500 pages, you can't read them all. Five years ago, something like a third of those documents were being updated/changed every six months. Initially, I decided to read at least 10 HOWTOs a week. Some of them were either not interesting to me, or not relevant. There after, I set up a cron-job that checks ibiblio.org (the old "sunsite.unc.edu) comparing file timestamps nightly. The only way I could keep up is to do a 'diff' of the old/new HOWTO[s] and scan that. One other thing that helps is using 'grep' to find which document to look at.

Well, it's better to have 31 pages than something like 2 or 3. ;-) Again, use the search function (the '/' key) in your man pager to look for things.

Old guy

something simple:

Thanks very much for the clarifications, and for your earlier remarks and script.

Sorry about that. I think of machines on my lan as workstations because they're used for development, but I guess they're servers in the context of this discussion. (Told you I don't know what I'm doing:)

Some man pages are pretty good, and iptables seems like one of them, introducing some concepts and terminology up front. Just what I'm looking for. Some HOWTOs take forever to get to the point (and some are terrific). I tried finding a short canned script like the ones you and 59cobalt posted. Maybe I missed it. Fooling around and writing my own is how I typically learn "little languages" that I don't need to know too well. But iptables firewalls seem a little unique, because there's actually an intentionally malicious agent just waiting for you to make a mistake. So trial-and-error isn't quite the fun it usually is.