ACC SHELL
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>Chapter 14. Masquerading and Firewalls</title><link rel="stylesheet" href="susebooks.css" type="text/css"><meta name="generator" content="DocBook XSL Stylesheets V1.75.2"><link rel="home" href="index.html" title="Documentation"><link rel="up" href="part.network_security.html" title="Part III. Network Security"><link rel="prev" href="cha.ssh.html" title="Chapter 13. SSH: Secure Network Operations"><link rel="next" href="cha.security.vpnserver.html" title="Chapter 15. Configuring VPN Server"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><table width="100%" summary="Navigation header" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.network_security.html">Network Security</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 13. SSH: Secure Network Operations" href="cha.ssh.html"><span>◀</span></a> <a accesskey="n" title="Chapter 15. Configuring VPN Server" href="cha.security.vpnserver.html"><span>▶</span></a></strong></p></div></td></tr></table></div><div class="chapter" title="Chapter 14. Masquerading and Firewalls"><div class="titlepage"><div><div><h2 class="title"><a name="cha.security.firewall"></a>Chapter 14. Masquerading and Firewalls<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#cha.security.firewall">¶</a></span></h2></div></div></div><div class="toc"><p><b>Contents</b></p><dl><dt><span class="sect1"><a href="cha.security.firewall.html#sec.security.firewall.iptables">14.1. Packet Filtering with iptables</a></span></dt><dt><span class="sect1"><a href="cha.security.firewall.html#sec.security.firewall.masq">14.2. Masquerading Basics</a></span></dt><dt><span class="sect1"><a href="cha.security.firewall.html#sec.security.firewall.fw">14.3. Firewalling Basics</a></span></dt><dt><span class="sect1"><a href="cha.security.firewall.html#sec.security.firewall.SuSE">14.4. SuSEfirewall2</a></span></dt><dt><span class="sect1"><a href="cha.security.firewall.html#sec.security.firewall.info">14.5. For More Information</a></span></dt></dl></div><a class="indexterm" name="id588494"></a><a class="indexterm" name="id588503"></a><a class="indexterm" name="id588508"></a><a class="indexterm" name="id588516"></a><p>
Whenever Linux is used in a network environment, you can use the kernel
functions that allow the manipulation of network packets to maintain a
separation between internal and external network areas. The Linux
netfilter framework provides the means to establish an effective firewall
that keeps different networks apart. With the help of iptables—a
generic table structure for the definition of rule sets—precisely
control the packets allowed to pass a network interface. Such a packet
filter can be set up quite easily with the help of SuSEfirewall2 and the
corresponding YaST module.
</p><a class="indexterm" name="id588534"></a><div class="sect1" title="14.1. Packet Filtering with iptables"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.firewall.iptables"></a>14.1. Packet Filtering with iptables<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.iptables">¶</a></span></h2></div></div></div><p>
The components netfilter and iptables are responsible for the filtering
and manipulation of network packets as well as for network address
translation (NAT). The filtering criteria and any actions associated with
them are stored in chains, which must be matched one after another by
individual network packets as they arrive. The chains to match are stored
in tables. The <span class="command"><strong>iptables</strong></span> command allows you to alter
these tables and rule sets.
</p><p>
The Linux kernel maintains three tables, each for a particular category
of functions of the packet filter:
</p><div class="variablelist"><dl><dt><span class="term">filter</span></dt><dd><p>
This table holds the bulk of the filter rules, because it implements
the <span class="emphasis"><em>packet filtering</em></span> mechanism in the stricter
sense, which determines whether packets are let through
(<code class="literal">ACCEPT</code>) or discarded (<code class="literal">DROP</code>),
for example.
</p></dd><dt><span class="term">nat</span></dt><dd><p>
This table defines any changes to the source and target addresses of
packets. Using these functions also allows you to implement
<span class="emphasis"><em>masquerading</em></span>, which is a special case of NAT used
to link a private network with the Internet.
</p></dd><dt><span class="term">mangle</span></dt><dd><p>
The rules held in this table make it possible to manipulate values
stored in IP headers (such as the type of service).
</p></dd></dl></div><p>
These tables contain several predefined chains to match packets:
</p><div class="variablelist"><dl><dt><span class="term">PREROUTING</span></dt><dd><p>
This chain is applied to incoming packets.
</p></dd><dt><span class="term">INPUT</span></dt><dd><p>
This chain is applied to packets destined for the system's internal
processes.
</p></dd><dt><span class="term">FORWARD</span></dt><dd><p>
This chain is applied to packets that are only routed through the
system.
</p></dd><dt><span class="term">OUTPUT</span></dt><dd><p>
This chain is applied to packets originating from the system itself.
</p></dd><dt><span class="term">POSTROUTING</span></dt><dd><p>
This chain is applied to all outgoing packets.
</p></dd></dl></div><p>
<a class="xref" href="cha.security.firewall.html#fig.fire.table" title="Figure 14.1. iptables: A Packet's Possible Paths">Figure 14.1, “iptables: A Packet's Possible Paths”</a> illustrates the paths along which a
network packet may travel on a given system. For the sake of simplicity,
the figure lists tables as parts of chains, but in reality these chains
are held within the tables themselves.
</p><p>
In the simplest of all possible cases, an incoming packet destined for
the system itself arrives at the <code class="literal">eth0</code> interface. The
packet is first referred to the <code class="literal">PREROUTING</code> chain of
the <code class="literal">mangle</code> table then to the
<code class="literal">PREROUTING</code> chain of the <code class="literal">nat</code> table.
The following step, concerning the routing of the packet, determines that
the actual target of the packet is a process of the system itself. After
passing the <code class="literal">INPUT</code> chains of the
<code class="literal">mangle</code> and the <code class="literal">filter</code> table, the
packet finally reaches its target, provided that the rules of the
<code class="literal">filter</code> table are actually matched.
</p><div class="figure"><a name="fig.fire.table"></a><p class="title"><b>Figure 14.1. iptables: A Packet's Possible Paths</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.fire.table">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="65%"><tr><td><img src="images/fire_tables.png" width="100%" alt="iptables: A Packet's Possible Paths"></td></tr></table></div></div></div><br class="figure-break"></div><div class="sect1" title="14.2. Masquerading Basics"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.firewall.masq"></a>14.2. Masquerading Basics<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.masq">¶</a></span></h2></div></div></div><a class="indexterm" name="id588828"></a><a class="indexterm" name="id588836"></a><a class="indexterm" name="id588841"></a><a class="indexterm" name="id588849"></a><p>
Masquerading is the Linux-specific form of NAT (network address
translation). It can be used to connect a small LAN (where hosts use IP
addresses from the private range—see
Section “Netmasks and Routing” (Chapter 21, <i>Basic Networking</i>, ↑Reference)) with the Internet
(where official IP addresses are used). For the LAN hosts to be able to
connect to the Internet, their private addresses are translated to an
official one. This is done on the router, which acts as the gateway
between the LAN and the Internet. The underlying principle is a simple
one: The router has more than one network interface, typically a network
card and a separate interface connecting with the Internet. While the
latter links the router with the outside world, one or several others
link it with the LAN hosts. With these hosts in the local network
connected to the network card (such as <code class="literal">eth0</code>) of the
router, they can send any packets not destined for the local network to
their default gateway or router.
</p><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Using the Correct Network Mask"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Using the Correct Network Mask</th></tr><tr><td colspan="2" align="left" valign="top"><p>
When configuring your network, make sure both the broadcast address and
the netmask are the same for all local hosts. Failing to do so prevents
packets from being routed properly.
</p></td></tr></table></div><p>
As mentioned, whenever one of the LAN hosts sends a packet destined for
an Internet address, it goes to the default router. However, the router
must be configured before it can forward such packets. For security
reasons, this is not enabled in a default installation. To enable it, set
the variable <code class="systemitem">IP_FORWARD</code> in the file
<code class="filename">/etc/sysconfig/sysctl</code> to
<code class="systemitem">IP_FORWARD=yes</code>.
</p><p>
The target host of the connection can see your router, but knows nothing
about the host in your internal network where the packets originated.
This is why the technique is called masquerading. Because of the address
translation, the router is the first destination of any reply packets.
The router must identify these incoming packets and translate their
target addresses, so packets can be forwarded to the correct host in the
local network.
</p><p>
With the routing of inbound traffic depending on the masquerading table,
there is no way to open a connection to an internal host from the
outside. For such a connection, there would be no entry in the table. In
addition, any connection already established has a status entry assigned
to it in the table, so the entry cannot be used by another connection.
</p><p>
As a consequence of all this, you might experience some problems with a
number of application protocols, such as ICQ, cucme, IRC (DCC, CTCP), and
FTP (in PORT mode). Web browsers, the standard FTP program, and many
other programs use the PASV mode. This passive mode is much less
problematic as far as packet filtering and masquerading are concerned.
</p></div><div class="sect1" title="14.3. Firewalling Basics"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.firewall.fw"></a>14.3. Firewalling Basics<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.fw">¶</a></span></h2></div></div></div><a class="indexterm" name="id588940"></a><p>
<span class="emphasis"><em>Firewall</em></span> is probably the term most widely used to
describe a mechanism that provides and manages a link between networks
while also controlling the data flow between them. Strictly speaking, the
mechanism described in this section is called a <span class="emphasis"><em>packet
filter</em></span>. A packet filter regulates the data flow according to
certain criteria, such as protocols, ports, and IP addresses. This allows
you to block packets that, according to their addresses, are not supposed
to reach your network. To allow public access to your Web server, for
example, explicitly open the corresponding port. However, a packet filter
does not scan the contents of packets with legitimate addresses, such as
those directed to your Web server. For example, if incoming packets were
intended to compromise a CGI program on your Web server, the packet
filter would still let them through.
</p><p>
A more effective but more complex mechanism is the combination of several
types of systems, such as a packet filter interacting with an application
gateway or proxy. In this case, the packet filter rejects any packets
destined for disabled ports. Only packets directed to the application
gateway are accepted. This gateway or proxy pretends to be the actual
client of the server. In a sense, such a proxy could be considered a
masquerading host on the protocol level used by the application. One
example for such a proxy is Squid, an HTTP and FTP proxy server. To use
Squid, the browser must be configured to communicate via the proxy. Any
HTTP pages or FTP files requested are served from the proxy cache and
objects not found in the cache are fetched from the Internet by the
proxy.
</p><p>
The following section focuses on the packet filter that comes with
openSUSE. For further information about packet filtering and
firewalling, read the Firewall HOWTO included in the
<code class="systemitem">howto</code> package. If this package
is installed, read the HOWTO with
</p><pre class="screen">less /usr/share/doc/howto/en/txt/Firewall-HOWTO.gz</pre></div><div class="sect1" title="14.4. SuSEfirewall2"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.firewall.SuSE"></a>14.4. SuSEfirewall2<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.SuSE">¶</a></span></h2></div></div></div><a class="indexterm" name="id589006"></a><a class="indexterm" name="id589015"></a><p>
SuSEfirewall2 is a script that reads the variables set in
<code class="filename">/etc/sysconfig/SuSEfirewall2</code> to generate a set of
iptables rules. It defines three security zones, although only the first
and the second one are considered in the following sample configuration:
</p><div class="variablelist"><dl><dt><span class="term">External Zone</span></dt><dd><p>
Given that there is no way to control what is happening on the
external network, the host needs to be protected from it. In most
cases, the external network is the Internet, but it could be another
insecure network, such as a WLAN.
</p></dd><dt><span class="term">Internal Zone</span></dt><dd><p>
This refers to the private network, in most cases the LAN. If the
hosts on this network use IP addresses from the private range (see
Section “Netmasks and Routing” (Chapter 21, <i>Basic Networking</i>, ↑Reference)), enable network
address translation (NAT), so hosts on the internal network can access
the external one.
</p></dd><dt><span class="term">Demilitarized Zone (DMZ)</span></dt><dd><p>
While hosts located in this zone can be reached both from the external
and the internal network, they cannot access the internal network
themselves. This setup can be used to put an additional line of
defense in front of the internal network, because the DMZ systems are
isolated from the internal network.
</p></dd></dl></div><p>
Any kind of network traffic not explicitly allowed by the filtering rule
set is suppressed by iptables. Therefore, each of the interfaces with
incoming traffic must be placed into one of the three zones. For each of
the zones, define the services or protocols allowed. The rule set is only
applied to packets originating from remote hosts. Locally generated
packets are not captured by the firewall.
</p><p>
The configuration can be performed with YaST (see
<a class="xref" href="cha.security.firewall.html#sec.security.firewall.SuSE.yast" title="14.4.1. Configuring the Firewall with YaST">Section 14.4.1, “Configuring the Firewall with YaST”</a>). It can also be
made manually in the file
<code class="filename">/etc/sysconfig/SuSEfirewall2</code>, which is well
commented. Additionally, a number of example scenarios are available in
<code class="filename">/usr/share/doc/packages/SuSEfirewall2/EXAMPLES</code>.
</p><div class="sect2" title="14.4.1. Configuring the Firewall with YaST"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.firewall.SuSE.yast"></a>14.4.1. Configuring the Firewall with YaST<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.SuSE.yast">¶</a></span></h3></div></div></div><div class="important"><table border="0" cellpadding="3" cellspacing="0" width="100%" summary="Important: Automatic Firewall Configuration"><tr class="head"><td width="32"><img alt="[Important]" src="admon/important.png"></td><th align="left">Automatic Firewall Configuration</th></tr><tr><td colspan="2" align="left" valign="top"><p>
After the installation, YaST automatically starts a firewall on all
configured interfaces. If a server is configured and activated on the
system, YaST can modify the automatically-generated firewall
configuration with the options <span class="guimenu">Open Ports on Selected
Interface in Firewall</span> or <span class="guimenu">Open Ports on
Firewall</span> in the server configuration modules. Some server
module dialogs include a <span class="guimenu">Firewall Details</span> button for
activating additional services and ports. The YaST firewall
configuration module can be used to activate, deactivate, or
reconfigure the firewall.
</p></td></tr></table></div><p>
The YaST dialogs for the graphical configuration can be accessed from
the YaST Control Center. Select <span class="guimenu">Security and
Users</span>+<span class="guimenu">Firewall</span>. The
configuration is divided into seven sections that can be accessed
directly from the tree structure on the left side.
</p><div class="variablelist"><dl><dt><span class="term">Start-Up</span></dt><dd><p>
Set the start-up behavior in this dialog. In a default installation,
SuSEfirewall2 is started automatically. You can also start and stop
the firewall here. To implement your new settings in a running
firewall, use <span class="guimenu">Save Settings and Restart Firewall
Now</span>.
</p><div class="figure"><a name="fig.yast2.firewall_1"></a><p class="title"><b>Figure 14.2. The YaST Firewall Configuration</b><span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#fig.yast2.firewall_1">¶</a></span></p><div class="figure-contents"><div class="mediaobject"><table border="0" summary="manufactured viewport for HTML img" cellspacing="0" cellpadding="0" width="75%"><tr><td><img src="images/yast2_firewall_1.png" width="100%" alt="The YaST Firewall Configuration"></td></tr></table></div></div></div><br class="figure-break"></dd><dt><span class="term">Interfaces</span></dt><dd><p>
All known network interfaces are listed here. To remove an interface
from a zone, select the interface, press <span class="guimenu">Change</span>,
and choose <span class="guimenu">No Zone Assigned</span>. To add an interface
to a zone, select the interface, press <span class="guimenu">Change</span> and
choose any of the available zones. You may also create a special
interface with your own settings by using <span class="guimenu">Custom</span>.
</p></dd><dt><span class="term">Allowed Services</span></dt><dd><p>
You need this option to offer services from your system to a zone
from which it is protected. By default, the system is only protected
from external zones. Explicitly allow the services that should be
available to external hosts. After selecting the desired zone in
<span class="guimenu">Allowed Services for Selected Zone</span>, activate the
services from the list.
</p></dd><dt><span class="term">Masquerading</span></dt><dd><p>
Masquerading hides your internal network from external networks (such
as the Internet) while enabling hosts in the internal network to
access the external network transparently. Requests from the external
network to the internal one are blocked and requests from the
internal network seem to be issued by the masquerading server when
seen externally. If special services of an internal machine need to
be available to the external network, add special redirect rules for
the service.
</p></dd><dt><span class="term">Broadcast</span></dt><dd><p>
In this dialog, configure the UDP ports that allow broadcasts. Add
the required port numbers or services to the appropriate zone,
separated by spaces. See also the file
<code class="filename">/etc/services</code>.
</p><p>
The logging of broadcasts that are not accepted can be enabled here.
This may be problematic, because Windows hosts use broadcasts to know
about each other and so generate many packets that are not accepted.
</p></dd><dt><span class="term">IPsec Support</span></dt><dd><p>
Configure whether the IPsec service should be available to the
external network in this dialog. Configure which packets are trusted
under <span class="guimenu">Details</span>.
</p></dd><dt><span class="term">Logging Level</span></dt><dd><p>
There are two rules for the logging: accepted and not accepted
packets. Packets that are not accepted are DROPPED or REJECTED.
Select from <span class="guimenu">Log All</span>, <span class="guimenu">Log Only
Critical</span>, or <span class="guimenu">Do Not Log Any</span> for both of
them.
</p></dd><dt><span class="term">Custom Rules</span></dt><dd><p>
Here, set special firewall rules that allow connections, matching
specified criteria such as source network, protocol, destination port,
and source port. Configure such rules for external, internal, and
demilitarized zones.
</p></dd></dl></div><p>
When finished with the firewall configuration, exit this dialog with
<span class="guimenu">Next</span>. A zone-oriented summary of your firewall
configuration then opens. In it, check all settings. All services,
ports, and protocols that have been allowed and all custom rules are
listed in this summary. To modify the configuration, use
<span class="guimenu">Back</span>. Press <span class="guimenu">Finish</span> to save your
configuration.
</p></div><div class="sect2" title="14.4.2. Configuring Manually"><div class="titlepage"><div><div><h3 class="title"><a name="sec.security.firewall.SuSE.man"></a>14.4.2. Configuring Manually<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.SuSE.man">¶</a></span></h3></div></div></div><p>
The following paragraphs provide step-by-step instructions for a
successful configuration. Each configuration item is marked as to
whether it is relevant to firewalling or masquerading. Use port range
(for example, <code class="literal">500:510</code>) whenever appropriate. Aspects
related to the DMZ (demilitarized zone) as mentioned in the
configuration file are not covered here. They are applicable only to a
more complex network infrastructure found in larger organizations
(corporate networks), which require extensive configuration and in-depth
knowledge about the subject.
</p><p>
First, use the YaST module System Services (Runlevel) to enable SuSEfirewall2 in
your runlevel (3 or 5 most likely). It sets the symlinks for the
SuSEfirewall2_* scripts in the <code class="filename">/etc/init.d/rc?.d/</code>
directories.
</p><div class="variablelist"><dl><dt><span class="term"><code class="systemitem">FW_DEV_EXT</code> (firewall, masquerading) </span></dt><dd><p>
The device linked to the Internet. For a modem connection, enter
<code class="literal">ppp0</code>. For an ISDN link, use
<code class="literal">ippp0</code>. DSL connections use
<code class="literal">dsl0</code>. Specify <code class="literal">auto</code> to use the
interface that corresponds to the default route.
</p></dd><dt><span class="term"><code class="systemitem">FW_DEV_INT</code> (firewall, masquerading) </span></dt><dd><p>
The device linked to the internal, private network (such as
<code class="literal">eth0</code>). Leave this blank if there is no internal
network and the firewall protects only the host on which it runs.
</p></dd><dt><span class="term"><code class="systemitem">FW_ROUTE</code> (firewall, masquerading) </span></dt><dd><p>
If you need the masquerading function, set this to
<code class="literal">yes</code>. Your internal hosts will not be visible to
the outside, because their private network addresses (e.g.,
<code class="literal">192.168.x.x</code>) are ignored by Internet routers.
</p><p>
For a firewall without masquerading, set this to
<code class="literal">yes</code> if you want to allow access to the internal
network. Your internal hosts need to use officially registered IP
addresses in this case. Normally, however, you should
<span class="emphasis"><em>not</em></span> allow access to your internal network from
the outside.
</p></dd><dt><span class="term"><code class="systemitem">FW_MASQUERADE</code> (masquerading) </span></dt><dd><p>
Set this to <code class="literal">yes</code> if you need the masquerading
function. This provides a virtually direct connection to the Internet
for the internal hosts. It is more secure to have a proxy server
between the hosts of the internal network and the Internet.
Masquerading is not needed for services that a proxy server provides.
</p></dd><dt><span class="term"><code class="systemitem">FW_MASQ_NETS</code> (masquerading) </span></dt><dd><p>
Specify the hosts or networks to masquerade, leaving a space between
the individual entries. For example:
</p><pre class="screen">FW_MASQ_NETS="192.168.0.0/24 192.168.10.1"</pre></dd><dt><span class="term"><code class="systemitem">FW_PROTECT_FROM_INT</code> (firewall) </span></dt><dd><p>
Set this to <code class="literal">yes</code> to protect your firewall host from
attacks originating in your internal network. Services are only
available to the internal network if explicitly enabled. Also see
<code class="systemitem">FW_SERVICES_INT_TCP</code> and
<code class="systemitem">FW_SERVICES_INT_UDP</code>.
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_EXT_TCP</code> (firewall) </span></dt><dd><p>
Enter the TCP ports that should be made available. Leave this blank
for a normal workstation at home that should not offer any services.
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_EXT_UDP</code> (firewall) </span></dt><dd><p>
Leave this blank unless you run a UDP service and want to make it
available to the outside. The services that use UDP include include
DNS servers, IPsec, TFTP, DHCP and others. In that case, enter the
UDP ports to use.
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_ACCEPT_EXT</code> (firewall) </span></dt><dd><p>
List services to allow from the Internet. This is a more generic form
of the <code class="systemitem">FW_SERVICES_EXT_TCP</code> and
<code class="systemitem">FW_SERVICES_EXT_UDP</code> settings, and more
specific than <code class="systemitem">FW_TRUSTED_NETS</code>. The notation
is a space-separated list of
<code class="option"><em class="replaceable"><code>net</code></em>,<em class="replaceable"><code>protocol</code></em>[,<em class="replaceable"><code>dport</code></em>][,<em class="replaceable"><code>sport</code></em>]</code>,
for example <code class="literal">0/0,tcp,22</code> or
<code class="literal">0/0,tcp,22,,hitcount=3,blockseconds=60,recentname=ssh</code>,
which means: allow at most three ssh connects per minute from the
same IP address.
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_INT_TCP</code> (firewall) </span></dt><dd><p>
With this variable, define the services available for the internal
network. The notation is the same as for
<code class="systemitem">FW_SERVICES_EXT_TCP</code>, but the settings are
applied to the <span class="emphasis"><em>internal</em></span> network. The variable
only needs to be set if <code class="systemitem">FW_PROTECT_FROM_INT</code>
is set to <code class="literal">yes</code>.
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_INT_UDP</code> (firewall) </span></dt><dd><p>
See <code class="systemitem">FW_SERVICES_INT_TCP</code>.
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_ACCEPT_INT</code> (firewall) </span></dt><dd><p>
List services to allow from internal hosts. See
<code class="systemitem">FW_SERVICES_ACCEPT_EXT.</code>
</p></dd><dt><span class="term"><code class="systemitem">FW_SERVICES_ACCEPT_RELATED_*</code> (firewall) </span></dt><dd><p>
This is how the SuSEfirewall2 implementation considers packets
<code class="literal">RELATED</code> by netfilter.
</p><p>
For example, to allow finer grained filtering of Samba broadcast
packets, <code class="literal">RELATED</code> packets are not accepted
unconditionally. Variables starting with
<code class="systemitem">FW_SERVICES_ACCEPT_RELATED_</code> allow
restricting <code class="literal">RELATED</code> packets handling to certain
networks, protocols and ports.
</p><p>
This means that adding connection tracking modules (conntrack
modules) to <code class="systemitem">FW_LOAD_MODULES</code> does not
automatically result in accepting the packets tagged by those
modules. Additionally, you must set variables starting with
<code class="systemitem">FW_SERVICES_ACCEPT_RELATED_</code> to a suitable
value.
</p></dd><dt><span class="term"><code class="systemitem">FW_CUSTOMRULES</code> (firewall)</span></dt><dd><p>
Uncomment this variable to install custom rules. Find examples in
<code class="filename">/etc/sysconfig/scripts/SuSEfirewall2-custom</code>.
</p></dd></dl></div><p>
<a class="indexterm" name="id589881"></a> After configuring the firewall, test your setup. The
firewall rule sets are created by entering <span class="command"><strong>SuSEfirewall2
start</strong></span> as <code class="systemitem">root</code>.
Then use <span class="command"><strong>telnet</strong></span>, for example, from an external host
to see whether the connection is actually denied. After that, review
<code class="filename">/var/log/messages</code>, where you should see something
like this:
</p><pre class="screen">Mar 15 13:21:38 linux kernel: SFW2-INext-DROP-DEFLT IN=eth0
OUT= MAC=00:80:c8:94:c3:e7:00:a0:c9:4d:27:56:08:00 SRC=192.168.10.0
DST=192.168.10.1 LEN=60 TOS=0x10 PREC=0x00 TTL=64 ID=15330 DF PROTO=TCP
SPT=48091 DPT=23 WINDOW=5840 RES=0x00 SYN URGP=0
OPT (020405B40402080A061AFEBC0000000001030300)
</pre><p>
Other packages to test your firewall setup are Nmap (portscanner) or
OpenVAS (Open Vulnerability Assessment System). The documentation of
Nmap is found at <code class="filename">/usr/share/doc/packages/nmap</code> after
installing the package and the documentation of openVAS resides at
<a class="ulink" href="http://www.openvas.org" target="_top">http://www.openvas.org</a>.
</p></div></div><div class="sect1" title="14.5. For More Information"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="sec.security.firewall.info"></a>14.5. For More Information<span class="permalink"><a alt="Permalink" title="Copy Permalink" href="#sec.security.firewall.info">¶</a></span></h2></div></div></div><p>
The most up-to-date information and other documentation about the
<code class="systemitem">SuSEfirewall2</code> package is found in
<code class="filename">/usr/share/doc/packages/SuSEfirewall2</code>. The home page
of the netfilter and iptables project,
<a class="ulink" href="http://www.netfilter.org" target="_top">http://www.netfilter.org</a>, provides a large collection of
documents in many languages.
</p></div></div><div class="navfooter"><table width="100%" summary="Navigation footer" border="0" class="bctable"><tr><td width="80%"><div class="breadcrumbs"><p><a href="index.html"> Documentation</a><span class="breadcrumbs-sep"> > </span><a href="book.security.html">Security Guide</a><span class="breadcrumbs-sep"> > </span><a href="part.network_security.html">Network Security</a><span class="breadcrumbs-sep"> > </span><strong><a accesskey="p" title="Chapter 13. SSH: Secure Network Operations" href="cha.ssh.html"><span>◀</span></a> <a accesskey="n" title="Chapter 15. Configuring VPN Server" href="cha.security.vpnserver.html"><span>▶</span></a></strong></p></div></td></tr></table></div></body></html>
ACC SHELL 2018