Chapter 29
The SuSE packet filter
|
|
|
| |
|
 |
| In this chapter: |
| |
|
| |
 |
Discussing general expectations from the packet filter
|
|
Seeing how the filter rules are set up
|
|
Configuring of the filter script
|
|
| |
|
|
| |
With version 6.3 SuSE ships a redesigned package filter aka
Firewall package with its distribution. The new
implementation is a total rewrite of the package filter and has pretty
much nothing in common with the previous versions. In case you are
running an older SuSE version, I recommend getting the new package
from the SuSE ftp-server and use this instead of the old version. The
new implementation is much more elaborate and allows a more flexible
configuration of the filter rules.
|
| 29.1 | Expectations from the packet filter |
| |
Before delving into a discussion on how the SuSE packet filter works
and how to configure it, we have to think about what we expect the
filter to do. But even before this, it should be pointed out what it is
not.
|
 |
Even if its often referred to as firewall it
really is 'only' a packet filter. It permits or denies traffic on the
TCP/IP layer. It does not implement proxy services and depending on
the configuration, it does not block all traffic through the router.
|
| |
For Example, if you are running a Web server on the firewall machine,
you may allow communication to this service from the Internet. If the
Web server has a security vulnerability, the package filter will not
protect you against attacks coming through the Web server's security
hole. But it helps you to protect services on your machine to which
untrusted persons should not get access to, and let you detect attacks
on your server from filter violations.
The primary purpose of the packet filter is to protect our local
network against intruders from the Internet. In most situations, the
aim is not to block all traffic from the outside. You may have services
that should be accessible, like Web browsing, FTP capabilities, or a
mail server. There may be trusted hosts which should have access to
our whole network. These exceptions may include include contractors or
maintenance accounts that visit the network and to whom we do not want
to deny access. Or we may want to control who can access the Internet
from our local workstations.
In it's documentation for the packet filter, SuSE lists the following
goals for it's implementation:
|
| |
|
Security is most important
Whoever installs and setup this firewall, expects that it will do all
things possible to protect the server and the local networks the
firewall is connected to.
|
|
An error should not leave the system open
This is usally referred to the "fail close" mechanism: If there's a
configuration error, it should not result in an open system. This is
very hard to implement, but SuSE tried to do everything possible to
make sure that the firewall setup is faily failsafe.
|
|
Easy configuration
The major goal is to make the complexity of writing filter rules
transparent to the admistrator and to allow the setup of complex rules
using a set of variables which define the proposed functionality. The
rules are configured by setting variables in a configuration file. The
number of varaibles is realonable low and using the provided
documentation, their functionality should be fairly easy to
understand. But the adminstrator still has to have a basic
understanding of TCP/IP, network daemons and security.
|
|
Automation
To reduce the needed configuration options and to easy the complexity
SuSE tried to collect as much data as possible from the running
system. Beside of the obvious advantage, that this simplifies the
configuration, it also helps to better support dynamic configured
systems.
|
|
| |
|
| 29.2 | The firewall script |
| |
The packet filter is controlled by the script
/sbin/init.d/firewall. This boot script uses
/sbin/SuSEfirewall to configure the filter rules. The
script /sbin/init.d/firewall understands the usual
parameters start, stop,
restart, reload and status as
you know them from other boot scripts (see also chapter for more info on boot scripts). If the firewall is
initialized at boot time or not depends on the variable
FW_START in the file /etc/rc.config. If set
to yes, the rules will be set up, otherwise the package
filter will remain inactive.
I will outline the steps the firewall setup performs during it's setup
in the next paragraphs.
After loading the configuration form /etc/rc.firewall,
the script makes sure, that all required tools like sed,
awk, grep, ifconfig,
netstat and of course ipchains are
available. It terminates with an error message if one of these tools
is missing. The script also makes sure that the running Linux kernel
is one of the 2.2 series. If the kernel version can not be determined,
it prints out a warning message. If an older kernel version is detected
the script terminates with an error message.
The next step is to process all the configuration options, some
logical settings and checks are done and data like IP addresses and
net masks of interfaces are collected from the running system. If an
interface that is specified in the configuration is not up yet, some
small protection rules are generated for this interface.
|
 |
Note, that the script should be rerun any time a new interface (i.e. a
dial-up connection with dynamic IP address) has been set up.
|
| |
After this initial phase of verifying that the environment is sane,
all former filter rules are flushed. The default for incoming packets
and those which have to be routed is set to
deny. This is done to make sure that if there's no
rule found for a special packet, it will be thrown away. The default
for outgoing packets is set to allowed.
If the firewall is configured to allow routing, packet forwarding will
be activated. The /proc system allows easy online kernel
configuration not only for the forwarding feature, but also for more
advanced network settings (see chapter 4). The script
uses this possibility to add some security settings if specified in the
firewall configuration.
After this is done, the script explicitly allows all traffic coming
from and going to the localhost interface. This interface
is used only for internal traffic. It would be a very bad idea to
block connections here, as local communication won't be possible
anymore.
Next the IP spoofing and circumvention rules are set. They prevent
attacks in which an intruder tries to disguise his data as coming
from the internal network. Packets with an source address indicating
they come from the inside, which arrive through an outside interface
are thrown away.
When these pretty general settings are done, the more specific options
are processed. First traffic from the internal network may or may not
be allowed, depending on the configuration. In case the default for
traffic originated form the inside network is deny,
the interface(s) pointing to the inside will be handled the same way
as interfaces pointing to the outside unless stated otherwise.
Now all ICMP, TCP and UDP rules are generated. The ICMP rules are
generated in two steps. First special ICMP packets are allowed or
denied, depending on the configuration (i.e. ping to the
firewall my be allowed). Then rules to deny dangerous ICMP packets and
to allow important ones are generated. The internal network is always
allowed to ping the firewall.
For TCP traffic all services allowed to be accessed from the outside
and -- if applicable -- from the internal network to trusted networks
are allowed. Then port 113 is set to send connection resets to all
incoming connections. This is important to prevent long mail sending
delays. Then a fine automation process is done. If the option
FW_AUTOPROTECT_GLOBAL_SERVICES (see below for more
details) was set to yes, all services which are listening
on all interfaces (this is the default for most daemons) will be
protected. This is useful if you have to open your high ports ports to
incoming connections, but you want to ensure that e.g. your database
running on port 4545 is not accessible form the outside. Finally, it
is decided from the configuration how the unprivileged ports (between
1024 and 65535) may be accessed: not at all, only DNS packets from
name servers which are defined in /etc/resolv.conf, only
packets which come from a special source port (not recommended, this
protection is easy to subvert), or everyone. Internal networks are
always allowed to access unprivileged ports (except to those
protected by the autoprotect routine). The same is
done for UDP packets. The only difference is that the connection reset
for port 113 is not needed here.
The next step is to initialize the redirection rules. These rules are
used to redirect traffic directed to the internal network or to local
ports to special ports on the firewall. Related to this is routing in
general and this is whats handled next. Rules restricting the access to
internal systems by external machines are set up.
|
|
Please think twice before you allow anyone direct access to your
system. Keep in mind that IP address spoofing is an easy task and
the use of source addresses as base of access decisions is in general
a bad idea.
|
| |
If needed masquerading rules will be generated in the next step. Now
the script is almost done. In the last steps additional logging
mechanisms for special packets are installs. It is possible to log
all incoming TCP packets which want to initiate a connection. You
can even log all packets arriving at the firewall which may be handy
if you have to debug the packet filter itself.
As very last step some optimization rules some installed. They are
intended to make the transfer of ssh, ftp,
www, syslog and snmp traffic
faster and more reliable.
Teh script returns one if an error occurred or zero when everthing
went Ok.
|
|
An important to mention is the initialization of the firewall during
the boot up. The rc script /sbin/init.d/firewall is
called twice during run level 2. First throught the lind
S04firewall_init and again thruoght
S99firewall_setup. The first call generates a rule set
for all interfaces available at this time and doesn't reports
errors. However, because more dynamic connections and services might
be run later, it is called a second time from after all network
related scripts have been processed. In this instance is generates all
possible rules and also gives back error messages. The link
K51firewall is used to remove all filter rules during
system shutdown and allows all packets, however, it turns routing off.
|
| |
From dynamic dialup scripts you should always call the firewall setup
script using the link /sbin/init.d/rc2.d/S99firewall_setup
with start as parameter. This ensures that the firewall
rules are loaded for the new installed interface(s).
|
| 29.3 | Configuration of the Packet Filter |
| |
The configuration of the filter rules is done in
/etc/rc.firewall. This kind of breaks the rule that
SuSE's configuration scripts are located in
/etc/rc.config.d, but the firewall script expects it's
configuration file in the /etc-directory. SuSE provides a
well documented configuration file, explaining all variable settings
that can be done in this file. We'll discuss these variables and their
meanings in the following sections. A short summary of all variables
is given in table 1-1
at the end of this chapter. Please
note that the variables are not listed in the order they appear in the
default configuration. I tried to order them in groups related to
their function in this chapter. So if you look at the example
configuration while reading this you may have to scroll around to find
the discussed settings.
|
| 29.3.1 | Interface settings |
| |
As the firewall (excuse my sloppiness here, but 'firewall' is
much easier to write and understand than 'packet filtering machine')
is usually a router connected to more than one network, we will have
to specify which interfaces are affected by the filter rules.
|
| | Outside Interfaces |
| |
The variable FW_DEV_WORLD lists all interfaces directed
to untrusted networks. In most cases this would be the device that
connects your machine to the Internet. But it may also be a connection
to another local network or a dial in device from which you'd like to
have protection. You can list one on more devices, separated by spaces
in this variable:
|
| | FW_WORLD_DEV="eth0 ppp0 isdn0"
|
| |
This setting would mean that the devices eth0,
ppp0 and isdn0 are pointing to untrusted
networks. Please note that these devices will have to be configured
prior to the packet filter. These means you can't use this setting for
dynamic generated interfaces, such as dial in or nonpermanent ISDN
connections. But in case you have dynamic interfaces with static
addresses, you can use the syntax
FW_DEV_WORLD_device="ip-address
netmask" to force rules to be loaded for the
specified interface even if the interface does not exist. For example a
Point-To-Point interface with IP-address 192.168.42.69
and net mask 255.255.255.0 may be specified as:
|
| | FW_WORLD_DEV_ppp0="192.168.42.69 255.255.255.0"
|
| |
Even if this still does not cover dynamicly assigned IP addresses, it
may help in some cases.
|
| | Inside Interfaces |
| |
Just as you specified the interface(s) to the outside world, you have
to tell the packet filter which interfaces can be trusted. This is
done with the variable FW_DEV_IN. The syntax is the same
as above, you can list one or more interfaces here:
|
| | FW_INT_DEV="eth1"
|
| |
And just as you saw it for the outside interfaces, you can use a
interface postfix to set up not yet existing interfaces:
|
| | FW_DEV_INT_eth1="192.168.10.4 255.255.255.0"
|
| |
|
| 29.3.2 | Allow Routing |
| |
You can turn routing on or off using the variable
FW_ROUTE. If this variable is set to no, no
traffic from or to the devices listed in FW_INT_DEV will
be allowed. Please note that this will inhibit incoming as well as
outgoing traffic. So even if you don't want to allow external machines
to access your network, you will have to allow routing in order to
enable access to the outside for your internal machines. You allow
routing by setting FW_ROUTE to yes. In this
case you will have to specify at least one internal device in
FW_INT_DEV.
|
| 29.3.3 | Outbound traffic |
| |
Like said earlier, the firewall can not only be used to protect your
local network, but also to restrict access to the outside world. This
may be done for several reason. A bad example would be a company
policy, that prohibits access to the Internet from the company
network. A better reason is to enforce the use of proxy servers like
squid (for HTTP and FTP), bind (for DNS),
etc. The use of proxies is in general more secure choice than allowing
direct access. It also can be combined with caching to decrease the
real traffic going through the outbound device.
|
| | Masquerading |
| |
The SuSE packet filter always masquerades outbound traffic. This means
that all connections made from the inside network (or more correct
coming form a device listed in FW_INT_DEV) appears to be
initiated by the firewall on an outside server. Masquerading has to be
enabled to allow outbound traffic. This is done by setting the variable
FW_MASQUERADE to yes. Additionally you may
specify the outside device where the masquerading takes place by
specifying this device in FW_MASQ_DEV. If not specified
it defaults to the device(s) listed in FW_WORLD_DEV.
The second variable related to masquerading is
FW_MASQ_MODULES. It contains the modules to be loaded for
protocolls that need special handling. Usually there shouldn't be any
need to change the settings of this variable. But in case you need to
add a service that needs special handling (such as ICQ i.e.), and get
a kernel module for this service, you want to add it to the list of
modules in this variable.
|
| | Restrict or allow outbound traffic |
| |
Now you can specify which machines or networks are allowed to access
the outside world. Only IP-addresses listed in
FW_LOCALNETS will be allowed to go through the
firewall. Note, that addresses not listed here may still access the
firewall itself. This is useful when you set up proxies on the
firewall, allowing access to the outside.
You can specify a space separated list of IP addresses and/or network
addresses (with net mask) in FW_LOCALNETS. To allow
Internet access for all machines in the
192.168.0.0/255.255.255.0 network you could use a setting
like this:
|
| | FW_LOCALNETS="192.168.0.0/255.255.255.0"
|
| |
|
| | Protecting the firewall from the inside network |
| |
By setting the variable FW_PROTECT_FROM_INTERNAL to
yes you prohibit connections made from the inside network
to the firewall. This doesn't mean that no services on the firewall
will be accessible from the inside, you still can allow certain
services by listing them in the FW_*_SERVICES_INTERNAL
variables (see next paragraph). The default (allowed or prohibited) is
set by this variable.
In case you prohibit connections from the inside (which is the
recommended strategy), you may want to make exceptions to this rule for
certain ports (i.e. your proxy servers should be accessible). This
exceptions have to be listed in FW_TCP_SERVICES_INTERNAL
for TCP port and in FW_UDP_SERVICES_INTERNAL for UDP
ports. As usual these variables shall contain a space separated list
of port number or serve names (from /etc/services).
|
| 29.3.4 | Inbound traffic |
| |
The remaining settings control the handling of incoming traffic. We
can divide incoming traffic by it's destination. It may be directed to
the firewall machine itself, or to a machine within on of the local
networks.
|
| Table 29-1 |
Variables controlling the packet filter |
| |
| Variable Name |
Meaning |
| FW_WORLD_DEV |
Device(s) directed to untrusted networks (i.e. the Internet) |
| FW_INT_DEV |
Device(s) directed to trusted (inside) networks |
| FW_ROUTE |
Allow routing (yes/no) |
| FW_MASQUERADE |
Enable masquerading (yes/no) |
| FW_MASQ_DEV |
Masquerading device(s) |
| FW_MASQ_MODULES |
Masquerading modules |
| FW_LOCALNETS |
Local addresses that may access outside networks |
| FW_PROTECT_FROM_INTERNAL |
Allow or prohibit connections from the inside to the firewall |
| FW_TCP_SERVICES_INTERNAL |
TCD ports that may be accesses from the internal network |
| FW_UDP_SERVICES_INTERNAL |
UPD ports that may be accesses from the internal network |
| |
| |
|
| |
|
|
| Summary: |
| |
|
|
