Network archives - Open Source Software and Linux

Open Source Software and Linux:

network

Feb 12 2009   1:19AM GMT

How secure is your network? (Part 2)



Posted by: John Little
network, breach, harden, hardening, Security, secure, attack, dos

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
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
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.

#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the “wheel” group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the “wheel” group.
auth required pam_wheel.so use_uid <==uncomment this line
auth include system-auth
account sufficient pam_succeed_if.so uid = 0 use_uid quiet
account include system-auth
password include system-auth
session include system-auth
session optional pam_xauth.so

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.
hosts.allow:

sshd: 172.16.0.201

hosts.deny:

ALL: ALL

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
libwrap.so.0 => /usr/lib/libwrap.so.0 (0×00ddf000)
[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/dist.su /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/id_rsa.pub.jlittle >> /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.

-j

Feb 11 2009   6:47PM GMT

How secure is your network? (Part 1)



Posted by: John Little
Security, network, Firewalls, hackers, crackers, ssh

After reading this article I began to wonder how secure my home network really is. After giving the article much thought I concluded that my home network is probably not as secure as I would want.

Sure it’s secure, probably above and beyond most home networks. I use iptables as my firewall. Connections from the internet are directed to a particular machine based on the inbound port. SSH connections from the outside are directed to one machine so that you must be able to get to that machine to reach the rest of the network. My web server uses standard apache security. Seems reasonably secure for a home network. Maybe.

After all I’m not a millionaire. I don’t have other people’s confidential information on my network. I’m not the FAA or a bank. No one in their right mind would try and extort money from me based on the information contained on my network. Besides, what little I could give them wouldn’t make it worth their time. However these justifications just don’t give me a warm and fuzzy feeling inside.

Crackers don’t necessarily just want those things. Sometimes it is just vandalism by tearing up someone’s machine. Or they may want to use a machine to setup a DOS attack. It could be that they want to use the mail server as a mail relay for spam. Whatever it is I don’t want to have to take the time to clean up after them. After all if they can break into the networks listed in the article it would seem rather arrogant of me to think that they couldn’t break into mine.

The question then becomes what to do to make it more secure. Below I’ve created a scope sheet of sorts of work that needs to be done.

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

What else can I do? I’ll give that some thought. If you have suggestions post them in the comments. It is always interesting to hear how other people secure their networks above and beyond the norms.

In my next post I’ll describe the changes that I’ve made based on the scope of work above.

-j