[Network Administration]: Some Notes on Security

Before moving on, I’ll put some notes here on security. Basically, there really isn’t any. At some point, if someone really wants to get in, they’re going to. Hopefully, it won’t be malicious, and it won’t be that easy, but unless you’re completely isolated from the internet, I just don’t see any way that a machine can be completely secure. Possibly the best way is to try to stay out ahead. There are some things that can make things harder for an intruder. Probably, the best way is to really limit the number of network services. Especially, ways that are less secure. The less services running that are unneeded, the less visibility on the network. Also, I don’t have my KDC or LDAP server directly accessible from the internet. Of course, all of this means that it’s all less accessible to me, but that’s something that I can live with. Also, there is a very limited set of users who have access.

Disabling Services

  • Disable telnetd. It’s insecure, and there are more secure alternatives out there. Even better, don’t even install it.
  • Disable NFS if you can get away with it. It’s not secure, and it’s another means to get into the system. Especially, if anything runs off the NFS shares.

Review the list of ports that are open
You can get a list of open ports and the processes associated with them to verify that there is nothing with an open port that is not expected. The command netstat will dump out a list

root@hopper:~# netstat -tulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 *:kerberos              *:*                     LISTEN      1178/krb5kdc    
tcp        0      0 localhost:smtp          *:*                     LISTEN      1328/master     
tcp        0      0 localhost:953           *:*                     LISTEN      1197/named      
tcp        0      0 *:ldaps                 *:*                     LISTEN      1357/slapd      
tcp        0      0 *:ldap                  *:*                     LISTEN      1357/slapd      
tcp        0      0 *:kerberos-adm          *:*                     LISTEN      1185/kadmind    
tcp        0      0 *:kpasswd               *:*                     LISTEN      1185/kadmind    
tcp        0      0 hopper.internal.:domain *:*                     LISTEN      1197/named      
tcp        0      0 localhost:domain        *:*                     LISTEN      1197/named      
tcp        0      0 *:ssh                   *:*                     LISTEN      1156/sshd       
tcp6       0      0 [::]:kerberos           [::]:*                  LISTEN      1178/krb5kdc    
tcp6       0      0 localhost:smtp          [::]:*                  LISTEN      1328/master     
tcp6       0      0 [::]:ldaps              [::]:*                  LISTEN      1357/slapd      
tcp6       0      0 [::]:ldap               [::]:*                  LISTEN      1357/slapd      
tcp6       0      0 [::]:kerberos-adm       [::]:*                  LISTEN      1185/kadmind    
tcp6       0      0 [::]:kpasswd            [::]:*                  LISTEN      1185/kadmind    
tcp6       0      0 [::]:ssh                [::]:*                  LISTEN      1156/sshd       
udp        0      0 *:kpasswd               *:*                                 1185/kadmind    
udp        0      0 *:kerberos4             *:*                                 1178/krb5kdc    
udp        0      0 hopper.internal.:domain *:*                                 1197/named      
udp        0      0 localhost:domain        *:*                                 1197/named      
udp        0      0 *:kerberos              *:*                                 1178/krb5kdc    
udp        0      0 hopper.internal.foo:ntp *:*                                 1541/ntpd       
udp        0      0 localhost:ntp           *:*                                 1541/ntpd       
udp        0      0 *:ntp                   *:*                                 1541/ntpd       
udp6       0      0 [::]:kpasswd            [::]:*                              1185/kadmind    
udp6       0      0 [::]:kerberos4          [::]:*                              1178/krb5kdc    
udp6       0      0 [::]:kerberos           [::]:*                              1178/krb5kdc    
udp6       0      0 fe80::201:2eff:fe48:ntp [::]:*                              1541/ntpd       
udp6       0      0 localhost:ntp           [::]:*                              1541/ntpd       
udp6       0      0 [::]:ntp                [::]:*                              1541/ntpd       

From the list, you can see that there are ports listening for kerberos, smtp (MTS), bind (DNS), LDAP, and SSH daemon. There are the one that are expected, and I don’t have anything unusual listening that shouldn’t. Originally, when I looked at this, I did have RPC-bind running which was required for NFS, but I’ve disabled this, and it’s one less port that I need to worry about.

Use secure remote access
For machines that require remote access, SSH is a much more secure protocol than telnet. The Secure Shell protocol transmits it’s information over an encrypted session, whereas telnet will transmit data, including passwords, in cleartext. Setting up a SSH daemon is fairly straight forward. Under Ubuntu, the package is called openssh-server. The package is installed with

sudo apt-get install openssh-server

Also, password authentication should be disabled. SSH allows for key based authentication which is much more resilient to brute-force and dictionary attacks. I’ll use a 2048-bit key, which is equivalent to a 256-character random character password. Here are some of the relevant parts of the openssh daemon configuration file. The man page for sshd_config is useful here.

ServerKeyBits 2048

# Authentication:
PermitRootLogin no

# Set the allowed users. Previously non-existant
# Only allow administrator to connect
AllowUsers administrator

PubkeyAuthentication yes
AuthorizedKeysFile      /usr/local/etc/ssh/%u/authorized_keys

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to no to disable tunnelled clear text passwords
# No passwords, keys only - '#PasswordAuthentication yes'
PasswordAuthentication no

The first line sets the server key length to be 2048 bits. The next two lines will disable root login through ssh, and then only allow the administrator account to log in. This reduces the number of accounts that have access, and I don’t need to worry about other users getting in if their accounts are compromised. The next line enables public-key authentication. This is what we want to use. The line after this specifies the location of the authorized keys which can connect. The standard value of this variable locates the keys inside the users home directory. In most cases this is a fine, but since I am using encrypted home directories, I cannot locate my keys there. The directories are unencrypted once the user has already been authenticated. Since the key is unavailable during the authentication process, we need to put them in a place that they are available at the time. The permissions for the directories and keys need to be associated with the user, and not with the SSH daemon since it will attempt to read them as the user. Continuing, we disable the use of empty passwords, since that’s a giant security hole, and finally disable password based authentication.
An ssh key is generated using ssh-keygen

ssh-keygen -t rsa -b 2048 -f <keyfile>

This will generate an RSA key with 2048 bits, and the associated public key with a .pub suffix on the end. Once the key is generated, it needs to be installed on the server. Instead of using ssh-copy-id, I’ll generate the key on the machine onto a flash drive (since I usually store the keys there), and then manually copy the public key into the AuthorizedKeysFile. You should be able to connect to the machine.

ssh -i <location of private key file> user@host

If there is an error, the argument -v will generate verbose output. Sometimes there is a permissions problem with the AuthorizedKeysFile directory and the user’s /ssh directory. If the permissions are too lenient, then the connection will fail if StrictModes is set to “yes” in sshd_config(the default). It cannot have group/other read/write permissions.

Reviewing Logs
Review the logs. It gives insight into what’s happening to the machine, how much activity it’s responding to, and if there is anything anomalous that may need to be investigated.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s