Open Source Software and Linux

Feb 12 2009   1:19AM GMT

How secure is your network? (Part 2)

John Little Profile: Xjlittle

In my last post I referred to an article about the number of security breaches in networks across the U.S. This has caused economic losses of an estimated trillion dollars.

As I mentioned in that post my home network certainly doesn’t rank with those mentioned in the article but it did give me pause to consider the security of my network. In that post I outlined some things that I wanted to harden on my network as follows:
1. Disallow ssh root logins
2. Disallow su to root except for certain users
3. Disallow internal ssh logins to any machine on the network. These logins must come from the “jump” machine

An overview of my network: I have a 1u server running Centos 5.2 using the native virtualization. All of the servers on the machine are para-virtualized and run Centos 5.2 with the exception of the NAS fronted. This is from the Openfiler project at rpath. These include file, web, a NAS frontend, database, dns, dhcp and a firewall. A NIC is imported to the firewall machine which is directly connected to the internet. All of the machines share a common NFS mount. Service requests inbound from the internet are forwarded to the appropriate machine based on the port number.

I disallowed ssh root logins by editing the /etc/ssh/sshd_config file as shown below.

Protocol 2
SyslogFacility AUTHPRIV
PermitRootLogin no <==changed this to no
MaxAuthTries 2 <==changed this to 2
PasswordAuthentication yes
ChallengeResponseAuthentication yes <==changed this to yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM yes
X11Forwarding yes
Subsystem sftp /usr/libexec/openssh/sftp-server

The above is the stock sshd_config file with the noted changes made.

I disallowed su to root by removing the comment on a line in /etc/pam.d/su. This file is shown below.

auth sufficient
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth required use_uid <==uncomment this line
auth include system-auth
account sufficient uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional

After making this change I added my account to the wheel group so that I could su to root as necessary. I also modified the sudoers file and added the following line so that I could use sudo and not have to su to root for short administrative tasks:

jlittle ALL=(ALL) ALL

Again all of these files are the stock CentOS files except for the changes.

I then edited the tcpwrappers files, /etc/hosts.allow and /etc/hosts.deny, so that the machines would only except ssh connections from the “jump” machine in the internal network.




If you want to check to see if a binary is tcpwrappers aware such as sshd use the following command:

[root@fw0 ~]# ldd `which sshd` |grep libwrap => /usr/lib/ (0x00ddf000)
[root@fw0 ~]#

Substitute the binary that you want to check for sshd.

To speed the changes along I copied all of the modified files to the shared NFS mount. I then created a script to replace the existing files, add my username to all of the machines and enter my ssh public key into ~/.ssh/authorized_keys. All I had to do at this point was login to each machine and run the script to make the changes. The script follows. Make sure that you adjust it to fit your needs if you want to use it.

cp -af /srv/secure/hosts.* /etc
cp -af /srv/secure/ /etc/pam.d/su
cp -af /srv/secure/sshd_config.root /etc/ssh/sshd_config
cp -af /srv/secure/sudoers.jlittle /etc/sudoers
useradd jlittle
usermod -a -G wheel jlittle
passwd jlittle
[ -d /home/jlittle/.ssh ]
if [ $? -ne 0 ]; then mkdir /home/jlittle/.ssh; fi
cat /srv/secure/ >> /home/jlittle/.ssh/authorized_keys
chmod -R 600 /home/jlittle/.ssh && chown -R jlittle:jlittle /home/jlittle/.ssh
service sshd restart

There you have it. An hour of two of work and I have hardened my network a little more. This coupled with strong passwords goes a long way in securing your network from inside and outside attacks.


 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: