Securing your network traffic

If you want to start some exciting discussion in a security forum, just say you use telnet: you’ll find that every admin knows that telnet is insecure, that one should use OpenSSH or similar to encrypt the traffic, and that telnet should be banned from the server environment entirely.

However, telnet is not the only server that transmits its passwords in the clear. There are a lot of others. Here’s a list I came up with:

  • FTP
  • HTTP
  • IMAP
  • IPP
  • LDAP
  • LPD
  • NFS
  • POP3
  • rsync
  • SMTP
  • SNMP
  • syslog
  • VNC
  • X11

I won’t cover all of these here (more about these items can be found in my book) but I do want to cover just a few.

Consider, for example, the mail protocols: SMTP, POP3, and IMAP. SSL encryption is available with all three – but do you use it? And what about your logins to your mailbox at your ISP? Every time you login, your password to your mailbox goes across the wire in the clear.

What about NFS – particularly NFS home directories? If you have unencrypted secrets in your home directory, then these items will be transmitted across the network in the clear as well. What about private SSH keys? Unfortunately, there is no way to encrypt NFS traffic.

VNC is another one to watch for: if you type passwords for your root logins over VNC – even if you are using SSH in your VNC session – the passwords are in the clear. The only way to secure VNC entirely is to use an SSH tunnel to encrypt it.

X11 is insecure in the same way, but presents special problems. However, OpenSSH handles X transparently through the use of special tunnels just for X.

syslog is another unencrypted service; do you have passwords put into the system logs? What about secret doings of your servers? How much information leakage can you handle? Unfortunately, syslog is another service that cannot be secured unless you use something such as syslog-ng which permits you to use TCP (and thus, an OpenSSH tunnel).

Why does my ksh login hang? (HP-UX)

Recently I had the problem of ksh logins under HP-UX hanging. The symptom was that the login process would appear to work, all of the system profile and the user’s profile would be executed, then the login would hang.

This happened in Korn shell (ksh), but not the default POSIX shell (sh).

Turns out this is a FAQ (!) even though it’s something I’ve not run into these many years. In the comp.sys.hp.hpux faq it is question and answer 8.7. The answer to both symptoms is the fact that the history file ($HOME/.sh_history) is on an NFS mount. In the book Optimizing NFS Performance: Tuning and Troubleshooting NFS on HP-UX Systems (by Dave Olker) he discusses (in section 6.4: Avoiding NFS File Lock Hangs in Your Environment) how NFS locks can cause hangs such as the Korn shell hanging. A small portion of section 6.4 can be read online.

This also was discussed in this message thread on a LDAP mailing list. Turns out that the Korn shell was hanging as it was trying to open the history file ($LOGNAME/.sh_history). To fix the problem, move the history file to /tmp or some other local directory. One suggestion was /tmp/.sh_history.$$; there is probably a better idea which is more secure.

One solution was to make the NFS-mounted file mode 777; but this is definitely insecure and not a good idea.