Originally Published: Tuesday, 11 January 2000 Author: miff
Published to: learn_articles_support/Articles Page: 1/1 - [Printable]

How to Secure Your Linux Box

So you've finally dumped windows and installed Linux, but you don't want to get owned up by script kiddies? Used as a bot farm, icmp source, spam gateway, etc? Don't want your e-mail read at random, personal files purused, rm'ed even?

   Page 1 of 1  

OK, well today I'm gonna talk about some really practical ways to secure your Linux box. I'll say up front: there's no way I could cover everything - there's no insurance against getting owned if you are connected to a network. There's just the prospect of knowing a little more than the guy on the other end trying to get in. I'll cover important concepts and get to the details where possible, but you'll have to do some digging and experimentation as well. Happy securing.

Note: suggested commands will appear in brackets. If you want to learn more about the command, type: man <command>. If you want to learn more about a concept, do a web search using www.altavista.com, or www.hotbot.com (for more results displayed per page). Be persistent in your web searches and thoughtful in your search criteria and you can find anything you need.

Post Installation There are a bunch of things you want to do right away, before you connect to the net. I'll list them in no particular order:

  • Add two non-root users [adduser] One user should be for you, so you don't use the root account for normal activities, and the other should be a cracker user - a normal account which you will use to test exploits and stuff against your box.
  • For your root account and your two new accounts, choose hard passwords! Don't choose any simple English word, or a word followed by a number. Those can be cracked. Choose a random mishmash of numbers, letters, and punctuation.
  • Disable all unneeded network services. Linux comes with lots of neat stuff, but much of it you will never use. You probably don't need to be running imap. Maybe its a good idea to disable finger as well. Many (but not all) network services are configured in the file /etc/inetd.conf. Edit this file and comment out anything that you don't know that you need. I'd suggest leaving only ftpd and telnetd. If you are really paranoid, either comment everything out or just don't run inetd at all. I've seen lots of boxes that run nothing but sshd - secure shell encrypted sessions only. To remove inetd or other network services from your startup files, go into the directory /etc/rc.d - this is where most of the startup activity on your box occurs. (Note: on redhat, you may find these files in /etc/rc.d/init.d - check the docs for your distribution to be sure you know where all the startup files are). Its worth the time to look through everything in this directory, but if you aren't sure which file contains the commands to start a service that you want to remove, do a quick [grep <the service you are interested in removing> *] in the directory. You may find something like: ${NET}/inetd - comment it out by placing a # sign at the beginning of the line. If you don't want to run a web server (though many do) take out httpd while you're at it. When you think you are done removing services from inetd.conf and from your startup files, you can either reboot (lazy) or kill the daemons that you don't want running [kill -TERM <ps id of daemon>] and restart inetd [kill -HUP <pid of inetd>]. Now you must verify that you really aren't running anything that you don't want to: Two ways to do this (I suggest using both) are: 1) Get a copy of strobe or another portscanner and run it against your box. It will let you know what ports are open. 2) Run the command [netstat -a]. Feel free to read more on netstat in the man pages, as it is a very useful command.
  • Disable all unneeded daemons. You've probably already killed a few to get rid of some network services and removed them from startup files in /etc/rc.d. But there may be more non-network related daemons that you really don't want to have running. Things such as fax servers, printing stuff (do you need it?), etc. Take a close look at all running processes with [ps aux | more]. Some of these are needed for the system to function, so don't just kill them at random. You'll need to investigate each running process to see what it does, then decide if it is needed. (Hint: you need things like init, kswapd, kflushd, kerneld...) Once you've determined what you don't need, kill the processes [kill -TERM <ps id to die>], and if your system hasn't crashed (meaning you didn't kill init or something), go back to /etc/rc.d and comment out all the processes youdon't want.

    OK, your system is starting to get nice and slim now - trimming off useless security risks and whatnot. One last major hole to be plugged before we have covered the basics:

  • Remove suid bits from all files that don't absolutely need to be used (and used as root). Setuid files are programs that, when run as a normal user, assume the identity of the owner or group of the file. Often the owner is root. When a hole (typically a buffer overflow these days) is found in an suid root program, one of your users will download the latest exploit script, and yer owned. Guh. Therefore, you must create an inventory of all suid files on your box. Do something like:

    [ls -alF `find / -perm -4000` > /tmp/suidfiles]

    Now you've got a nice list of all suid files (including non-root owned) on your box sitting in /tmp. (suid files are distinguished by permissions of 4755 or similar, and look like :

    -rwsr-sr-x   1 root     mail        59240 Apr  6 20:04 /usr/bin/procmail*

    Take a close look at them. Anything that you don't need, change the perms. Personally I like [chmod 4700 <file>] because then the file still looks like suid to a scanning script kiddie, but really it isnt executable by the user so everything is irie. Here again you'll need to investigate each suid file to see what it does and comtemplate whether or not you really need it to be available as such. Discuss amongst friends.

    Attack Yourself

  • Subscribe to the bugtraq mailing list or some other source of security discussion. Here you can get the latest public exploits pretty much as they become available. [echo "subscribe BUGTRAQ" | mail listserv@netspace.org]. You need to get any and all exploits for your remaining suid files, network services, and kernel.
  • Test your machine: Using your cracker account, get ahold of exploits for everything you are running, if they exist. Web searches and looking through security archives can get you, for example, the remote ftpd exploit. Run all this stuff and see if you are vulnerable. Note: remote exploits are much more dangerous than local, since the attacker doesn't need to have login access to your machine - so check your network services first. Local stuff you shouldn't have to worry about until you have users, or until someone busts in from the outside as non-root.
  • You might also want to run some commercial or free security scanning products against your machine. I'm sure they would love your patronage.

    Once you are confident that your network services, suid's, and kernel are secure, you can move on to more advanced prevention and monitoring techniques. Don't forget to keep abreast of security issues and the latest holes and exploits.

    System Modifactions

  • Protect your critical files: Besides running regular backups, you might consider making secure copies of critical or oft-trojaned system files like your login executables, ps, ifconfig, netstat, etc. A good list of what to protect can be gotten by looking at the latest linux rootkit, which is designed to leave backdoors in your system binaries for later use by the installer. Here's what to do: copy all of your identified "trojan-risk binaries" to a floppy. Write protect the floppy. Eject it. Every once in a while [diff] the floppy files with the stuff on your system. They should be exactly the same. This is an effective anti-trojan strategy.
  • Consider installing a non-executable stack patch, such as the one from Solar Designer. This decreases the likelihood that a vulnerable program can get buffer overflowed - which is the technique du jour for rooting a box.
  • Consider installing tripwire or similar programs which check and protect the integrity of your files.
  • Consider mailing your log files out to another secure machine every once in a while. Sticking security audit stuff elsewhere makes it hard for an attacker to erase his tracks.
  • Consider using creative mount techniques - such as mounting world writable areas like /tmp from their own partition, and making them nosuid. This means that even if someone successfully creates an suid root shell in a world writable area, the system won't respect the suid bit, and the cracker will just get a normal shell. You can also do this with /home if you like. [mount]
  • Use firewalling techniques both on your system and (if possible) between you and the Internet. You can use [ipfwadm] to deny packets from hosts that are suspect, hosts that are portscanning you for example. You can use hosts.allow and hosts.deny to carefully configure which hosts your network services will allow connections to. (I assume most modern linux distro's come with tcpwrappers...)
  • When you have the choice, configure and log with IP adresses instead of names. This defeats DNS cache poisoning or other name spoofing attacks.

    Monitoring and Logging

  • Pay attention to your standard log files - /var/adm/syslog and /var/adm/messages. (sometimes these are in /var/log or other places). Learn about what goes into them and how to configure applications to give you more or less detail about what is going on. Use alternate log files if you like.
  • Run additional logging: There are utilites to log just about everything - all tcp SYN's, all icmps, etc., etc. You have to be careful here not to end up logging a terrabyte of data - so play with different loggers to suit your needs and check how much data they are generating. You might want to run a logger in a terminal window (not to a file) with a large scrollback so that you can pretty much see what is going on (or scroll back to it) but you don't end up logging a ton of shit if you are getting DOS'ed for example.
  • Use sniffers. You can use [tcpdump] to generally view what is going on on the network. I wouldn't log this to a file. You can also use other sniffers to monitor inbound and outbound connections on assorted ports - [sniffit] is a highly configurable sniffer that includes an interactive mode. It is good to run the sniffer on an alternate machine, if possible. Also, be careful of user privacy here. Using a sniffer you could easily intercept outbound passwords and email, etc etc. or other confidential stuff from your subnet. Get a good sniffer and practice with it. Use it at random to see exactly what is travelling over your wires.
  • Use linspy, ttysnoop, or similar. Careful here, these are real privacy invaders. You may only want to use these if you suspect you are in the process of being hacked, and you want to see what is going on. There's alot of power in session monitoring.
  • Portscan yourself frequently. If anyone has anything running on one of your ports, you'll find it. You can also use netstat -a or -e to see what services are running.

    Whew. Thats all I've got for right now. Remember, the best proactive monitoring is unpredictable stuff you make up yourself. Have fun and watch the crackers claw in vain at your mighty fortress. Finally, don't forget to keep up with the latest holes and exploits. Keep attacking yourself with the cracker account. You should be able to stay one step ahead of the bad guys.

    Originally published in 2600 The Hacker Quarterly: Volume 16, Number Two Summer 1999. Republished here by permission of the author.





  •    Page 1 of 1