LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/HOWTO/Security-Quickstart-Redhat-.../firewalls.html

2918 lines
66 KiB
HTML
Raw Permalink Blame History

<HTML
><HEAD
><TITLE
>Step 3: Firewalls and Setting Access Policies</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="Security Quick-Start HOWTO for Red Hat Linux"
HREF="index.html"><LINK
REL="PREVIOUS"
TITLE="Step 2: Updating"
HREF="updates.html"><LINK
REL="NEXT"
TITLE="Intrusion Detection"
HREF="intrusion.html"></HEAD
><BODY
CLASS="SECT1"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>Security Quick-Start HOWTO for Red Hat Linux</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="updates.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="intrusion.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="FIREWALLS">5. Step 3: Firewalls and Setting Access Policies</H1
><P
> So what is a <SPAN
CLASS="QUOTE"
>"firewall"</SPAN
>? It's a vague term that can mean
anything that acts as a protective barrier between us and the outside world.
This can be a dedicated system, or a specific application that provides this
functionality. Or it can be a combination of components, including various
combinations of hardware and software. Firewalls are built from
<SPAN
CLASS="QUOTE"
>"rules"</SPAN
> that are used to define what is allowed to enter and
exit a given system or network. Let's look at some of the possible components
that are readily available for Linux, and how we might implement a reasonably
safe firewalling strategy.&#13;</P
><P
> In Step 1 above, we have turned off all services we don't need. In our
example, there were a few we still needed to have running. In this
section, we will take the next step here and decide which we need to leave
open to the world. And which we might be able to restrict in some way. If we can
block them all, so much the better, but this is not always practical.&#13;</P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="STRATEGY">5.1. Strategy</H2
><P
> What we want to do now is restrict connections and traffic so that we only
allow the minimum necessary for whatever our particular situation is. In
some cases we may want to block all incoming <SPAN
CLASS="QUOTE"
>"new"</SPAN
> connection
attempts. Example: we want to run <SPAN
CLASS="APPLICATION"
>X</SPAN
>, but don't
want anyone from outside to access it, so we'll block it completely from
outside connections. In other situations, we may want to limit, or restrict,
incoming connections to trusted sources only. The more restrictive, the
better. Example: we want to <B
CLASS="COMMAND"
>ssh</B
> into our system from
outside, but we only ever do this from our workplace. So we'll limit
<B
CLASS="COMMAND"
>sshd</B
> connections to our workplace address range. There are
various ways to do this, and we'll look at the most common ones.
</P
><P
> We also will not want to limit our firewall to any one application. There is
nothing wrong with a <SPAN
CLASS="QUOTE"
>"layered"</SPAN
> defense-in-depth approach. Our
front line protection will be a packet filter -- either
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> or <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>
(see below). Then we can use additional tools and mechanisms to reinforce
our firewall.
</P
><P
> We will include some brief examples. Our rule of thumb will be to deny
everything as the default policy, then open up just what we need. We'll try
to keep this as simple as possible since it can be an involved and complex
topic, and just stick to some of the most basic concepts. See the
<A
HREF="appendix.html#LINKS"
>Links section</A
> for further reading on this
topic.&#13;</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="FILTERS">5.2. Packet Filters -- Ipchains and Iptables</H2
><P
> <SPAN
CLASS="QUOTE"
>"Packet filters"</SPAN
> (like <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>)
have the ability to look at individual packets, and make decisions based
on what they find. These can be used for many purposes. One common purpose
is to implement a firewall.</P
><P
> Common packet filters on Linux are <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> which
is standard with 2.2 kernels, and <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> which
is available with the more recent 2.4 kernels.
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> has more advanced packet filtering
capabilities and is recommended for anyone running a 2.4 kernel. But either
can be effective for our purposes. <SPAN
CLASS="APPLICATION"
>ipfwadm</SPAN
> is
a similar utility for 2.0 kernels (not discussed here).
</P
><P
> If constructing your own <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> or
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> firewall rules seems a bit daunting,
there are various sites that can automate the process. See the
<A
HREF="appendix.html#LINKS"
>Links section</A
>. Also the included examples may be
used as a starting point.
As of Red Hat 7.1, Red Hat is providing init scripts
for <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>,
and <SPAN
CLASS="APPLICATION"
>gnome-lokkit</SPAN
> for generating a very basic
set of firewall rules (<A
HREF="firewalls.html#LOKKIT"
>see below</A
>). This may be
adequate, but it is still recommended to know the proper syntax and
how the various mechanisms work as such tools rarely do more than a
few very simple rules.&#13;</P
><DIV
CLASS="NOTE"
><P
></P
><TABLE
CLASS="NOTE"
WIDTH="100%"
BORDER="0"
><TR
><TD
WIDTH="25"
ALIGN="CENTER"
VALIGN="TOP"
><IMG
SRC="../images/note.gif"
HSPACE="5"
ALT="Note"></TD
><TD
ALIGN="LEFT"
VALIGN="TOP"
><P
> Various examples are given below. These are presented for illustrative
purposes to demonstrate some of the concepts being discussed here.
While they might also be useful as a starting point for your own
script, please note that they are not meant to be all encompassing.
You are strongly encouraged to understand how the scripts work, so
you can create something even more tailored for your own situation.
</P
><P
> The example scripts are just protecting inbound connections to one interface
(the one connected to the Internet). This may be adequate for many simple
home type situations, but, conversely, this approach is not adequate for
<EM
>all</EM
> situations!
</P
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="IPCHAINS">5.2.1. ipchains</H3
><P
> <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> can be used with either 2.2 or 2.4
kernels. When <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> is in place, it checks
every packet that moves through the system. The packets move across different
<SPAN
CLASS="QUOTE"
>"chains"</SPAN
>, depending where they originate and where they are
going. Think of <SPAN
CLASS="QUOTE"
>"chains"</SPAN
> as rule sets. In advanced
configurations, we could define our own custom chains. The three default
built-in chains are <TT
CLASS="LITERAL"
>input</TT
>, which is incoming traffic,
<TT
CLASS="LITERAL"
>output</TT
>, which is outgoing traffic, and
<TT
CLASS="LITERAL"
>forward</TT
>, which is traffic being forwarded from one
interface to another (typically used for <SPAN
CLASS="QUOTE"
>"masquerading"</SPAN
>).
Chains can be manipulated in various ways to control the flow of traffic in
and out of our system. Rules can be added at our discretion to achieve
the desired result.&#13;</P
><P
> At the end of every <SPAN
CLASS="QUOTE"
>"chain"</SPAN
> is a <SPAN
CLASS="QUOTE"
>"target"</SPAN
>. The
target is specified with the <TT
CLASS="LITERAL"
>-j</TT
> option to the command. The
target is what decides the fate of the packet and essentially terminates that
particular chain. The most common targets are mostly self-explanatory:
<TT
CLASS="LITERAL"
>ACCEPT</TT
>, <TT
CLASS="LITERAL"
>DENY</TT
>,
<TT
CLASS="LITERAL"
>REJECT</TT
>, and <TT
CLASS="LITERAL"
>MASQ</TT
>.
<TT
CLASS="LITERAL"
>MASQ</TT
> is for <SPAN
CLASS="QUOTE"
>"ipmasquerading"</SPAN
>.
<TT
CLASS="LITERAL"
>DENY</TT
> and <TT
CLASS="LITERAL"
>REJECT</TT
> essentially do the
same thing, though in different ways. Is one better than the other? That is
the subject of much debate, and depends on other factors that are beyond the
scope of this document. For our purposes, either should suffice.
</P
><P
> <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> has a very flexible configuration. Port
(or port ranges), interfaces, destination address, source address can be
specified, as well as various other options. The man page explains these
details well enough that we won't get into specifics here.</P
><P
> Traffic entering our system from the Internet, enters via the
<TT
CLASS="LITERAL"
>input</TT
> chain. This is the one that we need as tight as we
can make it.</P
><P
> Below is a brief example script for a hypothetical system. We'll let the
comments explain what this script does. Anything starting with a
<SPAN
CLASS="QUOTE"
>"#"</SPAN
> is a comment. <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> rules
are generally incorporated into shell scripts, using shell variables to
help implement the firewalling logic.&#13;</P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>&#13;#!/bin/sh
#
# ipchains.sh
#
# An example of a simple ipchains configuration.
#
# This script allows ALL outbound traffic, and denies
# ALL inbound connection attempts from the outside.
#
###################################################################
# Begin variable declarations and user configuration options ######
#
IPCHAINS=/sbin/ipchains
# This is the WAN interface, that is our link to the outside world.
# For pppd and pppoe users.
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
## end user configuration options #################################
###################################################################
# The high ports used mostly for connections we initiate and return
# traffic.
LOCAL_PORTS=`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f1`:\
`cat /proc/sys/net/ipv4/ip_local_port_range |cut -f2`
# Any and all addresses from anywhere.
ANYWHERE="0/0"
# Let's start clean and flush all chains to an empty state.
$IPCHAINS -F
# Set the default policies of the built-in chains. If no match for any
# of the rules below, these will be the defaults that ipchains uses.
$IPCHAINS -P forward DENY
$IPCHAINS -P output ACCEPT
$IPCHAINS -P input DENY
# Accept localhost/loopback traffic.
$IPCHAINS -A input -i lo -j ACCEPT
# Get our dynamic IP now from the Inet interface. WAN_IP will be our
# IP address we are protecting from the outside world. Put this
# here, so default policy gets set, even if interface is not up
# yet.
WAN_IP=`ifconfig $WAN_IFACE |grep inet |cut -d : -f 2 |cut -d \ -f 1`
# Bail out with error message if no IP available! Default policy is
# already set, so all is not lost here.
[ -z "$WAN_IP" ] &#38;&#38; echo "$WAN_IFACE not configured, aborting." &#38;&#38; exit 1
# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are
# the high, unprivileged ports (1024 to 4999 by default). This will
# allow return connection traffic for connections that we initiate
# to outside sources. TCP connections are opened with 'SYN' packets.
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT
# We can't be so selective with UDP since that protocol does not
# know about SYNs.
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT
## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
$IPCHAINS -A input -p icmp --icmp-type echo-reply \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input -p icmp --icmp-type destination-unreachable \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPCHAINS -A input -p icmp --icmp-type time-exceeded \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-l'.
# Outgoing traffic is allowed as the default policy for the 'output'
# chain. There are no restrictions on that.
$IPCHAINS -A input -l -j DENY
echo "Ipchains firewall is up `date`."
##-- eof ipchains.sh
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> To use the above script would require that it is executable (i.e.
<TT
CLASS="LITERAL"
>chmod +x ipchains.sh</TT
>), and run by root to build the
chains, and hence the firewall. &#13;</P
><P
> To summarize what this example did was to start by setting some shell
variables in the top section, to be used later in the script. Then we set
the default rules (ipchains calls these <SPAN
CLASS="QUOTE"
>"policies"</SPAN
>) of denying
all inbound and forwarded traffic, and of allowing all our own outbound
traffic. We had to open some holes in the high, unprivileged ports so
that we could have return traffic from connections that bigcat initiates to
outside addresses. If we connect to someone's web server, we want that HTML
data to be able to get back to us, for instance. The same applies to other
network traffic. We then allowed a few specific types of the ICMP protocol
(most are still blocked). We are also logging any inbound traffic that
violates any of our rules so we know who is doing what. Notice that we are
only using IP address here, not hostnames of any kind. This is so that
our firewall works, even in situation where there may be DNS failures.
Also, to prevent any kind of DNS spoofing.&#13;</P
><P
> See the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> man page for a full explanation
of syntax. The important ones we used here are:&#13;</P
><A
NAME="AEN653"><BLOCKQUOTE
CLASS="BLOCKQUOTE"
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-A input</TT
>: Adds a rule to the
<SPAN
CLASS="QUOTE"
>"input"</SPAN
> chain. The default chains are input, output, and forward.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-p udp</TT
>: This rule only applies to the
<SPAN
CLASS="QUOTE"
>"UDP"</SPAN
> <SPAN
CLASS="QUOTE"
>"protocol"</SPAN
>. The <TT
CLASS="LITERAL"
>-p</TT
>
option can be used with tcp, udp or icmp protocols.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-i $WAN_IFACE</TT
>: This rule applies to the specified
interface only, and applies to whatever chain is referenced (input, output,
or forward).
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-s &#60;IP address&#62;</TT
> [port]: This rule only
applies to the source address as specified. It can optionally have a port
(e.g. 22) immediately afterward, or port range, e.g. 1023:4999.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-d &#60;IP address&#62;</TT
> [port]: This rule only
applies to the destination address as specified. Also, it may include port or
port range.
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-l</TT
> : Any packet that hits a rule with this option
is logged (lower case <SPAN
CLASS="QUOTE"
>"L"</SPAN
>).
</TD
></TR
></TBODY
></TABLE
><P
></P
><P
></P
><TABLE
BORDER="0"
><TBODY
><TR
><TD
> <20><TT
CLASS="LITERAL"
>-j ACCEPT</TT
>: Jumps to the <SPAN
CLASS="QUOTE"
>"ACCEPT"</SPAN
>
<SPAN
CLASS="QUOTE"
>"target"</SPAN
>. This effectively terminates this chain
and decides the ultimate fate for this particular packet, which in this
example is to <SPAN
CLASS="QUOTE"
>"ACCEPT"</SPAN
> it. The same is
true for other <TT
CLASS="LITERAL"
>-j</TT
> targets like <TT
CLASS="LITERAL"
>DENY</TT
>.
</TD
></TR
></TBODY
></TABLE
><P
></P
></BLOCKQUOTE
><P
> By and large, the order in which command line options are specified is not
significant. The chain name (e.g. <TT
CLASS="LITERAL"
>input</TT
>) must come first
though.&#13;</P
><P
> Remember in Step 1 when we ran <B
CLASS="COMMAND"
>netstat</B
>, we had
both X and print servers running among other things. We don't want these
exposed to the Internet, even in a limited way. These are still happily
running on bigcat, but are now safe and sound behind our
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> based firewall. You probably have other
services that fall in this category as well.&#13;</P
><P
> The above example is a simplistic all or none approach. We allow all our own
outbound traffic (not necessarily a good idea), and block all inbound
connection attempts from outside. It is only protecting one interface, and
really just the inbound side of that interface. It would more than likely
require a bit of fine tuning to make it work for you. For a more advanced set
of rules, see the <A
HREF="appendix.html#PFILTERS"
>Appendix</A
>. And you might
want to read <A
HREF="http://tldp.org/HOWTO/IPCHAINS-HOWTO.html"
TARGET="_top"
>http://tldp.org/HOWTO/IPCHAINS-HOWTO.html</A
>.&#13;</P
><P
> Whenever you have made changes to your firewall, you should verify its
integrity. One step to make sure your rules seem to be doing what you
intended, is to see how <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> has interpreted
your script. You can do this by opening your <SPAN
CLASS="APPLICATION"
>xterm</SPAN
>
very wide, and issuing the following command:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; # ipchains -L -n -v | less
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> The output is grouped according to chain. You should also find a way to scan
yourself (see the <A
HREF="firewalls.html#VERIFY"
>Verifying section</A
> below). And
then keep an eye on your logs to make sure you are blocking what is
intended.&#13;</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="IPTABLES">5.2.2. iptables</H3
><P
> <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> is the next generation packet filter for
Linux, and requires a 2.4 kernel. It can do everything
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> can, but has a number of noteworthy
enhancements. The syntax is similar to <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> in
many respects. See the man page for details.&#13;</P
><P
> The most noteworthy enhancement is <SPAN
CLASS="QUOTE"
>"connection tracking"</SPAN
>, also
known as <SPAN
CLASS="QUOTE"
>"stateful inspection"</SPAN
>. This gives
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> more knowledge of the state of each
packet. Not only does it know if the packet is a TCP or UDP packet, or
whether it has the SYN or ACK flags set, but also if it is part of an existing
connection, or related somehow to an existing connection. The implications
for firewalling should be obvious.&#13;</P
><P
> The bottom line is that it is easier to get a tight firewall with
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>, than with
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>. So this is the recommended way to go.
</P
><P
> Here is the same script as above, revised for
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>:&#13;</P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>&#13;#!/bin/sh
#
# iptables.sh
#
# An example of a simple iptables configuration.
#
# This script allows ALL outbound traffic, and denies
# ALL inbound connection attempts from the Internet interface only.
#
###################################################################
# Begin variable declarations and user configuration options ######
#
IPTABLES=/sbin/iptables
# Local Interfaces
# This is the WAN interface that is our link to the outside world.
# For pppd and pppoe users.
# WAN_IFACE="ppp0"
WAN_IFACE="eth0"
#
## end user configuration options #################################
###################################################################
# Any and all addresses from anywhere.
ANYWHERE="0/0"
# This module may need to be loaded:
modprobe ip_conntrack_ftp
# Start building chains and rules #################################
#
# Let's start clean and flush all chains to an empty state.
$IPTABLES -F
# Set the default policies of the built-in chains. If no match for any
# of the rules below, these will be the defaults that IPTABLES uses.
$IPTABLES -P FORWARD DROP
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -P INPUT DROP
# Accept localhost/loopback traffic.
$IPTABLES -A INPUT -i lo -j ACCEPT
## ICMP (ping)
#
# ICMP rules, allow the bare essential types of ICMP only. Ping
# request is blocked, ie we won't respond to someone else's pings,
# but can still ping out.
$IPTABLES -A INPUT -p icmp --icmp-type echo-reply \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type destination-unreachable \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -p icmp --icmp-type time-exceeded \
-s $ANYWHERE -i $WAN_IFACE -j ACCEPT
###################################################################
# Set the catchall, default rule to DENY, and log it all. All other
# traffic not allowed by the rules above, winds up here, where it is
# blocked and logged. This is the default policy for this chain
# anyway, so we are just adding the logging ability here with '-j
# LOG'. Outgoing traffic is allowed as the default policy for the
# 'output' chain. There are no restrictions on that.
$IPTABLES -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -A INPUT -m state --state NEW -i ! $WAN_IFACE -j ACCEPT
$IPTABLES -A INPUT -j LOG -m limit --limit 30/minute --log-prefix "Dropping: "
echo "Iptables firewall is up `date`."
##-- eof iptables.sh
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> The same script logic is used here, and thus this does pretty much the same
exact thing as the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> script in the
previous section. There are some subtle differences as to syntax. Note the
case difference in the chain names for one (e.g. INPUT vs input). Logging is
handled differently too. It has its own <SPAN
CLASS="QUOTE"
>"target"</SPAN
> now
(<TT
CLASS="LITERAL"
>-j LOG</TT
>), and is much more flexible.&#13;</P
><P
> There are some very fundamental differences as well, that might not be so
obvious. Remember this section from the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>
script:</P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>&#13;# Accept non-SYN TCP, and UDP connections to LOCAL_PORTS. These are the high,
# unprivileged ports (1024 to 4999 by default). This will allow return
# connection traffic for connections that we initiate to outside sources.
# TCP connections are opened with 'SYN' packets. We have already opened
# those services that need to accept SYNs for, so other SYNs are excluded here
# for everything else.
$IPCHAINS -A input -p tcp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS ! -y -j ACCEPT
# We can't be so selective with UDP since that protocol does not know
# about SYNs.
$IPCHAINS -A input -p udp -s $ANYWHERE -d $WAN_IP $LOCAL_PORTS -j ACCEPT
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> We jumped through hoops here with <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> so
that we could restrict unwanted, incoming connections as much as possible. A
bit of a kludge, actually.&#13;</P
><P
> That section is missing from the <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> version.
It is not needed as connection tracking handles this quite nicely, and then
some. This is due to the <SPAN
CLASS="QUOTE"
>"statefulness"</SPAN
> of
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>. It knows more about each packet than
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>. For instance, it knows whether the
packet is part of a <SPAN
CLASS="QUOTE"
>"new"</SPAN
> connection, or an
<SPAN
CLASS="QUOTE"
>"established"</SPAN
> connection, or a <SPAN
CLASS="QUOTE"
>"related"</SPAN
>
connection. This is the so-called <SPAN
CLASS="QUOTE"
>"stateful inspection"</SPAN
> of
connection tracking.&#13;</P
><P
> There are many, many features of <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> that
are not touched on here. For more reading on the Netfilter project and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>, see <A
HREF="http://netfilter.samba.org"
TARGET="_top"
>http://netfilter.samba.org</A
>.
And for a more advanced set of rules, see the <A
HREF="appendix.html#PFILTERS"
>Appendix</A
>. &#13;</P
></DIV
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="LOKKIT">5.2.3. Red Hat Firewall Configuration Tools</H3
><P
> Red Hat has not included firewall configuration tools until 7.1, when
the GUI utility <B
CLASS="COMMAND"
>gnome-lokkit</B
> started being bundled.
<B
CLASS="COMMAND"
>gnome-lokkit</B
> does a minimalist set of rules for
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> only. Explicit support for
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> configuration is not an option, despite
the fact that the default kernel is 2.4.&#13;</P
><P
> <B
CLASS="COMMAND"
>gnome-lokkit</B
> is an option on non-upgrade installs, and
can also be run as a stand-alone app any time after installation. It will ask
a few simple questions, and dump the resulting rule-set into
<TT
CLASS="FILENAME"
>/etc/sysconfig/ipchains</TT
>.&#13;</P
><P
> As mentioned, this is a fairly minimalist set of rules, and possibly a
sufficient starting point. An example
<TT
CLASS="FILENAME"
>/etc/sysconfig/ipchains</TT
> created by
<B
CLASS="COMMAND"
>gnome-lokkit</B
>:&#13;</P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>&#13; # Firewall configuration written by lokkit
# Manual customization of this file is not recommended.
# Note: ifup-post will punch the current nameservers through the
# firewall; such entries will *not* be listed here.
:input ACCEPT
:forward ACCEPT
:output ACCEPT
-A input -s 0/0 -d 0/0 80 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 25 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 22 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 23 -p tcp -y -j ACCEPT
-A input -s 0/0 -d 0/0 -i lo -j ACCEPT
-A input -s 0/0 -d 0/0 -i eth1 -j ACCEPT
-A input -s 127.0.0.1 53 -d 0/0 -p udp -j ACCEPT
-A input -s 0/0 -d 0/0 -p tcp -y -j REJECT
-A input -s 0/0 -d 0/0 -p udp -j REJECT
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> This is in a format that can be read by the
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> command
<B
CLASS="COMMAND"
>ipchains-restore</B
>. Consequently, a new or modified set or
rules can be generated with the <B
CLASS="COMMAND"
>ipchains-save</B
>, and
redirecting the output to this file. <B
CLASS="COMMAND"
>ipchains-restore</B
> is
indeed how the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> init script processes
this file. So for this to work, the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>
service must be activated: &#13;</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; # chkconfig ipchains on
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Conversely, if you want to roll your own <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>
rules instead, you should make sure the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>
init service is disabled. There is also an
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> init script, that works much the same as
the <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> version. There is just no support
from <B
CLASS="COMMAND"
>gnome-lokkit</B
> at this time.&#13;</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="TCPWRAPPERS">5.3. Tcpwrappers (libwrap)</H2
><P
> <SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
> provides much the same desired results
as <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> above, though works quite differently.
<SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
> actually intercepts the connection
attempt, then examines its configurations files, and decides whether to
accept or reject the request. <SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
>
controls access at the application level, rather than the socket level
like <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> and <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>.
This can be quite effective, and is a standard component on most Linux
systems.&#13;</P
><P
> <SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
> consists of the configuration
files <TT
CLASS="FILENAME"
>/etc/hosts.allow</TT
> and
<TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
>. The functionality is provided by the
<SPAN
CLASS="APPLICATION"
>libwrap</SPAN
> library. &#13;</P
><P
> <SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
> first looks to see if access is
permitted in <TT
CLASS="FILENAME"
>/etc/hosts.allow</TT
>, and if so, access is
granted. If not in <TT
CLASS="FILENAME"
>/etc/hosts.allow</TT
>, the file
<TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
> is then checked to see if access is
<EM
>not</EM
> allowed. If so, access is denied. Else,
<EM
>access is granted</EM
>. For this reason,
<TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
> should contain only one uncommented
line, and that is: <TT
CLASS="LITERAL"
>ALL: ALL</TT
>. Access should then be
permitted through entries in <TT
CLASS="FILENAME"
>/etc/hosts.allow</TT
>, where
specific services are listed, along with the specific host addresses allowed
to access these services. While hostnames can be used here, use of hostnames
opens the limited possibility for name spoofing.&#13;</P
><P
> <SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
> is commonly used to protect services
that are started via <SPAN
CLASS="APPLICATION"
>inetd</SPAN
> (or
<SPAN
CLASS="APPLICATION"
>xinetd</SPAN
>). But also any program
that has been compiled with <SPAN
CLASS="APPLICATION"
>libwrap</SPAN
> support, can
take advantage of it. Just don't assume that all programs have built in
<SPAN
CLASS="APPLICATION"
>libwrap</SPAN
> support -- they do not. In fact, most
probably don't. So we will only use it in our examples here to protect
services start via <SPAN
CLASS="APPLICATION"
>inetd</SPAN
>. And then rely on our
packet filtering firewall, or other mechanism, to protect non-(x)inetd
services.&#13;</P
><P
> Below is a small snippet from a typical <TT
CLASS="FILENAME"
>inetd.conf</TT
> file:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; # Pop and imap mail services et al
#
#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d
#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd
#
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> The second to last column is the <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
>
daemon -- <B
CLASS="COMMAND"
>/usr/sbin/tcpd</B
>. Immediately after is the daemon
it is protecting. In this case, <SPAN
CLASS="APPLICATION"
>POP</SPAN
> and
<SPAN
CLASS="APPLICATION"
>IMAP</SPAN
> mail servers. Your distro probably has
already done this part for you. For the few applications that have built-in
support for <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> via the
<SPAN
CLASS="APPLICATION"
>libwrap</SPAN
> library, specifying the daemon as above
is not necessary.&#13;</P
><P
> We will use the same principles here: default policy is to deny everything,
then open holes to allow the minimal amount of traffic necessary.&#13;</P
><P
> So now with your text editor, <B
CLASS="COMMAND"
>su</B
> to root and open
<TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
>. If it does not exist, then create
it. It is just a plain text file. We want the following line:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; ALL: ALL
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> If it is there already, fine. If not, add it in and then save and close file.
Easy enough. <SPAN
CLASS="QUOTE"
>"ALL"</SPAN
> is one of the keywords that
<SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> understands. The format is
<TT
CLASS="LITERAL"
>$SERVICE_NAME : $WHO</TT
>, so we are denying all connections to
all services here. At least all services that are using
<SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
>. Remember, this will primarily be
<SPAN
CLASS="APPLICATION"
>inetd</SPAN
> services. See <TT
CLASS="LITERAL"
>man 5
hosts_access</TT
> for details on the syntax of these files. Note the
<SPAN
CLASS="QUOTE"
>"5"</SPAN
> there!&#13;</P
><P
> Now let's open up just the services we need, as restrictively as we can,
with a brief example:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; ALL: 127.0.0.1
sshd,ipop3d: 192.168.1.
sshd: .myworkplace.com, hostess.mymomshouse.com
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> The first line allows all <SPAN
CLASS="QUOTE"
>"localhost"</SPAN
> connections.
You will need this. The second
allows connections to the <SPAN
CLASS="APPLICATION"
>sshd</SPAN
> and
<SPAN
CLASS="APPLICATION"
>ipop3d</SPAN
> services from IP addresses that start with
<TT
CLASS="LITERAL"
>192.168.1.</TT
>, in this case the private address range for
our hypothetical home LAN. Note the trailing <SPAN
CLASS="QUOTE"
>"."</SPAN
>. It's
important. The third line allows connections to only our
<SPAN
CLASS="APPLICATION"
>sshd</SPAN
> daemon from any host associated with
<TT
CLASS="LITERAL"
>.myworkplace.com</TT
>. Note the leading <SPAN
CLASS="QUOTE"
>"."</SPAN
> in
this example. And then also, the single host
<TT
CLASS="LITERAL"
>hostess.mymomshouse.com</TT
>. In summary, localhost and all
our LAN connections have access to any and all tcpwrappered services on
bigcat. But only our workplace addresses, and our mother can use
<SPAN
CLASS="APPLICATION"
>sshd</SPAN
> on bigcat from outside connections. Everybody
else is denied by the default policy in <TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
>.
</P
><P
> The types of wild cards above (<TT
CLASS="LITERAL"
>.myworkplace.com</TT
> and
<TT
CLASS="LITERAL"
>192.168.1.</TT
>) are not supported by
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>,
or most other Linux applications for that matter. Also,
<SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> can use hostnames in place of
IP addresses which is quite handy in some situations. This does
not work with <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>. &#13;</P
><P
> You can test your <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> configuration
with the included <B
CLASS="COMMAND"
>tcpdchk</B
> utility (see the man page). Note
that at this time this does not work with <SPAN
CLASS="APPLICATION"
>xinetd</SPAN
>,
and may not even be included in this case.&#13;</P
><P
> There is nothing wrong with using both <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
>
and a packet filtering firewall like <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>. In
fact, it is recommended to use a <SPAN
CLASS="QUOTE"
>"layered"</SPAN
> approach. This
helps guard against accidental misconfigurations. In this case, each
connection will be tested by the packet filter rules first, then
<SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
>. &#13;</P
><P
> Remember to make backup copies before editing system configuration files,
restart the daemon afterward, and then check the logs for error messages.&#13;</P
><DIV
CLASS="SECT3"
><H3
CLASS="SECT3"
><A
NAME="XINETD2">5.3.1. xinetd</H3
><P
> As mentioned, <A
HREF="http://www.xinetd.org"
TARGET="_top"
>xinetd</A
> is an
enhanced <SPAN
CLASS="APPLICATION"
>inetd</SPAN
> , and replaces
<SPAN
CLASS="APPLICATION"
>inetd</SPAN
> as of Red Hat 7.0. It has much of the
same functionality, with some notable enhancements. One is that
<SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> support be
is compiled in, eliminating the need for explicit references to
<B
CLASS="COMMAND"
>tcpd</B
>. Which means <TT
CLASS="FILENAME"
>/etc/hosts.allow</TT
>
and <TT
CLASS="FILENAME"
>/etc/hosts.deny</TT
> are automatically in effect.
</P
><P
> Some of <SPAN
CLASS="APPLICATION"
>xinetd's</SPAN
> other enhancements: specify
IP address to listen on, which is a very effective method of access control;
limit the rate of incoming connections and the total number of simultaneous
connections; limit services to specific times of day. See the
<SPAN
CLASS="APPLICATION"
>xinetd</SPAN
> and <SPAN
CLASS="APPLICATION"
>xinetd.conf</SPAN
>
man pages for more details.&#13;</P
><P
> The syntax is quite different though. An example from
<TT
CLASS="FILENAME"
>/etc/xinetd.d/tftp</TT
>:</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; service tftp
{
socket_type = dgram
bind = 192.168.1.1
instances = 2
protocol = udp
wait = yes
user = nobody
only_from = 192.168.1.0
server = /usr/sbin/in.tftpd
server_args = /tftpboot
disable = no
}
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> Notice the <TT
CLASS="LITERAL"
>bind</TT
> statement. We are only listening on,
or <SPAN
CLASS="QUOTE"
>"binding"</SPAN
> to, the private, LAN interface here. No outside
connections can be made since the outside port is not even opened. We are
also only accepting connections from <TT
CLASS="LITERAL"
>192.168.1.0</TT
>, our LAN.
For <SPAN
CLASS="APPLICATION"
>xinetd's</SPAN
> purposes, this denotes any IP
address beginning with <SPAN
CLASS="QUOTE"
>"192.168.1"</SPAN
>. Note that the syntax is different
from <SPAN
CLASS="APPLICATION"
>inetd</SPAN
>. The <TT
CLASS="LITERAL"
>server</TT
>
statement in this case is the <B
CLASS="COMMAND"
>tftp</B
> daemon,
<B
CLASS="COMMAND"
>in.tftpd</B
>. Again, this assumes that
<SPAN
CLASS="APPLICATION"
>libwrap/tcpwrappers</SPAN
> support is compiled into
<SPAN
CLASS="APPLICATION"
>xinetd</SPAN
>. The <TT
CLASS="LITERAL"
>user</TT
> running the
daemon will be <SPAN
CLASS="QUOTE"
>"nobody"</SPAN
>. Yes, there is a user account called
<SPAN
CLASS="QUOTE"
>"nobody"</SPAN
>, and it is wise to run such daemons as non-root users
whenever possible. Lastly, the <TT
CLASS="LITERAL"
>disable</TT
> statement is
<SPAN
CLASS="APPLICATION"
>xinetd's</SPAN
> way of turning services on or off. In
this case, it is <SPAN
CLASS="QUOTE"
>"on"</SPAN
>. This is on here only as an example. Do
NOT run <SPAN
CLASS="APPLICATION"
>tftp</SPAN
> as a public service as it is unsafe.&#13;</P
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PORTSENTRY">5.4. PortSentry</H2
><P
> <A
HREF="http://www.psionic.org/products/portsentry.html"
TARGET="_top"
>Portsentry</A
>
works quite differently than the other tools discussed so far.
<SPAN
CLASS="APPLICATION"
>Portsentry</SPAN
> does what its name implies --
it guards ports. <SPAN
CLASS="APPLICATION"
>Portsentry</SPAN
> is configured with the
<TT
CLASS="FILENAME"
>/etc/portsentry/portsentry.conf</TT
> file.
</P
><P
> Unlike the other applications discussed above, it does this by actually
becoming the listening server on those ports. Kind of like baiting a trap.
Running <TT
CLASS="LITERAL"
>netstat -taup</TT
> as root while
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> is running, will show
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> as the <TT
CLASS="LITERAL"
>LISTENER</TT
> on
whatever ports <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> is configured for. If
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> senses a connection attempt, it blocks
it completely. And then goes a step further and blocks the route to that host
to stop all further traffic. Alternately, <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>
or <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> can be used to block the host
completely. So it makes an excellent tool to stop port scanning of a range of
ports.
</P
><P
> But <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> has limited flexibility as to
whether it allows a given connection. It is pretty much all or nothing. You
can define specific IP addresses that it will ignore in
<TT
CLASS="FILENAME"
>/etc/portsentry/portsentry.ignore</TT
>. But you cannot allow
selective access to individual ports. This is because only one server can
bind to a particular port at the same time, and in this case that is
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> itself. So it has limited usefulness as a
stand-alone firewall. As part of an overall firewall strategy, yes, it can
be quite useful. For most of us, it should not be our first line of defense,
and we should only use it in conjunction with other tools.
</P
><P
> Suggestion on when <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> might be useful:</P
><P
></P
><UL
><LI
><P
>
As a second layer of defense, behind either
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> or <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>.
Packet filtering will catch the packets first, so that anything that gets
to <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> would indicate a misconfiguration.
Do not use in conjunction with <SPAN
CLASS="APPLICATION"
>inetd</SPAN
> services --
it won't work. They will butt heads.
</P
></LI
><LI
><P
>
As a way to catch full range ports scans. Open a pinhole or two in the
packet filter, and let <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> catch these
and re-act accordingly.
</P
></LI
><LI
><P
>
If you are <EM
>very sure</EM
> you have no exposed public servers
at all, and you just want to know who is up to what. But do not assume
anything about what <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> is protecting.
By default it does not watch all ports, and may even leave some very
commonly probed ports open. So make sure you configure it accordingly.
And make sure you have tested and verified your set up first, and that
nothing is exposed.
</P
></LI
></UL
><P
> All in all, the packet filters make for a better firewall.&#13;</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="PROXIES">5.5. Proxies</H2
><P
> The dictionary defines <SPAN
CLASS="QUOTE"
>"proxy"</SPAN
> as <SPAN
CLASS="QUOTE"
>"the authority or power
to act on behalf of another"</SPAN
>. This pretty well describes software proxies as
well. It is an intermediary in the connection path. As an example, if we
were using a web proxy like <SPAN
CLASS="QUOTE"
>"squid"</SPAN
> (<A
HREF="http://www.squid-cache.org/"
TARGET="_top"
>http://www.squid-cache.org/</A
>),
every time we browse to a web site, we
would actually be connecting to our locally running <SPAN
CLASS="APPLICATION"
>squid</SPAN
> server.
Squid in turn, would relay our request to the ultimate, real destination. And
then <SPAN
CLASS="APPLICATION"
>squid</SPAN
> would relay the web pages back to us. It is
a go-between. Like <SPAN
CLASS="QUOTE"
>"firewalls"</SPAN
>, a <SPAN
CLASS="QUOTE"
>"proxy"</SPAN
> can refer
to either a specific application, or a dedicated server which runs a proxy
application. &#13;</P
><P
> Proxies can perform various duties, not all of which have much to do with
security. But the fact that they are an intermediary, makes them a good place
to enforce access control policies, limit direct connections through a
firewall, and control how the network behind the proxy looks to the Internet.
So this makes them strong candidates to be part of an overall firewall
strategy. And, in fact, are sometimes used instead of packet filtering
firewalls. Proxy based firewalls probably make more sense where many users
are behind the same firewall. And it probably is not high on the list of
components necessary for home based systems. &#13;</P
><P
> Configuring and administering proxies can be complex, and is beyond the scope of
this document. The Firewall and Proxy Server HOWTO, <A
HREF="http://tldp.org/HOWTO/Firewall-HOWTO.html "
TARGET="_top"
>http://tldp.org/HOWTO/Firewall-HOWTO.html</A
>, has examples
of setting up proxy firewalls. Squid usage is discussed at
<A
HREF="http://squid-docs.sourceforge.net/latest/html/book1.htm"
TARGET="_top"
>http://squid-docs.sourceforge.net/latest/html/book1.htm</A
>
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="INDAPPS">5.6. Individual Applications</H2
><P
> Some servers may have their own access control features. You should check
this for each server application you run. We'll only look at a few of the
common ones in this section. Man pages, and other application specific
documentation, is your friend here. This should be done whether you have
confidence in your firewall or not. Again, <SPAN
CLASS="APPLICATION"
>layers</SPAN
>
of protection is always best. &#13;</P
><P
> <P
></P
><UL
><LI
><P
> <SPAN
CLASS="APPLICATION"
>BIND</SPAN
> - a very common package that provides name
server functionality. The daemon itself is <SPAN
CLASS="QUOTE"
>"named"</SPAN
>. This only
requires full exposure to the Internet if you are providing DNS look ups
for one or more domains to the rest of the world. If you are not sure what
this means, <EM
>you do not need, or want</EM
>, it exposed. For
the overwhelming majority of us this is the case. It is a very common
crack target.
</P
><P
> But it may be installed, and can be useful in a caching only mode. This
does not require full exposure to the Internet. Limit the interfaces
on which it <SPAN
CLASS="QUOTE"
>"listens"</SPAN
> by editing
<TT
CLASS="FILENAME"
>/etc/named.conf</TT
> (random example shown):
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>
options {
directory "/var/named";
listen-on { 127.0.0.1; 192.168.1.1; };
version "N/A";
};
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
> The <SPAN
CLASS="QUOTE"
>"listen-on"</SPAN
> statement is what limits where named
listens for DNS queries. In this example, only on localhost and bigcat's
LAN interface. There is no port open for the rest of the world. It just
is not there. Restart <B
CLASS="COMMAND"
>named</B
> after making changes.
</P
></LI
><LI
><P
> X11 can be told not to allow TCP connections by using the
<TT
CLASS="LITERAL"
>-nolisten tcp</TT
> command line option. If using
<B
CLASS="COMMAND"
>startx</B
>, you can make this automatic by placing
<TT
CLASS="LITERAL"
>alias startx="startx -- -nolisten tcp"</TT
> in your
<TT
CLASS="FILENAME"
>~/.bashrc</TT
>, or the system-wide file,
<TT
CLASS="FILENAME"
>/etc/bashrc</TT
>, with your text editor. If using
<SPAN
CLASS="APPLICATION"
>xdm</SPAN
> (or variants such as
<SPAN
CLASS="APPLICATION"
>gdm</SPAN
>, <SPAN
CLASS="APPLICATION"
>kdm</SPAN
>, etc),
this option would be specified in
<SPAN
CLASS="APPLICATION"
>/etc/X11/xdm/Xservers</SPAN
> (or comparable) as
<TT
CLASS="LITERAL"
>:0 local /usr/bin/X11/X -nolisten tcp</TT
>.
<SPAN
CLASS="APPLICATION"
>gdm</SPAN
> actually uses
<TT
CLASS="FILENAME"
>/etc/X11/gdm/gdm.conf</TT
>.
</P
><P
> If using <SPAN
CLASS="APPLICATION"
>xdm</SPAN
> (or comparable) to start X
automatically at boot, <TT
CLASS="FILENAME"
>/etc/inittab</TT
> can
be modified as: <TT
CLASS="LITERAL"
>xdm -udpPort 0</TT
>, to further
restrict connections. This is typically near the bottom of
<TT
CLASS="FILENAME"
>/etc/inittab</TT
>.
</P
></LI
><LI
><P
> Recent versions of <SPAN
CLASS="APPLICATION"
>sendmail</SPAN
> can be told to
listen only on specified addresses:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; # SMTP daemon options
O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
> The above excerpt is from <TT
CLASS="FILENAME"
>/etc/sendmail.cf</TT
> which can
be carefully added with your text editor. The
<TT
CLASS="FILENAME"
>sendmail.mc</TT
> directive is:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>
dnl This changes sendmail to only listen on the loopback device 127.0.0.1
dnl and not on any other network devices.
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
> In case you would prefer to build a new <TT
CLASS="FILENAME"
>sendmail.cf</TT
>,
rather than edit the existing one. Other mail server daemons likely have
similar configuration options. Check your local documentation.
As of Red Hat 7.1, <SPAN
CLASS="APPLICATION"
>sendmail</SPAN
> has
compiled in support for <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> as well.
</P
></LI
><LI
><P
> <SPAN
CLASS="APPLICATION"
>SAMBA</SPAN
> connections can be restricted in
<TT
CLASS="FILENAME"
>smb.conf</TT
>:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; bind interfaces = true
interfaces = 192.168.1. 127.
hosts allow = 192.168.1. 127.
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
> This will only open, and allow, connections from localhost (127.0.0.1),
and the local LAN address range. Adjust the LAN address as needed.
</P
></LI
><LI
><P
> The <SPAN
CLASS="APPLICATION"
>CUPS</SPAN
> print daemon can be told where
to listen for connections. Add to <TT
CLASS="FILENAME"
>/etc/cups/cupsd.conf</TT
>:
</P
><P
> <TABLE
BORDER="1"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="SCREEN"
>&#13; Listen 192.168.1.1:631
</PRE
></FONT
></TD
></TR
></TABLE
>
</P
><P
> This will only open a port at the specified address and port number.
</P
></LI
><LI
><P
> <SPAN
CLASS="APPLICATION"
>xinetd</SPAN
> can force daemons to listen only
on a specified address with its <SPAN
CLASS="QUOTE"
>"bind"</SPAN
> configuration
directive. For instance, an internal LAN interface address.
See <TT
CLASS="LITERAL"
>man xinetd.conf</TT
> for this and other syntax.
There are various other control mechanisms as well.
</P
></LI
></UL
></P
><P
> As always, anytime you make system changes, backup the configuration file
first, restart the appropriate daemon afterward, and then check the
appropriate logs for error messages.</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="VERIFY">5.7. Verifying</H2
><P
> The final step after getting your firewall in place, is to verify that it
is doing what you intended. You would be wise to do this anytime you make
even minor changes to your system configuration. </P
><P
> So how to do this? There are several things you can do.</P
><P
> For our packet filters like <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>, we can list all our rules, chains,
and associated activity with <TT
CLASS="LITERAL"
>iptables -nvL | less</TT
>
(substitute <B
CLASS="COMMAND"
>ipchains</B
> if appropriate). Open
your xterm as wide as possible to avoid wrapping long lines. </P
><P
> This should give you an idea if your chains are doing what you think they
should. You may want to perform some of the on-line tasks you normally do
first: open a few web pages, send and retrieve mail, etc. This will, of
course, not give you any information on <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> or
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
>. <B
CLASS="COMMAND"
>tcpdchk</B
> can
be used to verify <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
> configuration
(except with <SPAN
CLASS="APPLICATION"
>xinetd</SPAN
>).&#13;</P
><P
> And then, scan yourself. <SPAN
CLASS="APPLICATION"
>nmap</SPAN
> is the scanning
tool of choice and
is included with recent Red Hat releases, or from
<A
HREF="http://www.insecure.org/nmap/nmap_download.html"
TARGET="_top"
>http://www.insecure.org/nmap/nmap_download.html</A
>. <SPAN
CLASS="APPLICATION"
>nmap</SPAN
> is very
flexible, and essentially is a <SPAN
CLASS="QUOTE"
>"port prober"</SPAN
>. In other words,
it looks for open ports, among other things. See the
<SPAN
CLASS="APPLICATION"
>nmap</SPAN
> man page for details.
</P
><P
> If you do run <SPAN
CLASS="APPLICATION"
>nmap</SPAN
> against yourself (e.g.
<TT
CLASS="LITERAL"
>nmap localhost</TT
>), this should tell you what ports are
open -- and <EM
>visible locally</EM
> only! Which hopefully by now, is
quite different from what can be seen from the outside. So, scan yourself,
and then find a trusted friend, or site (see the <A
HREF="appendix.html#LINKS"
>Links
section</A
>), to scan you from the outside. Make sure you are not
violating your ISPs Terms of Service by port scanning. It may not be allowed,
even if the intentions are honorable. Scanning from outside is the best way
to know how the rest of the world sees you. This should tell you how well
that firewall is working. See the <A
HREF="appendix.html#NMAP"
>nmap</A
> section in
the Appendix for some examples on <SPAN
CLASS="APPLICATION"
>nmap</SPAN
> usage.
</P
><P
> One caveat on this: some ISPs may filter some ports, and you will not know
for sure how well your firewall is working. Conversely, they make it look
like certain ports are open by using web, or other, proxies. The scanner
may see the web proxy at port 80 and mis-report it as an open port on your
system. &#13;</P
><P
> Another option is to find a website that offers <EM
>full
range</EM
> testing. <A
HREF="http://www.hackerwhacker.com"
TARGET="_top"
>http://www.hackerwhacker.com</A
> is
one such site. Make sure that any such site is not just scanning a relatively
few well known ports.&#13;</P
><P
> Repeat this procedure with every firewall change, every system upgrade or new
install, and when any key components of your system changes.&#13;</P
><P
> You may also want to enable logging all the denied traffic. At least
temporarily. Once the firewall is verified to be doing what you think it
should, and if the logs are hopelessly overwhelming, you may want to disable
logging. &#13;</P
><P
> If relying on <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
> at all, please read the
documentation. Depending on your configuration it will either drop the
route to the scanner, or implement a
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>/<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> rule
doing the same thing. Also, since it <SPAN
CLASS="QUOTE"
>"listens"</SPAN
> on the
specified ports, all those ports will show as <SPAN
CLASS="QUOTE"
>"open"</SPAN
>. A false
alarm in this case.
</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="LOGGING">5.8. Logging</H2
><P
> Linux does a lot of logging. Usually to more than one file. It is not always
obvious what to make of all these entries -- good, bad or indifferent? Firewall
logs tend to generate a fair amount of each. Of course, you are wanting to
stop only the <SPAN
CLASS="QUOTE"
>"bad"</SPAN
>, but you will undoubtedly catch some
harmless traffic as well. The 'net has a lot of background noise. &#13;</P
><P
> In many cases, knowing the intentions of an incoming packet are almost
impossible. Attempted intrusion? Misbehaved protocol? Mis-typed IP address?
Conclusions can be drawn based on factors such as destination port, source
port, protocol, and many other variables. But there is no substitute for
experience in interpreting firewall logs. It is a black art in many cases.&#13;</P
><P
> So do we really need to log? And how much should we be trying to log? Logging
is good in that it tells us that the firewall is functional. Even if we
don't understand much of it, we know it is doing <SPAN
CLASS="QUOTE"
>"something"</SPAN
>.
And if we have to, we can dig into those logs and find whatever data might be
called for.
</P
><P
> On the other hand, logging can be bad if it is so excessive, it is difficult
to find pertinent data, or worse, fills up a partition. Or if we over re-act
and take every last entry as an all out assault. Some perspective is a great
benefit, but something that new users lack almost by definition. Again, once
your firewall is verified, and you are perplexed or overwhelmed, home
desktop users may want to disable as much logging as possible. Anyone with
greater responsibilities should log, and then find ways to extract the
pertinent data from the logs by filtering out extraneous information.&#13;</P
><P
> Not sure where to look for log data? The two logs to keep an eye on are
<TT
CLASS="FILENAME"
>/var/log/messages</TT
> and <TT
CLASS="FILENAME"
>/var/log/secure</TT
>.
There may be other application specific logs, depending on what you have
installed, or using. <SPAN
CLASS="APPLICATION"
>FTP</SPAN
>, for instance, logs
to <TT
CLASS="FILENAME"
>/var/log/xfer</TT
> on Red Hat.&#13;</P
><P
> <SPAN
CLASS="APPLICATION"
>Portsentry</SPAN
> and <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
>
do a certain amount of logging that is not adjustable.
<SPAN
CLASS="APPLICATION"
>xinetd</SPAN
> has logging enhancements that can be turned
on. Both <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>, on the other hand, are very flexible as
to what is logged. </P
><P
> For <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> the <TT
CLASS="LITERAL"
>-l</TT
> option can
be added to any rule. <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> uses the
<TT
CLASS="LITERAL"
>-j LOG</TT
> target, and requires its own, separate rule instead.
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> goes a few steps further and allows
customized log entries, and rate limiting. See the man page. Presumably, we
are more interested in logging blocked traffic, so we'd confine logging to
only our <TT
CLASS="LITERAL"
>DENY</TT
> and <TT
CLASS="LITERAL"
>REJECT</TT
> rules.&#13;</P
><P
> So whether you log, and how much you log, and what you do with the logs, is
an individual decision, and probably will require some trial and error so
that it is manageable. A few auditing and analytical tools can be quite
helpful:&#13;</P
><P
> Some tools that will monitor your logs for you and notify you when necessary.
These likely will require some configuration, and trial and error, to make
the most out of them: &#13;</P
><P
> <P
></P
><UL
><LI
><P
> A nice log entry analyzer for <SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> and
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> from Manfred Bartz: <A
HREF="http://www.logi.cc/linux/NetfilterLogAnalyzer.php3"
TARGET="_top"
>http://www.logi.cc/linux/NetfilterLogAnalyzer.php3</A
>.
What does all that stuff mean anyway?
</P
></LI
><LI
><P
>
<SPAN
CLASS="APPLICATION"
>LogSentry</SPAN
> (formerly <SPAN
CLASS="APPLICATION"
>logcheck</SPAN
>) is available from
<A
HREF="http://www.psionic.org/products/logsentry.html"
TARGET="_top"
>http://www.psionic.org/products/logsentry.html</A
>,
the same group that is responsible for
<SPAN
CLASS="APPLICATION"
>portsentry</SPAN
>. <SPAN
CLASS="APPLICATION"
>LogSentry</SPAN
>
is an all purpose log monitoring tool with a flexible configuration, that
handles multiple logs.
</P
></LI
><LI
><P
> <A
HREF="http://freshmeat.net/projects/firelogd/"
TARGET="_top"
>http://freshmeat.net/projects/firelogd/</A
>, the Firewall Log Daemon from Ian Jones, is designed to
watch, and send alerts on <SPAN
CLASS="APPLICATION"
>iptables</SPAN
> or
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> logs data.
</P
></LI
><LI
><P
> <A
HREF="http://freshmeat.net/projects/fwlogwatch/"
TARGET="_top"
>http://freshmeat.net/projects/fwlogwatch/</A
> by Boris Wesslowski, is a similar idea, but supports
more log formats.
</P
></LI
></UL
></P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="WHERETOSTART">5.9. Where to Start</H2
><P
> Let's take a quick look at where to run our firewall scripts from.</P
><P
> <SPAN
CLASS="APPLICATION"
>Portsentry</SPAN
> can be run as an init process, like
other system services. It is not so important when this is done.
<SPAN
CLASS="APPLICATION"
>Tcpwrappers</SPAN
> will be automatically be invoked by
<SPAN
CLASS="APPLICATION"
>inetd</SPAN
> or <SPAN
CLASS="APPLICATION"
>xinetd</SPAN
>, so not
to worry there either.
</P
><P
> But the packet filtering scripts will have to be started somewhere. And many
scripts will have logic that uses the local IP address. This will mean that
the script must be started after the interface has come up and been assigned
an IP address. Ideally, this should be immediately after the interface is up.
So this depends on how you connect to the Internet. Also, for protocols like
<SPAN
CLASS="APPLICATION"
>PPP</SPAN
> or <SPAN
CLASS="APPLICATION"
>DHCP</SPAN
> that may
be dynamic, and get different IP's on each re-connect, it is best to have
the scripts run by the appropriate daemon.
</P
><P
> Red Hat uses
<TT
CLASS="FILENAME"
>/etc/ppp/ip-up.local</TT
> for any user defined, local
PPP configuration. If this file does not exist, create it, and
make it executable (<TT
CLASS="LITERAL"
>chmod +x</TT
>). Then with your text editor,
add a reference to your firewall script.&#13;</P
><P
> For <SPAN
CLASS="APPLICATION"
>DHCP</SPAN
>, it depends on which client.
<B
CLASS="COMMAND"
>dhcpcd</B
> will execute
<B
CLASS="COMMAND"
>/etc/dhcpcd/dhcpcd-&#60;interface&#62;.exe</B
> (e.g.
dhcpcd-eth0.exe) whenever a lease is obtained or renewed. So this is where to
put a reference to your firewall script. For
<B
CLASS="COMMAND"
>pump</B
> (the default on Red Hat), the main
configuration file is <TT
CLASS="FILENAME"
>/etc/pump.conf</TT
>.
<B
CLASS="COMMAND"
>Pump</B
> will run whatever script is defined by the
<SPAN
CLASS="QUOTE"
>"script"</SPAN
> statement any time there is a new or renewed lease:&#13;</P
><P
> <TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="100%"
><TR
><TD
><FONT
COLOR="#000000"
><PRE
CLASS="PROGRAMLISTING"
>&#13; script /usr/local/bin/ipchains.sh
</PRE
></FONT
></TD
></TR
></TABLE
></P
><P
> If you have a static IP address (i.e. it never changes), the placement is not
so important and should be <EM
>before</EM
> the interface comes
up!</P
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="SUMMARY3">5.10. Summary and Conclusions for Step 3</H2
><P
> In this section we looked at various components that might be used to
construct a <SPAN
CLASS="QUOTE"
>"firewall"</SPAN
>. And learned that a firewall is as
much a strategy and combination of components, as it is any one particular
application or component. We looked at a few of the most commonly available
applications that can be found on most, if not all, Linux systems. This is
not a definitive list.</P
><P
> This is a lot of information to digest at all at one time and expect anyone
to understand it all. Hopefully this can used as a starting point, and
used for future reference as well. The packet filter firewall examples can be
used as starting points as well. Just use your text editor, cut and paste
into a file with an appropriate name, and then run <TT
CLASS="LITERAL"
>chmod
+x</TT
> against it to make it executable. Some minor editing of the
variables may be necessary. Also look at the <A
HREF="appendix.html#LINKS"
>Links</A
> section for sites and utilities that can be
used to generate a custom script. This may be a little less daunting.&#13;</P
><P
> Now we are done with Steps 1, 2 and 3. Hopefully by now you have already
instituted some basic measures to protect your system(s) from the various and
sundry threats that lurk on networks. If you haven't implemented any of the
above steps yet, now is a good time to take a break, go back to the top, and
have at it. The most important steps are the ones above.
</P
><P
> A few quick conclusions...</P
><P
> <SPAN
CLASS="QUOTE"
>"What is best <SPAN
CLASS="APPLICATION"
>iptables</SPAN
>,
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
>, <SPAN
CLASS="APPLICATION"
>tcpwrappers</SPAN
>,
or <SPAN
CLASS="APPLICATION"
>portsentry</SPAN
>?"</SPAN
> The quick answer is that
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> can do more than any of the others. So
if you are using a 2.4 kernel, use
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
>. Then,
<SPAN
CLASS="APPLICATION"
>ipchains</SPAN
> if using a 2.2 kernel. The long answer is
<SPAN
CLASS="QUOTE"
>"it just depends on what you are doing and what the objective
is"</SPAN
>. Sorry. The other tools all have some merit in any given
situation, and all can be effective in the right situation. &#13;</P
><P
> <SPAN
CLASS="QUOTE"
>"Do I really need all these packages?"</SPAN
> No, but please combine
more than one approach, and please follow all the above recommendations.
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> by itself is good, but in conjunction
with some of the other approaches, we are even stronger. Do not rely on any
single mechanism to provide a security blanket. <SPAN
CLASS="QUOTE"
>"Layers"</SPAN
> of
protection is always best. As is sound administrative practices. The best
<SPAN
CLASS="APPLICATION"
>iptables</SPAN
> script in the world is but one piece of
the puzzle, and should not be used to hide other system weaknesses.&#13;</P
><P
> <SPAN
CLASS="QUOTE"
>"If I have a small home LAN, do I need to have a firewall on each
computer?"</SPAN
> No, not necessary as long as the LAN gateway has a properly
configured firewall. Unwanted traffic should be stopped at that point. And as
long as this is working as intended, there should be no unwanted traffic on
the LAN. But, by the same token, doing this certainly does no harm. And on
larger LANs that might be mixed platform, or with untrusted users, it would
be advisable.&#13;</P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="updates.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="intrusion.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Step 2: Updating</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
>&nbsp;</TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Intrusion Detection</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
Reference in New Issue View Git Blame Copy Permalink