[Nottingham] Exposing our internal network

[Chris Booth]

>>>>> martin at stupids.org 12/01/05 6:02 pm >>>
>>On Thu, 2005-12-01 at 17:29 +0000, Michael Leuty wrote:

>> I should be grateful for your comments on how risky it is to open ports 22 
> >and 80, and whether Firestarter provides adequate defence against script 
>> kiddies.

>If you are opening up port 22. I would recommend:

>1) Ensure root login is disabled (in /etc/ssh/sshd_config)
>2) run denyhosts. (see http://denyhosts.sourceforge.net/)

>I will leave others to comment on port 80 etc.

>-- 
>Martin.


Firestarter is pretty adequate, you won't get much more protection than Firestarter without moving to a proxy-level firewall.

As Martin said disabling root logins is a good idea, as is running denyhosts.  To disable root logins edit sshd_config (usually /etc/ssh/sshd_config) and change PermitRootLogin yes to PermitRootLogin no.

I manage multiple Internet facing servers and see ssh & http attacks all day every day.  Read up at http://httpd.apache.org/download.cgi  on the documentation links.

Opening up a port through the firewall is like opening a hole in a wall. Just because you have only opened port 22 and port 80 doesn't mean that you will only get legitimate SSH or HTTP attempting connections, therefore you will only be as secure as the daemon and the OS listening at those ports.

Before opening holes in your firewall make sure your OS is completely up to date (which is as easy as apt-get update; apt-get upgrade  if you use Debian or Ubuntu), then make sure the daemons listening on those ports are as secure as possible: man <daemon>.  google re: secure <daemon>

You might like to read up about openssh security from the links from the OpenBSD website: http://www.openbsd.org/   and    http://www.openssh.com/


If you can do without passwords entirely by using ssh keys then do it. Using ssh keys rather than passwords is *much* faster and can be more secure (no shoulder surfing or post-it notes).

Each individual user needs to create their own ssh public/private keypair: 
user at host$ ssh-keygen -t rsa  <enter>
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/ide_rsa):  <enter>
Enter passphrase <enter - yes that's right NO Password!>
Enter same passphrase: <enter again>
...
The key fingerprint is:
aa:bb:cc:12:34:56:a1:b2:c3:b8:c7:a6:13:14:15:0a user at host

Make a written note of your own key fingerprint for future reference.

Now you have a public/private ssh key pair in the local host directory ~/.ssh

To use ssh keys you now copy your public key to the remote host (always keep your private key secure (if you are paranoid change the location (above) to a usb key or something).
$ ssh remotehosst
$ mkdir .ssh
$ chmod 0700 .ssh
exit back to your host
$ scp .ssh/id_rsa.pub remotehost:.ssh/authorized_keys <enter password for remotehost>
Now for the magic bit
$ ssh <remotehost>
The remotehost should let you in without asking for a password.  The first time only it will ask you to confirm the connection.
$ exit
$ ssh <remotehost>
$ uname -n
$ exit
$ uname -n
Magic!

Now whenever you need to ssh to the remote host you only have to type:
$  ssh <remotehost>

Similarly if you want to copy files to your home directory on the remote host you only have to type:
$ scp filename <remotehost>:

If you want to recursively copy  /var/www on the local host  to  /var/backup on the remote host you only have to type:

$ scp -r /var/www <remotehost>:/var/backup/



Chris Booth
Computer Officer (Unix Systems)
Systems and Security Team
The University of Nottingham
e.:    chris.booth at nottingham.ac.uk
t.:     +44 (0)115 951 3027 (+voicemail)
m.:   +44 (0)771 781 4012



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.