wiley publishing suse linux 9 bible phần 9 ppt

482
Part IV ✦ Implementing Network Services in SUSE Linux
The Linux firewalling, as we said, is packet filter–based. A packet filter will act upon a net-
work packet, dealing with the parameters that can be queried in the TCP/IP headers. For
example, you can produce a rule that takes into consideration the source of the packet (the
source IP address), the destination (destination IP address), the protocol (for example, TCP),
the port (SSH), and the TCP options (SYN).
Taking all of these into consideration, you can define a rule that describes a very specific sce-
nario for a network connection. Putting numerous rules together, you can produce a very
powerful firewall.
With the introduction of
iptables, we were given the godsend that was stateful firewalls.
iptables is something that most Linux administrators should know, especially when you
need to secure your network or individual machines from a network attack. They are rela-
tively simple to use and extremely powerful when done correctly. All kudos to Rusty Russell
(the lead
iptables developer) for implementing this feature as it allowed us to produce tight
firewalls with fewer rules. We will talk about stateful firewalls and what they do in this chap-
ter, as well as a few scenario-based
iptables rules.
Why Use a Firewall?
A firewall, whether Linux-based or not, should always be used to protect machines connected
to the Internet. A firewall, by its very nature, is designed to control what can be accomplished
over the network, and it is very unlikely you want your 200 Windows machines to be connected
to the Internet in full view of any malicious person that comes along (and bare Windows
machines on the Internet are like drops of blood in a 10-mile radius of a pack of sharks!).
Most people think that a firewall is there to stop crackers from the Internet, but the fact of the
matter is that your users are untrusted, too. It is all well and good to trust your users when
you have security checked them and have run psychoanalytical tests to see if they have a
predisposition for breaking the rules you have imposed on them. However, internal situations
aren’t always so simple. Take the following example.

We had a customer whose firewall was very tight at deterring Internet-based attacks and didn’t
let in anything that did not need to be there. For their internal users, there were no restrictions
on connections to the Internet. All users were trusted and all good guys. Their email and oper-
ating system on the other hand were not, and they started receiving emails with viruses that
arbitrarily scanned thousands of hosts on the Internet to carry on propagating throughout the
ether. The customer found this out only because their Internet service provider (ISP) called
them to say their connection would be closed if the scanning did not stop.
This virus came through email to the user, and because Simple Mail Transport Protocol
(SMTP) traffic was allowed through to the mail server, there was nothing to stop it. This is an
important point. A packet filtering firewall does not stop viruses that are transported using
HTTP, SMTP, and so on. It stops TCP/IP traffic only on certain ports.
We used the logging facilities of
iptables to track the source of these problems, and we pro-
ceeded to remove the virus (the customer subsequently installed virus scanners on all
machines).
To combat these internal problems in the future, we tightened the security of the organiza-
tion from a network standpoint. We restricted what could be accessed on the Internet from
the internal network apart from the essentials. This stopped port scans from exiting the net-
work and stopped most incarnations of virus transmission over Internet protocols.
32_577395 ch23.qxd 12/15/04 12:23 AM Page 482
483
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
Port scanning is when a machine automatically tries to connect to a range of TCP/IP ports on
a machine to see if there are any services listening. It is used not only by crackers, but also by
legitimate users who wish to see what services are available on a server. You should port
scan only hosts that you have been allowed to interrogate. Port scanning a machine usually
triggers alarms on a system, and you may get into trouble depending what the administrator
is feeling like that day.
This example fully illustrates that network security must be considered as a whole, not just
as a threat from the Internet.

Configuring a Firewall with iptables
To configure a firewall on Linux, you need to get used to the iptables command, which is
used to manipulate the kernel packet filtering settings from user space. (Refer to Chapter 6
for more information on TCP/IP, because an understanding of TCP/IP is needed.)
The terms user space and kernel space are used a lot in the Unix community. When some-
thing runs in kernel space, it is under the control and the constraints of the kernel.
Something running in kernel space could be a kernel module or the packet filtering code.
When something is in user space, it uses the system libraries and is not under the strict con-
trol of the kernel. We use iptables (user space) to tell the kernel space filtering code
(netfilter) what it needs to do with the TCP/IP packets it receives. When a TCP/IP packet
is received by the kernel, it is passed and acted upon in kernel space by the netfilter
code.
The kernel filtering code uses chains to signify where a packet is in the kernel. Figure 23-1
gives an overview of how the kernel sees a TCP/IP packet. This also helps us to see how
iptables interacts with these packets later in the chapter.
Figure 23-1: Overview of the kernel chains
Forward
Kernel/Processes
OutputInput
Note
Note
32_577395 ch23.qxd 12/15/04 12:23 AM Page 483
484
Part IV ✦ Implementing Network Services in SUSE Linux
The filtering chains are extremely important to the operation of the filtering code because
they determine whether or not a packet should be interpreted by the kernel.
The chains themselves represent the final destination of the packet:
✦ INPUT— The packet is destined for the firewall itself.
✦ OUTPUT— The packet originated from the firewall.
✦ FORWARD— The packet is passing through the firewall (neither originates from nor is

destined for the firewall).
Consider these examples to show how the chains work in a normal firewall:
✦ My firewall at home is Linux based, and it does a few things that most small firewalls
do: It provides my non-routable addresses with a public Internet address via Network
Address Translation (NAT), and runs an SSH server for me to log in remotely to my
network.
When setting up a firewall appliance, you need to enable IP forwarding. IP forwarding allows
packets to be routed from one network interface to another in the Linux machine. This is inte-
gral to the whole process of routing packets and the Linux machine’s acting as a router. Most
iptables firewalls that protect a network run on low-cost, low CPU–powered hardware.
When a TCP/IP packet leaves my laptop, it is sent to the default route, which is my
iptables firewall on my router. When the firewall receives the packet, it analyzes it to
find its destination. As it sees that the packet is not destined for the machine itself, it is
sent to the FORWARD chain.
When in the FORWARD chain, the packet will traverse all firewall rules until it is either
dropped or is sent to the outbound network interface (my ADSL router) for further
processing.
The important part of the scenario is that any non-local packets (destined or originat-
ing from the machine) are passed to the forward chain (for forwarding!).
✦ When I SSH into my firewall from the Internet, a TCP/IP packet attempts to open an SSH
connection for me. In the same way that the packet will reach the firewall as in the for-
warding example, the kernel analyzes the packet to see where it is destined. As my
machine is the final destination for the packet, it is inserted into the INPUT chain for
further processing. If the packet is allowed through, it is passed over to the kernel to be
handed over to user space (which is normal when no firewalling is used).
✦ The OUTPUT chain is slightly different because it does not deal with traffic from the
network. An OUTPUT chain is triggered only when a packet originates from the
machine itself. For example, if you are logged into the machine and initiate an FTP con-
nection to the outside world, this is considered a packet that traverses the OUTPUT
chain.

Implementing an iptables firewall
As a general rule of thumb when talking about network security, you should deny all and allow
some. This means that by default you should not allow any network traffic at all to a machine,
and then enable only what is needed for the operation of your firewall/network/server.
Note
32_577395 ch23.qxd 12/15/04 12:23 AM Page 484
485
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
In the rest of the examples in this chapter, you must be logged in as root because you are
changing memory belonging to the kernel through the iptables command, and that
requires a privileged user.
To make this easier, netfilter provides a default policy for each chain (INPUT, OUTPUT,
FORWARD). You can set this policy to drop all packets that do not trigger a rule (that is, are
not explicitly allowed).
The Linux filtering code is always running, but by default, the policy for the chains is ACCEPT
(see Listing 23-1).
Listing 23-1: The Default Filtering Rules
bible:~ # iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
For each chain, the output of iptables -L (list rules) contains information on the target
(ACCEPT, DROP, and REJECT are the most common targets), the TCP/IP protocol, and the
packet source and destination.
iptables targets
When a TCP/IP packet is analyzed, a decision is made about what to do if that packet matches
a rule. If the packet matches a rule, it is sent to a

netfilter target, most likely ACCEPT,
DROP, or REJECT.
We’ll use an incoming SSH connection to a firewall as an example. It will be a TCP connection
on port 22 on the INPUT rule at a bare minimum. If you have a rule that describes this packet,
you need to tell the
netfilter system to ACCEPT this packet into the TCP/IP stack for fur-
ther processing by the kernel.
However, you could tell
netfilter to DROP or REJECT the packet:
✦ When a packet is sent to the DROP target, it simply disappears and the sending
machine does not know this has happened until it times out.
✦ When a packet is subject to the REJECT target, the sending machine is notified via an
Internet Control Message Protocol (ICMP) message that the port was not reachable
(that is, it was stopped).
If you configure the default policy of all chains to DROP/REJECT all non-triggered packets, it
is unlikely you need to use these as targets because any packets that have not been explic-
itly ACCEPTed will be subject to the DROP/REJECT target.
Tip
Note
32_577395 ch23.qxd 12/15/04 12:23 AM Page 485
486
Part IV ✦ Implementing Network Services in SUSE Linux
Stateful firewall
The netfilter firewalling code provides a stateful firewall, and this is a great new feature
of the
netfilter code. In the past, it was up to the administrator to track all connections
through the firewall, which produced a lot of rules that were difficult to manage. With a state-
ful firewall,
netfilter keeps a record of connection states. With this information, netfilter
can track a connection initiation and match up related network traffic.

For example, previously, if you wanted to allow an incoming connection to SSH on the fire-
wall, you had to first allow the incoming connection and also the return traffic from the SSH
server to the client. With stateful firewalls, you can tell the firewall to manage the subsequent
outgoing connection automatically because it is aware that an incoming connection to the
machine will produce traffic in the opposite direction. It does this by storing the state of a
connection and acting upon it with connection tracking.
To enable the stateful connection tracking, you need to enable states in the firewall. We dis-
cuss this in a small firewall script later in the chapter.
Setting your first rules
Before you touch upon setting more specific rules, you need to set the default policy for the
firewall and enable some state rules (see Listing 23-2).
Listing 23-2: Setting Initial Firewall Rules
bible:~ # iptables -P INPUT DROP
bible:~ # iptables -P OUTPUT DROP
bible:~ # iptables -P FORWARD DROP
bible:~ # iptables -A INPUT -m state state ESTABLISHED,RELATED -j ACCEPT
bible:~ # iptables -A FORWARD -m state state ESTABLISHED,RELATED -j ACCEPT
bible:~ # iptables -A OUTPUT -m state state NEW,ESTABLISHED,RELATED -j ACCEPT
Here, you have set the default policy for all chains to DROP the packets. At this moment in
time, all network connections, regardless of their originating address, will be dropped.
To set or change the policy of a chain, you need to specify that this is a policy edit (
-P), the
chain (INPUT, OUTPUT, or FORWARD), and also what to do with the packet.
It’s a secure feeling knowing that any connection from the Internet that you do not need is
dropped and the sender has to wait for a timeout before being notified. Imagine someone run-
ning a port scan of all 64,000 available ports on a TCP/IP machine. If they have to wait for a
timeout on each port, it will take them quite a few hours to complete the full scan. It provides
a kind of tar pit for any malicious users.
This is also true for internal connection, too. If your users are interested in what they can and
cannot connect to, without reading the network rules, then making them wait will, one hopes,

deter them from pushing the network too hard.
You have also configured the stateful firewall with the
-m state declaration. This tells the fire-
wall that you will allow any established or related connections on the INPUT chain.
This may seem like quite a big security hole, but bear in mind that it will allow only a connec-
tion that has been established, not a new connection. For the stateful rules to kick in, you
would have already had to allow a new connection through the chain.
32_577395 ch23.qxd 12/15/04 12:23 AM Page 486
487
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
Depending on how paranoid you are about security, you may not want to allow all new con-
nections from the firewall itself. However, when you wish to use the firewall machine as a
server, or want to be able to “bounce” from the machine to other hosts without the burden of
setting up new rules for every protocol or TCP port you wish to connect to, it is quite useful.
At this point, your firewall is locked down with the exception of allowing outgoing connections.
Now, suppose you want to allow an incoming SSH connection to the firewall.
Adding a rule
When you add a rule proper, you need to specify as much information as possible to have full
control over the TCP/IP you are allowing into the trusted network.
At a minimum, you need the chain, protocol, and destination port. With just this information,
you do not have a very good rule because it does not specify the interface you are allowing
the SSH connection to. Another option that can be set is the connection type:
✦ NEW— This is a new connection; no other traffic is associated with this packet.
✦ ESTABLISHED — This packet is from a machine you already have a connection to
(remember, you both send and receive data when a connection exists).
✦ RELATED — This packet is related to an existing connection. The FTP protocol, for
example, makes a connection to the FTP server, and the FTP server actually makes a
separate connection to the client. This separate connection from the server to the
client is a RELATED connection.
iptables –A INPUT –p tcp –dport ssh –i eth0 –j ACCEPT

In this example, you have told netfilter that you want to append (-A) a rule to the INPUT
chain, specifying the TCP protocol (
-p tcp), with a destination port (-dport) of ssh (port
22), incoming (
-i) on the eth0 interface, and finally that you want to ACCEPT the packet (-j
ACCEPT). The -j parameter means “jump to a target.” Remember that netfilter rules are in
a chain, so you are saying, “Stop processing this chain because you have a match and jump to
the target.” In this case, ACCEPT.
The -dport parameter can take either a numerical port number or a service name that is
specified in /etc/services.
When setting up a rule for connections, you really need to know how the protocol works. In
the case of SSH, it is well known that it is a TCP protocol, running on port 22. With this in
mind, it is relatively easy to write a rule for it.
It is up to you as to how you want to write the rule regarding the state of the connection, but
because the initial INPUT state rule has allowed all ESTABLISHED and RELATED connections,
you do not need to explicitly set the state to NEW because you have effectively allowed all
connection types for SSH by not explicitly setting them.
When you do not specify something explicitly with an iptables rule, it is assumed that you
want the default setting. For example, if you did not set the interface for the incoming con-
nection, netfilter would have allowed an SSH connection on all network interfaces. This
is indeed the same for the protocol type and the destination port. Be very careful how you
write your rules, and make sure you explicitly set everything you wish to control; otherwise
you will probably let in more than you think.
Caution
Note
32_577395 ch23.qxd 12/15/04 12:23 AM Page 487
488
Part IV ✦ Implementing Network Services in SUSE Linux
For any incoming connections you wish to have on a firewall, you can append a rule in the
same way you did with the SSH connection.

The order of rules
You must be very conscious of the order you set rules in a chain because netfilter passes
the TCP/IP packet through the rules in the order they are inserted into the kernel. If you wish
to insert a rule at the top of the list (that is, making it the first rule that is executed), you can
use the
-I (insert) parameter to iptables.
For example, if you are allowing SSH into your firewall from the Internet, but you know
that you do not want a certain IP address to have access to SSH, you have to insert the
REJECT/DROP rule before the general SSH rule:
iptables –A INPUT –p tcp –dport ssh –i eth0 –j ACCEPT
iptables –I INPUT –p tcp –dport ssh –i eth0 –s 10.32.1.4 –j DROP
In this example, using the -s option to specify a source IP address, we have inserted the
DROP rule before the general SSH acceptance rule.
When a TCP/IP packet has been inserted into a chain, it is checked in order with each rule. If
one of the rules matches the TCP/IP packet, it is then sent to the target specified (ACCEPT,
DROP, REJECT) immediately. In the case of our inserted SSH DROP rule, it fires off packets
destined for the SSH port to the DROP target before it gets to the ACCEPT SSH rule.
In essence, all the TCP/IP packets sequentially go through every rule in the chain until they
are directed to a target. If none of the rules fires off a packet to a target, that packet is dealt
with by the default policy, which is to kill the packet in this case.
Network Address Translation
While one of the main uses of netfilter is its packet filtering functions, another very impor-
tant aspect of
netfilter is its NAT functions.
Network Address Translation (NAT) is the process whereby the source or destination IP
address of a packet is seamlessly changed when it passes through the firewall.
Chapter 6 contains some more information about NAT.
Source NAT
Source NAT (SNAT) works on packets forwarded through the firewall before a packet leaves
for the outbound network. For this to work, you must deal with the packets before any rout-

ing decisions have been made, and the POSTROUTING chain must be used to implement
Source NAT.
The main purpose of SNAT is to hide private networks behind a firewall with a public IP
address. This drastically reduces the cost of acquiring public IP addresses and allows you to
use non-routable addresses in your internal network.
The POSTROUTING chain deals with any packets that are about to be sent out to the network
card. This includes any packets that are routed onto other destinations. In the case of SNAT,
this is the only chain that you want to use because, for example, it makes no sense to source
NAT traffic coming into the firewall INPUT chain.
Note
Cross-
Reference
32_577395 ch23.qxd 12/15/04 12:23 AM Page 488
489
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
Figure 23-2 details a home network that uses netfilter to SNAT our internal network.
Figure 23-2: Network using a netfilter firewall
In this scenario, all of the machines are behind a
netfilter firewall that not only protects
the machines, but also provides SNAT for outgoing connections. For SNAT to work, IP for-
warding must be enabled. To do this, enter a “1” into
/proc/sys/net/ipv4/ip_forward.
bible:~ # echo 1 > /proc/sys/net/ipv4/ip_forward
This will immediately enable IP forwarding on your Linux machine. This is a volatile opera-
tion, and once your machine has been rebooted, IP forwarding will be turned off by default.
To set IP forwarding on by default, edit the file
/etc/sysconfig/sysctl and change
IP_FORWARD from no to yes and re-run SuSEconfig. While editing the sysctl file, make sure
that
DISABLE_ECN is set to yes.

ECN is Enhanced Congestion Notification. This is a new feature of TCP/IP that allows
machines to notify you that a network route is congested. It is a great feature, but unfortu-
nately is not in widespread circulation and can stop your network traffic from traversing the
Internet correctly if it goes through a router that does not support ECN. We have been on
customer sites where their network just stopped working for certain sites for no reason.
Turning off ECN fixed this.
When IP forwarding has been enabled, you can insert the SNAT rule into the POSTROUTING
chain.
In the home network, you need to source NAT all the internal traffic (192.168.1.0/24) to the
firewall public address of 217.41.132.74. To do this, you need to insert a SNAT rule into the
NAT table.
Tip
Internet
217.41.132.74
eth1
192.168.1.1
SUSE 9.1
192.168.1.3
AirPort
OSX
192.168.1.0/24 DHCP
eth0
Linux Firewall
32_577395 ch23.qxd 12/15/04 12:23 AM Page 489
490
Part IV ✦ Implementing Network Services in SUSE Linux
The NAT table is used specifically for address translation rules. This includes source and des-
tination address translation.
bible:~ # iptables –t nat –A POSTROUTING –s 192.168.1.0/24 –o eth1 –j SNAT –to
217.41.132.74

Here, we have told iptables to edit the nat table (-t nat) by appending a rule to the
POSTROUTING chain. We have stated that any traffic from the 192.168.1.0/24 network (
-s)
and destined to leave the firewall through
eth1 (-o) should be source address NAT’d to
217.41.132.74.
In the example, note that we have tried to be as descriptive as possible concerning what traf-
fic should be subject to the SNAT, detailing the source IP address (specifying the network
address with netmask) and the network adaptor that the traffic will leave on.
You know that the traffic you need to be SNAT’d will leave the
eth1 interface because you
want to SNAT only traffic that is heading out to the Internet. This can be through the
eth1
interface only.
Any traffic that is sent back to the machines behind the firewall (for example, during the
three-way handshake) will be translated back by the firewall (it remembers connection
states) and the destination address will automatically be set to the address of the machine
on the private network that initiated the connection.
Allowing the packets to be forwarded
It is all well and good setting up SNAT, but the astute of you will probably realize that you
have already told
netfilter not to allow any forwarded traffic through the firewall (the
default FORWARD policy is DROP). To correct this, you need to allow the firewall to forward
these packets before they can be manipulated by the SNAT rule.
To do this, you need to enable forwarding for traffic from the private network to the Internet:
bible:~ # iptables –A FORWARD –s 192.168.1.0/24 –i eth0 -o eth1 –j ACCEPT
Here, iptables is being used to append (-A) to the FORWARD chain (any traffic that enters
and then leaves the firewall on separate interfaces). Any traffic from the 192.168.1.0/24 net-
work entering the firewall on interface
eth0 and leaving on interface eth1 will be allowed

through.
So, in this example, we have told
netfilter that any traffic from the 192.168.1.0/24 network
coming in on
eth0 and leaving the firewall on eth1 should be allowed through. Again, we
are relying on the fact that any traffic coming in on
eth0 and leaving on eth1 that is from
192.168.1.0/24 will be traffic we want to be allowed out to the Internet.
In this example, we have been quite liberal in what we are allowing our users to access on
the Internet. It is usually the policy of most companies that IM clients, P2P, and IRC should
not be allowed from the corporate network. As it stands, users can access anything on the
Internet as if they were directly connected. For the home network example, this is fine
because the users are trusted. However, if you are implementing a corporate firewall, you
will probably need to have quite a few DROP rules in the FORWARD chain, or do the right
thing and deny everything and allow only essential traffic (maybe only HTTP).
Tip
Note
32_577395 ch23.qxd 12/15/04 12:23 AM Page 490
491
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
Destination NAT
Destination NAT (DNAT) is a nice feature when building netfilter firewalls. It does the exact
opposite of the SNAT function by translating the destination address of a network packet into
another address.
Imagine in the example in Figure 23-2 that you had a mail server on your desktop machine. If
you want to give access to that machine to Internet users, you can’t just tell the firewall that
you want everyone to access the IP 192.168.1.3 over port 25; because this is a non-routable
address, Internet users would never be able to reach it. To combat this, you can tell
netfilter
that any traffic destined for port 25 on the public firewall address should be redirected to the

machine 192.168.1.3. Any return traffic to the initiating machine will have the source address
of the firewall, making the connection routable. And as far as the initiating machine is con-
cerned, it has no idea that the machine it is actually talking to is hidden behind a firewall and
is on a non-routable address.
To create the illusion, you need to add a DNAT rule to the NAT table for the Simple Mail
Transport Protocol (SMTP) service.
bible:~ # iptables –t nat –A PREROUTING –p tcp –-dport smtp –i eth1 –j DNAT –to-
destination=192.168.1.3
Here, iptables has been told to work on the NAT table (-t nat) by appending to the
PREROUTING chain. You have stated that any traffic that is TCP (
-p tcp)–based, with a
destination port of SMTP (25), and entering the firewall on
eth1 should be destination
NAT’d to 192.168.1.3.
In this case, all traffic for port 25 (SMTP) on the public network interface of the firewall will
have its destination address changed to 192.168.1.3. The port destination of 25 will be
untouched (we will come to this later).
When enabling DNAT, you have to insert the rules into the PREROUTING chain because a
routing decision has to be made on the final destination of the packet. At this point in the
netfilter processing in the PREROUTING chain, the final destination address has not
been inserted into the packet, so the routing decision is still yet to be made after this for suc-
cessful delivery.
In the same regard as SNAT, you still need to allow traffic destined on port 25 to 192.168.1.3 to
be forwarded through the firewall.
bible:~ # iptables –A FORWARD –p tcp –dport 25 –d 192.168.1.3 –i eth1 –o eth0 –j
ACCEPT
Here, iptables will append to the FORWARD chain, allowing through any TCP traffic that is
destined for the SMTP port on 192.168.1.3 entering the firewall on
eth1 and leaving on eth0.
Once set, all traffic destined for port 25 on the firewall public interface is successfully for-

warded to 192.168.1.3.
Redirecting Traffic
What if you want to redirect traffic to a different port on the firewall? This is very common
when you are setting up a transparent HTTP proxy with something like Squid or another con-
tent proxy.
Note
32_577395 ch23.qxd 12/15/04 12:23 AM Page 491
492
Part IV ✦ Implementing Network Services in SUSE Linux
A redirection rule does not redirect to an IP, only a port. This makes it a local rule to the fire-
wall only. With this in mind, any redirect rules must have a matching INPUT rule allowing the
traffic to be accepted on the redirected port.
bible:~ # iptables –t nat –A PREROUTING –p tcp -–dport 80 –i eth0 –s
192.168.1.0/24 –j REDIRECT -–to-port=3128
bible:~ # iptables –A INPUT –p tcp -–dport 3128 –s 192.168.1.0/24 –j ACCEPT
In the first instance, we have told iptables to append to the PREROUTING chain in the NAT
table. Any traffic that is TCP-based, destined for port 80 (HTTP), entering the firewall in
eth0
from 192.168.1.0/24 should be redirected to port 3128 on the firewall itself.
In the second instance, we have appended to the INPUT chain (traffic destined for the firewall
itself), allowing TCP traffic destined for port 3128 (the standard Squid proxy port number)
from the 192.168.1.0/24 network.
So, any outbound traffic (to the Internet) that is for port 80 (HTTP) will be redirected to port
3128. Assuming that you have Squid running and properly configured as a transparent proxy,
all of your web traffic will be automatically cached.
For more information on Squid, see Chapter 25.
Allowing ICMP Traffic
It is all well and good having a secure firewall, but you still need to be able to receive ICMP
traffic so that your users, you, and other Internet users are aware if there is a problem.
Internet Control Message Protocol (ICMP) is integral to the working of the Internet. ICMP is

used to send status and error messages about the state of the network to interested parties.
For example, when you
ping a machine, the ping packet and its echo are sent over ICMP. If
you cannot access a machine because its network connectivity is not working, you are told
this over ICMP, which your application interprets and tells you “Destination Unreachable.”
One traditional cracker attempt to subvert your network is by issuing an ICMP redirect mes-
sage. This tells a server that a route is unavailable and traffic for that destination should be
routed through another destination.
As a minimum, you should allow destination unreachable, source quench (when you need to
send smaller packets), and Time to Live (TTL) errors, which is when the packet has traveled
through too many routers without reaching its destination. It is up to you if you want to allow
ping requests or not. Traditionally, you do not enable these as it gives malicious users another
tool during initial investigation for an attack.
To allow these types of ICMP traffic, you need to allow inbound ICMP and some outbound
ICMP packets:
bible:~ # iptables -I INPUT -p icmp icmp-type destination-unreachable -j
ACCEPT
bible:~ # iptables -I INPUT -p icmp icmp-type source-quench -j ACCEPT
bible:~ # iptables -I INPUT -p icmp icmp-type time-exceeded -j ACCEPT
For each ICMP protocol type you have allowed, you are accepting incoming (that is, destined
for the firewall) ICMP traffic that reports destination unreachable, source quench, and TTL
exceeded.
Cross-
Reference
32_577395 ch23.qxd 12/15/04 12:23 AM Page 492
493
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
Allowing Loopback
It is advisable that you allow loopback traffic on your firewall because many services that you
usually assume can communicate internally with each other will fail if you don’t. To do this,

you can specify that the loopback device should not be restricted:
bible:~ # iptables –A INPUT –i lo –j ACCEPT
bible:~ # iptables –A OUTPUT –o lo –j ACCEPT
In this example, by appending to the INPUT chain you accept any type of traffic that is des-
tined for (
-i) or sent out (-o) of the loopback (lo) device.
As the loopback device is not capable of forwarding packets, you do not need to enable traf-
fic through the FORWARD chain.
Logging Dropped Packets
When your firewall has been configured to your liking, you will want to log any traffic that has
not been explicitly sanctioned by you. To do this, you need a final rule before the packet hits
the default policy for the chain that uses a target of LOG.
The LOG target interprets the TCP/IP packet and logs it via the
syslog facility for you to mon-
itor unauthorized traffic.
Just logging raw, unauthorized traffic is quite difficult to manage, and thankfully the LOG tar-
get allows you to specify a log prefix to distinguish the entry based on the chain it originated
from:
bible:~ # iptables –A INPUT –j LOG -–log-prefix=INPUT:
bible:~ # iptables –A OUTPUT –j LOG -–log-prefix=OUTPUT:
bible:~ # iptables –A FORWARD –j LOG -–log-prefix=FORWARD:
In this example, for each chain that a packet traverses, you have appended a rule that will
send all packets to the LOG target (
-j LOG). The -log-prefix parameter will make sure each
packet that is logged is prefixed by INPUT:, OUTPUT:, or FORWARD: (depending on the chain
the rule has been appended to).
Any traffic that does not get triggered by a rule will be logged using the LOG target before
hitting the default policy. For each chain, you are logging the packet details, with a prefix
relating to the chain it originated from.
The location of the LOG rules is of paramount importance. If the LOG target were “inserted”

at the beginning of the chain, all traffic, whether it is allowed or not, would be logged. You
will find your logs filling up very quickly if you make this mistake.
Using SuSEfirewall2
SUSE includes its own sysconfig-based firewall script called SuSEfirewall2. The SuSEfirewall
script has come a long way since its conception many years ago and provides a robust fea-
ture set that can be configured through YaST.
Caution
32_577395 ch23.qxd 12/15/04 12:23 AM Page 493
494
Part IV ✦ Implementing Network Services in SUSE Linux
For new users who need to set up a quick firewall, this is the perfect option. We would have
suggested in years gone by that you should write your own firewall script, but if you do not
feel the need to be able to control your rules explicitly, SuSEfirewall produces a robust secure
firewall for most environments.
To configure a small firewall for use at home using the YaST management system, follow these
steps:
1. In YaST, select Users and Security➪ Firewall (see Figure 23-3). When the module is
loaded, you can continue with the firewall configuration.
Figure 23-3: Loading the Firewall YaST module
32_577395 ch23.qxd 12/15/04 12:23 AM Page 494
495
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
2. You are asked to select the interfaces that you wish to protect. It is very important that
you get this right; otherwise, your configuration will be the wrong way round and will
not work as you expect. In the sample network configuration previously in the chapter,
you had
eth0 as the internal network interface and eth1 as the external public inter-
face, so set that here as well (see Figure 23-4).
Figure 23-4: Selecting the protected interfaces
32_577395 ch23.qxd 12/15/04 12:23 AM Page 495

496
Part IV ✦ Implementing Network Services in SUSE Linux
3. You need to select what services are allowed into the firewall (see Figure 23-5). This is
the same as defining an INPUT chain rule. Be very careful what you want to allow into
the firewall because if any of these services are compromised, a cracker will have
access to your first line of defense.
Figure 23-5: Selecting available firewall services
32_577395 ch23.qxd 12/15/04 12:23 AM Page 496
497
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
4. You need to enable certain security features of the firewall itself (see Figure 23-6):
• Because this is going to be a NAT box for your internal network, you need to
enable Forward Traffic and Do Masquerading.
• As you have explicitly stated that you want access to the SSH protocol, and noth-
ing else, you want to protect all other running services, so you need to select
Protect All Running Services.
• If you like to run traceroutes when you want to test network connectivity, turn on
Allow Traceroute as well.
Figure 23-6: Enabling firewall features
32_577395 ch23.qxd 12/15/04 12:23 AM Page 497
498
Part IV ✦ Implementing Network Services in SUSE Linux
5. It is always a good idea to log any malicious packets that hit the firewall, and you can
choose how verbose you want to be. In Figure 23-7, you can see that we’ve chosen to
see all traffic that we have not explicitly allowed onto our network.
Figure 23-7: Enabling logging
6. When you are happy with the configuration, click Next to save and continue to commit
your firewall (see Figure 23-8).
Figure 23-8: Saving your configuration
Once saved, your firewall configuration will be implemented. If you notice any strange behav-

ior on your network after this, check the logs on your firewall for dropped packets.
32_577395 ch23.qxd 12/15/04 12:23 AM Page 498
499
Chapter 23 ✦ Implementing Firewalls in SUSE Linux
What Next?
Firewalls are the first step in protecting your network. They are sometimes all that stand
between you and crackers. Many organizations incorporate a multitier, multivendor firewall
solution to provide as much security as possible. Keep two things in mind:
✦ The first and most important rule of firewall building is to design it first! Sit down with
the relevant departments in your organization to see what is needed and then come up
with a conceptual diagram that describes what you need to do before typing a single
rule.
✦ And remember, deny all, and then enable specific services that are needed. Better that
than leave a massive backdoor in your firewall.
iptables is a huge topic, and we’ve given you the best bits to help you move forward.
However, the best way to learn is to set up a small network and test out some rules to see
how it works. For more information, the
iptables man page is excellently written, and
the
iptables team has some great documentation on the iptables web site at www
.netfilter.org/.
✦✦✦
32_577395 ch23.qxd 12/15/04 12:23 AM Page 499
32_577395 ch23.qxd 12/15/04 12:23 AM Page 500
Working with
LDAP in SUSE
B
ack in the day, the only way to centrally manage your users and
services was to use NIS (Network Information System). NIS was
an endeavor by Sun to help Unix administrators manage their users

without having to locally create user accounts on all machines.
NIS is capable of maintaining user account information, user groups,
services, hosts, and many more pieces of information that, histori-
cally, needed to be managed on a local level.
NIS was great for what it did at the time, but it had a few shortcom-
ings; one problem, in particular, was that it wasn’t great at dealing
with very large amounts of data. We don’t mean the physical size of
the data, but the management of that data. NIS uses flat files as input
to the NIS database, which does not bode well in large infrastruc-
tures. One other major drawback of NIS was that it could not store
any other information apart from account and systems data.
One way around this management problem is to use a tree to orga-
nize data in a manageable fashion. This is where LDAP comes to the
rescue.
Lightweight Directory Access Protocol (LDAP) organizes data in a hier-
archical structure, allowing you to organize information based on
departments, or any other distinguishing method.
When introducing people to LDAP, we have always found that it is not
an easy concept to explain because it is not easily compared to any
existing technology. In this chapter, we give you an overview of what
LDAP is, its uses, how to populate an LDAP server with information,
and also a scenario that is common to the use of LDAP, including
configuration.
What Is LDAP?
LDAP is not a specific server. Much in the same way that Domain
Name System (DNS) and Simple Mail Transport Protocol (SMTP) are
conceptual protocols, LDAP describes organization of data, access to
the data, and the protocol used to talk to an LDAP server.
The Linux LDAP implementation is the extremely popular OpenLDAP
server. It has been around for a very long time and uses the LDAP

specification as a base to implement new features.
24
24
CHAPTER
✦✦✦✦
In This Chapter
What is LDAP?
Implementing
OpenLDAP
Integrating Linux with
LDAP
✦✦✦✦
33_577395 ch24.qxd 12/15/04 12:14 AM Page 501
502
Part IV ✦ Implementing Network Services in SUSE Linux
LDAP is a part of many organizations although many people in those organizations aren’t
even aware of its use. The Active Directory service from Microsoft is heavily based on the
LDAP protocol, as is Novell’s eDirectory implementation.
The main distinguishing factor of LDAP is in the way it “stores” its information. All data in an
LDAP database is stored in a tree. LDAP is an inverse tree in the same way that your filesys-
tem is. At the top of the LDAP tree, you have the base object, usually the organization. Below
this, you then have objects that are part of the LDAP tree, or you can also have a further split
using subtrees.
Figure 24-1 puts this structure into a diagram.
Figure 24-1: Conceptual overview of LDAP
When thinking about LDAP, try to think not on a technology level, but on an organizational
level. LDAP design should follow the organization of what you are storing data about. For our
example, we will take the organization of a fictional company called Acme Technology. Acme,
like many organizations, has departments that deal with certain parts of the business (Sales,
Marketing, HR, IT, the Board, and so on), and we will model this in our LDAP server.

We have taken the IT department and expanded it slightly to include job title and also some
people in the organization. You may be thinking that this looks a lot like a standard Org chart
that you see when you start a company, and this is how you should view it.
All the people in the organization belong to a department, which belongs to the organization,
and this methodology is how you should see LDAP. You can see that the tree structure lends
itself very well to organizational data, whether it is just for an address book or user accounts.
LDAP objects
LDAP uses objects to store data. Take the user object as an example. You can store a lot of
information about a user: first and last name, location, telephone, fax, pager, mobile, and
maybe a picture of that person. LDAP uses classes to define what information can be stored
about that object, commonly known as object attributes.
Objects can be a business, a car, a person, a stock item, or a desk. Any data about these
objects can be defined and stored in an LDAP server.
Sales Marketing IT
Acme
Technology
HR Services
Helpdesk Architects Administrators
Michael
Armstrong
Aimee Davies
James
Farnsworth
Jane Dadswell
Note
33_577395 ch24.qxd 12/15/04 12:14 AM Page 502
503
Chapter 24 ✦ Working with LDAP in SUSE
LDAP is very particular about what information you store in the LDAP server because it
needs to maintain the integrity of all data. To do this, an object is specifically defined so that

it must include certain data, may contain other data about an object, and will include nothing
else. This may seem restrictive, but it stops any data that does not concern the object being
stored.
For example, take the employee Jane Dadswell; the record must contain her first, middle, and
last name; employee ID; Social Security number; telephone number; email address; date of
birth; and her location (the list is not exhaustive, and we expect you can come up with more).
One the other hand, her record may contain information about her car (if she has one), pager
number (if she has one), picture, and home telephone number.
Any other data will not be allowed because the object is strictly defined to store only certain
information. The object definitions are in the LDAP schema, which we talk about later in the
chapter. At this stage, you just need to be aware that there are very tight restrictions on what
data is associated with an object, and that many object definitions exist for many situations.
The hierarchy
You know that LDAP is a hierarchical database, but you may not be aware of all of the bene-
fits of this.
Imagine on your filesystem, you have a home directory; mine is
/home/justin. Inside this
directory, I have a subdirectory called
Documents, with a further subdirectory of Finances.
Another user, roger, has a home directory of
/home/roger. Roger, being a conscientious per-
son like me, also stores information about his finances in his
Documents directory.
It just so happens that Roger and I both have a file called
finances_2004.xml in our
Finance directories. Even with the same filename, these two files do not impact each other
because their location is different throughout the filesystem tree.
LDAP works the same way. If a person called John Doe joins Acme as an HR assistant and
another John Doe (it is a popular name!) joins IT as an architect, their locations in the tree
mean that their information is uniquely identified by the path to that data. See Figure 24-2 for

another diagram of Acme with some LDAP thrown in to explain how LDAP uses the tree
design.
Figure 24-2: Acme organization in LDAP
ou=Sales ou=Marketing ou=IT
o=Acme, c=UK
ou=HR ou=Services
ou=Helpdesk ou=Architects ou=Administrators
cn=Michael
Armstrong
cn=Aimee Davies
cn=James
Farnsworth
cn=Jane Dadswell
33_577395 ch24.qxd 12/15/04 12:14 AM Page 503
504
Part IV ✦ Implementing Network Services in SUSE Linux
We have replaced the Org chart with an LDAP structure. Reading back from Jane Dadswell,
much like you read back from the
finances_2004.xml file, you can uniquely identify this
person in the organization. In the case of Jane Dadswell, her unique entry is
cn=”Jane
Dadswell”, ou=Helpdesk, ou=IT, o=Acme,c=UK.
Notice the quotes around Jane Dadswell in the entry above. This is to make sure the space is
included in the cn for Jane.
From this information, you see that Jane Dadswell is in the organization Acme (in the UK), the
department of IT, and the subdepartment of Helpdesk.
The person Jane Dadswell is unique in the organization, working on the Helpdesk, and is
unique in the LDAP directory. This unique identifier is called the Distinguished Name (dn),
and we will refer to this throughout the rest of the chapter.
This is a quick introduction to how LDAP stores its data, and throughout the rest of the chap-

ter, you will learn by example about using LDAP in the Acme organization, taking the Org
chart as a basis for its design.
Designing an LDAP directory is something that has to be done correctly. If you have an up-to-
date Org chart that effectively represents your organization, your life will be a lot easier.
Implementing the LDAP Server
When you have installed the OpenLDAP server using YaST, you need to do some initial config-
uration. The LDAP server is configured in the file
/etc/openldap/slapd.conf and is heavily
commented. The two very important parts you need to configure before even starting to pop-
ulate the server are the
basedn and the administrator account.
Configuring the administrator
The basedn is the very top of the LDAP tree. In the base of Acme, the basedn will be
o=Acme,c=uk. The o component means Organization, whereas the c component refers to the
country. As with everything in LDAP, there are strict rules on naming the
basedn. The most
common elements are the o= and c= definitions, but also the general domain component (dc)
is used to refer to the fully qualified domain name (FQDN) of the organization. In the case of
Acme, you could use a
basedn of dc=Acme,dc=co,dc=uk. However, as we are designing the
LDAP structure from an Org chart, we will use the organizational terms. To edit the LDAP
configuration files, you must be root. When you have set the username and password for the
administrator, you can be any user as long as you can authenticate as the administrator when
connecting to OpenLDAP.
1. In the
slapd.conf file, find the entry for the suffix and the rootdn (the administrator
user) and change it to reflect your organization.
suffix “o=Acme,c=UK”
rootdn “cn=admin,o=Acme,c=UK”
The rootdn should reflect your basedn with a user component. In this case, we have

used the
cn definition for the user (Common Name).
2. When the
suffix and the rootdn have been defined, you need to configure the admin-
istrator password. There are a few ways to do this— insecure and secure. Obviously,
you want to securely set up the password.
Note
33_577395 ch24.qxd 12/15/04 12:14 AM Page 504
505
Chapter 24 ✦ Working with LDAP in SUSE
The rootdn is not an entry in the LDAP directory but the account information for the LDAP
administrator.
To produce an encrypted password, you need to use the slappasswd command:
bible:/etc/openldap # slappasswd
New password:
Re-enter new password:
{SSHA}F13k4cAbh0IAxbpKNhH7uVcTL4HGzsJ+
bible:/etc/openldap #
You can define the password using cleartext (the password is just entered into the
slapd.conf) if you wish to do a quick and dirty implementation, but it is highly advisable
to insert the encrypted form of the password.
3. After you enter the password you wish to use twice, the slappasswd command returns
an encrypted password that can be used in
slapd.conf.
4. When you have the encrypted password, you need to find the
rootpw entry in
slapd.conf and enter it there.
rootpw {SSHA}F13k4cAbh0IAxbpKNhH7uVcTL4HGzsJ+
Testing the LDAP server
When the initial slapd.conf configuration has taken place, you need to start the LDAP

server with
rcldap:
bible:/etc/openldap # rcldap start
Starting ldap-server done
Once started, you can use the ldapsearch command to bind (connect to) the LDAP server
with the administrator account (see Listing 24-1). Unlike an anonymous bind, we are authenti-
cating to the LDAP server.
To automatically start OpenLDAP when the system boots, use chkconfig: chkconfig -a
ldap.
You can connect to the LDAP server with an anonymous bind, which means you have not pre-
sented authentication credentials to the LDAP server, and you are limited in what you can
read and write to the server based on the default access control list (ACL) settings.
Listing 24-1: Authenticating to the LDAP Server
bible:/etc/openldap # ldapsearch -x -D “cn=admin,o=Acme,c=UK” -W
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <> with scope sub
Continued
Tip
Caution
Note
33_577395 ch24.qxd 12/15/04 12:14 AM Page 505
506
Part IV ✦ Implementing Network Services in SUSE Linux
Listing 24-1 (continued)
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object
# numResponses: 1
As you do not have anything in the LDAP server, you will not receive any responses back.
The
ldapsearch command is extremely powerful, not only for diagnostic purposes but also
for viewing data in the LDAP server. In Listing 24-1, we used the
-D option to specify the
bindDN to connect to the LDAP server with, as well as the
-W option to tell ldapsearch to
ask us for the bind password.
We also used the -x option to tell ldapsearch to do a simple bind to the LDAP server. If
you do not specify -x, you need to bind using a Simple Authentication and Security Layer
(SASL) mechanism. We will not discuss SASL authentication in this chapter because this is
just an introduction to LDAP. For more information on configuring OpenLDAP with SASL,
refer to the OpenLDAP documentation in /usr/share/doc/packages/openldap2.
Adding information
When the LDAP server is up and running, you can populate the server with your information.
Some tools available for LDAP help with the initial population of LDAP data, as well as migrat-
ing existing users on the system to the LDAP directory. Here, we will populate the server with
information using an LDIF (LDAP Data Interchange Format) file.
PADL (the reverse of LDAP) provides some infrastructure tools that integrate into LDAP, pro-
viding a much easier environment for an administrator to work in. They have also designed
the Pluggable Authentication Modules (PAM) LDAP and NSS (name switch service) LDAP
modules that allow a Unix machine to query the LDAP server for user information. We dis-
cuss PAM/NSS LDAP integration later in the chapter. Download the PADL migration tools
from www.padl.com/download/MigrationTools.tgz.
LDIF
An LDIF file is a text file containing LDAP data in a protocol defined fashion. You need to cre-

ate an LDIF file that defines not only the data to be stored, but also the structure of the LDAP
server. Use your favorite text editor to create the LDIF file. In Listing 24-2, we have created
one you can work from that reflects the Acme organization.
Note
Note
33_577395 ch24.qxd 12/15/04 12:14 AM Page 506