………………………………………………………………………………………. Now that we have a jail cell, it’s time to check in and decorate it a little. Final Jail Setup The jail setup process is not as sophisticated as FreeBSD’s installer. To prepare the environment for your jail, you must perform all of the following commands from within the jail. 1. To begin, first create a jailed /etc/rc.conf. Include the following lines: ………………………………………………………………………………………. v portmap_enable=”NO” w network_interfaces=”" x sshd_enable=”YES” ………………………………………………………………………………………. Since portmap will not run well in a jail, we turn it off (v). Since the jailed system startup will complain if it can’t configure the interface, we tell it to ignore its interfaces (w). And, since you’ll have difficulty accessing your jail via a command line once the jail starts, it’s easiest to enable sshd on the jail and access it via the network (x). 2. FreeBSD requires an /etc/fstab file. Since the jail has no filesystem control, an empty one suffices. ………………………………………………………………………………………. # touch /etc/fstab ………………………………………………………………………………………. 3. Because sendmail(8) will complain if the aliases database does not exist, we use newaliases(1) to build the proper database for it. (If you won’t be running sendmail in the jail, either because you’ll be running postfix, as discussed in Chapter 12, or because you just don’t want a mail server here, this isn’t an issue.) ………………………………………………………………………………………. # newaliases ………………………………………………………………………………………. 4. Set a root password for the jailed environment. Use one that’s different from the host environment that’s part of what a jail is for, after all. ………………………………………………………………………………………. # passwd ………………………………………………………………………………………. 5. Your users will appreciate a correct time zone in the jail. (At least they can watch the seconds tick by in their prison.) ………………………………………………………………………………………. # tzsetup ………………………………………………………………………………………. 181
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Starting the Jail From this point on, your jail will resemble a default FreeBSD install in which you can configure nameservice, add packages and users, and so on. Once you exit this shell, though, the virtual machine will stop running and your jail will shut down. Note I highly recommend using packages to add software to jailed servers; building ports can take up a lot of CPU time. Your jail is ready to run multi-user, however. To start the jail in its full long-term, multi-user glory, just run the virtual machine’s /etc/rc script from within the jail, either by hand or automatically at boot by adding the command to the end of your /usr/local/etc/rc.d/jail.sh script. To start a jail from the host system, enter this command: ………………………………………………………………………………………. # jail /test1 jailhost 192.168.1.223 /bin/sh /etc/rc ………………………………………………………………………………………. Note You’ll notice several errors on startup. Most of these are sysctls that cannot be accessed in a jailed environment. At this point, your jail is running. You can ssh in and configure it exactly as you would any other system. Managing Jails Jails do complicate process management. If you’re logged in to the actual jail server, you can see all the processes in all of your jails. Which processes are the actual ones in your server, and which belong to a jail? Doing a ps -ax on the host system shows all running processes, even jailed ones. A STAT of J means that the process is running in a jail. If you have few jails, each with a dedicated purpose, you might be able to guess which is the process you want. For example, if you only have one nameserver, and it’s jailed, it’s a good bet which named process you’re after. While you might want to manage processes from outside the jail, the simplest way to manage a jail is from within. To do so, log into your jail as root and use ps -ax and all the other standard process-management tools to control running programs. If you don’t want to log into the jail, you have to resort to more difficult control mechanisms. Procfs To investigate individual processes to learn which jail they’re part of, use the process filesystem, procfs. (This is perhaps the only time you’ll ever need to manually dig around in /proc it’s normally only used by programs such as ps and top.) This procedure is most useful for identifying a jail from a process ID. If you see a database process running amok and soaking up your memory, you can check its PID under /proc to see what jail it’s in and act appropriately. /proc contains a directory for each process running on the system. (If you’re bored, you can look 182
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
that: ………………………………………………………………………………………. # cd /usr/src/etc # make distribution DESTDIR=/jail1 NO_MAKEDEV_RUN=yes ………………………………………………………………………………………. Once you have the /etc directory, you’ll need to create the device nodes for the jail. (Since a jail does not require all the device nodes that the full system requires, MAKEDEV has a special target for use in jails.) ………………………………………………………………………………………. # cd /jail1/dev # sh MAKEDEV jail ………………………………………………………………………………………. Many programs expect to find a file named /kernel. Even if they don’t actually do anything with this file, they’re happier when the file exists. (Since you don’t want people to be able to touch your actual kernel, tie this fake to a harmless point. That way hostile users can overwrite your jailed kernel all they want, but to no avail.) ………………………………………………………………………………………. # cd jail1 # ln -sf dev/null kernel ………………………………………………………………………………………. The IP Address Now that the directory tree is established, you need to provide an IP address for the jail, since each jail has its own IP address. We’ll assume that 192.168.1.223 is our jailed IP address, and use ifconfig to attach this address to our network card. ………………………………………………………………………………………. # ifconfig fxp0 alias 192.168.1.223 ………………………………………………………………………………………. You can make this attachment happen automatically on boot by adding the following to /etc/rc.conf: ………………………………………………………………………………………. ifconfig_fxp0_alias0=”192.168.1.223″ ………………………………………………………………………………………. The Process Filesystem Finally, every FreeBSD system requires its own process filesystem, or procfs. If you’re not using jails, you really don’t need to worry about procfs; it appears automatically when you boot the system, cannot be tuned, and programs fairly transparently access it when needed. It’s a necessary bit of infrastructure, however. I create a script /usr/local/etc/rc.d/jail.sh and add all the procfs mount lines to this script. 179
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
Syslogd Syslogd is another story, because the system logger opens a socket so it can send log messages to other servers. To silence syslogd entirely, set syslogd_flags=”ss” in /etc/rc.conf, though if you do you won’t be able to log remotely. We’ll discuss syslogd in detail in Chapter 15. Named and sendmail Other daemons, such as named and sendmail, want to attach to all available addresses. To solve this problem, you can choose to configure them to bind to only a single IP address and run them on the host system, but since you’re using jails already, why not set up a “services jail” that contains these daemons? Not only is it easier, but also it allows you to provide an additional layer of security. (While named and sendmail are both quite secure today, they have a spotty history. Many older admins will feel much better if those services are jailed.) Inetd Inetd also attaches to all available addresses, but it is simple enough to control with the -a flag. If your jail host has an IP address of 192.168.1.222, add inetd_flags=”-a 192.168.1.222″ to /etc/rc.conf. Sshd The last problematic network service is sshd. Assume again that your jail server has the IP address of 192.168.1.222. You can tell sshd which port to listen on with the following entry in /etc/ssh/sshd_config: ………………………………………………………………………………………. ListenAddress 192.168.1.222 ………………………………………………………………………………………. Since your jail host is probably not providing any network services itself, you’re better off disabling every network daemon except sshd. Ideally, your sockstat output should look something like this: ………………………………………………………………………………………. # sockstat -4 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root sshd 248 3 tcp4 192.168.1.222:22 *:* # ………………………………………………………………………………………. We have only one daemon listening to the network, sshd. It is listening on a particular IP address (192.168.1.222) and on a particular port. This daemon will not interfere with our jails. Configuring Your Kernel to Use Jail The preceding section takes care of the network part of configuring jail, but we still have some kernel configuration to do. The jail system has three special sysctls: jail.set_hostname_allowed By default, the root user in a jail can set the host-name of that jail. Since the jail uses its hostname to communicate with the host, changing the hostname can easily confuse an administrator responsible for managing it. You can set this sysctl to 0 to disable 177
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
changing the hostname. jail.socket_unixiproute_only A jail defaults to only communicating via IP. While it isn’t that likely that a user might want to use, say, UNIX sockets or IPX, it’s entirely possible. The jail system only supports IP, however, so if you allow use of these other protocols, you’re allowing the user to “leak” out of the jail. They probably can’t do anything with that access, but it’s unwise to assume that you’re smarter than every malicious hacker out there. Set this to 1 to be careful and restrain your users most tightly. Set it to 0 if you do choose to allow the use of any network or socket protocol. jail.sysvipc_allowed System V IPC is a UNIX standard for allowing interprocess communication via shared memory segments. Basically, related programs can use one chunk of memory to store shared information. By default, IPC cannot be used in a jail, as the jail system does not build separate areas of memory for each jail. Enabling IPC would allow information to leak to and from the jail. Using this weakness to compromise the system would require a skilled attacker, however. You can choose to do allow System V IPC by setting this sysctl to 1. Many database programs require System V IPC. Client Setup Setting up a jail is straightforward, though you will need a FreeBSD source tree (see Chapter 6). For example, say you want to build a jail on the partition /jail1. (Jails can be in directories as well, but putting them on separate partitions gives you a quick-and-dirty method of controlling their size. Other admins will just keep an eye on their users, and raise their rates for disk hogs.) To begin, go to your FreeBSD source tree (generally under /usr/src). For your first jail, run this command: ………………………………………………………………………………………. # make world DESTDIR=/jail1 ………………………………………………………………………………………. This command will build a complete copy of FreeBSD and install it in the directory /jail1. For all subsequent jails, you don’t have to build all the binaries; you can install the ones you built the first time by just running this command: ………………………………………………………………………………………. # make installword DESTDIR=/jail1 ………………………………………………………………………………………. This will copy a complete set of FreeBSD userland programs into the jail. Note Many people have special methods to reduce the amount of space a jail takes up, but the preceding method is the approved one. Search the FreeBSD-security mailing list archives if you’re interested in other methods. The /etc Tree Each jail has its own /etc tree. While not everything in there is functional, it’s simpler to ignore the extras than trim them out. You need to grab a copy of the /etc tree from the same source code you used to build your jail, and install it properly in the jail’s directory. The commands here do exactly 178
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
………………………………………………………………………………………. These two rules say that any traffic whatsoever can pass in and out on the loop-back interface. There isn’t much point in using groups to optimize these rules, as they’re very short and quick. The first rule group comes after the preceding general rules: ………………………………………………………………………………………. #these rules control outbound traffic v pass out on xl0 all head 100 w block out from 127.0.0.0/8 to any group 100 x block out from any to 127.0.0.0/8 group 100 y block out from any to 192.168.1.200/32 group 100 ………………………………………………………………………………………. These rules control which traffic the server may send to the network. The first rule is very simple, and states that all traffic outbound on the xl0 interface may pass (v). The most interesting part of this rule is the end, where we start rule group 100. (The number 100 is arbitrarily chosen.) Packets that match this rule will only be compared to rules in group 100. The second rule is the same sort of rule we looked at earlier, blocking traffic from the loopback interface (w). We don’t need to specify an interface in this rule, as we already know that this rule group only applies to packets going out on the xl0 interface. In short, we’re blocking packets going out that we should never be sending. The next rule blocks a similar sort of illegal packet (x). If these 127.0.0.0/8 addresses are loopback addresses, we should never try to reach them over the network. Finally, in the last rule in the group, we block outbound packets to our own address (y). This is another sort of problem; packets bound for our own system should not actually leave the network card. Rule group 100 ends here. If a packet is outbound on this interface, and doesn’t match any of the other rules in group 100, it will be allowed to go on its merry way. Outbound connections from this machine are running in a default accept stance. Now, let’s consider packets entering the system: ………………………………………………………………………………………. #these rules control inbound traffic v block in on xl0 all head 200 w block in from 127.0.0.0/8 to any group 200 x block in from 192.168.1.200/32 to any group 200 y pass in quick proto tcp from any to any port = www keep state group 200 pass in quick proto tcp from any to any port = pop3 keep state group 200 pass in quick proto tcp from any to any port = smtp keep state group 200 #help clients close their connections when they request a service we #don’t offer. This makes our server look faster, and reduces general #Internet load by a very, very, very small amount z block return-rst in log proto tcp from any to any flags S/SA group 200 { block return-icmp(net-unr) in proto udp all group 200 ………………………………………………………………………………………. 174
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
The first rule in the preceding group blocks all traffic coming in from the Internet on this interface (we’re using a default deny stance for inbound traffic) and it starts rule group 200, another arbitrarily-chosen number (v). Incoming packets that have made it through the earlier rules will be diverted into this rule. The second rule blocks anything from a loopback IP (w). Since it is part of rule group 200, this rule will only be applied to packets that arrive over the network card. There are many possible explanations for such a packet arriving, but none of them are good. Similarly, the next rule blocks any packet that appears to come from the server’s own IP address (x). These packets should never arrive over the network. Almost the only possible explanation for their presence is an attempted hack. The next three rules open holes for services that this particular server provides (y). Use of the quick keyword cuts off all further processing, and the keep state option maintains the connection throughout the request. The final rules (z,{) are perhaps the most difficult to understand. Incoming network requests will remain until they time out. The first of these rules sends a “reset” notice to rejected TCP connections, telling them that their connection request is rejected rather than making the client time out (z). The last rule does something similar for UDP connections ({). To describe exactly how this works would require a fairly in-depth explanation of IP. These rules are not only safe, but also polite to other users, and they will reduce network traffic. I highly recommend their use when filtering incoming traffic. Your typical incoming packet requesting a Web page will go through a total of nine rules. The first two rules will check to see if the packet is too small or contains IP options, and are obviously bogus. The next two will see if the packet is going over the loopback interface. It then checks to see if the packet is going out on the network interface. The packet is coming in, not going out, so all of the rules in group 100 are skipped. Finally, the packet is checked against the rule for incoming packets on the network interface, and drops into rule group 200. There it is checked against two rules for more obviously bogus packets, and is finally approved. Without rule grouping, the packet would go through 12 rules. A 25 percent savings might not seem like much, but it can be very important when processing millions of packets. As your rules grow more complex, the savings will increase. IPFilter Logging IPFilter’s ipmon(8) is a separate program that handles logging for the system. IPFilter reads packets as they pass through the kernel, and transmits them to FreeBSD’s logging system as the LOCAL0 facility. (See Chapter 19 to learn how to handle this data properly.) The simplest way to use ipmon is to dump the log to syslogd(8) (see Chapter 19) with the -s flag: ………………………………………………………………………………………. #ipmon -s ………………………………………………………………………………………. One of UNIX’s oldest security mechanisms is the idea of changed root or chroot, which confines a user to a subsection of the filesystem, thus protecting the rest of the filesystem. Chroot is useful for small services, but isn’t so helpful when you’re hosting dozens (or hundreds!) of clients on a single server, because each client has special needs and each program has its own requirements for chrooting. 175
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Clients who understand the power of UNIX frequently make requests that make an administrator’s life difficult. They want to be able to install software or to reconfigure the Web server to enable the latest nifty Apache module. In short, they want root access, and under most UNIX systems you can’t hand out root access willy-nilly to clients on a multi-user server. Unless you’re on FreeBSD. FreeBSD administrators faced this problem long ago, and solved it by improving the chroot process dramatically. In fact, they solved it so well that, when using FreeBSD, you can build an entire virtual machine on disk, and isolate that machine from the rest of your system. This is called a jail. Think of a jail as something like a client-server environment. The main server is the host system, and each jailed system is a client. Changes made to the host can be reflected across all systems, but changes to the jail can’t affect the main system, unless you allow a jail to fill up a disk drive or some such. When in jail, clients can have root access and even install whatever nifty toys they desire without interfering with the main system. All processes that are running in the jail are restricted to the jail environment, and the kernel does not give them access to any information not in their jail. The filesystem in the jail does not know about files or filesystems outside the jail. Since no program or process in the jail knows about anything outside the jail, and cannot read or access anything outside the jail, the user is locked in. Not only can the client not break out of the jail, if the jail is hacked the intruder can’t break out of the jail. This helps secure your system while meeting client needs. On modern hardware with cheap disks and gobs of memory, a single FreeBSD system can host dozens of jailed Web servers (though you’d need to be certain that your kernel is well tweaked to allow this many Web servers to run, as discussed in Chapter 4). From a sales perspective, a jailed machine is a good intermediate step between a virtual domain on a shared server and a private colocated server. Configuring Your Server to Use Jail Before you begin using jails, be sure that your server is configured properly. Jails put a number of special requirements on a server, the most annoying of which is that daemons cannot bind to all available IP addresses. Each jail is tied to a particular IP address, and is defined by that IP address. The jail must have exclusive access to that IP address; nothing else can be using it. If your main server has a daemon that binds to all available IP addresses on the system, that daemon will prevent a jail from starting. If you look at your system’s sockstat(1) output, you may notice several entries where the local address resembles “*.22″. This means that the daemon is listening on all IP addresses, on that port number. If you want to use a jail, you must reconfigure these daemons to only listen on a single IP address. Check all of the following daemons before trying to start a jail. Portmap Of the standard FreeBSD daemons, portmap is the most problematic, preventing you from combining NFS and jails. (Since very few systems on the naked Internet use NFS, this usually isn’t a problem.) 176
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Inexpensive Web Hosting services
Also, when writing such rules, we couldn’t be sure what random high-number port clients would use to initiate connections. Manually filling in these rules would leave security holes and block legitimate connections. By allowing IPFilter to compare each packet with its list of existing connections, we eliminate those potential holes. Loading IPFilter Rules Now that you know how to create the IPFilter rules you need, how do you load them? IPFilter is controlled by ipf(8), which you can set to read rules from a text file. (I generally put rules in /etc/ipf.conf.) The -f flag tells IPFilter to read in rules from a specific file, /etc/ipf.conf in this case: ………………………………………………………………………………………. # ipf -f /etc/ipf.conf ………………………………………………………………………………………. When you make changes to rules, you must flush the existing packet-filter rules before you load the current ones with the -F flag. Otherwise, you will have all your old rules and all your new rules in the packet filter. When flushing existing rules, you can also specify inbound (i), outbound (o), or all (a) rules: ………………………………………………………………………………………. # ipf -F a ………………………………………………………………………………………. Or to minimize exposure, you can do both in a single command: ………………………………………………………………………………………. # ipf -F a && ipf -f /etc/ipf.conf ………………………………………………………………………………………. Note You can directly manipulate the IPFilter rules table to eliminate the extremely brief period where your rules table is empty, but this requires a fair amount of experience. If you’re actually learning anything from this section, you’re not ready to do that yet. Once you’re quite comfortable with IPFilter rules, see ipf(8) for details. Rule Grouping A rule group is a set of rules that matches a certain type of packet. For example, you will have some rules that only apply to TCP packets and some that only apply to UDP packets. Some rules will only apply to, say, requests for new connections, and others apply to every packet. It’s not necessary to compare every packet against every rule. IPFilter uses rule groups to funnel packets through an optimal rule path that only evaluates that type of packet. This way, you can compare each packet against the fewest possible rules, which makes your rules easier to understand, easier to debug, and faster to actually run. A rule that starts a rule group has a “head” statement at the very end of the rule, and members of that group have a group statement at the end of the rule. Each rule group has a group number. These group numbers are completely arbitrary. I recommend using group numbers that are at least a hundred apart from each other, so that you can add subgroups and dependent rules between them. We’ll see some examples of how to do this as we go on. 172
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services
For example, the following rule snippet catches all packets going out of interface ed0, and routes them into rule group 100. ………………………………………………………………………………………. pass out on ed0 all head 100 ………………………………………………………………………………………. A packet that matches this rule will be processed by each rule in the rules list until it hits this rule, at which point it will only be tested against rules in group 100. What’s more, a packet that doesn’t match this rule will never be tested against any rule in group 100. For example: ………………………………………………………………………………………. block out from 127.0.0.0/8 to any group 100 ………………………………………………………………………………………. Here, 127.0.0.0/8 is the block of addresses reserved for loopback connections, and your server should not send packets from these addresses out across the Net. This rule blocks these loopback packets. Packets from this address range are allowed over the loopback interface lo0. You would never want to use a universal rule to block all loopback packets because they are necessary for normal operation. However, the preceding rule is in group 100, and according to the head rule for this group, the only packets that will be affected are those that are outbound on the ed0 interface. Loopback packets should never go out over a network interface, so this rule is appropriate. Thus, this rule would protect others from being damaged by a misconfiguration on your network, but wouldn’t prevent someone from sending you IP packets that appeared to be from your loopback interface. After all, you’re only checking outbound packets in this rule. So, how does this all fit together? The following example rule set is for a server with one network interface, xl0, and one IP address, 192.168.1.200. This ruleset allows incoming POP3, SMTP, and Web connections, and any outgoing connections. (You can find more examples of IPFilter rules for various protocols in /usr/src/contrib/ipfilter/rules.) ………………………………………………………………………………………. #block garbage we never ever want to accept. v block in log quick from any to any with ipopts w block in log quick proto tcp from any to any with short ………………………………………………………………………………………. These initial rules are not in any group, and they come first, so they are applied against all packets. The first rule tells the system to reject all packets using IP Options (v). If you don’t know what IP Options are, you don’t want to accept them. No standard server program will require them. The second rule tells you to reject all ultra-short TCP packets (w). These rules are fairly standard in all IPFilter installs, and are widely recommended on any firewall or packet filter you might encounter. The next two rules are as follows: ………………………………………………………………………………………. #the system loopback interface #we can do anything we like to ourselves. pass in quick on lo0 all pass out quick on lo0 all 173
Note: If you are looking for good and high quality web space to host and run your application check Lunarwebhost Linux Web Hosting services