Summary: System setups that are known to be buggy can persist for far too long unless you force yourself to take the time to revisit them periodically.

I'm on a lot of mailing lists, including one for my local LUG (Linux user's group) and tend to respond to a lot of questions from complete strangers.[1] For some reason it seems that in the last few weeks I've fielded an increased number of emails that I don't want to help out on, for example

1. "I can't get telnet to my machine - how can I disable the firewall?"
2. "I can telnet fine, but not as root, I need to su. How can I let root log in from the network directly over telnet?"
3. "I'm trying to change the password for a user, but it only let's me choose passwords that are longer than 4 characters, what's wrong?"

Each time I hear questions like this I take a deep breath. I know the answers.[2] The problem is that they want to do things to which I personally object, things that decrease the security of their systems.

People like to use the tools they're familiar with. Retraining people to do things in a new (more secure) way is very difficult. For instance when I took over a cluster of SGIs years ago I installed SSH across the board, but needed to leave telnet enabled for the PC users who needed to be able to log in.[3] However even those with Unix boxen on their desk, on which ssh was installed, didn't want to use SSH. I'd even set up users with passwordless logins and host-based trust across the machines. I noted the savings of three characters in "ssh" vs "telnet". Nothing worked until I replaced /usr/bin/telnet with a shell script that looked something like this:

  #!/bin/sh
  
  quit () {
	  echo "glad you came to your senses."
	  exit 0;
  }

  # If user specifies a port or no host at all, run real telnet binary.
  # Yes, this lets them type 'telnet host 23' - oh well.
  if [ $# -gt 1 ] ; then
	  exec /usr/bin/telnet.real "$@"
  elif [ $# -eq 0 ] ; then
	  exec /usr/bin/telnet.real
  fi
  
  # See if SSH is available on the target.  If not,
  # then invoke telnet.  (nc -z can be used as a poor man's port scan.)
  if ! `nc -z $1 22>/dev/null 2>&1` ; then
	  echo running telnet - ssh not running
	  exec /usr/bin/telnet.real "$@"
  fi

 
  # OK, they're using 'telnet hostname' to a machine that's running SSH.
  #
  # Forcibly instigate "worker retraining".

  echo "Are you sure you'd like to use telnet?"
  echo "We've installed SSH on this machine, which is much better."
  echo -n "use telnet anyway?  (yes/n)  "
  read a
  if [ "x$a" != "xyes" ] ;  then
	  quit
  fi

  echo "Are you *really* sure you'd like to use telnet?"
  echo "SSH will encrypt your sessions.  That's good..."
  echo -n "Should I stop and let you ssh? (nothanks/y)  "
  read a
  if [ "x$a" != "xnothanks" ] ;  then
	  quit
  fi
  
  ...
  # About three more yes/no questions, alternating the
  # response they must provide to make it harder.
  ...

  # give up, let them use telnet if they're so darned sure...
  exec /usr/bin/telnet.real "$@"

Everyone had become set in their ways. They were used to telnet, and even though a more secure, robust, and in this case even easier method was available, they wanted to stick to the old system.

Unfortunately, inertia is very common in any organisation. You need to be sure to periodically question the methods your organisation uses to do it's business. Any time you put functionality in place that isn't the most secure thing in the world, make sure to revisit it in three months time to see if there's a better way to do it later.[4]

For example, say your software push system requires that the software push account on the distribution server is able to rcp files to any machine in the company. This was common back in the days before SSH. The remote machines would trust connections coming from the IP address of the dist server. However that meant any machine that could steal the dist server's IP could connect to any other machine. Nowadays you could mirror that functionality using SSH and it's host-key based trust, or using SSH identities/pubkeys. Now someone would need to compromise the actual server, not just knock it offline.

Similarly, say you've got a webserver where people log in, fill out forms, and the form data emailed to the person in charge. It would be pretty trivial for a cracker to forge an email to look like the official emails. Instead, you could have the authenticated form data written to a database on the webserver, and create an SSL-encrypted authenticated web front end for the human to access the data. No longer is the (potentially sensitive) data going across the wire to be sniffed, or worse, manipulated or forged.

It's especially hard to justify taking the time to reinvent processes that are 'working'. However removing vulnerabilities in your setup will prevent you from looking the fool when someone breaks a system you set up ages ago which you know isn't secure.

NOTES:

[1] Note I said 'respond to' instead of answer, since I can be wrong just as much as the next guy. But if you've been reading my newsletter for a while, you already knew that.

[2]

1. ipchains -F or iptables -F, assuming the default policy is "ACCEPT".

2.  for tty in `perl -e 'print join " ", 1..30, "\n"'`
     do
      echo "/dev/pts/$tty">> /etc/securetty
     done
   

3. Edit /etc/pam.d/passwd, remove the min= argument from the password required line.

[3] This was a long time ago, before SSH clients were available for windows/mac, long before OpenSSH existed.

[4] Of course, it's always best to do it right the first time.

Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. None of his systems have any old, crufty, historical methods of operation. Really. None of his systems operate at all. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2003

This is the June 02, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Security-request@lists.onsight.com.