"Paul M. Nealen" <pnealen@hotmail.com> said:
>I am seeking some advice on a IPTABLES ruleset for a multi-function
>server (running Slackware Linux 9.1). This machine performs a variety
>of services, including:
>
>1) firewall and IP masquerading for an internal subnet (192.168.X.X)
>2) handles internal and external HTTP, SFTP, and SSH requests
>3) serves up a couple of Linux partitions as Samba shares to the
>internal subnet (eventually, to the external network as well)
>4) port forwarding of external Remote Desktop requests (port 3389) to an
>internal machine (192.168.X.10)
>5) prints to an externally-networked JetDirect printer

Ok.

Based on those, your ruleset looks pretty good (though you could've
told which of your interfaces are external and which are internal).

Issues:
- if I understood correctly, your machine is connecting to port 9100
of some remote JetDirect printer; if so, I don't see any reason to
have the rule
># accept external printer communication on port 9100
>/usr/sbin/iptables -A INPUT -p tcp --dport 9100 -j ACCEPT
- you have a slight inconsistency in explicitly policy for OUTPUT
and FORWARD chains, and not setting a policy for INPUT chain (but
effectively doing the same by terminating the INPUT chain with
a DROP rule)
- your LOG target in FORWARD chain only logs packets that didn't
match any forward rule, so packets that are going to be dropped
(this might be your intention, but the comment line before the
LOG line seems to say otherwise)

>As supplemental info, I've appended an NMAP scan of this machine
>(below). I'd be happy to provide any other information which would help
>an evaluation.

>Nmap -sS -v XXX.XXX.XXX.XXX
>
>
>Starting nmap 3.45 ( http://www.insecure.org/nmap/ ) at 2004-05-06 21:44 EDT
>Host XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) appears to be up ... good.
>Initiating SYN Stealth Scan against XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) at
>21:44
>Adding open port 111/tcp
....

If these results were obtained by running nmap on the machine itself,
I wouldn't completely trust them. Try running a scan from somewhere
outside the machine (so, somewhere from behind the eth0 interface).

One question is, though, that are you actually using the rpcbind service
for something on the machine? If not, shut down the RPC portmapper.

Additionally, if there are services you've only planning to provide to
the internal network, configure the processes of those services to only
bind to the internal interface. This way, even if your iptables rulesets
fail at some point, the services stay visible for the internal network
only.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)