+------------------------------------------------------------------+ | Linux Security: Tips, Tricks, and Hackery | | Published by Onsight, Inc. | | | | 02-June-2003 | | http://www.hackinglinuxexposed.com/articles/20030602.html | +------------------------------------------------------------------+ This issue sponsored by Gibraltar Software, Inc., your best source for Secure Patch Management. With Gibraltar Software's flagship security product, the Everguard (tm) System, sysadmins can now run one tool to keep a network of Linux, Windows, and Solaris machines completely patched and up-to-date. Everguard 2.0 features remote deployment capabilities, automated software discovery and tracking, centralized management, a variety of reporting tools, and rated priority to patches. Everguard 2.0 is the most secure cross-platform patch management system available today. For more information, visit our website at http://www.dvpm.com/ -------------------------------------------------------------------- Challenge yourself to get rid of insecure software. By Brian Hatch 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. ------------- Brian 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. Brian can be reached at brianat_private -------------------------------------------------------------------- This newsletter is distributed by Onsight, Inc. The list is managed with MailMan (http://www.list.org). You can subscribe, unsubscribe, or change your password by visiting http://lists.onsight.com/ or by sending email to linux_security-requestat_private Archives of this and previous newsletters are available at http://www.hackinglinuxexposed.com/articles/ -------------------------------------------------------------------- Copyright 2003, Brian Hatch. - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Tue Jun 03 2003 - 01:05:41 PDT