[We need to finally settle on a logo]
... although we have done fine without one for five years

Hardening your instance

-- Part 1

Some people have asked about hardening. Jim Perrin's outline at

http://wiki.centos.org/HowTos/OS_Protection

is quite suitable, but has much not really applicable to a virtual unit in a secure data center. Jim mentions the NSA hardening guide, which seems not to have been updated since December 2007 in its version 2. I had laid out this copyright free item U S Government (NSA) work at Lulu so I could have a desk reference, and a softbound copy may be bought through link. There is a pamphlet [pdf, 246k] summary as well.

Disallowing password based access

See: man 5 sshd_config

Adding the changes totally eliminating use of password based authentication to

/etc/ssh/sshd_config 
comes to mind:
[root@hostname directory]# diff -u /etc/ssh/sshd_config.rpmnew /etc/ssh/sshd_config
--- /etc/ssh/sshd_config.rpmnew 2009-12-16 20:15:09.000000000 -0500
+++ /etc/ssh/sshd_config        2009-11-13 17:52:27.000000000 -0500
@@ -57,23 +57,23 @@
 # To disable tunneled clear text passwords, change to no here!
 #PasswordAuthentication yes
 #PermitEmptyPasswords no
-PasswordAuthentication yes
+PasswordAuthentication no

 # Change to no to disable s/key passwords
 #ChallengeResponseAuthentication yes
 ChallengeResponseAuthentication no

 # Kerberos options
-#KerberosAuthentication no
+KerberosAuthentication no
 #KerberosOrLocalPasswd yes
 #KerberosTicketCleanup yes
 #KerberosGetAFSToken no

 # GSSAPI options
-#GSSAPIAuthentication no
-GSSAPIAuthentication yes
+GSSAPIAuthentication no
+# GSSAPIAuthentication yes
 #GSSAPICleanupCredentials yes
-GSSAPICleanupCredentials yes
+# GSSAPICleanupCredentials yes

 # Set this to 'yes' to enable PAM authentication, account processing,
 # and session processing. If this is enabled, PAM authentication will
@@ -110,7 +110,6 @@
 #PidFile /var/run/sshd.pid
 #MaxStartups 10
 #PermitTunnel no
-#ChrootDirectory none

 # no default banner path
 #Banner /some/path
[root@hostname directory] #

and restart the ssh service

/sbin/service sshd restart

to make sure the edits were properly made, and to have them take effect.

Restricting 'root' access

See: man 5 securetty

We ship minor changes to /etc/securetty, to support the virtualization console connections for manual recovery. Tread carefully making changes here.

'wrappers' to restrict access

Then of course, one should remember wrappers. Start by reading: man 8 tcpd

wrappers are perhaps considered passe, and too often overlooked in this age of iptables. We presently do not ship with a default set, but will probably add sample ones to a base install, along the lines of:

#	/etc/hosts.allow
ALL:    ALL@127.0.0.1
sshd:    ALL@10.0.0.0/255.0.0.0
#
#	be careful restricting this one
sshd:	ALL@ALL
#
#	add your IP for other services to taste
#

and then the restricting catch-all

#       /etc/hosts.deny
ALL:    ALL@ALL
#

and test the propose change by leaving the edit on /etc/hosts.allow open but temporarily commenting out the line:

sshd:	ALL@ALL

Then attempt to connect both from the permitted IP block (which should 'just work' in the usual fashion), and also from a non-permitted one. The latter attempted connection should be immediately closed in this fashion:

[userid@hostname directory]$ ssh -l root 198.49.244.196
ssh_exchange_identification: Connection closed by remote host
[userid@hostname directory]$ 

If the edits were properly made, the proper IPs or IP blocks specified, the blocking function takes effect at once with no re-starts needed. One nice side effect of adding proper wrappers is that the 'dictionary attack' connection attempts under ssh that usually clutter the log file /var/log/messages will stop (assuming the attacks are not coming from IP addresses you have added trust for in /etc/hosts.allow ).

It is usually a good idea to have a couple of permitted blocks pre-staged, to provide a 'backdoor' or two. the PMMan interface also a tool to 'move aside' the /etc/hosts.deny file, so that one can recover access through the web control form as well, assuming the 'backside' RFC-1918 network entry [the line: sshd: ALL@10.0.0.0/255.0.0.0]is not tampered with. If it somehow damaged, tech support will need to do some manual and 'hands on' recovery of the box, through a paid support ticket.

iptables to restrict access

The relevant part of /etc/sysconfig/iptables in a stock PMman virtual instance, is this:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
   ...
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
   ...
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

One relevant variation to restrict that to only say:

1.2.3.4
44.55.66.77

might look like this:

# Firewall configuration written by system-config-securitylevel
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo   -j ACCEPT
-A RH-Firewall-1-INPUT -i eth1 -j ACCEPT
   ...
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp                        --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -i eth0 -s 1.2.3.4     --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -i eth0 -s 44.55.66.77 --dport 22 -j ACCEPT
   ...
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

Note: We use blue font for additions, and strike through to note a line to remove. The deleted line was 're-formatted' to show the additions more clearly.

The first line is to ensure that access for the control interface of the web tool over the 'backside network' is preserved; the last two add IP's on a 'one per' basis

Then attempt to connect both from the permitted IP block (which should 'just work' in the usual fashion), and also from a non-permitted one. Unlike with wrappers and the immediate close of the connection, when a connection start is not permitted in iptables it 'just sits there', and evenually simply 'times out'. That is, the latter attempted connection should be eventually closed in this fashion:

[userid@hostname directory]$ ssh -l root 198.49.244.196
ssh: connect to host 198.49.244.196 port 22: Connection timed out
[userid@hostname directory]$
This may be seen more immediately with nmap by doing a TCP ping on port 22 (the 'well known' SSH connection port) thus:

[userid@hostname directory]$ nmap -sT -p22 198.49.244.196

Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap run completed -- 1 IP address (0 hosts up) scanned in 36 seconds
[userid@hostname directory]$

Note: nmap is a well known and powerful network probing tool. Please do not use it to probe networks or hosts that you are not expresly permitted to run such 'pen testing' ("penetration testing").

If the edits were properly made, the proper IPs or IP blocks specified, one has to cause the new iptables rules to be reloaded to have them take effect.

/sbin/service iptables restart

As before a nice side effect of adding proper wrappers is that the 'dictionary attack' connection attempts under ssh that usually clutter the log file /var/log/messages will stop (assuming the attacks are not coming from IP addresses for which you have added trust in /etc/sysconfig/iptables ).

It is usually a good idea to have a couple of permitted blocks pre-staged, to provide a 'backdoor' or two. the PMMan interface also a tool to 'move aside' the /etc/hosts.deny file, so that one can recover access through the web control form as well, assuming the 'backside' RFC-1918 network entry [the line:   sshd: ALL@10.0.0.0/255.0.0.0  ] is not tampered with. If it somehow damaged, tech support will need to do some manual and 'hands on' recovery of the box, through a paid support ticket.

Feedback please

We welcome suggestions of course.


[  Top  |  About  |  Sign Up  |  LOG ON  |  Tour  |  News  |  Support  |  Media  |  Site Map  |  EULA  |  Legal  |  DMCA  |  Contact  ]

Copyright © 2009 PMMan.com, a division of 781 Resolution, LLC

Valid HTML 4.0 Transitional