Script Kiddies The most numerous attackers are script kiddies. Script kiddies are not sysadmins. They are not skilled. They download small attack programs that work on a point-and-click basis and go looking for people to attack. They’re the equivalent of drive-by shooters looking for easy pickings. Fortunately, script kiddies are particularly easy to protect against; you simply have to keep your system and server programs patches up to date. Disaffected Users The second group causes the majority of security problems: your own users. The fact is, disaffected employees cause most security breaches because they’re most likely to know where your security holes are. For example, you might have all your servers patched, but if you have a modem in the back closet that lets anyone who knows the password into the network behind your firewall, you’re in trouble. The best way to stop people like these is to not be sloppy. When someone leaves the company, change all passwords, and tell all employees that the person has left and not to share information with that person. And get rid of the unsecured modem, or the undocumented telnet server, or whatever other hurried hack you put into place thinking that nobody would ever find it. Skilled Attackers The last group is actually dangerous: skilled attackers. These are competent systems administrators, security researchers, and penetration specialists who want specific information from your company. If one of these people wants into your systems, they can probably get there. Still, the proper security measures that will stop the first two groups of people can change the tactics that the skilled attacker must use. Rather than breaking into your computers over the network, he’ll have to show up at the door dressed as a telephone company repairman lugging a packet sniffer, or dumpster-dive searching for old sticky notes with passwords scribbled on them. This raises his exposure dramatically, and can even make a break-in more trouble than it’s worth. RANT You’ll frequently hear the word “hacker” used to describe people who break into computers. This word has different meanings depending on the speaker. In the technical world, a hacker is someone who is interested in the inner workings of technological systems. Some hackers are interested in everything, some have a narrow area of interest such as computers. In the FreeBSD community, “hacker” is a title of respect. The main FreeBSD technical list is called FreeBSD-hackers. In the popular media, a hacker is someone who breaks into computer systems, end of story. To them, all hackers are bad. I recommend avoiding the word entirely to avoid confusion. In this book, I call those who break into systems intruders.[2] Technical wizards can be called by a variety of names, but they rarely object to sir or “madam.” [2]In person, I call them much less pleasant things. FreeBSD Security Announcements The best way to stop all attackers is to keep your system up to date. That means you need to know when to update your system, and what to update. An outdated system is a script kiddie’s best friend. The FreeBSD project has a team of developers who specialize in auditing source code and 139
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Chapter 7: Securing Your System Overview Securing your system means ensuring that your computer’s resources are used only by authorized people for authorized purposes, because even if you have no important data on your system, you still have valuable CPU time, memory, and bandwidth. In fact, many folks who thought that their systems were too unimportant to bother securing found themselves an unwitting relay for an attack that disabled a major corporation. You don’t want to wake up one morning to the delightful sound of law enforcement agents kicking in your door because your insecure computer was used to break into a bank. Sure, there are things worse than having some kid take over your servers say, having both your legs broken. Coming in to work one day to discover that the company Web page now says, “Ha, ha, you’ve been r00ted!” is a pretty close second. Sadly, over the last few years, it has become much easier to take over remote computers. Precanned point-and-click programs for subverting computers are becoming more and more common, and can be found through an underground search engine like http://astalavista.com/. It takes just one bright attacker to write an exploit, and several thousand bored teenagers with nothing better to do than download it and make life difficult for the rest of us. Even if you don’t care about your system, you need to secure it. Generally speaking, operating systems are not broken in to; the programs running on operating systems are. Even the most paranoically secure-by-default operating system in the world[1] cannot protect badly written programs from themselves. Occasionally, a problem with one of these programs can interact with the operating system in such a way as to actually compromise the operating system. The most common of these are called buffer overflows, where an intruder’s program is dumped right into the CPU’s execution space and the operating system runs it. FreeBSD has undergone extensive auditing to eliminate buffer overflows, but that’s no guarantee that they are totally eradicated. New functions and programs are being written all the time, and they can interact with older functions in unexpected ways. This chapter focuses on patching and securing your systems. (Auditing your network design is a topic that fills thick books, and isn’t really on topic for a book on FreeBSD.) FreeBSD gives you many tools to help you secure your system against network attackers. [1]That would be OpenBSD. Or any OS on a computer that’s disconnected from any network, buried under 12 feet of steel-reinforced concrete and, if at all possible, crushed into a billion tiny pieces and soaked in hydrofluoric acid for several months. Who Is the Enemy? First off, I’m going to arbitrarily lump potential attackers into three groups: script kiddies, disaffected users, and skilled attackers. You will find more fine-grained profiles in books dedicated to security, but that’s not what you’re here for. These categories are easily explained, easily understand, and include 99 percent of all the attackers you’re likely to encounter. 138
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
CVSup IDs are email addresses, such as mwlucas@AbsoluteBSD.com. The shared secret is based upon a cryptographic hash saying you’re the administrator’s chosen password for that user. The class field is reserved for future use, and should be left blank. Finally, the comment field can be used by the administrator. For example, if you give someone access to your CVSup mirror, it’s a good idea to put in a comment stating why they have access. (You might remember now, but will you remember in a year or two?) The cvpasswd(1) command automates generating these cvsupd.passwd entries. Cvpasswd takes two arguments: the email address of the user and the server name. It will ask you for the password for this user twice, and spit out some instructions. ………………………………………………………………………………………. # cvpasswd mwlucas@AbsoluteBSD.com magpire.AbsoluteBSD.com Enter password: Enter same password again: Send this line to the server administrator at magpire.AbsoluteBSD.com: ——————————————————————————- v mwlucas@AbsoluteBSD.com:$md5$bf489b753a0a949a1c63a3f5da0d61b6:: ——————————————————————————- Be sure to send it using a secure channel! Add this line to your file “$HOME/.cvsup/auth”, replacing “XXX” with the password you typed in: ——————————————————————————- magpire.AbsoluteBSD.com:mwlucas@AbsoluteBSD.com:XXX: ——————————————————————————- Make sure the file is readable and writable only by you! # ………………………………………………………………………………………. The cryptic line in the middle of this output (v) gives the username and the shared secret, based upon the password. Send this line to the user you want to allow to connect. The “secure channel” mentioned means that you should send this line in such a way that it cannot be captured by hostile people on the Internet. You can read the code to the other user over the phone, hand-type it into the system, copy it to a floppy disk, and hand-deliver it, or encrypt it with PGP and email it. If you send it via standard unencrypted email, anyone who captures the email en route can use this to try to access your CVSup server. However, if someone steals this information, the risk of unauthorized access is not that great; a user still needs the password to access the mirror. Once the user has this line, he puts it in his home directory in the file .cvsup/auth. This can be copied to any system he wants to upgrade from this CVSup server. He also needs to make sure that nobody else can read this file, by running chmod 600 .cvsup/auth. On the server side, copy that same line into /usr/local/etc/cvsup/cvsupd.passwd. It is formatted to be a correct, although minimal, password entry. You can add a comment at the end, if you like. Once you have this entry on both the client and server sides, the user will be prompted for a password each time he runs CVSup and tries to connect to this server. Note If you have neither cvsupd.access nor cvsupd.passwd, anyone can connect to your server from any location on the Internet. The FreeBSD Project is happy to let anyone run a mirror, but you should be aware that you are doing so! 136
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
Combining Authentication and Access Combining authentication and authorization by IP address can be a little tricky because you don’t want hosts that are listed by IP addresses to be asked for passwords, or users with passwords to be rejected because their IP address is rejected. There is an implicit “authenticate” rule at the end of cvsupd.access. If your client hasn’t been blocked out by an explicit “deny” rule based on an IP address, you’ll be allowed to authenticate. No special configuration is required. In the example cvsupd.access file shown previously, I explicitly denied access to all IP addresses that were not in the list. If you wanted to give other users a chance to authenticate, you would list IP addresses that may always connect, and explicitly reject smaller blocks that you know you will never connect from. Here’s a commented example: ………………………………………………………………………………………. #allow anyone inside our company to connect +192.168.0.0/16 #allow anyone from our sister company to connect +10.10.0.0/16 # users from here can never connect -24.0.0.0/8 ………………………………………………………………………………………. In this example, systems with an IP address beginning with 192.168 or 10.10 could always connect. Computers with an IP address beginning with 24. could never connect, even if they had a username and password. If a computer with none of the above IP addresses tries to connect, it will be able to try a username and password. This gives you complete control over access to your mirror. 137
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
………………………………………………………………………………………. +192.168.0.0/16 -0.0.0.0/0 ………………………………………………………………………………………. Controlling access by IP address is good for a static network. For example, an Internet service provider (ISP) knows the IP addresses of its servers and can easily keep them in cvsupd.access. You might need a more flexible system, however, if you’re connecting from random IP addresses. When I was consulting, for example, I kept a mirror that accepted connections from any IP address. Users needed a username and password to connect, however. If your cvsupd.access file is empty, access is controlled entirely by username and password authentication. Authentication Use authentication to allow connections to your CVSup mirror from any location on the Internet. The CVSup server uses a challenge-response system for authentication, rather than transmitting passwords in clear text. When a client connects, it combines its shared secret (CVSup for password) and the system time, and runs them through a scrambler. The server does the same. In theory, both the client and the server are performing the same calculations on the same piece of secret data, and both should get the same answer. If the client’s scrambled message matches what the server computed, the server assumes that the client has the secret data and permits access. This is a very secure system. For example, if someone drops a packet sniffer on the network, she cannot grab the password. What’s more, since the challenge-response system incorporates the time, a captured response cannot be used a second time. Authentication requires a password file, /usr/local/etc/cvsup/cvsupd.passwd, which must only be readable by the CVSup user so that no one else can grab user information. (You can do this by running chown cvsup cvsupd.passwd and chmod 600 cvsupd.passwd.) If you don’t have a password file, access will be controlled entirely by the cvsupd.access file. Blank lines and comment lines (which begin with #) in cvsupd.passwd are ignored. The first code line in cvsupd.passwd is the server name and a private key, separated by a colon. ………………………………………………………………………………………. magpire.AbsoluteBSD.com:testkey ………………………………………………………………………………………. The server name is sent back to the client, and the private key is used for additional randomness. You don’t have to have a private key the CVSup password system is pretty random as is but you must have the colon that precedes the private key. The private key cannot contain a colon. Next in the file, you have your legitimate users. Each user appears on a separate line, in the following format: ………………………………………………………………………………………. user ID:shared secret:class:comment ………………………………………………………………………………………. 135
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
Since you probably want only the main source repository, answer n to the next three questions: ………………………………………………………………………………………. Do you wish to mirror the installed World Wide Web data [y]? n Do you wish to mirror the GNATS bug tracking database [y]? n Do you wish to mirror the mailing list archive [y]? n ………………………………………………………………………………………. Of course, if you’d prefer to mirror the whole http://www.freebsd.org/ site, including the PR database and the mailing list archives, answer y. But be warned: the mailing list archives are huge. The source repository itself is well over 1GB at this writing, and growing continuously. Use unique user and group IDs for the next series of questions. (Do not use “nobody”, “nonroot”, or nogroup.) You can use the defaults, or change the usernames and group names to fit your local scheme: ………………………………………………………………………………………. Unique unprivileged user ID for running the client [cvsupin]? Unique unprivileged group ID for running the client [cvsupin]? Unique unprivileged user ID for running the server [cvsup]? Unique unprivileged group ID for running the server [cvsup]? ………………………………………………………………………………………. Lastly, the maximum simultaneous client connections is easy to change later, so don’t sweat it. It’s fine to accept the default: ………………………………………………………………………………………. Maximum simultaneous client connections [8]? ………………………………………………………………………………………. Once you finish answering the questions, the make install process picks up where you left off, adds these usernames, sets the configuration, and generally gets you ready to go. Controlling Access Just because you want to be a good systems administrator and have a private repository doesn’t mean that you want every Joe Sixpack to download from your CVSup mirror. The CVSup server allows you to control which computers have access to the mirror. The file /usr/local/etc/cvsup/cvsupd.access controls which hosts may connect to your CVSup mirror. Lines beginning with the pound symbol (#) denote a comment; a plus sign (+) means that the client can connect, and a hyphen (-) means that the client cannot. An asterisk (*) means that the client must authenticate, as discussed in the following “Authentication” section. Each rule in cvsupd.access can refer to either a hostname or an IP address; IP addresses are preferred. You can use netmasks with IP addresses as well. For example, to allow access from the network 192.168.0.0/16 and explicitly reject clients accessing from elsewhere, use these lines: 134
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
At some point, the install process will pause and prompt you for information: ………………………………………………………………………………………. Master site for your updates [cvsup-master.FreeBSD.org]? ………………………………………………………………………………………. The default site, http://cvsup-master.freebsd.org/, is reserved for official FreeBSD mirror use only; you can use it if you become an official mirror and allow the world access to your system. If not, use one of the 80-odd public CVSup servers instead. If you’re setting up a CVSup mirror, you should have already identified a public mirror that’s close to you. Enter the name of that mirror. The next prompt will look like this: ………………………………………………………………………………………. How many hours between updates of your files [1]? ………………………………………………………………………………………. The script updates /etc/crontab (explained in Chapter 9) to run CVSup automatically. You can accept this default, or change it easily. If you accept the default, your system will upgrade itself once an hour via cron. This is the way the official mirrors do it. I generally enter 168, which updates the repository once a week, since I will not be upgrading servers more than weekly! Your first update will take quite a while, but later updates generally only take a few minutes. Note In many cases, I only upgrade the CVSup server by hand by running the script /usr/local/etc/cvsup/update.sh. To upgrade a group of machines all to the same version of -stable, all you have to do is update your CVSup server once and upgrade all the machines from the server. I frequently upgrade one server, put it through several rounds of extensive quality-assurance testing, and upgrade the rest from the same CVSup batch, which guarantees good code and identical systems. There is no requirement for you to be more up to date than you wish; the source code is yours to do with as you see fit, after all! If you update your server manually, you will want to edit /etc/crontab to remove the automatic update! We’ll discuss /etc/crontab in Chapter 9. ………………………………………………………………………………………. Do you wish to mirror the main source repository [y]? ………………………………………………………………………………………. Most people just need the main source repository, so the default is usually fine. ………………………………………………………………………………………. Where would you like to put it [/home/ncvs]? /repo ………………………………………………………………………………………. This prompt is where you enter the path to the location on disk where you want your mirror kept. I frequently add a separate, small disk to a system to keep the mirror on, and call that disk /repo. You can put it in the default location of /home/ncvs without any problems. 133
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
………………………………………………………………………………………. # make update ………………………………………………………………………………………. Some people find it more pleasant to simply go to /usr/src and type make update && make buildworld && make install than to give the full CVSup command. It’s up to you. [1]This format is called a “diff,” and is quite common in the UNIX world. [2]Unless, of course, strange behavior, weird crashes, and lost data make you happy. Building a Local CVSup Server Many people have quite a few FreeBSD systems. During an upgrade from source, however, every single server must connect to a FreeBSD CVS server and download the latest code, which can be a pain. For one, all of the mirrors are maintained by volunteers who are donating the servers and bandwidth. Why download the same bits over and over again? Also, each server might wind up with slightly different code if they all connect to different servers. Suppose you log in to each server and start a CVSup. In the few minutes between starting each source-code upgrade, the code on the CVSup server might change slightly. The mirrors aren’t going to stop updating their code just because you’re in the middle of upgrading four machines, and if you’re running several production machines, you’d be best served if all the systems were absolutely identical. Even if they’re running a version of -stable somewhere between 4.4-release and 4.5-release, being able to eliminate different versions of the software as a potential problem can help troubleshooting immensely. You don’t want to think, “Gee, server 1 keeps dying; could it be because each server has a slightly different version of FreeBSD?” That way lies madness. You can address this problem by running a central CVSup server (also known as a “cvsupd” server), which is essentially your own local mirror. You can control when your local mirror updates, and you can guarantee that all of your machines have exactly the same code. Doing so will not only make you popular with the mirror operators (or at least, won’t make you unpopular with them), it will also eliminate a variety of possible problems resulting from having different code on each of your servers. You can still have problems if you have different settings in /etc/make.conf, but you can compare those files yourself and see what you’re doing differently. It is much easier to compare two files than several thousand! It’s not particularly easy to run a CVSup server, but there’s help to make it simpler. The port /usr/ports/net/cvsup-mirror handles all the tricky bits of configuring a mirror. When you install the port, cvsup-mirror asks you some questions; there are default suggestions, but you should change many of them. We’ll discuss software installation in detail in Chapter 9, but installing this port is pretty straightforward. First, make sure you have an Internet connection, and enter the following commands: ………………………………………………………………………………………. # cd /usr/ports/net/cvsup-mirror # make install clean ………………………………………………………………………………………. You will see messages scroll up your screen, including the compiler messages you should recognize by now. (You might not know what they mean, but you should recognize compiling when you see it.) 132
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Unix Web Hosting services
First, you’ll need to set several variables in /etc/make.conf. ………………………………………………………………………………………. SUP_UPDATE= yes ………………………………………………………………………………………. The preceding line enables the “make” front end to CVSup. ………………………………………………………………………………………. SUP= ./usr/local/bin/cvsup ………………………………………………………………………………………. The SUP setting is the default location for CVSup on your system. If you have a custom CVSup replacement, or if you need to specify the full path to the cvsup binary, set it here. ………………………………………………………………………………………. SUPFLAGS= -g -L 2 ………………………………………………………………………………………. This SUPFLAGS setting gives standard flags for your CVSup command. To run CVSup silently, change this to -g -L 0. ………………………………………………………………………………………. SUPHOST= cvsup13.FreeBSD.org ………………………………………………………………………………………. List a reasonably close FreeBSD cvsup mirror in the SUPHOST line. ………………………………………………………………………………………. SUPFILE= /usr/share/examples/cvsup/stable-supfile ………………………………………………………………………………………. The SUPFILE value tells CVSup which configuration file to use. ………………………………………………………………………………………. PORTSSUPFILE= /usr/share/examples/cvsup/ports-supfile ………………………………………………………………………………………. PORTSSUPFILE specifies which supfile should be used to upgrade ports. Don’t define this if you don’t want to upgrade your ports collection. ………………………………………………………………………………………. DOCSUPFILE= /usr/share/examples/cvsup/doc-supfile ………………………………………………………………………………………. Finally, DOCSUPFILE is the supfile for the source code of the documents collection. Leave this undefined if you don’t want to upgrade your documentation tree (including the Handbook, FAQ, articles, and so on). Note DOCSUPFILE does not specify the actual documentation, but rather the source code to the documentation. If you don’t have the documentation building tools, this is almost useless. Once you have set these values, you can replace the cvsup stable-supfile command with this one: 131
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
configuration information, like /etc/passwd or /etc/group. Leave such files unchanged by pressing d. Pressing m will take you through a file and let you merge the changes. This is a powerful option, and useful once you’re comfortable with mergemaster, diff, and the contents of /etc, but beginners are almost certainly better off simply totally replacing or rejecting files. You can learn all about /etc in Chapter 9. Device Entries In Chapter 3 we briefly discussed device nodes, files in the /dev directory that programs can use to send data to and from devices. Then, in Chapter 4 I defined a kernel as the interface between the hardware and the software. When you run an upgrade, these two concepts intersect: The kernel might very well rearrange how it talks to devices, and the interface for how those devices are handled might change. So far in this upgrade process, we haven’t changed those special files in /dev, but if you have old device nodes talking to a new kernel, you can get unpredictable behavior. These changes might not happen with every upgrade, but you have to be aware that they’re possible. FreeBSD includes a script that creates correct device nodes, /dev/MAKEDEV. The version of /dev/MAKEDEV distributed with a given kernel is expected to create the correct device nodes for that kernel. Mergemaster compares the /dev/MAKEDEV script from the updated source code with the old script still installed in /dev/MAKEDEV, and it offers to install the new one. Do it.[2] Correct device nodes are not optional. If the /dev/MAKEDEV script has changed, mergemaster will offer to run /dev/MAKEDEV for you. Do that too. Again, correct device nodes are vital. Last Steps Once you have completed mergemaster, your system has every piece of the upgrade in place. Just reboot, and you will have completed a FreeBSD upgrade! Any number of things can go wrong with a system upgrade. The make buildworld command might not finish, or the system might behave oddly afterwards. If something goes wrong, follow a similar process to what you do during a kernel-build failure. Search for the error in the FreeBSD mailing list archives. If the problem isn’t discussed there, send the last five or six lines of your build output to FreeBSD-questions@FreeBSD.org, and include the following information: The end of the output of the failed compile Your FreeBSD version number The contents of /var/run/dmesg/boot The output of uname-a Simplifying the CVSup Upgrade Process Now that you understand how the upgrade process works, you can simplify it somewhat by making some changes in /etc/make.conf to reduce the CVSup portion of the upgrade process to a two-word command. While I don’t prefer to go this route myself, many people do, so here’s what you do. 130
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services