Re: report on ARNE

[Fraser Farrell <fraser@trilobytes.com.au>]

> ARNE, which is living outside our firewall for
> Chris to be able to program.  Since it sounds like
> the system has been compromised, we are going to
> bring it inside the firewall and rebuild the hard
> disk, upgrading to Linux 7.1 while we are at it.
> Whether it will be returned outside the firewall
> depends on how secure I can make the computer.

Arne,

(A long answer for the benefit of the readers 
who are Linux newbies...)

By default, most Linuxes will activate network 
services that you probably don't need, and 
permit access from people you probably don't 
want in there. But recent Linuxes include some 
effective tools to close these security holes.

If ARNE does have an SSH server installed, then 
all of the services listed in /etc/inetd.conf can be 
deleted or commented out (if they're not already), 
and Chris can get in via SSH. SSH servers allow 
"tunnelling" of other services such as file transfer, 
terminal sessions, X sessions etc. The usual SSH 
package for Linux is called OpenSSH.

Some SSH servers use the TCP Wrappers files 
/etc/hosts.allow & /etc/hosts.deny to define 
who can use them. For example, to allow anyone 
SSH access, use the following line in hosts.allow:

  sshd : ALL

Or to let in only www.usno.navy.mil:

  sshd : 192.5.41.214

The hosts.deny file on ARNE should contain the 
following line:

  ALL : ALL

which blocks everything/everyone not explicitly 
mentioned in hosts.allow. 

The foregoing is a first step. Next, use ipchains 
(or its successor netfilter) to harden ARNE 
against script kiddies and similar nuisances. 
Ipchains can be quite explicit about who is 
permitted to connect to what on ARNE, so you 
can in effect make ARNE "invisible" to most of 
the Internet.

Assuming ARNE has a fixed IP address of 1.2.3.4, 
and connects to the world via the interface "ext",
the ipchains rules would begin like this:

  ipchains -P input DENY
  ipchains -A input -i lo -j ACCEPT
  ipchains -A input -s 10.0.0.0/8 -d 1.2.3.4/32 -i ext -j DENY
  ipchains -A input -s 127.0.0.0/8 -d 1.2.3.4/32 -i ext -j DENY
  ipchains -A input -s 172.16.0.0/10 -d 1.2.3.4/32 -i ext -j DENY
  ipchains -A input -s 192.168.0.0/16 -d 1.2.3.4/32 -i ext -j DENY
  ipchains -A input -s 0.0.0.0/0 -d 1.2.3.4/32 -p 6 -j ACCEPT ! -y

Translated, these state:
  "by default, DENY everything not explicitly allowed"
  "ACCEPT Linux's internal loopback network" (essential!)
  "DENY anything from the world which claims to be 
   coming from an internal network."
  "ACCEPT any connection which is already established"

Assuming Chris has a fixed address of 6.7.8.9, 
then SSH access can be restricted to him using these 
additional rules:

ipchains -A input -s 6.7.8.9/32 -d 1.2.3.4/32 22:22 -p 6 -j ACCEPT
ipchains -A input -s 6.7.8.9/32 -d 1.2.3.4/32 22:22 -p 17 -j ACCEPT
ipchains -A input -s 1.2.3.4/32 -d 6.7.8.9/32 22:22 -p 6 -j ACCEPT

Translated, these state:
  "ACCEPT SSH traffic (on port 22) to and from 6.7.8.9"

If Chris doesn't have a fixed address, you could 
restrict SSH to his ISP's address range. For 
example, replacing 6.7.8.9/32 with 6.7.8.0/24 
in ipchains would restrict SSH access to the 
address range 6.7.8.0 to 6.7.8.255. Not perfect, 
but better than allowing anyone in!

Next, log in as root and issue the following 
commands:

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

This protects against some common pests 
such as Ping Of Death and TCP Fragment attacks.

For convenience, add these echo commands and all 
of your ipchains rules to your startup script 
(/etc/rc.d/rc.local), so that they run 
automatically on a reboot.

While you're in /etc/rc.d, check out the 
services being started in /etc/rc.d/init.d. 
Chances are that many – such as Samba or 
Apache - are unnecessary for ARNE's work. 
Stop them running, then use chmod to make 
them non-executable.

After doing all this, check out ARNE's 
external defences with tools such as nmap or 
Nessus, before reconnecting it to the 
world. Close or mitigate any holes 
that are found.

Of course Chris (and other users) should 
also have a solid password which is changed 
regularly; and he shouldn't write it 
down anywhere obvious, tell it to his 
girlfriend, or think about his password 
in public places ;-)

None of the foregoing will prevent access 
by someone rebooting ARNE into single-user 
mode. Lock ARNE up somewhere.

Finally, I personally would be reluctant 
to put a "public-accessible" machine like 
ARNE inside your internal firewall(s). 
Chris's evil terrorist twin might use 
his ARNE access to probe and exploit 
the USNO network. And there's always that 
tiny percentage of hackers who are 
diabolically cunning.

Your security gurus can suggest additional 
measures; I've rambled for long enough ;-)


cheers,
Fraser Farrell