Installing a firewall, Part 3

LinuxWorld.com –

In the first part of this series, we discussed the installation of Trustix, a secured Linux distribution, on our client's new firewall machine,
<font face="Courier">wolf.example.com</font>
. In the second part, we detailed setting up services on
<font face="Courier">wolf</font>
to provide functionality comparable to that of the server
<font face="Courier">wolf</font>
replaced,
<font face="Courier">plains.example.com</font>
. In this third and last installment, we will discuss some of the additional security measures we took to further protect our client's data. Those included firewall setup and the installation of intrusion-detection tools, along with local security measures.

After installing such services, it would be possible to get a false sense of security about the firewall system. But all the security software and setup in the world is worthless without regular monitoring. It is crucial that human beings look at the reports generated by the software and monitor security mailing lists for new vulnerabilities.

Creating a firewall

A firewall is a router that refuses to route and thus prevents outside traffic from reaching the inside. We chose to poke several holes through the firewall to permit a few different kinds of traffic through, but a pure firewall would allow no traffic at all. As discussed in the previous installment, the services running on our firewall,

<font face="Courier">wolf</font>
, are Postfix, Squid, and FTPD.

LinuxWorld.com links LinuxWorld.com home

Best of LinuxWorld.com

The Legacy Files

The Penguin Brief

Version Control

Linux links

Linux forums

It is particularly important to articulate a clear set of goals before designing or implementing the firewall rules. It is easy to succumb to the grave temptation of adding seemingly sensible but ultimately unnecessary rules to the firewall. Admins who do this usually wind up with firewalls they could use to strain pasta.

Our first goal was to allow users to perform certain operations transparently from behind the firewall. After all, it makes sense to allow safe internal operations.

<font face="Courier">ping</font>
and
<font face="Courier">traceroute</font>
to the outside world are nice utilities to permit, and are relatively low-risk. We allowed
<font face="Courier">ssh</font>
from the inside because we wanted to encourage its use. We permitted masqueraded FTP from the internal network because our client requested it, and it is very useful. Finally, to conform with Internet standards, we had to allow ICMP destination unreachable packets, which are used to signal when a particular host is unreachable.

We didn't need to restrict incoming traffic because we were not forwarding from the outside in. In other words, we were not passing stuff through the firewall at a packet level at all -- we were using applications such as Squid and Postfix to pass data through at the protocol level. We also installed a port scan detector to monitor unused ports. The scan detector can produce valuable warnings if someone is "casing" the firewall: if we blocked incoming traffic on those ports, we would disable that warning system.

Since we were using a 2.2 series kernel, we didn't need to set up explicit antispoofing firewall rules. Prior to the 2.2 series, it was necessary to explicitly block incoming traffic which claimed to be from an internal IP address. In the 2.2 series, there is a kernel parameter that defeats standard spoofing attacks. We still denied incoming traffic from the "unusable" networks, 192.168.0.0/16, 172.16.0.0/12, and 10.0.0.0/8. Our client is using the 10.0.0.0/8 network internally, so the antispoofing will catch that one.

Setup

On Trustix, you can set up your firewall rules by hand using the

<font face="Courier">ipchains</font>
command. When you are satisfied with your firewall setup, you can save it by running
<font face="Courier">/etc/rc.d/init.d/ipchains save</font>
. So, for example, to permit ICMP error packets to pass through the firewall, you might type the following commands:

<font face="Courier">
ipchains -N icmp-acc<BR>
ipchains -A icmp-acc -p icmp --icmp-type destination-unreachable -j ACCEPT<BR>
ipchains -A icmp-acc -p icmp --icmp-type source-quench -j ACCEPT<BR>
ipchains -A icmp-acc -p icmp --icmp-type time-exceeded -j ACCEPT<BR>
ipchains -A icmp-acc -p icmp --icmp-type parameter-problem -j ACCEPT<BR>
</font>

That set of commands creates a new (

<font face="Courier">-N</font>
) ipchain called
<font face="Courier">icmp-acc</font>
. We then added (
<font face="Courier">-A</font>
) to the chain rules that say if the packet matches protocol ICMP (
<font face="Courier">-p</font>
) and has a particular ICMP type, then jump (
<font face="Courier">-j</font>
) to the
<font face="Courier">ACCEPT</font>
rule, which is a default rule provided by ipchains. The
<font face="Courier">ACCEPT</font>
rule causes the firewall to accept a packet and pass it along.

The example above is taken from the ipchains HOWTO (see Resources for a link), an excellent reference that contains all the information necessary to understand and create firewall rules. The point of rules is to implement the goals defined in our previous article. We recommend that you use the examples there to set up the rules for your firewall.

Local security

Paradoxically, local security is less important on a firewall than on a normal server or workstation. This is because even a nonroot compromise of a firewall is a severe security violation. In other words, attackers don't need to get root access on your firewall if having a user account allows them to attack your undefended internal network. That said, since we were running several services on

<font face="Courier">wolf</font>
, local security was worth spending some time on. Finally, by local security, we mean non-network-related security, not physical security.

The first thing to worry about in local security is who can run what as another user. The userid and permission system is the first line of defense in Unix local security. Set-user-id (suid) executables are programs which, when invoked by one user, run as though they had been invoked by another. Set-group-id (sgid) executables are programs which work in a comparable way for groups. Both provide a way around the Unix privilege system and are therefore potential sources of local compromise.

We found all the suid executables with the command

<font face="Courier">find / -type f -perm -4000 -ls > suidfiles-2000-09-02</font>
. For sgid files, we used the command
<font face="Courier"> find / -type f -perm -2000 -ls > sgidfiles-2000-09-02</font>
. We restricted the search to files
<font face="Courier">(-type f)</font>
that had (before the number) either the suid bit (octal 4000) or sgid bit (octal 2000) set in the permissions (
<font face="Courier">-perm</font>
). We further specified that the system should take a long listing (
<font face="Courier">-ls</font>
) of all files matching the criteria and redirect them into a suitable output file. See the
<font face="Courier">find (1L)</font>
manual page for more parameters. On a default Trustix install, there are 29 suid files and 7 sgid files. See the sidebar below for a complete listing.

The suid and sgid files in Trustix
<font face="Courier">
 76615   10 -rwsr-xr-x   1 root     root         9540 Jun 18 09:39 /home/httpsd/sbin/suexec<BR>
 62233  376 -rwsr-xr-x   1 root     root       377096 Jun 18 10:15 /usr/bin/lpq<BR>
 62234  380 -rwsr-xr-x   1 root     root       383212 Jun 18 10:15 /usr/bin/lpr<BR>
 62235  372 -rwsr-xr-x   1 root     root       373324 Jun 18 10:15 /usr/bin/lprm<BR>
 62236  376 -rwsr-xr-x   1 root     root       380332 Jun 18 10:15 /usr/bin/lpstat<BR>
 62547   36 -rwsr-xr-x   1 root     root        34172 Jun 18 11:36 /usr/bin/chage<BR>
 62549   36 -rwsr-xr-x   1 root     root        35732 Jun 18 11:36 /usr/bin/gpasswd<BR>
 63127  548 -rws--x--x   2 root     root       555588 Jun 18 11:09 /usr/bin/suidperl<BR>
 63127  548 -rws--x--x   2 root     root       555588 Jun 18 11:09 /usr/bin/sperl5.00503<BR>
 63218  156 -rwsr-xr-x   1 root     root       155056 Jun 18 10:52 /usr/bin/ssh<BR>
 63226   12 -r-s--x--x   1 root     root        12260 Jun 18 11:03 /usr/bin/passwd<BR>
 63628   72 -rwsr-sr-x   1 root     mail        67060 Jun 18 11:13 /usr/bin/procmail<BR>
 63885   84 ---s--x--x   1 root     root        81752 Jun 18 11:43 /usr/bin/sudo<BR>
 63947   16 -rws--x--x   1 root     root        13800 Jun 18 11:54 /usr/bin/chfn<BR>
 63948   16 -rws--x--x   1 root     root        13544 Jun 18 11:54 /usr/bin/chsh<BR>
 63965    8 -rws--x--x   1 root     root         5492 Jun 18 11:54 /usr/bin/newgrp<BR>
 64012   24 -rwsr-xr-x   1 root     root        21504 Jun 18 11:57 /usr/bin/crontab<BR>
 46466   36 -rwsr-xr-x   1 root     root        33108 Jun 18 10:27 /usr/libexec/pt_chown<BR>
 77712  340 -rwsr-xr-x   1 root     root       340780 Jun 18 10:15 /usr/sbin/lpc<BR>
 77870   12 -rws--x--x   1 root     root         9172 Jun 18 09:37 /usr/sbin/suexec<BR>
 78130    8 -rwsr-xr-x   1 root     root         5996 Jun 26 04:49 /usr/sbin/usernetctl<BR>
 79425   16 -rwsr-xr-x   1 root     bin         15816 Jun 18 11:53 /usr/sbin/traceroute<BR>
 34843   40 -rwsr-sr-x   1 root     tty         38960 Jun 18 09:54 /sbin/dump<BR>
 34845   64 -rwsr-sr-x   1 root     tty         64080 Jun 18 09:54 /sbin/restore<BR>
 34898   27 -r-sr-xr-x   1 root     root        26144 Jun 18 11:03 /sbin/pwdb_chkpwd<BR>
 36907   60 -rwsr-xr-x   1 root     root        60300 Jun 18 10:25 /bin/mount<BR>
 36908   30 -rwsr-xr-x   1 root     root        28912 Jun 18 10:25 /bin/umount<BR>
 36923   16 -rwsr-xr-x   1 root     root        15264 Jun 18 11:38 /bin/su<BR>
 36927   23 -rwsr-xr-x   1 root     root        22040 Jun 18 11:11 /bin/ping<BR>
 62253    8 -r-xr-sr-x   1 root     tty          6868 Jun 18 11:44 /usr/bin/wall<BR>
 63626   16 -rwxr-sr-x   1 root     mail        14372 Jun 18 11:13 /usr/bin/lockfile<BR>
 63628   72 -rwsr-sr-x   1 root     mail        67060 Jun 18 11:13 /usr/bin/procmail<BR>
 63975   12 -rwxr-sr-x   1 root     tty          8240 Jun 18 11:54 /usr/bin/write<BR>
 34843   40 -rwsr-sr-x   1 root     tty         38960 Jun 18 09:54 /sbin/dump<BR>
 34845   64 -rwsr-sr-x   1 root     tty         64080 Jun 18 09:54 /sbin/restore<BR>
 34853    4 -rwxr-sr-x   1 root     root         3768 Jun 26 04:49 /sbin/netreport<BR>
</font>

People have different philosophies on whether or not suid programs should be disabled. The only suid program you really need on a computer is

<font face="Courier">su</font>
. If you want to do something that requires root privilege,
<font face="Courier">su</font>
to root and do it. On the other hand, it's nice to allow, for example, users to change their own passwords without having to ask root to do it for them.

We decided to retain the following suid and sgid executables by removing the suid bit from the other commands (

<font face="Courier">chmod 755 <em>filename</em></font>
). We didn't need printing, so that eliminated the
<font face="Courier">lp*</font>
commands. We weren't going to use Perl to write suid scripts, so we could discard
<font face="Courier">suidperl</font>
and
<font face="Courier">sperl5.00503 c</font>
too. The
<font face="Courier">ch*</font>
commands allow users to change their information in the password database -- since
<font face="Courier">wolf</font>
was not a user machine, we didn't need them. We kept network utilities like
<font face="Courier">ping</font>
and
<font face="Courier">traceroute</font>
for convenience. System scripts use
<font face="Courier">Netreport</font>
,
<font face="Courier">pt_chown</font>
, and
<font face="Courier">pwdb_chkpwd</font>
, so we retained them.
<font face="Courier">sudo</font>
,
<font face="Courier">su</font>
, and
<font face="Courier">newgrp</font>
allow more controlled changes in userid and groupid, and thus implement our security policy. We allowed
<font face="Courier">passwd</font>
because, as mentioned above, we didn't want to change users' passwords all the time. Finally,
<font face="Courier">ssh</font>
needs the suid bit to read the system private key file. Since
<font face="Courier">ssh</font>
is essential, we left the suid bit on. Below is a list of the commands that retained suid or sgid bits after we stripped privileges from the others.

1 2 Page 1
Page 1 of 2
ITWorld DealPost: The best in tech deals and discounts.
  
Shop Tech Products at Amazon