Re: [cobalt-security] Portsentry, ipchains and pmfirewall

[Michael Stauber <cobalt@xxxxxxxxxxxxxx>]

Hi Francisco,

> Since I only want to have ports 80 and 443 open in my server, as well as 22
> and 81 for restricted access, I wonder if I could do with these rules:
>
>
> $IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 80 -j ACCEPT
> $IPCHAINS -A input -p tcp -s $REMOTENET -d $OUTERNET 443 -j ACCEPT
> $IPCHAINS -A input -p tcp -s MY-IP/MY-NETMASK -d $OUTERNET 22 -j ACCEPT
> $IPCHAINS -A input -p tcp -s MY-IP/MY-NETMASK -d $REMOTENET 81 -i
> $OUTERIF -j ACCEPT
> $IPCHAINS -A input -j DENY -s $REMOTENET -d $REMOTENET -i $OUTERIF
>

Part of the problem here is that you don't allow connections from or to the 
loopback device 127.0.0.1, which might cause problems. 

Solution:

        $IPCHAINS -A input -i lo -s 0/0 -d 0/0 -j ACCEPT
        $IPCHAINS -A output -i lo -s 0/0 -d 0/0 -j ACCEPT

Furthermore you might want to allow connections originating locally to go 
through to the outside world:

        $IPCHAINS -A input -s $INTERNALNET -d $REMOTENET -j ACCEPT
        $IPCHAINS -A output -s $INTERNALNET -d $REMOTENET -j ACCEPT

Allowing SSH access to the machine might be a good idea as well, but we can 
be a little more creative here:

$IPCHAINS -A input -i $LOCALIF -p tcp -s $REMOTENET 22 -d $LOCALNET 513:1022 
'!' --syn -j ACCEPT

Your rules for the Apache ports (80, 81, 443 and 444) are not as 
detailed as they could be. You only want to allow *client* connections to 
those ports. Which means access from unprivileged client ports to the 
respective daemon port on your machine. So the rules for that purpose should 
look like this:

$IPCHAINS -A input -p tcp -s $REMOTENET 1023: -d $LOCALNET 80:81 -j ACCEPT
$IPCHAINS -A input -p tcp -s $REMOTENET 1023: -d $LOCALNET 443:444 -j ACCEPT

If you have webpages which allow you to upload files to the server, then you 
might need to extend the rules to allow for UDP connections as well:

$IPCHAINS -A input -p udp -s $REMOTENET 1023: -d $LOCALNET 80:81 -j ACCEPT
$IPCHAINS -A input -p udp -s $REMOTENET 1023: -d $LOCALNET 443:444 -j ACCEPT

Also, even though you might want to lock down most ICMP traffic, you 
certainly don't want to block traceroutes as well. For that the options below 
will do just fine:

$IPCHAINS -A input -p icmp -s $REMOTENET destination-unreachable -d $LOCALNET 
-j ACCEPT
$IPCHAINS -A input -p icmp -s $REMOTENET time-exceeded -d $LOCALNET -j ACCEPT
$IPCHAINS -A input -p icmp -s $REMOTENET echo-reply -d $LOCALNET -j ACCEPT
$IPCHAINS -A input -p icmp -s $REMOTENET -d $LOCALNET -l -j DENY
$IPCHAINS -A output -p icmp -s $LOCALNET -d $REMOTENET -j ACCEPT

> I understand that this would DENY all traffic, except http and https for
> the outside world, and only accept ssh and port 81 connections from the IPs
> I define.  Am I right.

Doesn't look to me that way. 

> $IPCHAINS -A input -j DENY -s $REMOTENET -d $REMOTENET -i $OUTERIF

That will not do as you're restricting traffic from source $REMOTENET *to* 
$REMOTENET on your outer interface. So that will still leave the machine wide 
open.

A *proper* ruleset would start with the following entries:

        $IPCHAINS -P input DENY
        $IPCHAINS -P output ACCEPT
        $IPCHAINS -P forward DENY

But BEWARE: That locks down everything (!!!!). Which is almost as good as 
pulling the network cable. You then start to open up selectively all those 
ports which you need to be reachable.

The problem here is that you need a solid understanding of the IP-stack and 
you have to look beyond just TCP/IP. The IP protocol consists of the three 
protocols, namely ICMP, UDP and TCP/IP. Sometimes it is not that transparent 
which kind of protocol you need to allow and which not. Some services require 
just UDP, some just TCP and some need both in order to function properly.

Opening both TCP and UDP as a precaution is as good as having no firewall at 
all. Example: Allow UDP traffic to the Webmin port (if webmin is installed) 
and you open yourself up to script kiddies which can then compromise your 
machine faster than you can say "holy shmucks". 

Even without extreme examples like that there are services where opening up 
just the proper port for the proper protocol will not suffice. FTP is a prime 
example for that. Most people think that all you need to do to allow FTP 
traffic is to open up port 21. Which is wrong. A proper rule to allow FTP 
traffic looks like this:

$IPCHAINS -A input -p tcp -s $REMOTENET -d $LOCALNET 21 -j ACCEPT
$IPCHAINS -A input -p tcp -s $REMOTENET ftp-data -d $LOCALNET 1023: -j ACCEPT
$IPCHAINS -A input -p tcp -s $REMOTENET -d $LOCALNET 20 -j ACCEPT

However, while this will allow FTP traffic, it will still put your FTP users 
into a world of pain as the logon process takes ages to complete. In most 
cases users will experience odd timeouts after the clients FTP programm has 
been sitting around idle for 2 minutes after initial connection to the 
server. That's because you're not allowing IDENT services, which ProFTPd 
usually tries to use to gather information about the client. But not only 
FTPd requires ident, so you might have to allow this kind of service as well:

$IPCHAINS -A input -p tcp -s $REMOTENET -d $LOCALNET 113 -j ACCEPT

You certainly are on the right track to setup good IPchains rules, but I urge 
you to read a little more on the issue and recommend you don't do this on a 
machine to which you do not have local access to. Local as in "being able to 
walk to it and to reboot it from the frontpanel". Because you might have the 
urgent need to do so a couple of times while you fiddle around with these 
rulesets. When I initially set up my firewall rules it took me two days of 
solid trial and error during which I locked myself out more often than not. 
And I had a serial port connection hooked up to the machine to be able to 
reset the rules.

Even resetting them is more complicated than issuing /sbin/ipchains -F as a 
normal flush won't do once you start to use ...

        $IPCHAINS -P input DENY
        $IPCHAINS -P output ACCEPT
        $IPCHAINS -P forward DENY

.. in your rules. Specifically you have to issue these commands in order to 
get back to normal:

    $IPCHAINS -P input ACCEPT
    $IPCHAINS -P output ACCEPT
    $IPCHAINS -P forward ACCEPT
    $IPCHAINS -F

> Any advise will be much appreciated before I put these rules in practice,
> as I do not want to be kicked out of my machine :-)

Trust me. You'll lock yourself out. More than once. A friend of mine used to 
say: "If you haven't locked yourself out more than once, then your rules 
won't do". That might be a little extreme, but it's not far from the truth I 
gather.

There is a good IPchains based Firewall with comprehensive rules available. 
Go to http://linuxmafia.org/~godot/ and search for the old ipchains driven 
version, which is available here: ftp://muse.linuxmafia.org/pub/gShield/v1/

Those scripts are a good start and I use an extensively modified version of 
it which has been extended to accomodate for a few Cobalt specific oddities 
like the GUI and the various backup solitions which are built into those 
little blue appliances.

I certainly don't want to discourage you to give it a try, but you should be 
aware that what you're planning to do is quite risky.

-- 

With best regards,

Michael Stauber
mstauber@xxxxxxxxxxxxxx
Unix/Linux Support Engineer