help needed to secure IPTABLES ruleset

Hi folks,

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

I know that having so many services available makes having extreme
security difficult (if not, impossible), but, alas, these functions are
needed to support our group.

I’ve got an IPTABLES ruleset that works for the above services, but I am
quite certain that I do not know enough about IPTABLES to ensure that it
is as secure as it could be. The last server in this position ended up
with a Trinoo worm – I’d *really* like to avoid a repeat of THAT incident.

If any experts out there could offer advice on this ruleset, I would be
very grateful. 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.

Thanks for any hints!

PMN
pnealen@hotmail.com




-------------------------------------------------------------------------
# eth0 configured to an external IP address XXX.XXX.XXX.XXX
# eth1 configured as 192.168.X.1


echo 1 > /proc/sys/net/ipv4/ip_forward

echo " Setting default INPUT policy..."
# flush INPUT chain
/usr/sbin/iptables -F INPUT

# accept established or related connections
/usr/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# accept external HTTP requests on ports 80 and 443
/usr/sbin/iptables -A INPUT -p tcp --dport 80 -j ACCEPT
/usr/sbin/iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# accept external printer communication on port 9100
/usr/sbin/iptables -A INPUT -p tcp --dport 9100 -j ACCEPT

# accept external remote desktop connections on port 3389
#/usr/sbin/iptables -A INPUT -p tcp --dport 3389 -j ACCEPT

# accept SSH connections on port 22
/usr/sbin/iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# accept internal connections
/usr/sbin/iptables -A INPUT -m state --state NEW -i ! eth0 -j ACCEPT

# drop everything else
/usr/sbin/iptables -A INPUT -j DROP


# accept all outgoing connections
/usr/sbin/iptables -P OUTPUT ACCEPT
/usr/sbin/iptables -F OUTPUT


# set up packet forwarding
/usr/sbin/iptables -P FORWARD DROP

echo "FWD: Allow all connections OUT and only existing and related ones IN"
/usr/sbin/iptables -A FORWARD -i eth0 -o eth1 -m state –state
ESTABLISHED,RELATED -j ACCEPT
/usr/sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

# forward remote desktop connections
/usr/sbin/iptables -A FORWARD -p tcp -i eth0 -d 192.168.X.10 --dport
3389 -j ACCEPT

# log all FORWARDING
/usr/sbin/iptables -A FORWARD -j LOG

echo "Enabling SNAT (MASQUERADE) functionality on external interface"
/usr/sbin/iptables -t nat -A PREROUTING -p tcp -i eth0 -d
XXX.XXX.XXX.XXX --dport 3389 -j DNAT --to 192.168.X.10:3389

/usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to
XXX.XXX.XXX.XXX



-------------------------------------------------------------------------

As supplemental info, a quick scan by NMAP of the external IP address
reveals the following:

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
Adding open port 53/tcp
Adding open port 515/tcp
Adding open port 22/tcp
Adding open port 587/tcp
Adding open port 631/tcp
Adding open port 80/tcp
Adding open port 139/tcp
Adding open port 25/tcp
The SYN Stealth Scan took 3 seconds to scan 1657 ports.
Interesting ports on XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX):
(The 1648 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
515/tcp open printer
587/tcp open submission
631/tcp open ipp

Nmap run completed -- 1 IP address (1 host up) scanned in 3.473 seconds

"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)

Juha Laiho wrote:
> Based on those, your ruleset looks pretty good (though you could've
> told which of your interfaces are external and which are internal).
>
> - 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)
>


Thanks for your detailed reply. All services are duplicated across
internal and external interfaces, so I cannot specify interfaces within
the rules.

My final FORWARD command was this:

# log all FORWARDING
/usr/sbin/iptables -A FORWARD -j LOG

I was hoping that this would log all forwarding, but as you pointed out,
it is logging only dropped requests. Is there a simple way to correct this?

Many thanks,

PMN
-------------------------------------------------------------------
Paul M. Nealen, Ph.D. tel: 215-573-2653
Biology Department fax: 215-898-8780
University of Pennsylvania
Philadelphia, PA 19104-6018 pnealen@mail.sas.upenn.edu

"Paul M. Nealen" <pnealen@mail.sas.upenn.edu> said:
>Juha Laiho wrote:
>> - 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)
>
>My final FORWARD command was this:
>
># log all FORWARDING
>/usr/sbin/iptables -A FORWARD -j LOG
>
>I was hoping that this would log all forwarding, but as you pointed out,
>it is logging only dropped requests. Is there a simple way to correct this?

The rule chains are sensitive to order -- DROP, ACCEPT and REJECT are
terminal rules, they stop processing the packet. In your ase, the LOG
rule was after the other rules in the FORWARD chain, so it only could
see those packets that were not accepted for forwarding by the other
rules.

To fix, just place the LOG rule to first position on the FORWARD chain.
LOG is not a terminal rule, so packets matched by a LOG rule will
be processes also by the subsequent rule(s) in the same chain.
--
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)