forked from extern/shorewall_code
Documentation Updates
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1657 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep
parent
af41248619
commit
bf85e3475b
@ -17,7 +17,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-09-23</pubdate>
|
||||
<pubdate>2004-10-01</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2004</year>
|
||||
@ -1824,12 +1824,79 @@ iptables: Invalid argument
|
||||
<para>Experimental Shorewall Bridging Firewall support is available —
|
||||
<ulink url="bridge.html">check here for details</ulink>.</para>
|
||||
</section>
|
||||
|
||||
<section id="faq39">
|
||||
<title>(FAQ 39) How do I block connections to a particular domain
|
||||
name?</title>
|
||||
|
||||
<para>I tried this rule to block Google's Adsense that you'll find on
|
||||
everyone's site. Adsense is a Javascript that people add to their Web
|
||||
pages. So I entered the rule:</para>
|
||||
|
||||
<programlisting>#ACTION SOURCE DEST PROTO
|
||||
REJECT fw net:pagead2.googlesyndication.com all</programlisting>
|
||||
|
||||
<para>However, this also sometimes restricts access to "google.com". Why
|
||||
is that? Using dig, I found these IPs for domain
|
||||
googlesyndication.com:<programlisting>216.239.37.99
|
||||
216.239.39.99</programlisting>And this for google.com:<programlisting>216.239.37.99
|
||||
216.239.39.99
|
||||
216.239.57.99</programlisting>So my guess is that you are not actually
|
||||
blocking the domain, but rather the IP being called. So how in the world
|
||||
do you block an actual domain name?</para>
|
||||
|
||||
<para><emphasis role="bold">Answer:</emphasis> Packet filters like
|
||||
Netfilter base their decisions on the contents of the various protocol
|
||||
headers at the front of each packet. Stateful packet filters (of which
|
||||
Netfilter is an example) use a combination of header contents and state
|
||||
created when the packet filter processed earlier packets. Netfilter (and
|
||||
Shorewall's use of netfilter) also consider the network interface(s)
|
||||
where each packet entered and/or where the packet will leave the
|
||||
firewall/router.</para>
|
||||
|
||||
<para>When you specify <ulink
|
||||
url="configuration_file_basics.htm#dnsnames">a domain name in a
|
||||
Shorewall rule</ulink>, the iptables program resolves that name to one
|
||||
or more IP addresses and the actual netfilter rules that are created are
|
||||
expressed in terms of those IP addresses. So the rule that you entered
|
||||
was equivalent to:</para>
|
||||
|
||||
<para><programlisting>#ACTION SOURCE DEST PROTO
|
||||
REJECT fw net:216.239.37.99 all
|
||||
REJECT fw net:216.239.39.99 all</programlisting>Given that
|
||||
name-based multiple hosting is a common practice (another example:
|
||||
lists.shorewall.net and www1.shorewall.net are both hosted on the same
|
||||
system with a single IP address), it is not possible to filter
|
||||
connections to a particular name by examiniation of protocol headers
|
||||
alone. While some protocols such as <ulink url="FTP.html">FTP</ulink>
|
||||
require the firewall to examine and possibly modify packet payload,
|
||||
parsing the payload of individual packets doesn't always work because
|
||||
the application-level data stream can be split across packets in
|
||||
arbitrary ways. This is one of the weaknesses of the 'string match'
|
||||
Netfilter extension available in Patch-O-Matic. The only sure way to
|
||||
filter on packet content is to proxy the connections in question -- in
|
||||
the case of HTTP, this means running something like <ulink
|
||||
url="Shorewall_Squid_Usage.html">Squid</ulink>. Proxying allows the
|
||||
proxy process to assemble complete application-level messages which can
|
||||
then be accurately parsed and decisions can be made based on the
|
||||
result.</para>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<appendix>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory>
|
||||
<revision>
|
||||
<revnumber>1.33</revnumber>
|
||||
|
||||
<date>2004-10-01</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Add FAQ 39.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.32</revnumber>
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-08-25</pubdate>
|
||||
<pubdate>2004-10-01</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2004</year>
|
||||
@ -37,7 +37,9 @@
|
||||
<warning>
|
||||
<para>To use this support, your kernel and iptables must include the
|
||||
Netfilter+ipsec patches and policy match support and you must be running
|
||||
Shorewall 2.1.5 or later.</para>
|
||||
Shorewall 2.1.5 or later. The Netfilter patches are available from
|
||||
Netfilter Patch-O-Matic-NG and are also included in some commercial
|
||||
distributions (most notably <trademark>SuSE</trademark> 9.1).</para>
|
||||
</warning>
|
||||
|
||||
<warning>
|
||||
@ -266,6 +268,65 @@ vpn loc ACCEPT</programlisting>
|
||||
|
||||
<para>Once you have these entries in place, restart Shorewall (type
|
||||
shorewall restart); you are now ready to configure IPSEC.</para>
|
||||
|
||||
<para>For full encrypted connectivity in this configuration (between the
|
||||
subnets, between each subnet and the opposite gateway, and between the
|
||||
gateways), you will need six policies in
|
||||
<filename>/etc/racoon/setkey.conf</filename>. For example, on gateway
|
||||
A:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting># First of all flush the SPD database
|
||||
spdflush;
|
||||
|
||||
# Add some SPD rules
|
||||
|
||||
spdadd 192.168.1.0/24 10.0.0.0/8 any -P out ipsec esp/tunnel/206.161.148.9-134.28.54.2/require;
|
||||
spdadd 192.168.1.0/24 134.28.54.2/32 any -P out ipsec esp/tunnel/206.161.148.9-134.28.54.2/require;
|
||||
spdadd 206.161.148.9/32 134.28.54.2/32 any -P out ipsec esp/tunnel/206.161.148.9-134.28.54.2/require;
|
||||
spdadd 10.0.0.0/8 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.161.148.9/require;
|
||||
spdadd 10.0.0.0/8 206.161.148.9/32 any -P in ipsec esp/tunnel/134.28.54.2-206.161.148.9/require;
|
||||
spdadd 134.28.54.2/32 192.168.1.0/24 any -P in ipsec esp/tunnel/134.28.54.2-206.161.148.9/require;</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>The <filename>setkey.conf</filename> file on gateway B would be
|
||||
similar.</para>
|
||||
|
||||
<para>A sample <filename>/etc/racoon/racoon.conf</filename> file using
|
||||
pre-shared keys might look like:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>path pre_shared_key "/etc/racoon/psk.txt" ;
|
||||
|
||||
remote anonymous
|
||||
{
|
||||
exchange_mode main ;
|
||||
my_identifier address ;
|
||||
lifetime time 24 hour ;
|
||||
proposal {
|
||||
encryption_algorithm 3des;
|
||||
hash_algorithm sha1;
|
||||
authentication_method pre_shared_key ;
|
||||
dh_group 2 ;
|
||||
}
|
||||
}
|
||||
|
||||
sainfo anonymous
|
||||
{
|
||||
pfs_group 2;
|
||||
lifetime time 12 hour ;
|
||||
encryption_algorithm 3des, blowfish, des, rijndael ;
|
||||
authentication_algorithm hmac_sha1, hmac_md5 ;
|
||||
compression_algorithm deflate ;
|
||||
}</programlisting>
|
||||
</blockquote>
|
||||
|
||||
<para>The <filename>/etc/racoon/psk.txt file</filename> on gateway
|
||||
A:</para>
|
||||
|
||||
<blockquote>
|
||||
<programlisting>134.28.54.2 <the key></programlisting>
|
||||
</blockquote>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@ -444,4 +505,4 @@ all all REJECT info
|
||||
occur, NONE policies are used.</para>
|
||||
</blockquote>
|
||||
</section>
|
||||
</article>
|
||||
</article>
|
||||
@ -13,7 +13,7 @@
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<pubdate>2004-09-21</pubdate>
|
||||
<pubdate>2004-10-01</pubdate>
|
||||
|
||||
<copyright>
|
||||
<year>2001-2002</year>
|
||||
@ -203,6 +203,13 @@ ACCEPT <emphasis><source></emphasis> <emphasis><destination></e
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> tcp 37</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>rsync</title>
|
||||
|
||||
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
|
||||
ACCEPT <emphasis><source></emphasis> <emphasis><destination></emphasis> tcp 873</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>SSH</title>
|
||||
|
||||
@ -357,6 +364,16 @@ ACCEPT <<emphasis>apps</emphasis>> <<emphasis>chooser</emphasis>
|
||||
<title>Revision History</title>
|
||||
|
||||
<para><revhistory>
|
||||
<revision>
|
||||
<revnumber>1.14</revnumber>
|
||||
|
||||
<date>2004-10-01</date>
|
||||
|
||||
<authorinitials>TE</authorinitials>
|
||||
|
||||
<revremark>Add rsync.</revremark>
|
||||
</revision>
|
||||
|
||||
<revision>
|
||||
<revnumber>1.13</revnumber>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user