Unix Host Security: Hacks 1-10

Security isn’t a noun, it’s a verb; not a product, but a process. Today, learn the hacks involved in reducing the risks involved in offering services on a Unix-based system. This the first part of chapter one in Network Security Hacks, by Andrew Lockhart (ISBN 0-596-00643-8, O’Reilly & Associates, 2004).

Networ Security HacksNetworking is all about connecting computers together, so it follows that a computer network is no more secure than the machines that it connects. A single insecure host can make lots of trouble for your entire network, as it can act as a tool for reconnaissance or a strong base of attack if it is under the control of an adversary. Firewalls, intrusion detection, and other advanced security measures are useless if your servers offer easily compromised services. Before delving into the network part of network security, you should first make sure that the machines you are responsible for are as secure as possible.

This chapter offers many methods for reducing the risks involved in offering services on a Unix-based system. Even though each of these hacks can stand on its own, it is worth reading through this entire chapter. If you only implement one type of security measure, you run the risk of all your preparation being totally negated once an attacker figures out how to bypass it. Just as Fort Knox isn’t protected by a regular door with an ordinary dead bolt, no single security feature can ultimately protect your servers. And the security measures you may need to take increase proportionally to the value of what you’re protecting.

As the old saying goes, security isn’t a noun, it’s a verb. That is, security is an active process that must be constantly followed and renewed. Short of unplugging the machine, there is no single action you can take to secure your machine. With that in mind, consider these techniques as a starting point for building a secure server that meets your particular needs.


Visit the O’Reilly Network http://www.oreillynet.com for more online content.

{mospagebreak title=Secure Mount Points Hack #1} 

Use mount options to help prevent intruders from further escalating a compromise.

The primary way of interacting with a Unix machine is through its filesystem. Thus, when an intruder has gained access to a system, it is desirable to limit what he can do with the files available to him. One way to accomplish this is with the use of restrictive mount options.

A mount option is a flag that controls how the filesystem may be accessed. It is passed to the operating system kernel’s code when the filesystem is brought online. Mount options can be used to prevent files from being interpreted as device nodes, to disallow binaries from being executed, and to disallow the SUID bit from taking affect (by using the nodev, noexec, and nosuid flags). Filesystems can also be mounted read-only with the ro option.

These options are specified from the command line by running mount with the -o flag. For example, if you have a separate partition for /tmp that is on the third partition of your first IDE hard disk, you can mount with the nodev, noexec, and nosuid flags, which are enabled by running the following command:

# mount -o nodev,noexec,nosuid /dev/hda3 /tmp

An equivalent entry in your /etc/fstab would look something like this:

/dev/hda3  /tmp  ext3  defaults,nodev,noexec,nosuid 1 2

By carefully considering your requirements and dividing up your storage into multiple filesystems, you can utilize these mount options to increase the work that an attacker will have to do in order to further compromise your system. A quick way to do this is to first categorize your directory tree into areas that need write access for the system to function and those that don’t. You should consider using the read-only flag on any part of the filesystem where the contents do not change regularly. A good candidate for this might be /usr, depending on how often updates are made to system software.

Obviously, many directories (such as /home) will need to be mounted as read-write. However, it is unlikely that users on an average multiuser system will need to run SUID binaries or create device files within their home directories. Therefore, a separate filesystem, mounted with the nodev and nosuid options, could be created to house the users’ home directories. In addition, if you’ve determined that your users will not need to execute programs stored in their home directories, you can use the noexec mount option as well. Similar situations also arise when looking at /tmp and /var, where it is highly unlikely that any process will legitimately need to execute SUID or  non-SUID binaries or access device files. This helps prevent the possibility of an attacker leaving a Trojan horse in common directories, such as /tmp or a user’s home directory. The attacker may be able to install the program, but it cannot actually run, with or without the proper chmod bits.

Note that services running in a chroot( ) environment [Hack #10] may be broken if nodev is specified on the filesystem running under the chroot. This is because device nodes such as /dev/log and /dev/null must be available within the chroot( ) environment.

There are a number of ways that an attacker can still circumvent these mount restrictions. For example, the noexec option on Linux can be bypassed by using /lib/ld-linux.so to execute binaries residing on such filesystems. At first glance, you’d think that this can be remedied by making ld-linux.so nonexecutable, but this would render all dynamically linked binaries unexecutable. So, unless all of the programs you rely on are statically linked (they’re probably not), then the noexec option is of little use in Linux. In addition, an attacker who has already gained root privileges will not be significantly hampered by filesystems mounted with special options, since these can often be remounted with the -o remount option. But by using mount flags, you can easily limit the possible attacks available to a hostile user before he gains root privileges.



{mospagebreak title=Scan for SUID and SGID Programs Hack #2}

Quickly check for potential root-exploitable programs and backdoors.

One potential way for a user to escalate her privileges on a system is to exploit a vulnerability in an SUID or SGID program. SUID and SGID are legitimately used when programs need special permissions above and beyond those that are available to the user who is running them. One such program is passwd. Simultaneously allowing a user to change her password while not allowing any user to modify the system password file means that the passwd program must be run with root privileges. Thus the program has its SUID bit set, which causes it to be executed with the privileges of the program file’s owner. Similarly, when the SGID bit is set, the program is executed with the privileges of the file’s group owner.

Running ls -l on a binary that has its SUID bit set should look like this:

-r-s–x–x 1 root root 16336 Feb 13 2003 /usr/bin/passwd

Notice that instead of an execute bit (x) for the owner bits, it has an s. This signifies an SUID file.

Unfortunately, a poorly written SUID or SGID binary can be used to quickly and easily escalate a user’s privileges. Also, an attacker who has already gained root access may hide SUID binaries throughout your system in order to leave a backdoor for future access. This leads us to the need for scanning systems for SUID and SGID binaries. This is a simple process and can be done with the following command:


One important thing to consider is whether an SUID program is in fact a shell script rather than an executable, since it’s trivial for someone to change an otherwise innocuous script into a backdoor. Most operating systems will ignore any SUID or SGID bits on a shell script, but if you want to find all SUID or SGID scripts on a system, change the argument to the -exec option in the last command and add a pipe so that the command reads:

# find / ( -perm -4000 -o -perm -2000 )
-type f -exec file {} ; | grep -v ELF

Now every time an SUID or SGID file is encountered, the file command will run and determine what type of file is being examined. If it’s an executable, grep will filter it out; otherwise, it will be printed to the screen with some information about what kind of file it is. Most operating systems use ELF-format executables, but if you’re running an operating system that doesn’t (older versions of Linux used a.out, and AIX uses XCOFF), you’ll need to replace the ELF in the previous grep command with the binary format used by your operating system and architecture. If you’re unsure of what to look for, run the file command on any binary executable, and it will report the string you’re looking for.

For example, here’s an example of running file on a binary in Mac OS X:

$ file /bin/sh
/bin/sh: Mach-O executable ppc

To go one step further, you could even queue the command to run once a day using cron and have it redirect the output to a file. For instance, this crontab entry would scan for files that have either the SUID or SGID bits set, compare the current list to the one from the day before, and then email the differences to the owner of the crontab (make sure this is all on one line):

0 4 * * * find / ( -perm -4000 -o -perm -2000 ) -type f
> /var/log/sidlog.new &&
diff /var/log/sidlog.new /var/log/sidlog &&
mv /var/log/sidlog.new /var/log/sidlog

This example will also leave a current list of SUID and SGID files in /var/log/sidlog



{mospagebreak title=Scan For World- and Group-Writable Directories Hack #3}

Quickly scan for directories with loose permissions.

World- and group-writable directories present a problem: if the users of a system have not set their umask properly, they will inadvertently create insecure files, completely unaware of the implications. With this in mind, it seems it would be good to scan for directories with loose permissions. Much like “Scan for SUID and SGID Programs” [Hack #2], this can be accomplished by running the find command:

# find / -type d ( -perm -g+w -o -perm -o+w ) -exec ls -lad {} ;

Any directories that are listed in the output should have the sticky bit set, which is denoted by a t in the directory’s permission bits. A world-writable directory with the sticky bit set ensures that even though anyone may create files in the directory, they may not delete or modify another user’s files. If you see a directory in the output that does not contain a sticky bit, consider whether it really needs to be world-writable or whether the use of groups or ACLs [Hack #4] will work better for your situation. If you really do need the directory to be world-writable, set the sticky bit on it using chmod +t.

To get a list of the directories that don’t have their sticky bit set, run this:

-not -perm -a+t -exec ls -lad {} ;

If you’re using a system that creates a unique group for each user (e.g., you create a user andrew, which in turn creates a group andrew as the primary group), you may want to modify the commands to not scan for group-writable directories. (Otherwise, you will get a lot of output that really isn’t pertinent.) To do this, run the command without the -perm -g+w portion.



{mospagebreak title=Create Flexible Permissions Hierarchies w/ith POSIX ACLs Hack #4}
When Unix mode-based permissions just aren’t enough, use an ACL.

Most of the time, the traditional Unix file permission system fits the bill just fine. But in a highly collaborative environment with multiple people needing access to files, this scheme can become unwieldy. Access control lists, otherwise known as ACLs (pronounced to rhyme with “hackles”), are a feature that is relatively new to the Linux operating system, but has been available in FreeBSD and Solaris for some time. While ACLs do not inherently add “more security” to a system, they do reduce the complexity of managing permissions. ACLs provide new ways to apply file and directory permissions without resorting to the creation of unnecessary groups.

ACLs are stored as extended attributes within the filesystem metadata. As the name implies, they allow you to define lists that either grant or deny access to a given file based on the criteria you provide. However, ACLs do not abandon the traditional permission system completely. ACLs may be specified for both users and groups and are still separated into the realms of read, write, and execute access. In addition, a control list may be defined for any user or group that does not correspond to any of the user or group ACLs, much like the “other” mode bits of a file. Access control lists also have what is called an ACL mask, which acts as a permission mask for all ACLs that specifically mention a user and a group. This is similar to a umask, but not quite the same. For instance, if you set the ACL mask to r–, any ACLs that pertain to a specific user or group and are looser in permissions (e.g., rw-) will effectively become r–. Directories also may contain a default ACL, which specifies the initial ACLs of files and subdirectories created within them. 

To modify or remove ACLs, use the setfacl command. To modify an ACL, the -m option is used, followed by an ACL specification and a filename or list of filenames. You can delete an ACL by using the -x option and specifying an ACL or list of ACLs.

There are three general forms of an ACL: one for users, another for groups, and one for others. Let’s look at them here:

# User ACL
# Group ACL
# Other ACL

Notice that in the user and group ACLs, the actual user and group names that the ACL applies to are optional. If these are omitted, it means that the ACL will apply to the base ACL, which is derived from the file’s mode bits. Thus, if you modify these, the mode bits will be modified and vice versa.

See for yourself by creating a file and then modifying its base ACL:

$ touch myfile
$ ls -l myfile
-rw-rw-r– 1 andrew andrew 0 Oct 13 15:57 myfile
$ setfacl -m u::—,g::—,o:— myfile
$ ls -l myfile
———- 1 andrew andrew 0 Oct 13 15:57 myfile

From this example, you can also see that multiple ACLs can be listed by separating them with commas.

You can also specify ACLs for an arbitrary number of groups or users:

$ touch foo
$ setfacl -m u:jlope:rwx,g:wine:rwx ,o:— foo
$ getfacl foo
# file: foo
# owner: andrew
# group: andrew

Now if you changed the mask to r–, the ACLs for jlope and wine would effectively become r– as well:

$ setfacl -m m:r– foo
$ getfacl foo
# file: foo
# owner: andrew
# group: andrew
jlope:rwx #effective:r–
group:wine:rwx #effective:r–

As mentioned earlier, directories can have default ACLs that will automatically be applied to files that are created within the directory. Default ACLs are set by prepending a d: to the ACL that you want to set:

$ mkdir mydir
$ setfacl -m d:u:jlope:rwx mydir
$ getfacl mydir
# file: mydir
# owner: andrew
# group: andrew

$ touch mydir/bar
$ getfacl mydir/bar
# file: mydir/bar
# owner: andrew
# group: andrew
jlope:rwx       #effective:rwgroup::—

As you may have noticed from the previous examples, you can list ACLs by using the getfacl command. This command is pretty straightforward and has only a few options. The most useful is the -R option, which allows you to list ACLs recursively and works very much like ls -R.



{mospagebreak title=Protect Your Logs from Tampering Hack #5}

Use file attributes to prevent intruders from removing traces of their break-in.

In the course of an intrusion, an attacker will more than likely leave telltale signs of his actions in various system logs. This is a valuable audit trail that should be well protected. Without reliable logs, it can be very difficult to figure out how the attacker got in, or where the attack came from. This information is crucial in analyzing the incident and then responding to it by contacting the appropriate parties involved [Hack #100]. However, if the breakin attempt is successful and the intruder gains root privileges, what’s to stop him from removing the traces of his misbehavior?

This is where file attributes come in to save the day (or at least make it a little better). Both Linux and the BSDs have the ability to assign extra attributes to files and directories. This is different from the standard Unix permissions scheme in that the attributes set on a file apply universally to all users of the system, and they affect file accesses at a much deeper level than file permissions or ACLs [Hack #4]. In Linux you can see and modify the attributes that are set for a given file by using the lsattr and chattr commands, respectively. Under the BSDs, ls -lo can be used to view the attributes, and chflags can be used to modify them. At the time of this writing, file attributes in Linux are available only when using the ext2 and ext3 filesystems. There are also kernel patches available for attribute support in XFS and reiserfs.



# chattr +a filename

Under the BSDs, use this:

# chflags sappnd filename

See how the +a attribute works by creating a file and setting its append-only attribute:

# touch /var/log/logfile
# echo “append-only not set” > /var/log/logfile
# chattr +a /var/log/logfile
# echo “append-only set” > /var/log/logfile
bash: /var/log/logfile: Operation not permitted


# echo “appending to file” >> /var/log/logfile
# cat /var/log/logfile
append-only not set
appending to file

Obviously, an intruder who has gained root privileges could realize that file attributes are being used and just remove the append-only flag from our logs by running chattr –a. To prevent this, we need to disable the ability to remove the append-only attribute. To accomplish this under Linux, use its capabilities mechanism. Under the BSDs, use its securelevel facility.

The Linux capabilities model divides up the privileges given to the allpowerful root account and allows you to selectively disable them. In order to prevent a user from removing the append-only attribute from a file, we need to remove the CAP_LINUX_IMMUTABLE capability. When present in the running system, this capability allows the append-only attribute to be modified. To
modify the set of capabilities available to the system, we will use a simple utility called lcap (http://packetstormsecurity.org/linux/admin/lcap-0.0.3.tar.bz2).

To unpack and compile the tool, run this command:

# tar xvfj lcap-0.0.3.tar.bz2 && cd lcap-0.0.3 && make


# ./lcap CAP_SYS_RAWIO

The first command removes the ability to change the append-only flag, and the second command removes the ability to do raw I/O. This is needed so that the protected files cannot be modified by accessing the block device they reside on. It also prevents access to /dev/mem and /dev/kmem, which would provide a loophole for an intruder to reinstate the CAP_LINUX_ IMMUTABLE capability. To remove these capabilities at boot, add the previous two commands to your system startup scripts (e.g., /etc/rc.local). You should ensure that capabilities are removed late in the boot order, to prevent problems with other startup scripts. Once lcap has removed kernel capabilities, they can be reinstated only by rebooting the system.

The BSDs accomplish the same thing through the use of securelevels. The securelevel is a kernel variable that can be set to disallow certain functionality. Raising the securelevel to 1 is functionally the same as removing the two previously discussed Linux capabilities. Once the securelevel has been set to a value greater than 0, it cannot be lowered. By default, OpenBSD will raise the securelevel to 1 when in multiuser mode. In FreeBSD, the securelevel is –1 by default.

To change this behavior, add the following line to /etc/sysctl.conf:





{mospagebreak title=Delegate Administrative Roles Hack #6}

Let others do your work for you without giving away root privileges.

The sudo utility can help you delegate some system responsibilities to other people, without giving away full root access. It is a setuid root binary that executes commands on an authorized user’s behalf, after she has entered her current password.

As root, run /usr/sbin/visudo to edit the list of users who can call sudo. The default sudo list looks something like this:

root ALL=(ALL) ALL

Unfortunately, many system administrators tend to use this entry as a template and grant unrestricted root access to all other admins unilaterally:

root ALL=(ALL) ALL
david ALL=(ALL) ALL

While this may allow you to give out root access without giving away the root password, this method is truly useful only when all of the sudo users can be completely trusted. When properly configured, the sudo utility provides tremendous flexibility for granting access to any number of commands, run as any arbitrary uid.

The syntax of the sudo line is:

user machine=(effective user) command

The first column specifies the sudo user. The next column defines the hosts in which this sudo entry is valid. This allows you to easily use a single sudo configuration across multiple machines.

For example, suppose you have a developer who needs root access on a development machine, but not on any other server:

peter beta.oreillynet.com=(ALL) ALL

The next column (in parentheses) specifies the effective user that may run the commands. This is very handy for allowing users to execute code as users other than root:

peter lists.oreillynet.com=(mailman) ALL

Finally, the last column specifies all of the commands that this user may run:

david ns.oreillynet.com=(bind) /usr/sbin/rndc,/usr/sbin/named

If you find yourself specifying large lists of commands (or, for that matter, users or machines), then take advantage of sudo’s Alias syntax. An Alias can be used in place of its respective entry on any line of the sudo configuration:

User_Alias ADMINS=rob,jim,david
User_Alias WEBMASTERS=peter,nancy
Runas_Alias DAEMONS=bind,www,smmsp,ircd
Host_Alias WEBSERVERS=www.oreillynet.com,www.oreilly.com,www.perl.com
Cmnd_Alias PROCS=/bin/kill,/bin/killall,/usr/bin/skill,/usr/bin/top
Cmnd_Alias APACHE=/usr/local/apache/bin/apachectl

It is also possible to specify system groups in place of the user specification, to allow any user who belongs to that group to execute commands. Just preface the group with a %, like this:

%wwwadmin WEBSERVERS=(www) APACHE

Now any user who is part of the wwwadmin group can execute apachectl as the www user on any of the web server machines.

One very useful feature is the NOPASSWD: flag. When present, the user won’t have to enter a password before executing the command:


This will allow the user rob to execute kill, killall, skill, and top on any machine, as any user, without entering a password.

Finally, sudo can be a handy alternative to su for running commands at startup out of the system rc files:

(cd /usr/local/mysql; sudo -u mysql ./bin/safe_mysqld &)
sudo -u www /usr/local/apache/bin/apachectl start

For that to work at boot time, the default line root ALL=(ALL) ALL must be present.

Use sudo with the usual caveats that apply to setuid binaries. Particularly if you allow sudo to execute interactive commands (like editors) or any sort of compiler or interpreter, you should assume that it is possible that the sudo user will be able to execute arbitrary commands as the effective user. Still, under most circumstances this isn’t a problem, and it’s certainly preferable to giving away undue access to root privileges.

—Rob Flickenger 



{mospagebreak title=Automate Cryptographic Signature Verification Hack #7}

Use scripting and key servers to automate the chore of checking software authenticity.

One of the most important things you can do for the security of your system is to be familiar with the software you are installing. You probably will not have the time, knowledge, or resources to actually go through the source code for all of the software that you are installing. However, verifying that the software you are compiling and installing is what the authors intended it to be can go a long way toward preventing the widespread distribution of Trojan horses. Recently, several pivotal pieces of software (such as tcpdump, LibPCap, Sendmail, and OpenSSH) have had Trojaned versions distributed. Since this is an increasingly popular vector for attack, verifying
your software is critically important.

Why is this even an issue? Unfortunately, it takes a little bit of effort to verify software before installing it. Either through laziness or ignorance, many system administrators overlook this critical step. This is a classic example of “false” laziness, as it will likely lead to more work for the sysadmin in the long run. This problem is difficult to solve because it relies on the programmers and distributors to get their acts together. Then there’s the laziness aspect: many times, software packages don’t even come with a signature to use for verifying the legitimacy of what you’ve downloaded. Often, signatures are available right along with the source code, but in order to verify the code, you must then hunt through the site for the public key that was used to create the signature. After finding the public key, you have to download it, verify that the key is genuine, add it to your keyring, and finally check the signature of the code.

Here is what this would look like when checking the signature for Version 1.3.28 of the Apache web server using GnuPG (http://www.gnupg.org):

# gpg -import KEYS
# gpg -verify apache_1.3.28.tar.gz.asc apache_1.3.28.tar.gz
gpg: Signature made Wed Jul 16 13:42:54 2003 PDT using DSA key ID 08C975E5
gpg: Good signature from “Jim Jagielski <
gpg: aka “Jim Jagielski <
gpg: aka “Jim Jagielski <
gpg: There is no indication that the signature belongs to the
Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5

As you can see, it’s not terribly difficult to do, but this step is often overlooked when you are in a hurry. This is where this hack comes to the rescue. We’ll use a little bit of shell scripting and what are known as key servers to reduce the number of steps to perform this process.

Key servers are a part of a public-key cryptography infrastructure that allows you to retrieve keys from a trusted third party. A nice feature of GnuPG is its ability to query key servers for a key ID and to download the result into a local keyring. To figure out which key ID to ask for, we rely on the fact that the error message generated by GnuPG tells us which key ID it was unable to find locally when trying to verify the signature.

In the previous example, if the key that GnuPG was looking for had not been imported prior to verifying the signature, it would have generated an error like this:

gpg: Can’t check signature: public key not found

The following script takes advantage of that error:

KEYID=”0x`gpg –verify $1 $2 2>&1 | grep ‘key ID’ | awk ‘{print $NF}’`”
gpg –no-default-keyring –keyring $VENDOR_KEYRING –recv-key
–keyserver $KEYSERVER $KEYID
gpg –keyring $VENDOR_KEYRING –verify $1 $2

The first line of the script specifies the keyring in which the result from the key server query will be stored. You could use pubring.gpg (which is the default keyring for GnuGP), but using a separate file will make managing vendor public keys easier. The second line of the script specifies which key server to query (the script uses search.keyserver.net; another good one is pgp.mit.edu). The third line attempts (and fails) to verify the signature without first consulting the key server. It then uses the key ID it saw in the error, and prepends an 0x in order to query the key server on the next line. Finally, GnuPG attempts to verify the signature, and specifies the keyring in which the query result was stored.

This script has shortened the verification process by eliminating the need to search for and import the public key that was used to generate the signature. Going back to the example of verifying the Apache 1.3.28 source code, you can see how much more convenient it is to verify the package’s authenticity:

# checksig apache_1.3.28.tar.gz.asc apache_1.3.28.tar.gz
gpg: requesting key 08C975E5 from HKP keyserver search.keyserver.net
gpg: key 08C975E5: public key imported
gpg: Total number processed: 1
gpg: imported: 1
gpg: Warning: using insecure memory!
gpg: please see
http://www.gnupg.org/faq.html for more information
gpg: Good signature from “Jim Jagielski <
gpg: aka “Jim Jagielski <
gpg: aka “Jim Jagielski <
gpg: checking the trustdb
gpg: no ultimately trusted keys found
gpg: There is no indication that the signature belongs to the
Fingerprint: 8B39 757B 1D8A 994D F243 3ED5 8B3A 601F 08C9 75E5

With this small and quick script, both the number steps needed to verify a source package and the amount of time needed have been reduced. As with any good shell script, it should help you to be lazy in a good way: by doing more work properly, but with less effort on your part. 



{mospagebreak title=Check for Listening Services Hack #8}




# netstat -luntp
Active Internet connections (only servers)
tcp 0 0* LISTEN 1679/sshd
udp 0 0* 1766/dhclient




# netstat -a -n | egrep ‘Proto|LISTEN’
tcp4 0 0 *.587 *.* LISTEN
tcp4 0 0 *.25 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN
tcp4 0 0 *.993 *.* LISTEN
tcp4 0 0 *.143 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN


# grep –w 993 /etc/services
imaps 993/udp # imap4 protocol over TLS/SSL
imaps 993/tcp # imap4 protocol over TLS/SSL

Also notice that, unlike the output of netstat on Linux, we don’t get the PIDs of the daemons themselves. You might also notice that no UDP ports were listed for DNS. This is because UDP sockets do not have a LISTEN state in the same sense that TCP sockets do. In order to display UDP sockets, you must add udp4 to the argument for egrep, thus making it ‘Proto|LISTEN|udp4’. However, due to the way UDP works, not all UDP sockets will necessarily be associated with a daemon process.



# sockstat -4 -l
root sendmail 1141 4 tcp4 *:25 *:*
root sendmail 1141 5 tcp4 *:587 *:*
root sshd 1138 3 tcp4 *:22 *:*
root inetd 1133 4 tcp4 *:143 *:*
root inetd 1133 5 tcp4 *:993 *:*
named named 1127 20 tcp4 *:53 *:*
named named 1127 21 udp4 *:53 *:*
named named 1127 22 udp4 *:1351 *:*


For most other Unix-like operating systems you can use the lsof utility (ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/). lsof is short for “list open files” and, as the name implies, allows you to list files that are open on a system, in addition to the processes and PIDs that have them open. Since sockets and files work the same way under Unix, lsof can also be used to list open sockets. This is done with the -i command-line option.


# lsof -i -n | egrep ‘COMMAND|LISTEN’

Again, you can change the argument to egrep to display UDP sockets. However, this time use UDP instead of udp4, which makes the argument ‘COMMAND|LISTEN|UDP’. As mentioned earlier, not all UDP sockets will necessarily be associated with a daemon process.



{mospagebreak title=Prevent Services from Binding to an Interface Hack #9}

Keep services from listening on a port instead of firewalling them.



If you use VirtualHost entries, you can specify interfaces to bind to on a pervirtual-host basis:



You may even have services that are listening on a TCP port but don’t need to be. Database servers such as MySQL are often used in conjunction with Apache, and are frequently set up to coexist on the same server when used in this way. Connections that come from the same machine that MySQL is installed on use a domain socket in the filesystem for communications. Therefore, you don’t need to have MySQL listening on a TCP socket. To do this, you can either use the –skip-networking command-line option when starting MySQL or specify it in the [mysqld] section of your my.cnf file:



Another program that you’ll often find listening on a port is your X11 server, which listens on TCP port 6000 by default. This port is traditionally used to enable remote clients to connect to your X11 server so they can draw their windows and accept keyboard and mouse input; however, with the advent of SSH and X11 forwarding, this really isn’t needed anymore. With X11 forwarding enabled in ssh, any client that needs to connect to your X11 server will be tunneled through your SSH connection and will bypass the listening TCP port when connecting to your X11 server. To get your X Windows server to stop listening on this port, all you need to do is add -nolisten tcp to the command that is used to start the server. This can be tricky, though — figuring out which file controls how the server is started can be a daunting task. Usually, you can find what you’re looking for in /etc/X11.

If you’re using gdm, open your gdm.conf and look for a line similar to this one:



If you’re using xdm, look for a file called Xservers and make sure it contains a line similar to this:


Alternatively, if you’re not using a managed display and instead you’re using startx or a similar command to start your X11 server, you can just add -nolisten tcp to the end of your startx command. To be sure that it is passed to the X server process, start it after an extra set of hyphens:

$ startx — -nolisten tcp




{mospagebreak title=Restrict Services with Sandboxed Environments Hack #10}

Mitigate system damage by keeping service compromises contained.

Sometimes keeping up with the latest patches just isn’t enough to prevent a break-in. Often, a new exploit will circulate in private circles long before an official advisory is issued, during which time your servers may be open to unexpected attack. With this in mind, it’s wise to take extra preventative measures to contain the aftermath of a compromised service. One way to do this is to run your services in sandbox environments. Ideally, this lets the service be compromised while minimizing the effects on the overall system.

Most Unix and Unix-like systems include some sort of system call or other mechanism for sandboxing that offers various levels of isolation between the host and the sandbox. The least restrictive and easiest to set up is a chroot( ) environment, which is available on nearly all Unix and Unix-like systems. In addition to chroot( ), FreeBSD includes another mechanism called jail( ), which provides a few more restrictions beyond those provided by chroot( ).

chroot( ) very simply changes the root directory of a process and all of its children. While this is a powerful feature, there are many caveats to using it. Most importantly, there should be no way for anything running within the sandbox to change its effective UID (EUID) to 0, which is root’s UID. Naturally, this implies that you don’t want to run anything as root within the jail. If an attacker is able to gain root privileges within the sandbox, then all bets are off. While the attacker will not be able to directly break out of the sandbox environment, it does not prevent him from running functions inside the exploited processes’ address space that will let him break out. There are many ways to break out of a chroot( ) sandbox. However, they all rely on being able to get root privileges within the sandboxed environment. The Achilles heel of chroot( ) is possession of UID 0 inside the sandbox.

There are a few services that support chroot( ) environments by calling the function within the program itself, but many services do not. To run these services inside a sandboxed environment using chroot( ), we need to make use of the chroot command. The chroot command simply calls chroot( ) with the first command-line argument and attempts to execute the program specified in the second argument. If the program is a statically linked binary, all you have to do is copy the program to somewhere within the sandboxed environment; but if the program is dynamically linked, you will need to copy all of its supporting libraries to the environment as well.

See how this works by setting up bash in a chroot( ) environment. First we’ll try to run chroot without copying any of the libraries bash needs:

# mkdir -p /chroot_test/bin
# cp /bin/bash /chroot_test/bin/
# chroot /chroot_test /bin/bash
chroot: /bin/bash: No such file or directory

Now we’ll find out what libraries bash needs, which you can do with the ldd command, and attempt to run chroot again:

# ldd /bin/bash
libtermcap.so.2 => /lib/libtermcap.so.2 (0x4001a000)
libdl.so.2 => /lib/libdl.so.2 (0x4001e000)
# mkdir -p chroot_test/lib/tls &&
> (cd /lib;
> cp libtermcap.so.2 libdl.so.2 ld-linux.so.2 /chroot_test/lib;
> cd tls; cp libc.so.6 /chroot_test/lib/tls)
# chroot /chroot_test /bin/bash
bash-2.05b# echo /*
/bin /lib

Setting up a chroot environment mostly involves trial and error in getting permissions right and all of the library dependencies in order. Be sure to consider the implications of having other programs such as mknod or mount available in the chroot environment. If these were available, the attacker could possibly create device nodes to access memory directly or to remount filesystems, thus breaking out of the sandbox and gaining total control of the overall system. This threat can be mitigated by putting the directory on a filesystem mounted with options that prohibit the use of device files (as in “Secure Mount Points” [Hack #1]), but that isn’t always convenient. It is advisable to make as many of the files and directories in the chrooted directory as possible owned by root and writable only by root, in order to make it impossible for a process to modify any supporting files (this includes files such as libraries and configuration files). In general it is best to keep permissions as restrictive as possible, and to relax them only when necessary (for example, if the permissions prevent the daemon from working properly).

The best candidates for a chroot( ) environment are services that do not need root privileges at all. For instance, MySQL listens for remote connections on port 3306 by default. Since this port is above 1024, mysqld can be started without root privileges and therefore doesn’t pose the risk of being used to gain root access. Other daemons that need root privileges can include an option to drop these privileges after completing all the operations for which it needs root access (e.g., binding to a port below 1024), but care should be taken to ensure that the program drops its privileges correctly. If a program uses seteuid( ) rather than setuid( ) to drop its privileges, it is still possible to gain root access when exploited by an attacker. Be sure to read up on current security advisories for programs that will run only with root privileges.

You might think that simply not putting compilers, a shell, or utilities such as mknod in the sandbox environment may protect them in the event of a root compromise within the restricted environment. In reality, attackers can accomplish the same functionality by changing their code from calling system(“/bin/sh”) to calling any other C library function or system call that they desire. If you can mount the filesystem that the chrooted program runs from using the read-only flag [Hack #1], you can make it more difficult for attackers to install their own code, but this is still not quite bulletproof. Unless the daemon you need to run within the environment can meet the criteria discussed earlier, you might want to look into using a more powerful sandboxing mechanism.

One such mechanism is available under FreeBSD and is implemented through the jail( ) system call. jail( ) provides many more restrictions in isolating the sandbox environment from the host system and provides additional features, such as assigning IP addresses from virtual interfaces on the host system. Using this functionality, you can create a full virtual server or just run a single service inside the sandboxed environment.

Just as with chroot( ), the system provides a jail command that uses the jail( ) system call. The basic form of the jail command is:

jail new root hostname ipaddr command

where ipaddr is the IP address of the machine on which the jail is running.

Try it out by running a shell inside a jail:

# mkdir -p /jail_test/bin
# cp /bin/sh /jail_test/sh
# jail /jail_test jail_test /bin/sh
# echo /*

This time, no libraries needed to be copied, because FreeBSD’s /bin/sh is statically linked.

On the opposite side of the spectrum, we can build a jail that can function as a nearly full-function virtual server with its own IP address. The steps to do this basically involve building FreeBSD from source and specifying the jail directory as the install destination.

You can do this by running the following commands:

# mkdir /jail_test
# cd /usr/src
# make world DESTDIR=/jail_test
# cd /etc && make distribution DESTDIR=/jail_test -DNO_MAKEDEV_RUN
# cd /jail_test/dev && sh MAKEDEV jail
# cd /jail_test && ln -s dev/null kernel

However, if you’re planning to run just one service from within the jail, this is definitely overkill. Note that in the real world you’ll most likely need to create /dev/null and /dev/log device nodes in your sandbox environment for most daemons to work correctly. 




chat sex hikayeleri Ensest hikaye