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.
- 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 -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.
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.