extern/shorewall_code
1
0
Fork 1
mirror of https://gitlab.com/shorewall/code.git synced 2024-11-22 07:33:43 +01:00
Code Issues Packages Projects Releases Wiki Activity

Documentation Updates

Browse Source 
git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@1657 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
teastep 2004-10-02 14:49:34 +00:00
parent af41248619
commit bf85e3475b
3 changed files with 150 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
Shorewall-docs2/FAQ.xml
View File

@ -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>

67
Shorewall-docs2/IPSEC-2.6.xml
View File

@ -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 &lt;the key&gt;</programlisting>
</blockquote>
</section>
<section>
@ -444,4 +505,4 @@ all all REJECT info
occur, NONE policies are used.</para>
</blockquote>
</section>
</article>
</article>

19
Shorewall-docs2/ports.xml
View File

@ -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>&lt;source&gt;</emphasis> <emphasis>&lt;destination&gt;</e
ACCEPT <emphasis>&lt;source&gt;</emphasis> <emphasis>&lt;destination&gt;</emphasis> tcp 37</programlisting>
</section>
<section>
<title>rsync</title>
<programlisting>#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <emphasis>&lt;source&gt;</emphasis> <emphasis>&lt;destination&gt;</emphasis> tcp 873</programlisting>
</section>
<section>
<title>SSH</title>
@ -357,6 +364,16 @@ ACCEPT &lt;<emphasis>apps</emphasis>&gt; &lt;<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>