2918 lines
66 KiB
HTML
2918 lines
66 KiB
HTML
|
<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. </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. </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. </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. </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. </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. </P
|
|||
|
><P
|
|||
|
> <TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="PROGRAMLISTING"
|
|||
|
> #!/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" ] && echo "$WAN_IFACE not configured, aborting." && 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. </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. </P
|
|||
|
><P
|
|||
|
> See the <SPAN
|
|||
|
CLASS="APPLICATION"
|
|||
|
>ipchains</SPAN
|
|||
|
> man page for a full explanation
|
|||
|
of syntax. The important ones we used here are: </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 <IP address></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 <IP address></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. </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. </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
|
|||
|
>. </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"
|
|||
|
> # 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. </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. </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. </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
|
|||
|
>: </P
|
|||
|
><P
|
|||
|
> <TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="PROGRAMLISTING"
|
|||
|
> #!/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. </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"
|
|||
|
> # 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. </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. </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
|
|||
|
>. </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. </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
|
|||
|
>. </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
|
|||
|
>: </P
|
|||
|
><P
|
|||
|
> <TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="PROGRAMLISTING"
|
|||
|
> # 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: </P
|
|||
|
><P
|
|||
|
> <TABLE
|
|||
|
BORDER="1"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="SCREEN"
|
|||
|
> # 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. </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. </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. </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. </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. </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"
|
|||
|
> # 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. </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. </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"
|
|||
|
> 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! </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"
|
|||
|
> 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
|
|||
|
>. </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. </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
|
|||
|
>. </P
|
|||
|
><P
|
|||
|
> Remember to make backup copies before editing system configuration files,
|
|||
|
restart the daemon afterward, and then check the logs for error messages. </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. </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"
|
|||
|
> 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. </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. </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. </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. </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. </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"
|
|||
|
> # 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"
|
|||
|
> 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"
|
|||
|
> 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
|
|||
|
>). </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. </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. </P
|
|||
|
><P
|
|||
|
> Repeat this procedure with every firewall change, every system upgrade or new
|
|||
|
install, and when any key components of your system changes. </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. </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. </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. </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. </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. </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. </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: </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: </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. </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-<interface>.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: </P
|
|||
|
><P
|
|||
|
> <TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="PROGRAMLISTING"
|
|||
|
> 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. </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. </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. </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. </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"
|
|||
|
> </TD
|
|||
|
><TD
|
|||
|
WIDTH="33%"
|
|||
|
ALIGN="right"
|
|||
|
VALIGN="top"
|
|||
|
>Intrusion Detection</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
></BODY
|
|||
|
></HTML
|
|||
|
>
|