RE: report on ARNE

["Albertson, Chris" <CAlbertson@primeadvantage.com>]

That's exactly why I suggested turning every but SSh off.
We can use SSH for everything including remote control of
camera.  SSH provides an encrypted path between two points
on the Internet.  You can "tunnel" other protocol using that
path.

IMO firewalls don't do anything that you can't also do
by configuring the computer.  Still getting one provides
a "belt and suspenders" type defense.  To leave a service
open would require two mistakes.  Also that Linksys firewall
is only about $100 now.  

> -----Original Message-----
> From: Fraser Farrell [mailto:fraser@trilobytes.com.au]
> Sent: Wednesday, April 18, 2001 10:29 PM
> To: aah@nofs.navy.mil
> Cc: tass@listserv.wwa.com
> Subject: Re: report on ARNE
> 
> 
> > 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
> 
>