Use Terminal Colors to Prevent Errors

As administrators, we often are working on more than one system at a time. If you use screen as much as I do, you may find that all screens are indistinguishable from one another. This becomes a perfect place to separate the different systems into one or more xterms with different colors. You could try to use GNU screen colors (by adjusting the termcap and terminfo entries) but using xterm’s color set is easier.

Using multiple xterms (or rxvt terminals) you can color them in different ways to represent different systems. With different xterm windows, you can also separate the windows in space by putting them in different areas of the screen.

You can also set the backspace key when you start up an rxvt session. Use the –backspacekey option with the appropriate string (such as “^H”). Combined with the background and foreground colors, you could start rxvt with a command like:

rxvt -bg LemonChiffon -fg Black --backspacekey "^H"

The names of the colors can be seen in the file rgb.txt included with X11; in Red Hat Enterprise Linux, it can be found in /usr/share/X11/rgb.txt. For some reason, Ubuntu doesn’t have this file; it seems to be expected by many programs in either /etc/X11/rgb.txt or the previously mentioned /usr/share/X11/rgb.txt. For some strange reason, the folks at Ubuntu refuse to load it into the base; here is a bug report that showcases some of the back and forth on the topic. You can download the current rgb.txt and put it into the correct path if you have to.

My favorite colors for backgrounds – easy on the eyes, easy to read black text – are these:

  • LemonChiffon
  • SkyBlue
  • PowerBlue
  • IndianRed
  • Plum1
  • PaleTurquoise

There are complete lists of X11 colors on the web, such as this page or this page – or this sortable table of colors.

You can also see the colors through the use of the programs xcolors and xcolorsel, both of which do similar things. Both are available as packages for Ubuntu and both require rgb.txt which is probably missing. There don’t seem to be RPM packages for Red Hat Linux (and variants) xcolors or xcolorsel for some reason, although both OpenSUSE and Mandriva look like there should be some current packages for these programs.

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
  • XDMCP

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