forked from extern/shorewall_code
88 lines
2.9 KiB
XML
88 lines
2.9 KiB
XML
|
<?xml version="1.0" encoding="UTF-8"?>
|
||
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||
|
|
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
||
|
|
<article>
|
||
|
|
<!--$Id$-->
|
||
|
|
|
||
|
|
<articleinfo>
|
||
|
|
<title>The Fool's Firewall</title>
|
||
|
|
|
||
|
|
<authorgroup>
|
||
|
|
<author>
|
||
|
|
<firstname>Tom</firstname>
|
||
|
|
|
||
|
|
<surname>Eastep</surname>
|
||
|
|
</author>
|
||
|
|
</authorgroup>
|
||
|
|
|
||
|
|
<pubdate><?dbtimestamp format="Y/m/d"?></pubdate>
|
||
|
|
|
||
|
|
<copyright>
|
||
|
|
<year>2009</year>
|
||
|
|
|
||
|
|
<holder>Thomas M. Eastep</holder>
|
||
|
|
</copyright>
|
||
|
|
|
||
|
|
<legalnotice>
|
||
|
|
<para>Permission is granted to copy, distribute and/or modify this
|
||
|
|
document under the terms of the GNU Free Documentation License, Version
|
||
|
|
1.2 or any later version published by the Free Software Foundation; with
|
||
|
|
no Invariant Sections, with no Front-Cover, and with no Back-Cover
|
||
|
|
Texts. A copy of the license is included in the section entitled
|
||
|
|
<quote><ulink url="GnuCopyright.htm">GNU Free Documentation
|
||
|
|
License</ulink></quote>.</para>
|
||
|
|
</legalnotice>
|
||
|
|
</articleinfo>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Definition</title>
|
||
|
|
|
||
|
|
<para>Occasionally, we hear from someone who has cabled his firewall's
|
||
|
|
external and internal firewall interfaces to the same switch. I call this
|
||
|
|
configuration <firstterm>The Fool's Firewall</firstterm>. </para>
|
||
|
|
|
||
|
|
<para>When the external interface supports broadcast, this configuration
|
||
|
|
has two very bad drawbacks:</para>
|
||
|
|
|
||
|
|
<orderedlist>
|
||
|
|
<listitem>
|
||
|
|
<para>It is very insecure</para>
|
||
|
|
</listitem>
|
||
|
|
|
||
|
|
<listitem>
|
||
|
|
<para>The up-stream router can send incoming packets to the wrong
|
||
|
|
interface.</para>
|
||
|
|
</listitem>
|
||
|
|
</orderedlist>
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>Security Issue</title>
|
||
|
|
|
||
|
|
<para>Because Fool's firewall is not physically located between the net
|
||
|
|
and the local systems, the local systems are exposed to all of the systems
|
||
|
|
in the same broadcast domain. Because the local systems (expecially those
|
||
|
|
running Windows) send broadcasts, those systems can be easily detected by
|
||
|
|
using a packet sniffer. Once the systems have been spotted, it is child's
|
||
|
|
play to add an IP address in Fool's internal IP network and bypass his
|
||
|
|
"Firewall". </para>
|
||
|
|
|
||
|
|
<graphic align="center" fileref="images/Fools.png" />
|
||
|
|
</section>
|
||
|
|
|
||
|
|
<section>
|
||
|
|
<title>ARP Roulette</title>
|
||
|
|
|
||
|
|
<para>The Linux IP stack exhibits some unexpected behavior with respect to
|
||
|
|
ARP. It will respond to ARP 'who-has' requests received on
|
||
|
|
<emphasis>any</emphasis> interface and not just on the interface owning
|
||
|
|
the address. So when the upstream router sends a 'who-has' request for
|
||
|
|
Fool's external IP address, the response may come from his
|
||
|
|
<emphasis>internal</emphasis> interface (and reflect the MAC address of
|
||
|
|
that interface). When that happens, packets from the net start entering
|
||
|
|
the firewall's internal interface.</para>
|
||
|
|
|
||
|
|
<graphic fileref="images/Foolsa.png" />
|
||
|
|
</section>
|
||
|
|
</article>
|