392 lines
8.3 KiB
HTML
392 lines
8.3 KiB
HTML
|
<HTML
|
|||
|
><HEAD
|
|||
|
><TITLE
|
|||
|
>Testing a
|
|||
|
Firewall Configuration</TITLE
|
|||
|
><META
|
|||
|
NAME="GENERATOR"
|
|||
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"><LINK
|
|||
|
REL="HOME"
|
|||
|
TITLE="Linux Network Administrators Guide"
|
|||
|
HREF="index.html"><LINK
|
|||
|
REL="UP"
|
|||
|
TITLE="TCP/IP Firewall"
|
|||
|
HREF="x-087-2-firewall.html"><LINK
|
|||
|
REL="PREVIOUS"
|
|||
|
TITLE="TOS Bit Manipulation"
|
|||
|
HREF="x-087-2-firewall.tos.manipulation.html"><LINK
|
|||
|
REL="NEXT"
|
|||
|
TITLE="A Sample Firewall Configuration"
|
|||
|
HREF="x-087-2-firewall.example.html"></HEAD
|
|||
|
><BODY
|
|||
|
CLASS="SECT1"
|
|||
|
BGCOLOR="#FFFFFF"
|
|||
|
TEXT="#000000"
|
|||
|
LINK="#0000FF"
|
|||
|
VLINK="#840084"
|
|||
|
ALINK="#0000FF"
|
|||
|
><DIV
|
|||
|
CLASS="NAVHEADER"
|
|||
|
><TABLE
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
CELLPADDING="0"
|
|||
|
CELLSPACING="0"
|
|||
|
><TR
|
|||
|
><TH
|
|||
|
COLSPAN="3"
|
|||
|
ALIGN="center"
|
|||
|
>Linux Network Administrators Guide</TH
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="10%"
|
|||
|
ALIGN="left"
|
|||
|
VALIGN="bottom"
|
|||
|
><A
|
|||
|
HREF="x-087-2-firewall.tos.manipulation.html"
|
|||
|
>Prev</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="80%"
|
|||
|
ALIGN="center"
|
|||
|
VALIGN="bottom"
|
|||
|
>Chapter 9. TCP/IP Firewall</TD
|
|||
|
><TD
|
|||
|
WIDTH="10%"
|
|||
|
ALIGN="right"
|
|||
|
VALIGN="bottom"
|
|||
|
><A
|
|||
|
HREF="x-087-2-firewall.example.html"
|
|||
|
>Next</A
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
><HR
|
|||
|
ALIGN="LEFT"
|
|||
|
WIDTH="100%"></DIV
|
|||
|
><DIV
|
|||
|
CLASS="SECT1"
|
|||
|
><H1
|
|||
|
CLASS="SECT1"
|
|||
|
><A
|
|||
|
NAME="X-087-2-FIREWALL.CHECKINGCONF"
|
|||
|
>9.10. Testing a
|
|||
|
Firewall Configuration</A
|
|||
|
></H1
|
|||
|
><P
|
|||
|
> After you've designed an appropriate firewall configuration, it's
|
|||
|
important to validate that it does in fact do what you want it to
|
|||
|
do. One way to do this is to use a test host outside your network to
|
|||
|
attempt to pierce your firewall: this can be quite clumsy and
|
|||
|
slow, though, and is limited to testing only those addresses that you can
|
|||
|
actually use.</P
|
|||
|
><P
|
|||
|
>A faster and easier method is available with the Linux firewall
|
|||
|
implementation. It allows you to manually generate tests and run them
|
|||
|
through the firewall configuration just as if you were testing with
|
|||
|
actual datagrams. All varieties of the Linux kernel firewall software,
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipfwadm</B
|
|||
|
>, <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipchains</B
|
|||
|
>, and
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>iptables</B
|
|||
|
>, provide support for this style of
|
|||
|
testing. The implementation involves use of the relevant
|
|||
|
<I
|
|||
|
CLASS="EMPHASIS"
|
|||
|
>check</I
|
|||
|
> command.</P
|
|||
|
><P
|
|||
|
>The general test procedure is as follows:</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><OL
|
|||
|
TYPE="1"
|
|||
|
><LI
|
|||
|
><P
|
|||
|
>Design and configure your firewall using <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipfwadm</B
|
|||
|
>,
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipchains</B
|
|||
|
>, or <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>iptables</B
|
|||
|
>.</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
>Design a series of tests that will determine whether your firewall is
|
|||
|
actually working as you intend. For these tests you may use any source
|
|||
|
or destination address, so choose some address combinations that
|
|||
|
should be accepted and some others that should be dropped. If you're
|
|||
|
allowing or disallowing only certain ranges of addresses, it is a good
|
|||
|
idea to test addresses on either side of the boundary of the
|
|||
|
range—one address just inside the boundary and one address just
|
|||
|
outside the boundary. This will help ensure that you have the correct
|
|||
|
boundaries configured, because it is sometimes easy to specify
|
|||
|
netmasks incorrectly in your configuration. If you're filtering by
|
|||
|
protocol and port number, your tests should also check all important
|
|||
|
combinations of these parameters. For example, if you intend to accept
|
|||
|
only TCP under certain circumstances, check that UDP datagrams are
|
|||
|
dropped.</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
>Develop <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipfwadm</B
|
|||
|
>, <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipchains</B
|
|||
|
>, or
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>iptables</B
|
|||
|
> rules to implement each test. It is
|
|||
|
probably worthwhile to write all the rules into a script so you can
|
|||
|
test and re-test easily as you correct mistakes or change your
|
|||
|
design. Tests use almost the same syntax as rule specifications, but
|
|||
|
the arguments take on slightly differing meanings. For example, the
|
|||
|
source address argument in a rule specification specifies the source
|
|||
|
address that datagrams matching this rule should have. The source
|
|||
|
address argument in test syntax, in contrast, specifies the source
|
|||
|
address of the test datagram that will be generated. For
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipfwadm</B
|
|||
|
>, you must use the <TT
|
|||
|
CLASS="OPTION"
|
|||
|
>–c</TT
|
|||
|
>
|
|||
|
option to specify that this command is a test, while for
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipchains</B
|
|||
|
> and <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>iptables</B
|
|||
|
>, you must
|
|||
|
use the <TT
|
|||
|
CLASS="OPTION"
|
|||
|
>–C</TT
|
|||
|
> option. In all cases you must
|
|||
|
<I
|
|||
|
CLASS="EMPHASIS"
|
|||
|
>always</I
|
|||
|
> specify the source address, destination
|
|||
|
address, protocol, and interface to be used for the test. Other
|
|||
|
arguments, such as port numbers or TOS bit settings, are optional.</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
>Execute each test command and note the output. The output of each test
|
|||
|
will be a single word indicating the final target of the datagram
|
|||
|
after running it through the firewall configuration—that is,
|
|||
|
where the processing ended. For <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipchains</B
|
|||
|
> and
|
|||
|
<B
|
|||
|
CLASS="COMMAND"
|
|||
|
>iptables</B
|
|||
|
>, user-specified chains will be tested
|
|||
|
in addition to the built-in ones.</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
>Compare the output of each test against the desired result. If there
|
|||
|
are any discrepancies, you will need to analyse your ruleset to
|
|||
|
determine where you've made the error. If you've written your test
|
|||
|
commands into a script file, you can easily rerun the test after
|
|||
|
correcting any errors in your firewall configuration. It's a good
|
|||
|
practice to flush your rulesets completely and rebuild them from
|
|||
|
scratch, rather than to make changes dynamically. This helps ensure
|
|||
|
that the active configuration you are testing actually reflects the
|
|||
|
set of commands in your configuration script.</P
|
|||
|
></LI
|
|||
|
></OL
|
|||
|
><P
|
|||
|
>Let's take a quick look at what a manual test transcript would look
|
|||
|
like for our na<6E>ve example with <B
|
|||
|
CLASS="COMMAND"
|
|||
|
>ipchains</B
|
|||
|
>. You will remember that our
|
|||
|
local network in the example was 172.16.1.0 with a netmask of
|
|||
|
255.255.255.0, and we were to allow TCP connections out to web servers
|
|||
|
on the net. Nothing else was to pass our forward chain. Start with a
|
|||
|
transmission that we know should work, a connection from a local host
|
|||
|
to a web server outside:
|
|||
|
|
|||
|
<TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><PRE
|
|||
|
CLASS="SCREEN"
|
|||
|
># <TT
|
|||
|
CLASS="USERINPUT"
|
|||
|
><B
|
|||
|
>ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
accepted</PRE
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></P
|
|||
|
><P
|
|||
|
>Note the arguments had to be supplied and the way they've been used to
|
|||
|
describe a datagram. The output of the command indicates that that the
|
|||
|
datagram was accepted for forwarding, which is what we hoped for.</P
|
|||
|
><P
|
|||
|
>Now try another test, this time with a source address that doesn't
|
|||
|
belong to our network. This one should be denied:
|
|||
|
<TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><PRE
|
|||
|
CLASS="SCREEN"
|
|||
|
># <TT
|
|||
|
CLASS="USERINPUT"
|
|||
|
><B
|
|||
|
>ipchains -C forward -p tcp -s 172.16.2.0 1025 -d 44.136.8.2 80 -i eth0</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
denied</PRE
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></P
|
|||
|
><P
|
|||
|
>Try some more tests, this time with the same details as the first test,
|
|||
|
but with different protocols. These should be denied, too:
|
|||
|
|
|||
|
<TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><PRE
|
|||
|
CLASS="SCREEN"
|
|||
|
># <TT
|
|||
|
CLASS="USERINPUT"
|
|||
|
><B
|
|||
|
>ipchains -C forward -p udp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
denied
|
|||
|
# <TT
|
|||
|
CLASS="USERINPUT"
|
|||
|
><B
|
|||
|
>ipchains -C forward -p icmp -s 172.16.1.0 1025 -d 44.136.8.2 80 -i eth0</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
denied</PRE
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></P
|
|||
|
><P
|
|||
|
>Try another destination port, again expecting it to be denied:
|
|||
|
|
|||
|
<TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><PRE
|
|||
|
CLASS="SCREEN"
|
|||
|
># <TT
|
|||
|
CLASS="USERINPUT"
|
|||
|
><B
|
|||
|
>ipchains -C forward -p tcp -s 172.16.1.0 1025 -d 44.136.8.2 23 -i eth0</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
denied</PRE
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></P
|
|||
|
><P
|
|||
|
>You'll go a long way toward achieving peace of mind if you design a series
|
|||
|
of exhaustive tests. While this can sometimes be as difficult as designing
|
|||
|
the firewall configuration, it's also the best way of knowing
|
|||
|
that your design
|
|||
|
is providing the security you expect of it.</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="NAVFOOTER"
|
|||
|
><HR
|
|||
|
ALIGN="LEFT"
|
|||
|
WIDTH="100%"><TABLE
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
CELLPADDING="0"
|
|||
|
CELLSPACING="0"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="33%"
|
|||
|
ALIGN="left"
|
|||
|
VALIGN="top"
|
|||
|
><A
|
|||
|
HREF="x-087-2-firewall.tos.manipulation.html"
|
|||
|
>Prev</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="34%"
|
|||
|
ALIGN="center"
|
|||
|
VALIGN="top"
|
|||
|
><A
|
|||
|
HREF="index.html"
|
|||
|
>Home</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="33%"
|
|||
|
ALIGN="right"
|
|||
|
VALIGN="top"
|
|||
|
><A
|
|||
|
HREF="x-087-2-firewall.example.html"
|
|||
|
>Next</A
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="33%"
|
|||
|
ALIGN="left"
|
|||
|
VALIGN="top"
|
|||
|
>TOS Bit Manipulation</TD
|
|||
|
><TD
|
|||
|
WIDTH="34%"
|
|||
|
ALIGN="center"
|
|||
|
VALIGN="top"
|
|||
|
><A
|
|||
|
HREF="x-087-2-firewall.html"
|
|||
|
>Up</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="33%"
|
|||
|
ALIGN="right"
|
|||
|
VALIGN="top"
|
|||
|
>A Sample Firewall Configuration</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
></BODY
|
|||
|
></HTML
|
|||
|
>
|