Archive for the ‘ Linux Security ’ Category

Checking For A DoS

Monday, November 17th, 2008

Working on groups of web servers, especially ones that are highly susceptible to attack, it is a good idea to have a string of commands that will allow you to check what is going on.

Check for DDos:

netstat -n | grep EST | awk '{ print $5 }' | cut -d: -f1 | sort | uniq -c | sort -nr | perl -an -e 'use Socket; ($hostname, @trash) = gethostbyaddr(inet_aton($F[1]), AF_INET); print "$F[0]\t$F[1]\t$hostname\n";'

Using this command will produce a list of hostnames that have a connect to the machine in an ESTABLISHED state. This is handy for creating a firewall rule either on the host (iptables, ipfw) or a little further away from the machine (at the edge router).

Check for web attacks:

cat | awk '{print $1 }' | sort | uniq -c | sort -nr | head | perl -an -e 'use Socket; ($hostname, @trash) = gethostbyaddr(inet_aton($F[1]), AF_INET); print "$F[0]\t$F[1]\t$hostname\n";'

By using this command, you will get a hostname lookup on the IP sorted by total hit count descending. As when checking for DDos attacks, you can use this information to write firewall rules.

More web attack checks:

for i in `ls *.20081015 | grep -v error`; do echo "##### $i ######"; tail -n 10000 $i| awk '{print $1};' | sort -n | uniq -c | sort -nr | head -2; done

The difference between this check and the previous check is that this time, you may have a lot more logfiles to go through. I am also assuming that they are stored by .. They will print out which file its scanning and the top 2 issues from that file.

Referrer Check:

for file in `ls -lrS *access*20080525* | tail -n20`; do echo "==========" $file; gawk --re-interval -F'"' '{ split($4, myrt, "/");  split($0, myct); split(myct[3], myc, " "); if (length(myrt[3])==0) { myrt[3]="none"}; if (myrt[3] ~ /([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}/) { referrers[myrt[3]"/"myc[1]]++; } else { t=split(myrt[3], myrt2, "."); myref="*."myrt2[t-1]"."myrt2[t]; referrers[myref"/"myc[1]]++; } } END { for (referrer in referrers) { print referrers[referrer], referrer } }' $file | grep -v none | sort -n; done

This last check will get the referrer for a page from the logs and count up the number of times that exact referrer drives traffic to your page. Although this may initially appear to be only tangentially useful, if you are getting DDos, it may be hard to track down. Let’s say that you have some static content like a funny image and want to know why everyone is going to that image. Maybe your getting Dugg or ./ and this will help you tell (and find out what your page is so you can Digg yourself if you’re into that sort of thing).

SSH Organization Tips

Friday, February 9th, 2007

Over the years, I have worked with many SSH boxen and had the pleasure to manage even more SSH keys. The problem with all that is the keys start to build up and then you wonder which boxes have which keys in the authorized keys file and so on and so on. Well, I can’t say I have the ultimate solution, but I do have a few tips that I have come across along the way. Hopefully they will be of use to someone else besides myself.

  1. Although this should hopefully already be done (my fingers are crossed for you), check the permissions on your ~/.ssh directory and the file contained in it.
    $ chmod 700 ~/.ssh
    $ chmod 600 ~/.ssh/id_dsa
    $ chmod 640 ~/.ssh/
  2. Now that SSHv2 is pretty widely accepted, try using that for all your servers. If that isn’t possible, then try to use SSHv2 whenever possible. This means a few things.
    1. Change your /etc/ssh/sshd_config file to say:
      Protocol 2

      instead of

      Protocol 1
    2. Don’t generate anymore RSA keys for yourself. Stick to the DSA keys:
      $ cd ~/.ssh
      $ ssh-keygen -t dsa
    3. Use public key based authentication and not password authentication. To do this change your /etc/ssh/sshd_config file to read:
      PubkeyAuthentication yes

      instead of

      PubkeyAuthentication no
  3. Keeping track of which keys are on the machine is a fairly simple yet often incomplete task. To allow for a user to login using their SSH(v2) key, we just add their public key to the ~/.ssh/authorized_keys file on the remote machine:
    1. Copy the file to the remote machine:
      $ scp user@host:.ssh/
    2. Append the key onto the authorized_keys file:
      $ cat ~/.ssh/ >> ~/.ssh/authorized_keys

    Before moving on here and just deleting the public key, let’s try some organizational techniques.

    1. Create a directory in ~/.ssh to store the public keys in:
      $ mkdir ~/.ssh/pub
    2. Move the public key file into that directory and change the name to something useful:
      $ mv ~/.ssh/ ~/.ssh/pub/
    3. NOTE: Don’t do this unless you are sure that you can log in with your public key otherwise you WILL lock yourself out of your own machine.

  4. Now a little of the reverse side of this. If a public key is no longer is use, then you should remove it from your ~/.ssh/authorized_keys file. If you have been keeping a file list in the directory, then the file should be removed from the directory tree as well. A little housekeeping is not only good for security, but also some piece of mind in efficiency and general cleanliness.
  5. Although this last item isn’t really organizational, it is just really handy and I will categorize it under the title of efficiency. Using ssh-agent to ssh around. If you are a sysadmin and you want to only type your passphrase once when you login to your computer, then do the following:
    1. Check to see if the agent is running:
      $ ssh-add -L

      NOTE: If ssh-agent is not running, it will say The agent has no identities.

    2. If its running, continue to the next step, otherwise type:
      $ ssh-agent
    3. Now to add your key to the agent’s keyring, type:
      $ ssh-add

    SSH to a machine that you know has that key and you will notice that you will no longer have to type in your passphrase while your current session is active.

These are just some tricks that I use to keep things sane. They may not work for you, but some of them are good habits to get into. Good luck.

10 More Tips Towards Securing Your Linux System

Wednesday, January 31st, 2007

Since everyone seemed to enjoy my first round of tips and tricks to securing a linux system, I figured I would throw together a few more. Enjoy.

  1. There are files that get changed very infrequently. For instance, if your system won’t have any users added anytime soon then it may be sensible to chattr immutably the /etc/password and /etc/shadow files. Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.
       chattr +i /etc/passwd /etc/shadow
  2. Password protect your linux install with LILO. Edit your /etc/lilo.conf. At the end of each linux image that you want to secure, put the lines:
       password = MySecurePassword

    Ensure you rereun /sbin/lilo so the changes take effect.

  3. Users who have sudoer (sudo) accounts setup can have the account setup to change to root without a password. To check this, as root use the following command:
       grep NOPASSWD /etc/sudoers

    If there is an entry in the sudoers file, it will look like this:

       eric    ALL=NOPASSWD:ALL

    To get rid of this, type visudo and remove the line in that file.

  4. Use sudo to execute commands as root as a replacement for su. In the /etc/sudoers file, add the following lines by using the visudo command:
       Cmnd_Alias LPCMDS = /usr/sbin/lpc, /usr/bin/lprm
       eric    ALL=LPCMDS

    Now the user ‘eric’ can sudo and use the lpc and lprm commands without having any other root level access.

  5. Turn off PasswordAuthentication and PermitEmptyPasswords in the SSH configuaration file /etc/ssh/sshd_config. This will ensure that users cannot set empty passwords or login without SSH keys.
       PermitEmptyPasswords no
       PasswordAuthentication no
  6. Instead of using “xhost +” to open up access to the X server, be more specific. Use the server name that you are allowing control to:
       xhost +storm:0.0

    Once you are done using it, remember to disallow access to the X server from that host:

       xhost -storm:0.0
  7. To find out the .Xauthority magic cookie looks like and to send it (authorization information) to the remote host, use the following command:
       xauth extract - $DISPLAY | ssh storm xauth merge -

    Now the user who ran this command on the original host can now run xcilents on storm. xauth needs to be present on both hosts.

  8. To turn on spoof protection, run a simple bash script:
       for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i done;

    Be careful to remember that it drops packets more or less ‘invisibly’.

  9. A SYN-flood attack has the ability to bring the network aspect of your linux box to a snail like crawl. TCP_SYNCookies protection attempts to stop this from taking a heavy toll on the machine. To enable cp_syncookies
    protection, use the following command:

       echo 1 > /proc/sys/net/ipv4/tcp_syncookies
  10. When possible use secure connection methods as opposed to insecure methods. Unless you are required to use telnet, substitute ssh (Secure SHell) in for rsh or telnet. Instead of POP3 or IMAP use SPOP3 or SIMAP (IMAPS). Both SIMAP and SPOP3 are just versions of IMAP and POP3 running over an SSL (Secure Socket Layer) tunnel.

10 Tips To Start Securing Your Linux System

Monday, January 29th, 2007

A while back I had been asked to write a few quick tips that as an administrator, one would find helpful. They published in one form or another and are now available here. There are MANY more, but these are just a few. Enjoy.

  1. Users who may be acting up or aren’t listening can still be controlled. Using a program called ‘skill’ (signal kill) which is part of the ‘procps’ package.
       Halt/Stop User eric: skill -STOP -u eric
       Continue User eric: skill -CONT -u eric
       Kill and Logout User eric: skill -KILL -u eric
       Kill and Logout All Users: skill -KILL -v /dev/pts/*
  2. Make use of security tools out there to test your server’s weaknesses. Nmap is an excellent port scanning tool to test to see what ports you have open. On a remote machine, type the command:
       # nmap -sTU <server_ip>

       Starting nmap 3.70 ( ) at 2006-08-10 13:51 EST
       Interesting ports on eric (
       (The 3131 ports scanned but not shown below are in state: closed)
       PORT    STATE         SERVICE
       22/tcp  open          ssh
       113/tcp open          auth

       Nmap run completed -- 1 IP address (1 host up) scanned in 221.669 seconds
  3. On a production server that is in a common area (although this should not be the case, some situations are inevidable). To avoid an accidental CTRL-ALT-DEL reboot of the machine, do the following to remove the necessary
    lines from the /etc/inittab file:

       # sed -i 's/ca::ctrlaltdel:/#ca::ctrlaltdel:/g' /etc/inittab
  4. Two SSH configuration options that can be set to improve security should be checked on your production server. UsePrivilegeSeparation is an option, when enabled will allow the OpenSSH server to run a small (necessary) amount of code as root and the of the code in a chroot jail environment. StrictModes checks to ensure that your ssh files and directories have the proper permissions and ownerships before allowing an SSH session to open up. The
    directives should be set in the /etc/ssh/sshd_config as follows:

       UsePrivilegeSeparation yes
       StrcitModes yes
  5. The default umask (usermask) on most systems should be 022 to ensure that files are created with the permissions 0644 (-rw-r–r–). To change the default umask setting for a system, edit /etc/profile to ensure that you umask is appropriate for your setup.
  6. Some users like to have a passwordless account. To check this you need to look at the /etc/shadow account with the following command line:
    awk -F: '$2 == "" { print $1, "has no password!" }' /etc/shadow
  7. Just in case someone else who has access to the superuser account decided to alter the password file and potentially make themselves a superuser. This is a method to check:
       awk -F: '$3 == 0 { print $1, "is a superuser!" }' /etc/passwd
  8. Setuid and Setgid files have the potential to be very hazardous if they are accessilbe by the wrong users on the system. Therefore it is handy to be able to check with files fall into this category.
       find /dir -xdev -type f -perm +ug=s -print
  9. World writable files can be left around by users wanting to make things easier for themselves. It is necessary to be careful about who can write to which files. To find all world writable files:
       find /dir -xdev -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print
  10. Some attackers, prior to attacking a host, (or users nmaping a host) will check to see if the host is alive. They do this by ‘ping’ing the host. In order to check if the host is up, they will use an ICMP echo request packet.
    To disallow these types of packets, use iptables:

       iptables -A INPUT -p icmp --icmp-type echo-request -j DROP

Brian Hatch & Duane Dunston Interview

Monday, December 25th, 2006

This is a re-post (or posting to my blog) of an interview I had done for Linux Security in September of 2002. The original article is available here.

Just to give everyone an idea about who writes these articles and feature stories that we spend so much of our time reading each day, I have decided to ask Brian Hatch and Duane Dunston, the newest members of the team, a few questions. I’d also like to begin by thanking both Brian Hatch and Duane Dunston for allowing us to conduct this interview.

Before we get to that, let me give you a brief introduction as to who these folks are, although I promise you that you will receive plenty of insight the further you read:

Brian Hatch is Chief Hacker at Onsight, Inc.[1] where he is a Unix/Linux and network security consultant. His clients have ranged from major banks, pharmaceutical companies and educational institutions to major California web browser developers
and dot-coms that haven’t failed. He has taught various security, Unix, and programming classes for corporations
through Onsight and as an adjunct instructor Northwestern University. He is also co-maintainer of Stunnel[2], an Open Source secure SSL wrapper used around the world to encrypt clear text protocols.

Brian Hatch has been interviewed several times on his stances on security, full disclosure, and Open Source technologies. (See interview 1 and interview 2.) Rather than retrace this ground, we thought we’d ask questions geared toward his personal rather than professional endeavors.

Duane Dunston is a Computer Security Analyst at STG Inc. for the National Climatic Data Center[3] in Asheville, NC. He received his B.A. and M.S. degrees from Pfeiffer University and he has his GSEC certification from SANS[14]. Not only does he enjoy his work in computer security, he also likes to get involved in its ever-growing technologies.

LS: How did you attain your security knowledge? Did you get a CS degree, or was it on your own?

Brian: I had your formal four year college education, but during that time had only one official computer class – Pascal – because they wouldn’t teach C at the time. All my Unix, C, and security knowledge was self taught from the man pages, which is definitely not the way I’d suggest for maintaining sanity. Nowhere is there an ‘asterisk means pointer’ man page. Suffice it to say, my early C code was ugly as sin. Luckily I’ve deleted every copy, and burned the tape backups.

Frequently I’m brought into security gigs in early stages to make decisions and get infrastructure in place, and then hand off the project to an employee, which means I frequently find myself in a position where I make hiring decisions. Because of my non-formal background, I am able to go in without preconceptions that certifications are the only mark of quality, and am able to get some extremely qualified folks hired even though they are sans certifications. (Pun intended.)

Had I been a CS major, there still would have been no chance to take security-related classes at the time anyway – there was no security emphasis at the time. There was a small group of us who would compare notes and tricks, and this was invaluable, more than any formal classes would have been. Hopefully more educational institutions are integrating security concepts into their curriculum, because without it the code being whipped up throughout the world will continue to be largely crap. Programs with buffer overflows are unconscionable, and yet they pop up in every product out there still, despite being a known quantity with well defined solutions.

Duane: I graduated from Pfeiffer University in 1997 with a BA in Sociology, the day after I ended up in Thaliand for about 5 months teaching English. When I returned there wasn’t much work for a Sociology major straight from Thailand teaching English.

I had some computer experience prior to that, though. My first PC was a Gateway 486 which I got back in ’94. I started shadowing my best friend and former boss at work and there I was introduced to Linux.

I continued to use Linux through Graduate school and learn more and more about security. After realizing I didn’t want to be a Manager, which is what I have my graduate degree in, I decided I wanted to stay with computers but with Security. Nearly all of what I have learned has been on my own from websites, books, and having support from my managers to just experiment.

LS: What are some of your other hobbies?

Brian: Between writing books, writing the Linux Security: Tips, Tricks and Hackery newsletter[4], preparing for a Linux security class I’ll be teaching in January, answering questions about Stunnel and maintaining the Stunnel website, trying to keep up with current security issues on mailing lists like Bugtraq and VulnWatch, web pages like and Help net Security, something called a “Day Job”, and a somewhat foreign concept in the computer geek circle called “wife and kids”, I’ve very little free time.

I like to read a lot, though the topic depends on the location. By myself, I usually pick security and geeky titles – I’ll re-read W. Richard Stevens’ books now and then for fun. But much more of my time is spent reading books such as Dinosaur Roar, Tumble Bumble, or Sheep in a Jeep to my daughter. If she stops paying attention, I start sneaking new characters in, such as Dmitri Dog, who is hounded by the evil Ashcroft Crow. I figure I need to sneak in anti-DMCA[12] sentiments early via allegory.

Duane: I don’t have many hobbies outside of computers. My interest tend to be around a particular aspect of computers. In particular, parallel computing, cryptography, finding good uses of open source in the business world, and computer forensics. I do have an interest in the arts. In particular, what is going through an artist’s mind as he or she is working. Two of my friends are artist and I really enjoy being around them, and other artists, and listening to them brainstorm ideas or talk about what their work means to them.

LS: Supposing you had free time, what would you be doing with it?

Brian: I’d devote some time to helping out the Linux Security Module project. I hope to help port systrace to LSM next year. Currently it is a kernel patch, and I think the community would be served better in the long run by having it available as an LSM module, which would make it more accessible to those who fear kernel compilation.

And some day I hope to get around to turning some of the megs of perl code I’ve written over the years into well defined Perl modules for CPAN. Then I won’t be the only one supporting this spaghetti code. 😉

If I had infinite time, I’d learn to play the Hammered Dulcimer and French Horn. There’s nothing in the world as musical as a well-played French Horn.

LS: In your opinion, what is the most interesting thing about Linux and Security?

Brian: The first thing is that, with Linux, security is a possibility. It is not an end point – you must constantly keep abreast of new attacks and revisit your security posture – but there is nothing that is unavailable to you if you want to look. Closed source systems can never offer this. By design, be it chosen for monetary reasons or to prevent competition, closed source products always hide details from the users and administrators that could be critical to understanding how thing function, and how they can be broken.

One of the beauties of Linux (and other open systems, such as *BSD) is that you can use them to boost the security of those closed source machines. By the liberal application of Linux machines throughout your infrastructure, you can keep those exploits-waiting-to-happen locked down where they can do less harm. For more of my ranting on this topic, see my article Linux is Securable — I won’t waste time rambling here.

What is most intriguing right now on the Linux horizon is the evolution of security controls. In the beginning, all you had to work with were file permissions. Root could do absolutely anything unchecked, and root access was required for some things such as binding low network ports or opening raw sockets, which meant use of set userid bits on programs, which frequently were broken to gain root access.

Next came capabilities, where each bit of root’s power was defined in more specific terms. When determining if a process could bind port 80 originally you’d check to see if uid==0. Now you’d check if the process had the CAP_NET_BIND_SERVICE capability. In theory, you could now remove capabilities from the system – for example removing the ability to load kernel modules ever again, which is good for defending against malicious LKMs.

This compartmentalization was a good evolutionary step, but it didn’t get used much in the real world. You had only global access to turn off a capability, and you’d never have it available again, except by rebooting. You couldn’t assign a capability on a process-by-process level, which made it much less useful.

Then came some excellent security kernel patches. LIDS[7], Grsecurity[8], SELinux[9], and others. Finally we had ways to give abilities to only the processes that needed them. We could completely lock down our machine such that any deviation from what we have allowed will fail. Should an unknown buffer overflow occur, the cracker can’t bind an inbound rootshell on port XYZ, it won’t be able to read files outside those we’ve allowed, and won’t be able to write to the file system anywhere. If they break in as root, they still can’t change anything in /etc unless they know yet another password, they won’t be able to Trojan files in /bin, or insert a loadable kernel module into the system. Life is good.

But, life could be better. These patches are not integrated into the kernel. You won’t get them on your Red Hat CD, or your Debian download. (Though some places do ship hardened kernels, such as Owl which contains the OpenWall[10] kernel security patches, or EnGarde[11], which comes with LIDS.) So normal users need to go out of their way to patch and recompile the kernel – a daunting task.

So, the current bright spot on the Linux security horizon in my opinion is the Linux Security Module infrastructure, which promises to make it possible to load these advance Linux security policy behaviors without a kernel recompile, thus removing a significant barrier to the new Linux administrators. If we can get more of the LSM modules to be stackable where appropriate, we’d be able to pick and choose the best of the features of each, something which currently involves manually merging kernel patches – quite a painful endeavor.

So, as we enter this new era of Linux security, you bet I’m excited. Just tell your manager that it’s a “Paradigm shift” and they’ll give you time to play with it too.

Duane: Computer forensics reigns supreme in my opinion. These experts provide us
the information we need to fine tune the tools we currently use and the tools needed to prevent attacks from occurring in the future. Sifting through megabytes or gigabytes of data to find one clue as to how someone compromised a system has to be tedious but the information they find helps us quickly learn how to patch the vulnerability and create tools to help detect how a system was compromised. I just don’t think the security industry can survive without forensic experts. There are many people who aren’t forensic “experts” who can and do identify how a system was compromised and they also provide the community with valuable information. However, the forensic experts can dig down and find the root of the problem and the information they provide can then be used to help fine tune currently used tools and methods.

LS: What are some of the lessons you you have learned in your years in computer security?

Brian: Well, in no particular order, here are a few things that pop to mind.

  • Never bother with a technological hack when a social engineering one takes ten seconds.
  • Posting a piece of paper listing a ‘contest for the most creative and verifiable username/password’ in a college campus food court will get you several hundred valid entries you can use at will.
  • The easiest way to get access to a friend’s account is to get them to ‘xhost +’ to play network xtank.
  • The next easiest is to untar /etc/shadow from the backup tapes that the administrator leaves next to the tape drive.
  • Sometimes the perfect hack is just one click away.

  • When you have a frustrating week, let the script kiddies amuse you. Set up a honeypot with as much known-buggy software as you can find. Break almost all the tools. Don’t include vi or emacs, make them learn ex. Include perl, but no modules. Install the Fortran compiler, but no others. Include netcat, but not telnet. Make the default shell tcsh, and remove all Bourne shell variants. Delete all terminfo/termcap definitions. Don’t include more,
    less, or any other pager. Compile a version of cat that randomly swaps letters every so often.

  • Never put that honeypot anywhere near your actual machines.
  • Use mutt. A good mailer is key to getting work done, and you can’t be secure if you’re too busy wading through your email.
  • If you can’t do it from the command line using Netcat, you don’t actually understand how it works.
  • If you can give the root password to your enemy and he can’t compromise your system, you’ve done a good job securing it.
  • Every now and then, lock the root password on your own machine and try to recover it. You’ll learn where your own weakness are, and hone your skills.
  • Make sure you have a throttle on any software that can page you.
  • Never rename /usr/lib/libc.a.
  • Always have a statically linked shell, in case another administrator renames libc.a and you need to re-create it using nothing but shell built-ins.

  • And check your logs. Always check your logs.

Duane: The most important lesson I have learned is that management support is critical to any security person’s job. If you don’t have management support to shut down services, put up a firewall, install
file-integrity, enforce policies, etc. then there is not much use to be around. All you are going to be doing is fighting fires and that can get old real quick. As security professionals we have to keep managers informed with
what is going on in the security world in plain terms. Some managers don’t understand the language of security people. A little bit of downtime to enable security is a small trade off compared to the downtime of a compromise or a well=publicized hack. I have been very fortunate to have very supportive supervisors. If you want to get their support then provide them hard facts and not theory. That doesn’t mean you have to run an exploit to prove your point but you can show them logs from your Intrusion Detection Sensor’s or logs from the firewall or from any other
devices you run.

LS: What got you interested in the field of computers/Linux/security?

Brian: Apparently I was born with an inherent distrust and paranoia. When I got my first computer, an Apple ][, I spent ages developing a completely secure ‘hello’ program. In order to boot off the disk, you needed several passwords, and could not drop out of it using any of the existing methods such as ctrl-reset, etc. You couldn’t boot off a separate disk to access the files because I slightly modified the disk layout to be not compatible. When I try to think back towhy I did this, I have no idea. There wasn’t a damn thing on those
disks that was private or, for that matter, interesting even to me. Just the ‘help Brian to learn to spell’ program that my mother and I wrote.

My actual interest in computers started from that very machine. I was playing Snake Byte (ahh, I miss that game) and hit ctrl-reset by mistake. I was dropped down to an asterisk prompt, and discovered it could do simple integer math. 2+2==4, 6+3==9. However when I got to higher results, such as 5+7 I was confused by the answer “C”. It took me a while to figure out what was going on, and soon I learned to think in hexadecimal, though it was many years before I learned what it was called. Knowing only some apple DOS and BASIC commands, I tried ‘list’ to see what the program looked like, but at the assembler prompt. “L” meant “List a page of assembly instructions”, “I” meant inverse, “S” meant “Step one instruction”, and “T” meant “trace execution”. So instead of getting a look at a BASIC program, I was accosted by pages of machine code in a manner less friendly that gdb.

I think that was my “Eureka!” moment where suddenly I knew there was something completely foreign out there, and I wanted to learn everything about it.

Since then, my drive for security has come from both directions. I’d be on a project where we were supposed to RCS everything, but the administrators failed to put us in the proper groups to be able to do our work. Some of their build process used sudo to chown files to the install user before packaging them up. This meant we all had unrestricted chown access, although that fact was buried deep inside the Makefiles. So, a quick ‘sudo chown bri /etc/group; vi /etc/group; sudo chown root /etc/group’ was all it took for us to get our work done and make our deadline.

The same personality traits that make me want to find the weaknesses in systems is the one that makes me want to lock things down as much as possible too, and I think most security freaks are the same way.

Duane: I got into security after a security incident occurred at an organization I was affiliated with. It became a sort of obsession trying to understand why someone hacked their server. The server that was attacked had nothing significant on it. However, I soon learned that there has tobe nothing of significance on the computer by simply having high-speed access, large storage space, or just having an Internet connection was
enough for someone to compromise a server. That year SANS had some of their courses freely available and I went through those documents and audio files with a fine-toothed comb. I remember spending Christmas that
year at my alma matr’s computer systems learning how to interpret syslog messages, how to enable tcp_wrapper support, using Crack, and how to run nmap. My supervisor, Bob, and my best friend, Bone, both knew security
was important and welcomed and supported any advice.

LS: Brian, I see that you’re donating all online proceeds from sales of Hacking Linux Exposed, Second edition to the Electronic Frontier Foundation.

Brian: I’m extremely worried about many recent changes that are affecting the world of technology — the DMCA and the continued threat of decreased privacy being the most obvious. I’m a member of the EFF[13], and thought this would be another good way to support them. We’ve set up ‘associates’ accounts with Amazon and Barnes and Noble, and all the money we get through those accounts we’ll send to the EFF. This actually goes for any purchases that ‘originate’ at our site too. See our books page for more info.

LS: Duane, during the many email conversations we have had, you have expressed some ideas about security related education, would you mind explaining those a little?

Duane: I would like to see a more systematic approach to teaching the basics of security and making this information freely-available. If System Administrators took care of the most common vulnerabilities then that would greatly reduce their chances of being compromised and make their job less frustrating. I know the time investment it takes to administer many servers but there has to be time for security.

  1. Onsight Inc.

    Onsight offers security design and implementation consulting, as well as on-site training in Unix and Network security, Basic Perl programming, Advanced Perl programming, CGI programming using Perl, Tcl/Tk, XML and JavaScript.

  2. Stunnel

    Stunnel is a program that allows you to encrypt arbitrary TCP connections inside SSL (Secure Sockets Layer) available on both Unix and Windows.

  3. National Climatic Data Center

    NCDC is the world’s largest active archive of weather data.

  4. Linux Security – Tips, Tricks, and Hackery

    This newsletter shows both defensive and offensive security tricks you can apply to your Linux (and other Unix-like) systems.

  5. Linux Security Module

    The Linux Security Modules (LSM) project provides a lightweight, general purpose framework for access control.

  6. Systrace

    Systrace enforces system call policies for applications by constraining the application’s access to the

  7. LIDS – Linux Intrusion Detection System

    LIDS is a kernel patch and admin tool to enhance the linux kernel security.

  8. Grsecurity

    Grsecurity is an extensive set of security patches to the 2.4 tree of Linux kernels.

  9. SELinux

    SELinux, the Security-Enhanced Linux (previously known as NSA Linux) provides a flexible Mandatory Access Control

  10. OpenWall

    The OpenWall patch is a collection of security-related features for the 2.2 Tree of Linux kernel,

  11. EnGarde Secure Linux

    EnGarde Secure Linux is a comprehensive software solution that provides all the tools necessary to build a complete
    online presence, including DNS, Web, e-mail services, and more.

  12. Anti-DMCA

    The Anti Digital Millenium Copyright Act Website.

  13. Electronic Frontier Foundation

    EFF is a donor-supported membership organization working to protect our fundamental rights regardless of technology.

  14. SysAdmin, Audit, Network, Security

    The SANS Institute is a cooperative research and education organization.

What Is Slapper?

Saturday, December 23rd, 2006

This is a re-post (or posting to my blog) of an article I had written for Linux Security in September of 2002. The original article is available here.

The question of the week: What is Slapper? Let me begin by telling you I am not only describing the Slapper worm, but I am also describing the Apache/mod_ssl worm, the bugtraq.c worm, and the Modap worm. In effect, this is just 4 different names for the same nasty worm.
On the always lucky day of Friday the 13th (of September) the first
reports appeared on Bugtraq of an active worm exploiting the OpenSSL buffer overflow vulnerability reported at the end of July. The next day, CERT issued an advisory CA-2002-27, the Apache/mod_ssl Worm.

A quote directly from the CERT issued advisory prior to the release of the worm:

Compromise by the Apache/mod_ssl worm indicates that a
remote attacker can execute arbitrary code as the apache user on the
victim system. It
may be possible for an attacker to subsequently leverage a local
privilege escalation exploit in order to gain root access to the
victim system. Furthermore, the DDoS capabilities included in the
Apache/mod_ssl worm allow victim systems to be used as platforms to
attack other systems.

By Sunday September 15th, F-Secure Corporation reported
13,000 infected servers out of “over 1,000,000 active OpenSSL
installations in the public web.” Businesswire gave a more in-depth
view into just how F-Secure got their numbers:

During the weekend following Friday the 13th, F-Secure
engineers have reverse engineered the peer-to-peer protocol that the
worm uses. F-Secure has now infiltrated the Slapper peer-to-peer attack
network, posing as an infected web server. Through this fake server,
the exact number of infected machines and their network names can be

Updates to fix the problem, including backports to earlier versions of OpenSSL, had been available
for over a month from the OpenSSL project, Caldera, Conectiva, Debian,
EnGarde, Eridani, Gentoo, Mandrake, OpenPKG, Red Hat, SuSE, Trustix and
Yellow Dog.

SecurityFocus has completed and released a full analysis (PDF format) of the worm in addition to their initial incident Alert (PDF format). F-Secure is maintaining a “Virus Description” of this worm with lots of interesting information.

The Linux.Slapper.Worm spreads in similar fashion to last year’s
Nimda and Code Red worms, by scanning for, and then infecting,
vulnerable systems. Because this worm establishes peer-to-peer links
among infected servers, experts fear it could create a powerful
platform to launch denial-of-service attacks against virtually any
target on the Internet.

Some of the more noteworthy (interesting) things thats the
Slapper Worm does are similar to the Apache Scalper worm. A major
difference is that Slapper creates a hierarchical network structure.
The Security Focus Analysis states:

The Modap Worm, like Scalper, implements many
innovative structures, including a hierarchical network structure in
which it keeps track of the systems it has infected, the system that
infected it, as well as a list of other infected systems and how many
hops away they are. All of the internal communication between hosts
infected with Modap is accomplished through an implementation of a
stateful protocol transmitted over UDP.

Once the worm has infected a system and created the necessary file
(below), it executes itself with at one command line parameter. If it
is not executed with at least one command line parameter, then it
displays an error message and does not run. Now that the worm is
running, the first thing it attempts to do is bind to UDP port 2002.
The bot (worm) then sends out a packet to register itself on the
network [of other worms]. Now that the worm is bound to a port, it
enters a daemon mode and forks and installs signal handlers for SIGCHLD
and SIGHUP which point to an empty function. The worm now enters a
while loop where it just scans and propagates.

The way the worm propagates is it begins by scanning for hosts
that are listening on port 80. Once a system is found, it send the
following string:

GET / HTTP/1.1\r\n\r\n

Since a “400 Bad Request” reply is generated, the worm now has
information about the server to look at. It parses the information
given with the response and determines weather or not it has just
contacted an apache server. The worm checks the response string to see
if the version of apache as well as the operating system are
vulnerable. If the operating system or the apache version don’t match
anything the worm has, then it uses the default attack.

F-Secure has charts which illustrate how many hosts are/were
infected at a given time. Although the count was nearing 20,000 hosts
as of 17 September, the number has been drastically reduced between
patching and emails to system administrators. The number is supposedly
down to below 1,000 at the time of this article writing.

One of the main characteristics associated with Slapper is the
file names that it creates. It creates 3 files within the /tmp

/tmp/.bugtraq This is the copy of the worm that is running on the infected system.
/tmp/.bugtraq.c This is the source code to the worm that is running on the infected system.
/tmp/.uubugtraq This is the uuencoded copy of the worm that is running on the
infected system. This file is also used by the worm to propagate itself
to other systems.

Media References include:

RUS-CERT has made available a tool to remotely detect vulnerable servers. However, Eric Rescorla has observed behavior different from what that tool expects.

If you have yet to apply a patch, I would strongly urge you to
do so now. If reading this article has not convinced you, then go apply
the patch to spite me. If you are unsure of where to obtain a patch for
your version of linux, Linux Security Advisories has a list of all the advisories by vendor.

Much of the information stated in this document is available via the sources and references listed throughout this document.