mirror of
https://github.com/Zeckmathederg/glfs.git
synced 2025-02-01 04:52:12 +08:00
a4040c12c8
git-svn-id: svn://svn.linuxfromscratch.org/BLFS/trunk/BOOK@3703 af4574ff-66df-0310-9fd7-8a98e5e911e0
536 lines
22 KiB
XML
536 lines
22 KiB
XML
<?xml version="1.0" encoding="ISO-8859-1"?>
|
||
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
|
||
<!ENTITY % general-entities SYSTEM "../../general.ent">
|
||
%general-entities;
|
||
]>
|
||
|
||
<sect1 id="fw-firewall" xreflabel="Firewalling">
|
||
<sect1info>
|
||
<othername>$LastChangedBy$</othername>
|
||
<date>$Date$</date>
|
||
</sect1info>
|
||
<?dbhtml filename="firewall.html"?>
|
||
<title>Setting up a network firewall</title>
|
||
|
||
<para>Before you read this part of the chapter, you should
|
||
have already installed iptables as described in the previous section.</para>
|
||
|
||
<sect2 id="fw-intro" xreflabel="Firewalling Introduction">
|
||
<title>Introduction to Firewall Creation</title>
|
||
|
||
<para>The general purpose of a firewall is to protect a computer or a network
|
||
against malicious access.</para>
|
||
|
||
<para>In a perfect world, every daemon or service
|
||
on every machine is perfectly configured and immune to flaws such as
|
||
buffer overflows or other problems regarding its
|
||
security. Furthermore, you trust every user accessing your services.
|
||
In this world, you do not need to have a firewall.</para>
|
||
|
||
<para>In the real world however, daemons may be misconfigured
|
||
and exploits against essential services are freely available. You
|
||
may wish to choose which services are accessible by certain machines or
|
||
you may wish to limit which machines or applications are allowed external
|
||
access. Alternatively, you may simply not trust some of your
|
||
applications or users. You are probably connected to the Internet. In this
|
||
world, a firewall is essential.</para>
|
||
|
||
<para>Don't assume however, that having a firewall makes careful configuration
|
||
redundant, or that it makes any negligent misconfiguration harmless. It doesn't
|
||
prevent anyone from exploiting a service you intentionally offer but haven't
|
||
recently updated or patched after an exploit went public. Despite having a
|
||
firewall, you need to keep applications and daemons on your system properly
|
||
configured and up to date. A firewall is not a cure all, but should be an
|
||
essential part of your overall security startegy.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2>
|
||
<title>Meaning of the word "firewall"</title>
|
||
|
||
<para>The word firewall can have several different meanings.</para>
|
||
|
||
<sect3><title><xref linkend="fw-persFw"/></title>
|
||
|
||
<para>This is a hardware device or software program commercially sold by
|
||
companies such as Symantec which claims that it
|
||
secures a home or desktop computer with Internet access. This type of firewall is
|
||
highly relevant for users who do not know how their computers
|
||
might be accessed via the Internet or how to disable that access,
|
||
especially if they are always online and connected via
|
||
broadband links.</para></sect3>
|
||
|
||
<sect3>
|
||
<title><xref linkend="fw-masqRouter"/></title>
|
||
|
||
<para>This is a system placed between the Internet and an intranet. To minimize
|
||
the risk of compromising the firewall itself, it should generally have only one
|
||
role—that of protecting the intranet. Although not completely risk free,
|
||
the tasks of doing the routing and IP masquerading (rewriting IP headers of
|
||
the packets it routes from clients with private IP addresses onto the Internet
|
||
so that they seem to come from the firewall itself) are commonly considered
|
||
relatively secure.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title><xref linkend="fw-busybox"/></title>
|
||
|
||
<para>This is often an old computer you may have retired and nearly forgotten,
|
||
performing masquerading or routing functions, but offering non-firewall
|
||
services such as a web-cache or mail. This may be used for home
|
||
networks, but is not be considered as secure as a firewall only
|
||
machine because the combination of server and router/firewall on one machine
|
||
raises the complexity of the setup.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Firewall with a demilitarized zone [not further described here]</title>
|
||
<para>This box performs masquerading or routing, but grants public access to
|
||
some branch of your network which, because of public IP's and a physically
|
||
separated structure, is essentially a separate network with direct Internet access.
|
||
The servers on this network are those which must be easily accessible
|
||
from both the Internet and intranet. The firewall protects
|
||
both networks. This type of firewall has a minimum of three network interfaces.</para>
|
||
</sect3>
|
||
|
||
<sect3>
|
||
<title>Packetfilter</title>
|
||
<para>This type of firewall does routing or masquerading, but does not maintain
|
||
a state table of ongoing communication streams. It is fast, but quite limited
|
||
in its ability to block inappropriate packets without blocking desired
|
||
packets.</para>
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2 id="fw-writing" xreflabel="writing the firewalling-setup-scripts">
|
||
<title>Now you can start to build your Firewall</title>
|
||
|
||
<caution><para>This introduction on how to setup a firewall
|
||
is not a complete guide to securing systems. Firewalling is a complex issue
|
||
that requires careful configuration. The scripts quoted here are simply
|
||
intended to give examples of how a firewall works. They are not intended to
|
||
fit into any particular configuration and may not provide complete protection
|
||
from an attack.</para>
|
||
|
||
<para>Customization of these scripts for your specific situation will
|
||
be necessary for an optimal configuration, but you should make a serious
|
||
study of the iptables documentation and creating firewalls in general before
|
||
hacking away. Have a look at the list of
|
||
<xref linkend="fw-library"/> at the end of this section for
|
||
more details. There you will find a list of URLs that contain quite
|
||
comprehensive information about building your own firewall.</para>
|
||
</caution>
|
||
|
||
<para>The firewall configuration script installed in the last section differs
|
||
from the standard configuration script. It only has two of the standard
|
||
targets: start and status. The other targets are clear and lock. For instance when you
|
||
run:
|
||
|
||
<screen><userinput><command>/etc/rc.d/init.d/iptables start</command></userinput></screen>
|
||
|
||
the firewall will be restarted just as it is upon system startup. The status target
|
||
will present a list of all currently implemented rules. The clear target turns off all
|
||
firewall rules and the lock target will block all packets in and out of the computer
|
||
with the exception of the loopback interface.</para>
|
||
|
||
<para>The main startup firewall is located in the file
|
||
<filename>/etc/rc.d/rc.iptables</filename>. The sections below provide three different
|
||
approaches that can be used for a system.</para>
|
||
|
||
<note><para>You should always run your firewall rules from a script. This ensures
|
||
consistency and a record of what was done. It also allows retention of comments
|
||
that are essential for understanding the rules long after they were written.
|
||
</para></note>
|
||
|
||
<sect3 id="fw-persFw" xreflabel="Personal Firewall">
|
||
<title>Personal Firewall</title>
|
||
|
||
<para>A Personal Firewall is designed to let you access all the services
|
||
offered on the Internet, but keep your box secure and your data private.</para>
|
||
|
||
<para>Below is a slightly modified version of Rusty Russell's recommendation
|
||
from the
|
||
<ulink url="http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html">
|
||
Linux 2.4 Packet Filtering HOWTO</ulink>. It is still applicable to the Linux 2.6 kernels.</para>
|
||
|
||
<screen><userinput><command>cat > /etc/rc.d/rc.iptables << "EOF"</command>
|
||
#!/bin/sh
|
||
|
||
# Begin $rc_base/rc.iptables
|
||
|
||
# Insert connection-tracking modules
|
||
# (not needed if built into the kernel)
|
||
modprobe ip_tables
|
||
modprobe iptable_filter
|
||
modprobe ip_conntrack
|
||
modprobe ip_conntrack_ftp
|
||
modprobe ipt_state
|
||
modprobe ipt_LOG
|
||
|
||
# Enable broadcast echo Protection
|
||
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
|
||
|
||
# Disable Source Routed Packets
|
||
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
|
||
|
||
# Enable TCP SYN Cookie Protection
|
||
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
|
||
|
||
# Disable ICMP Redirect Acceptance
|
||
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
|
||
|
||
# Don<6F>t send Redirect Messages
|
||
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
|
||
|
||
# Drop Spoofed Packets coming in on an interface, where responses
|
||
# would result in the reply going out a different interface.
|
||
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
|
||
|
||
# Log packets with impossible addresses.
|
||
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
|
||
|
||
# be verbose on dynamic ip-addresses (not needed in case of static IP)
|
||
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
|
||
|
||
# disable Explicit Congestion Notification
|
||
# too many routers are still ignorant
|
||
echo 0 > /proc/sys/net/ipv4/tcp_ecn
|
||
|
||
# Set a known state
|
||
iptables -P INPUT DROP
|
||
iptables -P FORWARD DROP
|
||
iptables -P OUTPUT DROP
|
||
|
||
# These lines are here in case rules are already in place and the
|
||
# script is ever rerun on the fly. We want to remove all rules and
|
||
# pre-exisiting user defined chains before we implement new rules.
|
||
iptables -F
|
||
iptables -X
|
||
iptables -Z
|
||
|
||
iptables -t nat -F
|
||
|
||
# Allow local-only connections
|
||
iptables -A INPUT -i lo -j ACCEPT
|
||
|
||
# Free output on any interface to any ip for any service
|
||
# (equal to -P ACCEPT)
|
||
iptables -A OUTPUT -j ACCEPT
|
||
|
||
# Permit answers on already established connections
|
||
# and permit new connections related to established ones
|
||
# (e.g. port mode ftp)
|
||
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||
|
||
# Log everything else. What's Windows' latest exploitable vulnerability?
|
||
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "
|
||
|
||
# End $rc_base/rc.iptables
|
||
<command>EOF</command></userinput></screen>
|
||
|
||
<para>This script is quite simple, it drops all traffic coming in into your
|
||
computer that wasn't initiated from your box, but as long as you are simply
|
||
surfing the Internet you are unlikely to exceed its limits.</para>
|
||
|
||
<para>If you frequently encounter certain delays at accessing ftp-servers,
|
||
take a look at <xref linkend="fw-BB-4"/>.</para>
|
||
|
||
<para>Even if you have daemons or services running on your system, these
|
||
will be inaccessible everywhere but from your computer itself.
|
||
If you want to allow access to services on your machine, such as ssh or
|
||
ping, take a look at <xref linkend="fw-busybox"/>.</para>
|
||
|
||
</sect3>
|
||
|
||
<sect3 id="fw-masqRouter" xreflabel="Masquerading Router">
|
||
<title>Masquerading Router</title>
|
||
|
||
<para>A true Firewall has two interfaces, one connected to an intranet, in this
|
||
example <emphasis role="strong">eth0</emphasis>, and one connected to the
|
||
Internet, here <emphasis role="strong">ppp0</emphasis>. To provide the
|
||
maximum security for the firewall itself, make sure that there
|
||
are no unnecessary servers running on it such as <application>X11</application> et
|
||
al. As a general principle, the firewall itself should not access any
|
||
untrusted service (Think of a remote server giving answers that makes a daemon on
|
||
your system
|
||
crash, or, even worse, that implements a worm via a buffer-overflow).</para>
|
||
|
||
<screen><userinput><command>cat > /etc/rc.d/rc.iptables << "EOF"</command>
|
||
#!/bin/sh
|
||
|
||
# Begin $rc_base/rc.iptables
|
||
|
||
echo
|
||
echo "You're using the example configuration for a setup of a firewall"
|
||
echo "from Beyond Linux From Scratch."
|
||
echo "This example is far from being complete, it is only meant"
|
||
echo "to be a reference."
|
||
echo "Firewall security is a complex issue, that exceeds the scope"
|
||
echo "of the configuration rules below."
|
||
echo "You can find additional information"
|
||
echo "about firewalls in Chapter 4 of the BLFS book."
|
||
echo "http://www.linuxfromscratch.org/blfs"
|
||
echo
|
||
|
||
# Insert iptables modules (not needed if built into the kernel).
|
||
|
||
modprobe ip_tables
|
||
modprobe iptable_filter
|
||
modprobe ip_conntrack
|
||
modprobe ip_conntrack_ftp
|
||
modprobe ipt_state
|
||
modprobe iptable_nat
|
||
modprobe ip_nat_ftp
|
||
modprobe ipt_MASQUERADE
|
||
modprobe ipt_LOG
|
||
modprobe ipt_REJECT
|
||
|
||
# Enable broadcast echo Protection
|
||
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
|
||
|
||
# Disable Source Routed Packets
|
||
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route
|
||
|
||
# Enable TCP SYN Cookie Protection
|
||
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
|
||
|
||
# Disable ICMP Redirect Acceptance
|
||
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
|
||
|
||
# Don<6F>t send Redirect Messages
|
||
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
|
||
|
||
# Drop Spoofed Packets coming in on an interface where responses
|
||
# would result in the reply going out a different interface.
|
||
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
|
||
|
||
# Log packets with impossible addresses.
|
||
echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
|
||
|
||
# Be verbose on dynamic ip-addresses (not needed in case of static IP)
|
||
echo 2 > /proc/sys/net/ipv4/ip_dynaddr
|
||
|
||
# Disable Explicit Congestion Notification
|
||
# Too many routers are still ignorant
|
||
echo 0 > /proc/sys/net/ipv4/tcp_ecn
|
||
|
||
# Set a known state
|
||
iptables -P INPUT DROP
|
||
iptables -P FORWARD DROP
|
||
iptables -P OUTPUT DROP
|
||
|
||
# These lines are here in case rules are already in place and the
|
||
# script is ever rerun on the fly. We want to remove all rules and
|
||
# pre-exisiting user defined chains before we implement new rules.
|
||
iptables -F
|
||
iptables -X
|
||
iptables -Z
|
||
|
||
iptables -t nat -F
|
||
|
||
# Allow local connections
|
||
iptables -A INPUT -i lo -j ACCEPT
|
||
iptables -A OUTPUT -o lo -j ACCEPT
|
||
|
||
# Allow forwarding if the initiated on the intranet
|
||
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||
iptables -A FORWARD -i ! ppp+ -m state --state NEW -j ACCEPT
|
||
|
||
# Do masquerading
|
||
# (not needed if intranet is not using private ip-addresses)
|
||
iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE
|
||
|
||
# Log everything for debugging
|
||
# (last of all rules, but before policy rules)
|
||
iptables -A INPUT -j LOG --log-prefix "FIREWALL:INPUT "
|
||
iptables -A FORWARD -j LOG --log-prefix "FIREWALL:FORWARD"
|
||
iptables -A OUTPUT -j LOG --log-prefix "FIREWALL:OUTPUT "
|
||
|
||
# Enable IP Forwarding
|
||
echo 1 > /proc/sys/net/ipv4/ip_forward
|
||
<command>EOF</command></userinput></screen>
|
||
|
||
<para>With this script your intranet should be reasonably secure against
|
||
external attacks. No one should be able to setup a new connection to any
|
||
internal service and, if it's masqueraded, makes your intranet invisible to the
|
||
Internet. Furthermore, your firewall should be relatively safe because there
|
||
are no services running that a cracker could attack.</para>
|
||
|
||
<note><para>If the interface you're connecting to the Internet doesn't connect
|
||
via ppp, you will need to change <replaceable>ppp+</replaceable> to the name of
|
||
the interface, e.g. <emphasis role="strong">eth1</emphasis>, which you are using.
|
||
</para></note>
|
||
|
||
</sect3>
|
||
|
||
<sect3 id="fw-busybox" xreflabel="BusyBox">
|
||
<title>BusyBox</title>
|
||
|
||
<para>This scenario isn't too different from the <xref linkend="fw-masqRouter"/>,
|
||
but additionally offers some services to your intranet.
|
||
Examples of this can be when you want to administer your firewall from another host
|
||
on your intranet or use it as a proxy or a name server.</para>
|
||
|
||
<note><para>Outlining a true concept of how to protect a server that offers
|
||
services on the Internet goes far beyond the scope of this document. See the references
|
||
at the end of this section for more information.</para></note>
|
||
|
||
<para>Be cautious. Every service you have enabled makes your
|
||
setup more complex and your firewall less secure. You are exposed to the risks of
|
||
misconfigured services or running a service with an exploitable bug. A
|
||
firewall should generally not run any extra services. See the introduction to
|
||
the <xref linkend="fw-masqRouter"/> for some more details.</para>
|
||
|
||
<para>If you want to add services such as internal samba or name servers that do not
|
||
need to access the Internet themselves, the additional statements are quite
|
||
simple and should still be acceptable from a security standpoint.
|
||
Just add the following lines
|
||
into the script <emphasis>before</emphasis> the logging rules.</para>
|
||
|
||
<screen>iptables -A INPUT -i ! ppp+ -j ACCEPT
|
||
iptables -A OUTPUT -o ! ppp+ -j ACCEPT</screen>
|
||
|
||
<para>If daemons, such as squid, have to access the Internet themselves,
|
||
you could open OUTPUT generally and restrict INPUT.</para>
|
||
|
||
<screen>iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|
||
iptables -A OUTPUT -j ACCEPT</screen>
|
||
|
||
<para>However, it is generally not advisable to leave OUTPUT unrestricted. You
|
||
lose any control over trojans who would like to "call home", and a bit of
|
||
redundancy in case you've (mis-)configured a service so that it broadcasts
|
||
its existence to the world.</para>
|
||
|
||
<para>To accomplish this, you should restrict INPUT and OUTPUT
|
||
on all ports except those that it's absolutely necessary to have open.
|
||
Which ports you have to open depends on your needs: mostly you will find them
|
||
by looking for failed accesses in your log files.</para>
|
||
<itemizedlist spacing="compact" role='iptables'>
|
||
|
||
<title>Have a look at the following examples:</title>
|
||
|
||
<listitem><para>Squid is caching the web:</para>
|
||
<screen>iptables -A OUTPUT -p tcp --dport 80 -j ACCEPT
|
||
iptables -A INPUT -p tcp --sport 80 -m state --state ESTABLISHED \
|
||
-j ACCEPT</screen>
|
||
</listitem>
|
||
|
||
<listitem><para>Your caching name server (e.g., named) does its
|
||
lookups via udp:</para>
|
||
<screen>iptables -A OUTPUT -p udp --dport 53 -j ACCEPT</screen>
|
||
</listitem>
|
||
|
||
<listitem><para>You want to be able to ping your box to
|
||
ensure it's still alive:</para>
|
||
|
||
<screen>iptables -A INPUT -p icmp -m icmp --icmp-type echo-request -j ACCEPT
|
||
iptables -A OUTPUT -p icmp -m icmp --icmp-type echo-reply -j ACCEPT</screen>
|
||
</listitem>
|
||
|
||
<listitem><para><anchor id='fw-BB-4' xreflabel="BusyBox example number 4"/>If you are
|
||
frequently accessing ftp servers or enjoy chatting, you might notice certain
|
||
delays because some implementations of these daemons have the feature of
|
||
querying an identd on your system to obtain usernames. Although there's really
|
||
little harm in this, having an identd running is not recommended because many
|
||
security experts feel the service gives out too much additional information.</para>
|
||
|
||
<para>To avoid these delays you could reject the requests
|
||
with a 'tcp-reset':</para>
|
||
|
||
<screen>iptables -A INPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset</screen>
|
||
</listitem>
|
||
|
||
<listitem><para>To log and drop invalid packets (packets
|
||
that came in after netfilter's timeout or some types of network scans):</para>
|
||
|
||
<screen>iptables -I INPUT -p tcp -m state --state INVALID \
|
||
-j LOG --log-prefix "FIREWALL:INVALID"
|
||
iptables -I INPUT -p tcp -m state --state INVALID -j DROP</screen></listitem>
|
||
|
||
<listitem><para>Anything coming from the outside should not have a
|
||
private address, this is a common attack called IP-spoofing:
|
||
|
||
<screen>iptables -A INPUT -i ppp+ -s 10.0.0.0/8 -j DROP
|
||
iptables -A INPUT -i ppp+ -s 172.16.0.0/12 -j DROP
|
||
iptables -A INPUT -i ppp+ -s 192.168.0.0/16 -j DROP</screen>
|
||
|
||
There are other addresses that you may also want to drop: 0.0.0.0/8,
|
||
127.0.0.0/8, 224.0.0.0/3 (multicast and experimental), 169.254.0.0/16 (Link
|
||
Local Networks), and 192.0.2.0/24 (IANA defined test network).</para>
|
||
</listitem>
|
||
|
||
<listitem><para>If your firewall is a DHCP client, you need to allow
|
||
those packets:</para>
|
||
|
||
<screen>iptables -A INPUT -i ppp0 -p udp -s 0.0.0.0 --sport 67 \
|
||
-d 255.255.255.255 --dport 68 -j ACCEPT</screen>
|
||
</listitem>
|
||
|
||
<listitem><para>To simplify debugging and be fair to anyone who'd like to
|
||
access a service you have disabled, purposely or by mistake, you could REJECT
|
||
those packets that are dropped.</para>
|
||
|
||
<para>Obviously this must be done directly after logging as the very
|
||
last lines before the packets are dropped by policy:</para>
|
||
|
||
<screen>iptables -A INPUT -j REJECT</screen>
|
||
</listitem>
|
||
</itemizedlist>
|
||
|
||
<para>These are only examples to show you some of the capabilities of the
|
||
firewall code in Linux. Have a look at the man page of iptables.
|
||
There you will find much more information. The port numbers needed for this can be
|
||
found in <filename>/etc/services</filename>, in case you didn't find them by
|
||
trial and error in your log file.</para>
|
||
|
||
</sect3>
|
||
</sect2>
|
||
|
||
<sect2 id="fw-finale" xreflabel="Conclusion">
|
||
<title>Conclusion</title>
|
||
|
||
<para>Finally, there is one fact you must not forget: The effort spent
|
||
attacking a system corresponds to the value the cracker expects to gain from
|
||
it. If you are responsible for valuable information, you need to spend the
|
||
time to protect it properly.</para>
|
||
|
||
</sect2>
|
||
|
||
<sect2 id="postlfs-security-fw-extra" xreflabel="Extra Information">
|
||
<title>Extra Information</title>
|
||
|
||
<sect3 id="fw-library" xreflabel="Links for further reading">
|
||
<title>Where to start with further reading on firewalls.</title>
|
||
|
||
<para><blockquote><literallayout>
|
||
<ulink url="http://www.netfilter.org/">www.netfilter.org - Homepage of the netfilter/iptables project</ulink>
|
||
<ulink url="http://www.netfilter.org/documentation/FAQ/netfilter-faq.html">Netfilter related FAQ</ulink>
|
||
<ulink url="http://www.netfilter.org/documentation/index.html#HOWTO">Netfilter related HOWTO's</ulink>
|
||
<ulink url="http://en.tldp.org/LDP/nag2/x-087-2-firewall.html">en.tldp.org/LDP/nag2/x-087-2-firewall.html</ulink>
|
||
<ulink url="http://en.tldp.org/HOWTO/Security-HOWTO.html">en.tldp.org/HOWTO/Security-HOWTO.html</ulink>
|
||
<ulink url="http://en.tldp.org/HOWTO/Firewall-HOWTO.html">en.tldp.org/HOWTO/Firewall-HOWTO.html</ulink>
|
||
<ulink url="http://www-106.ibm.com/developerworks/security/library/s-fire.html">www.ibm.com/developerworks/security/library/s-fire.html</ulink>
|
||
<ulink url="http://www-106.ibm.com/developerworks/security/library/s-fire2.html">www.ibm.com/developerworks/security/library/s-fire2.html</ulink>
|
||
<ulink url="http://www.interhack.net/pubs/fw-faq/">www.interhack.net/pubs/fw-faq/</ulink>
|
||
<ulink url="http://www.linuxsecurity.com/docs/">www.linuxsecurity.com/docs/</ulink>
|
||
<ulink url="http://www.little-idiot.de/firewall">www.little-idiot.de/firewall (German & outdated, but very comprehensive)</ulink>
|
||
<ulink url="http://www.linuxgazette.com/issue65/stumpel.html">www.linuxgazette.com/issue65/stumpel.html</ulink>
|
||
<ulink url="http://linux.oreillynet.com/pub/a/linux/2000/03/10/netadmin/ddos.html">linux.oreillynet.com/pub/a/linux/2000/03/10/netadmin/ddos.html</ulink>
|
||
<ulink url="http://staff.washington.edu/dittrich/misc/ddos">staff.washington.edu/dittrich/misc/ddos</ulink>
|
||
<ulink url="http://www.e-infomax.com/ipmasq">www.e-infomax.com/ipmasq</ulink>
|
||
<ulink url="http://www.circlemud.org/~jelson/writings/security/index.htm">www.circlemud.org/~jelson/writings/security/index.htm</ulink>
|
||
<ulink url="http://www.securityfocus.com">www.securityfocus.com</ulink>
|
||
<ulink url="http://www.cert.org/tech_tips/">www.cert.org - tech_tips</ulink>
|
||
<ulink url="http://security.ittoolbox.com/">security.ittoolbox.com</ulink>
|
||
<ulink url="http://www.linux-firewall-tools.com/linux/">www.linux-firewall-tools.com/linux/</ulink>
|
||
<ulink url="http://logi.cc/linux/athome-firewall.php3">logi.cc/linux/athome-firewall.php3</ulink>
|
||
<ulink url="http://www.insecure.org/reading.html">www.insecure.org/reading.html</ulink>
|
||
<ulink url="http://www.robertgraham.com/pubs/firewall-seen.html">www.robertgraham.com/pubs/firewall-seen.html</ulink>
|
||
</literallayout></blockquote></para>
|
||
</sect3>
|
||
|
||
</sect2>
|
||
</sect1>
|
||
|