[sclug] Firewalling on a server

[Bob Franklin]

On Thu, 5 Jan 2006, Tom Chance wrote:

> Just a quick question - if you've got a server running a certain number 
> of services and you know the ports they use, then presumably it makes 
> sense to firewall off every other port?

Possibly.  If you have people on the box who might run things without you 
knowing (e.g. start their own webserver on a high port), then this can 
stop them.

The default behaviour is probably to send a ICMP Service Unavailable 
message, indicating nothing is listening on that port.  Nowards, a 
firewall will usually drop requests to blocked ports (making scanning 
trickier, and not flooding your upstream connection with ICMP messages; 
although the kernel usually limits this to something like 30 per second)


> Or would I stupidly block off incoming data on ports that I didn't 
> realise are needed, beyond those for SSH (22), SMTP (25), Apache (80), 
> IMAP (143), LDAPS (636) and MySQL (3306)? Looking in /etc/services there 
> are lots of ports that are mentioned for basic services like echo, 
> netstat, login, who, etc. I've looked down the list given by 'netstat 
> -a' but I've noticed that some are listed without my running the related 
> server (*:ircd is listed as LISTEN).

You have to be careful, because some ports are used for things that you 
can't immediately spot (e.g. DNS requests go out to port 53 and come back 
on some arbitrary high port [for normal clients] or port 53 [for BIND 
servers configured to do that - it's changeable, now].

On my Linux box at home that used to (until last night!) do my internet 
connection had the following:

   #iptables -A internet -s 10.0.0.0/8 -j block #spoof - DISABLE because NTL use these
   #iptables -A internet -s 172.16.0.0/12 -j block #spoof - DISABLE because NTL use these
   iptables -A internet -s 192.168.0.0/16 -j block #spoof - we use these
   iptables -A internet -j special
   iptables -A internet -p tcp --tcp-flags ACK ACK -j ACCEPT #established-tcp
   iptables -A internet -p tcp --dport 12345 --syn -j allow #ssh
   iptables -A internet -p udp --dport 53 -j ACCEPT #dns
   iptables -A internet -p udp --sport 67 --dport 68 -j ACCEPT #bootpc
   iptables -A internet -p udp --dport 123 -j ACCEPT #ntp
   iptables -A internet -p icmp -j ACCEPT
   iptables -A internet -j block

   # ... and assign it to the input chain on eth0
   iptables -A INPUT -i eth0 -j internet

... since my PC ran its own DNS server, NTP server and was a DHCP client, 
to get its address from NTL.

I ran a special SSH server on 12345 (actually a different one; I'm keeping 
it secret - but NOT 22) for me to get in.  Making it not 22 good, here, 
because it cuts down on knob-twisting (and the server only has me and a 
couple of people access it, so it doesn't need to be 'easy' on the 
standard port).


The last rule 'iptables -A INPUT -i eth0 -j internet' was just to use the 
'internet' table [built above] for eth0 (the server had eth1 and eth2, 
too, and I didn't want to have to put that as a condition in for each 
other rules).

I have a rule to jump to the 'special' table, also.  This is normally 
empty, but is a good place to shove temporary permits and forwardings as 
it means you're not mucking about with the main 'internet' table; you can 
just clear the 'special' table, when you're done mucking about and not 
worry about clearing one of the essential ones (to avoid accidentally 
getting the rule number wrong).


Some of the ports may be being listened on by [x]inetd; that acts a single 
process that listens on the ports of other services and fires them up, 
when it needs them (saving having to run a pile of daemons which are 
rarely used).


The 'block' table jumped to by the above is:

   iptables -A block -j LOG --log-level 5 --log-prefix "iptables(block): "
   iptables -A block -j REJECT

... if you wish to use this, it's up to you -- you may want to not bother 
logging and just throw things away; you can jump to 'DROP' or 'REJECT' 
directly (I never read the logs, but it was interesting spotting 
patterns).


[As an aside, I recommend running your own DNS server, if you use NTL, as 
their DNS servers are pants.]

   - Bob


-- 
  Bob Franklin <r.c.franklin at reading.ac.uk>          +44 (0)118 378 7147
  Systems and Communications, IT Services, The University of Reading, UK