using a separate DNS server for local clients) such that
www.mydomain.com resolves to 130.141.100.69 externally and 192.168.1.5
internally. That's what I do here at shorewall.net for my local systems
-that use static NAT.
+that use one-to-one NAT.
If you insist on an IP solution to the accessibility
problem rather than a DNS solution, then assuming that your external
@@ -401,7 +411,7 @@ please upgrade to Shorewall 1.4.2 or later.
In /etc/shorewall/interfaces:
-
+
ZONE
@@ -507,7 +517,8 @@ DHCP/PPPoE client to automatically restart Shorewall each time that you
get a new IP address.
2a. I have a zone "Z" with an
-RFC1918 subnet and I use static NAT to assign non-RFC1918 addresses to
+RFC1918 subnet and I use one-to-one NAT to assign non-RFC1918 addresses
+to
hosts in Z. Hosts in Z cannot communicate with each other using their
external (non-RFC1918 addresses) so they can't access each other using
their DNS names.
@@ -521,7 +532,7 @@ solved using Bind Version 9 "views". It allows
both external and internal clients to access
a NATed host using the host's DNS name.
Another good way to approach this problem is to switch
-from static NAT to Proxy ARP. That way, the
+from one-to-one NAT to Proxy ARP. That way, the
hosts in Z have non-RFC1918 addresses and can
be accessed externally and internally using the same address.
If you don't like those solutions and prefer routing
@@ -984,9 +995,44 @@ cause of packets being logged in the FORWARD chain.
logflags - The packet is being logged because it failed
the checks implemented by the tcpflags interface option.
-
+ href="Documentation.htm#Interfaces">interface option.
+Here is an example:
+
+Jun 27 15:37:56 gateway kernel:
+Shorewall:all2all:REJECT:IN=eth2 OUT=eth1 SRC=192.168.2.2
+DST=192.168.1.3 LEN=67
+TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP
+SPT=1803 DPT=53 LEN=47
+
+Let's look at the important parts of this message:
+
+ - all2all:REJECT - This packet was REJECTed out of the all2all chain -- the packet
+was rejected under the "all"->"all"
+REJECT policy (number 3 above).
+ - IN=eth2 - the packet entered the firewall via eth2. If you see
+"IN=" with no interface name, the packet originated on the firewall
+itself.
+
+ - OUT=eth1 - if accepted, the packet would be sent on eth1. If you
+see "OUT=" with no interface name, the packet would be processed by the
+firewall itself.
+
+ - SRC=192.168.2.2 - the packet was sent by 192.168.2.2
+ - DST=192.168.1.3 - the packet is destined for 192.168.1.3
+ - PROTO=UDP - UDP Protocol
+ - DPT=53 - The destination port is 53 (DNS)
+
+
+In this case, 192.168.2.2 was in the "dmz" zone and
+192.168.1.3 is in the "loc" zone. I was missing the rule:
+ ACCEPT dmz
+loc udp 53
18. Is there any way to use aliased ip
addresses with Shorewall, and maintain separate rulesets for
different IPs?
@@ -1079,13 +1125,22 @@ Shorewall I am running?
At the shell prompt, type:
/sbin/shorewall
-version
+version
+
26. When I try to use any of the SYN
options in nmap on or behind the firewall, I get "operation not
permitted".
How can I use nmap with Shorewall?"
Edit /etc/shorewall/shorewall.conf and change "NEWNOTSYN=No" to
"NEWNOTSYN=Yes" then restart Shorewall.
+
+26a.
+When I try to use the "-O"
+option of nmap from the firewall system, I get "operation not permitted". How to I
+allow this option?
+Add this command to your /etc/shorewall/start file:
+run_iptables -D OUTPUT -p ! icmp -m state --state INVALID -j DROP
@@ -1118,8 +1173,208 @@ to allow connections from the internet to your local network. In all
other cases, you use ACCEPT unless you need to hijack connections as
they go through your firewall and handle them on the firewall box
itself; in that case, you use a REDIRECT rule.
+31. Does Shorewall provide protection
+against....
+
+ - IP Spoofing: Sending packets over the WAN interface using an
+internal LAP IP address as the source address? Answer: Yes.
+ - Tear Drop: Sending packets that contain overlapping fragments? Answer: This is the responsibility
+of the IP stack, not the Netfilter-based firewall since fragment
+reassembly occurs before the stateful packet filter ever touches each
+packet.
+ - Smurf and Fraggle: Sending packets that use the WAN or LAN
+broadcast address as the source address? Answer: Shorewall can be configured
+to do that using the blacklisting
+facility.
+ - Land Attack: Sending packets that use the same address as the
+source and destination address? Answer:
+ Yes, if the routefilter
+interface option is selected.
+ - DOS:
+ - SYN Dos
+ - ICMP Dos
+ - Per-host Dos protection
+ Answer: Shorewall has
+facilities for limiting SYN and ICMP packets. Netfilter as included in
+standard Linux kernels doesn't support per-remote-host limiting except
+by explicit rule that specifies the host IP address; that form of
+limiting is supported by Shorewall.
+
+32. My
+firewall has two connections to the internet from two different ISPs.
+How do I set this up in Shorewall?
+Setting this up in Shorewall is easy; setting up the routing is a bit
+harder.
-Last updated 10/04/2003 - Tom
+Assuming that eth0 and eth1 are the interfaces to the two ISPs then:
+
+/etc/shorewall/interfaces:
+
+
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ net
+ |
+ eth0 |
+ detect
+ |
+ ...
+ |
+
+
+ net
+ |
+ eth1
+ |
+ detect
+ |
+ ...
+ |
+
+
+
+
+/etc/shorewall/policy:
+
+
+
+
+ | SOURCE |
+ DESTINATION |
+ POLICY |
+ LIMIT:BURST |
+
+
+ net
+ |
+ net
+ |
+ DROP
+ |
+
+ |
+
+
+
+
+
The following information
+regarding setting up routing for this
+configuration is reproduced from the LARTC
+HOWTO and has not been verified by the author. If you have
+questions or problems with the instructions given below, please post to
+the LARTC mailing list.
+
A common configuration is the
+following, in which there are two providers
+that connect a local network (or even a single machine) to the big
+Internet.
+ ________
+------------+ /
| | |
+-------------+ Provider 1 +-------
__ | | | /
___/ \_ +------+-------+ +------------+ |
_/ \__ | if1 | /
/ \ | | |
| Local network -----+ Linux router | | Internet
\_ __/ | | |
\__ __/ | if2 | \
\___/ +------+-------+ +------------+ |
| | | \
+-------------+ Provider 2 +-------
| | |
+------------+ \________
+There are usually two questions given this setup.
+
+ Split access
+ The first is how to route answers to packets coming in over a
+particular provider, say Provider 1, back out again over that same
+provider.
+ Let us first set some symbolical names. Let $IF1
+be the name of the first interface (if1 in the picture above) and $IF2 the name of the second interface. Then let $IP1 be the IP address associated with $IF1 and $IP2 the IP
+address associated with $IF2. Next, let $P1 be the IP address of the gateway at Provider
+1, and $P2 the IP address of the gateway at
+provider 2. Finally, let $P1_NET be the IP
+network $P1 is in, and $P2_NET
+the IP network $P2 is in.
+ One creates two additional routing tables, say T1
+and T2. These are added in
+/etc/iproute2/rt_tables. Then you set up routing in these tables as
+follows:
+
+ ip route add $P1_NET dev $IF1 src $IP1 table T1
ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
+Nothing spectacular, just build a route to the gateway and build a
+default route via that gateway, as you would do in the case of a single
+upstream provider, but put the routes in a separate table per provider.
+Note that the network route suffices, as it tells you how to find any
+host in that network, which includes the gateway, as specified above.
+ Next you set up the main routing table. It is a good idea to route
+things to the direct neighbour through the interface connected to that
+neighbour. Note the `src' arguments, they make sure the right outgoing
+IP address is chosen.
+ ip route add $P1_NET dev $IF1 src $IP1
ip route add $P2_NET dev $IF2 src $IP2
+Then, your preference for default route:
+ ip route add default via $P1
+Next, you set up the routing rules. These actually choose what routing
+table to route with. You want to make sure that you route out a given
+interface if you already have the corresponding source address:
+ ip rule add from $IP1 table T1
ip rule add from $IP2 table T2
+This set of commands makes sure all answers to traffic coming in on a
+particular interface get answered from that interface.
+
+
+
+
+
+  |
+
+ Reader Rod Roark notes: 'If $P0_NET is the local network and
+$IF0 is its interface,
+the following additional entries are desirable:
+ ip route add $P0_NET dev $IF0 table T1
ip route add $P2_NET dev $IF2 table T1
ip route add 127.0.0.0/8 dev lo table T1
ip route add $P0_NET dev $IF0 table T2
ip route add $P1_NET dev $IF1 table T2
ip route add 127.0.0.0/8 dev lo table T2
+' |
+
+
+
+
+ Now, this is just the very basic setup. It will work for all
+processes running on the router itself, and for the local network, if
+it is masqueraded. If it is not, then you either have IP space from
+both providers or you are going to want to masquerade to one of the two
+providers. In both cases you will want to add rules selecting which
+provider to route out from based on the IP address of the machine in
+the local network.
+
+ Load balancing
+ The second question is how to balance traffic going out over the
+two providers. This is actually not hard if you already have set up
+split access as above.
+ Instead of choosing one of the two providers as your default route,
+you now set up the default route to be a multipath route. In the
+default kernel this will balance routes over the two providers. It is
+done as follows (once more building on the example in the section on
+split-access):
+ ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
nexthop via $P2 dev $IF2 weight 1
+This will balance the routes over both providers. The weight parameters can be tweaked to favor one
+provider over the other.
+ Note that balancing will not be perfect, as it is route based, and
+routes are cached. This means that routes to often-used sites will
+always be over the same provider.
+ Furthermore, if you really want to do this, you probably also want
+to look at Julian Anastasov's patches at http://www.ssi.bg/~ja/#routes
+, Julian's route patch page. They will make things nicer to work
+with.
+
End of information reproduced
+from the LARTC HOWTO. If you have
+questions or problems with the instructions given above, please post to
+the LARTC mailing list.
+
Last updated
+11/20/2003 - Tom
Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/FTP.html b/Shorewall-docs/FTP.html
index b9311431e..f1291a564 100644
--- a/Shorewall-docs/FTP.html
+++ b/Shorewall-docs/FTP.html
@@ -8,19 +8,37 @@
-
-
-
-
- Shorewall and FTP
- |
-
-
-
+Shorewall and FTP
+
+
+NOTICE: If you are running
+Mandrake 9.1 or 9.2 and are having problems with FTP, you have three
+choices:
+
+ - Edit /usr/share/shorewall/firewall and replace this line:
+
+ for suffix in o gz ko ; do
+
+with
+
+ for suffix in o gz ko o.gz ; do
+
+ and at a root shell prompt:
+
+ shorewall
+restart
+
+
+ - Install the Mandrake "cooker" version of Shorewall.
+
+
+ - Upgrade to Shorewall 1.4.7 or later.
+
+
+
FTP transfers involve two TCP connections. The first control
connection goes from the FTP client to port 21 on the FTP server. This
connection is used for logon and to send commands and responses between
@@ -30,7 +48,8 @@ connection is dependent on the mode
that the client is operating in:
- - Passive Mode (default for web browsers) -- The client issues a
+
- Passive Mode (often the default for web browsers) -- The client
+issues a
PASV command. Upon receipt of this command, the server listens on a
dynamically-allocated port then sends a PASV reply to the client. The
PASV reply gives the IP address
@@ -91,13 +110,17 @@ that the
modules "ip_conntrack_ftp" and "ip_nat_ftp" need to be loaded.
Shorewall automatically
loads these "helper" modules from /lib/modules/<kernel-version>/kernel/net/ipv4/netfilter/
-and you can determine if they are loaded using the 'lsmod' command:
+and you can determine if they are loaded using the 'lsmod' command. The
+<kernel-version> may be
+obtained by typing
+ uname -r
+
+Example:
- Example:
-
- [root@lists etc]# lsmod
Module Size Used by Not tainted
autofs 12148 0 (autoclean) (unused)
ipt_TOS 1560 12 (autoclean)
ipt_LOG 4120 5 (autoclean)
ipt_REDIRECT 1304 1 (autoclean)
ipt_REJECT 3736 4 (autoclean)
ipt_state 1048 13 (autoclean)
ip_nat_irc 3152 0 (unused)
ip_nat_ftp 3888 0 (unused)
ip_conntrack_irc 3984 1
ip_conntrack_ftp 5008 1
ipt_multiport 1144 2 (autoclean)
ipt_conntrack 1592 0 (autoclean)
iptable_filter 2316 1 (autoclean)
iptable_mangle 2680 1 (autoclean)
iptable_nat 20568 3 (autoclean) [ipt_REDIRECT ip_nat_irc ip_nat_ftp]
ip_conntrack 26088 5 (autoclean) [ipt_REDIRECT ipt_state ip_nat_irc ip_nat_ftp ip_conntrack_irc ip_conntrack_ftp ipt_conntrack iptable_nat]
ip_tables 14488 12 [ipt_TOS ipt_LOG ipt_REDIRECT ipt_REJECT ipt_state ipt_multiport ipt_conntrack iptable_filter iptable_mangle iptable_nat]
tulip 42464 0 (unused)
e100 50596 1
keybdev 2752 0 (unused)
mousedev 5236 0 (unused)
hid 20868 0 (unused)
input 5632 0 [keybdev mousedev hid]
usb-uhci 24684 0 (unused)
usbcore 73280 1 [hid usb-uhci]
ext3 64704 2
jbd 47860 2 [ext3]
[root@lists etc]#
+ [root@lists etc]# lsmod
Module Size Used by Not tainted
autofs 12148 0 (autoclean) (unused)
ipt_TOS 1560 12 (autoclean)
ipt_LOG 4120 5 (autoclean)
ipt_REDIRECT 1304 1 (autoclean)
ipt_REJECT 3736 4 (autoclean)
ipt_state 1048 13 (autoclean)
ip_nat_irc 3152 0 (unused)
ip_nat_ftp 3888 0 (unused)
ip_conntrack_irc 3984 1
ip_conntrack_ftp 5008 1
ipt_multiport 1144 2 (autoclean)
ipt_conntrack 1592 0 (autoclean)
iptable_filter 2316 1 (autoclean)
iptable_mangle 2680 1 (autoclean)
iptable_nat 20568 3 (autoclean) [ipt_REDIRECT ip_nat_irc ip_nat_ftp]
ip_conntrack 26088 5 (autoclean) [ipt_REDIRECT ipt_state ip_nat_irc
ip_nat_ftp ip_conntrack_irc ip_conntrack_ftp
ipt_conntrack iptable_nat]
ip_tables 14488 12 [ipt_TOS ipt_LOG ipt_REDIRECT ipt_REJECT ipt_state
ipt_multiport ipt_conntrack iptable_filter
iptable_mangle iptable_nat]
tulip 42464 0 (unused)
e100 50596 1
keybdev 2752 0 (unused)
mousedev 5236 0 (unused)
hid 20868 0 (unused)
input 5632 0 [keybdev mousedev hid]
usb-uhci 24684 0 (unused)
usbcore 73280 1 [hid usb-uhci]
ext3 64704 2
jbd 47860 2 [ext3]
[root@lists etc]#
@@ -105,6 +128,12 @@ and you can determine if they are loaded using the 'lsmod' command:
directory, you need to set the MODULESDIR variable in
/etc/shorewall/shorewall.conf to point to that directory.
+If your FTP helper modules are compressed and have the names ip_nat_ftp.o.gz and ip_conntrack_ftp.o.gz then you will
+need Shorewall 1.4.7 or later if you want Shorewall to load them for
+you.
+
Server configuration is covered in the
/etc/shorewall/rules documentation,
@@ -203,7 +232,7 @@ to the net.
-Last updated 9/17/2003 - Last updated 12/01/2003 - Tom Eastep
Copyright © 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/GenericTunnels.html b/Shorewall-docs/GenericTunnels.html
index 6509a4249..6340f2f85 100644
--- a/Shorewall-docs/GenericTunnels.html
+++ b/Shorewall-docs/GenericTunnels.html
@@ -8,17 +8,8 @@
-
-
-
-
- Generic Tunnels
- |
-
-
-
+Generic Tunnels
+
Shorewall includes built-in support for a wide range of VPN solutions.
If you have need for a tunnel type that does not have explicit support,
you can generally describe the tunneling software using "generic
diff --git a/Shorewall-docs/GnuCopyright.htm b/Shorewall-docs/GnuCopyright.htm
index ef2028032..cd238fe96 100644
--- a/Shorewall-docs/GnuCopyright.htm
+++ b/Shorewall-docs/GnuCopyright.htm
@@ -1,341 +1,420 @@
-
-
-
-
Copyright
-
-
-
-
-
-
- GNU Free Documentation License
- |
-
-
-
-
-
+
+GNU Free Documentation License
+
Version 1.1, March 2000
-
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
-
0. PREAMBLE
-
-The purpose of this License is to make a manual, textbook, or other written
-document "free" in the sense of freedom: to assure everyone the effective
-freedom to copy and redistribute it, with or without modifying it, either
-commercially or noncommercially. Secondarily, this License preserves for
-the author and publisher a way to get credit for their work, while not being
-considered responsible for modifications made by others.
-
-This License is a kind of "copyleft", which means that derivative works
-of the document must themselves be free in the same sense. It complements
-the GNU General Public License, which is a copyleft license designed for
+ The purpose of this License is to make a manual, textbook, or other
+written document "free" in the sense of freedom: to assure everyone the
+effective freedom to copy and redistribute it, with or without
+modifying it, either commercially or noncommercially. Secondarily, this
+License preserves for
+the author and publisher a way to get credit for their work, while not
+being considered responsible for modifications made by others.
+This License is a kind of "copyleft", which means that derivative
+works
+of the document must themselves be free in the same sense. It
+complements
+the GNU General Public License, which is a copyleft license designed
+for
free software.
-
-We have designed this License in order to use it for manuals for free software,
-because free software needs free documentation: a free program should come
-with manuals providing the same freedoms that the software does. But this
-License is not limited to software manuals; it can be used for any textual
-work, regardless of subject matter or whether it is published as a printed
-book. We recommend this License principally for works whose purpose is instruction
+ We have designed this License in order to use it for manuals for
+free software,
+because free software needs free documentation: a free program should
+come
+with manuals providing the same freedoms that the software does. But
+this License is not limited to software manuals; it can be used for any
+textual
+work, regardless of subject matter or whether it is published as a
+printed
+book. We recommend this License principally for works whose purpose is
+instruction
or reference.
-
1. APPLICABILITY AND DEFINITIONS
-
-This License applies to any manual or other work that contains a notice
-placed by the copyright holder saying it can be distributed under the terms
-of this License. The "Document", below, refers to any such manual or work.
+ This License applies to any manual or other work that contains a
+notice placed by the copyright holder saying it can be distributed
+under the terms
+of this License. The "Document", below, refers to any such manual or
+work.
Any member of the public is a licensee, and is addressed as "you".
-
-A "Modified Version" of the Document means any work containing the Document
-or a portion of it, either copied verbatim, or with modifications and/or translated
+ A "Modified Version" of the Document means any work containing the
+Document or a portion of it, either copied verbatim, or with
+modifications and/or translated
into another language.
-
-A "Secondary Section" is a named appendix or a front-matter section of
-the Document that deals exclusively with the relationship of the publishers
-or authors of the Document to the Document's overall subject (or to related
-matters) and contains nothing that could fall directly within that overall
-subject. (For example, if the Document is in part a textbook of mathematics,
-a Secondary Section may not explain any mathematics.) The relationship could
-be a matter of historical connection with the subject or with related matters,
-or of legal, commercial, philosophical, ethical or political position regarding
+ A "Secondary Section" is a named appendix or a front-matter section
+of
+the Document that deals exclusively with the relationship of the
+publishers
+or authors of the Document to the Document's overall subject (or to
+related matters) and contains nothing that could fall directly within
+that overall subject. (For example, if the Document is in part a
+textbook of mathematics,
+a Secondary Section may not explain any mathematics.) The relationship
+could
+be a matter of historical connection with the subject or with related
+matters,
+or of legal, commercial, philosophical, ethical or political position
+regarding
them.
-
-The "Invariant Sections" are certain Secondary Sections whose titles are
-designated, as being those of Invariant Sections, in the notice that says
+ The "Invariant Sections" are certain Secondary Sections whose titles
+are designated, as being those of Invariant Sections, in the notice
+that says
that the Document is released under this License.
-
-The "Cover Texts" are certain short passages of text that are listed,
-as Front-Cover Texts or Back-Cover Texts, in the notice that says that the
+ The "Cover Texts" are certain short passages of text that are
+listed,
+as Front-Cover Texts or Back-Cover Texts, in the notice that says that
+the
Document is released under this License.
-
-A "Transparent" copy of the Document means a machine-readable copy, represented
-in a format whose specification is available to the general public, whose
-contents can be viewed and edited directly and straightforwardly with generic
-text editors or (for images composed of pixels) generic paint programs or
-(for drawings) some widely available drawing editor, and that is suitable
-for input to text formatters or for automatic translation to a variety of
-formats suitable for input to text formatters. A copy made in an otherwise
-Transparent file format whose markup has been designed to thwart or discourage
-subsequent modification by readers is not Transparent. A copy that is not
+ A "Transparent" copy of the Document means a machine-readable copy,
+represented
+in a format whose specification is available to the general public,
+whose
+contents can be viewed and edited directly and straightforwardly with
+generic
+text editors or (for images composed of pixels) generic paint programs
+or
+(for drawings) some widely available drawing editor, and that is
+suitable
+for input to text formatters or for automatic translation to a variety
+of
+formats suitable for input to text formatters. A copy made in an
+otherwise
+Transparent file format whose markup has been designed to thwart or
+discourage
+subsequent modification by readers is not Transparent. A copy that is
+not
"Transparent" is called "Opaque".
-
-Examples of suitable formats for Transparent copies include plain ASCII
-without markup, Texinfo input format, LaTeX input format, SGML or XML using
-a publicly available DTD, and standard-conforming simple HTML designed for
-human modification. Opaque formats include PostScript, PDF, proprietary formats
-that can be read and edited only by proprietary word processors, SGML or
-XML for which the DTD and/or processing tools are not generally available,
-and the machine-generated HTML produced by some word processors for output
+ Examples of suitable formats for Transparent copies include plain
+ASCII without markup, Texinfo input format, LaTeX input format, SGML or
+XML using
+a publicly available DTD, and standard-conforming simple HTML designed
+for
+human modification. Opaque formats include PostScript, PDF, proprietary
+formats
+that can be read and edited only by proprietary word processors, SGML
+or
+XML for which the DTD and/or processing tools are not generally
+available,
+and the machine-generated HTML produced by some word processors for
+output
purposes only.
-
-The "Title Page" means, for a printed book, the title page itself, plus
-such following pages as are needed to hold, legibly, the material this License
-requires to appear in the title page. For works in formats which do not have
-any title page as such, "Title Page" means the text near the most prominent
-appearance of the work's title, preceding the beginning of the body of the
+ The "Title Page" means, for a printed book, the title page itself,
+plus
+such following pages as are needed to hold, legibly, the material this
+License requires to appear in the title page. For works in formats
+which do not have
+any title page as such, "Title Page" means the text near the most
+prominent appearance of the work's title, preceding the beginning of
+the body of the
text.
-
2. VERBATIM COPYING
-
-You may copy and distribute the Document in any medium, either commercially
-or noncommercially, provided that this License, the copyright notices, and
-the license notice saying this License applies to the Document are reproduced
-in all copies, and that you add no other conditions whatsoever to those of
-this License. You may not use technical measures to obstruct or control the
-reading or further copying of the copies you make or distribute. However,
-you may accept compensation in exchange for copies. If you distribute a large
-enough number of copies you must also follow the conditions in section 3.
+ You may copy and distribute the Document in any medium, either
+commercially or noncommercially, provided that this License, the
+copyright notices, and
+the license notice saying this License applies to the Document are
+reproduced
+in all copies, and that you add no other conditions whatsoever to those
+of
+this License. You may not use technical measures to obstruct or control
+the
+reading or further copying of the copies you make or distribute.
+However,
+you may accept compensation in exchange for copies. If you distribute a
+large
+enough number of copies you must also follow the conditions in section
+3.
-
-You may also lend copies, under the same conditions stated above, and
+ You may also lend copies, under the same conditions stated above,
+and
you may publicly display copies.
-
3. COPYING IN QUANTITY
-
-If you publish printed copies of the Document numbering more than 100,
-and the Document's license notice requires Cover Texts, you must enclose
-the copies in covers that carry, clearly and legibly, all these Cover Texts:
-Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover.
-Both covers must also clearly and legibly identify you as the publisher of
-these copies. The front cover must present the full title with all words
-of the title equally prominent and visible. You may add other material on
-the covers in addition. Copying with changes limited to the covers, as long
-as they preserve the title of the Document and satisfy these conditions,
+ If you publish printed copies of the Document numbering more than
+100,
+and the Document's license notice requires Cover Texts, you must
+enclose
+the copies in covers that carry, clearly and legibly, all these Cover
+Texts:
+Front-Cover Texts on the front cover, and Back-Cover Texts on the back
+cover.
+Both covers must also clearly and legibly identify you as the publisher
+of
+these copies. The front cover must present the full title with all
+words
+of the title equally prominent and visible. You may add other material
+on
+the covers in addition. Copying with changes limited to the covers, as
+long
+as they preserve the title of the Document and satisfy these
+conditions,
can be treated as verbatim copying in other respects.
-
-If the required texts for either cover are too voluminous to fit legibly,
-you should put the first ones listed (as many as fit reasonably) on the actual
-cover, and continue the rest onto adjacent pages.
-
-If you publish or distribute Opaque copies of the Document numbering more
-than 100, you must either include a machine-readable Transparent copy along
-with each Opaque copy, or state in or with each Opaque copy a publicly-accessible
-computer-network location containing a complete Transparent copy of the Document,
-free of added material, which the general network-using public has access
-to download anonymously at no charge using public-standard network protocols.
-If you use the latter option, you must take reasonably prudent steps, when
-you begin distribution of Opaque copies in quantity, to ensure that this Transparent
-copy will remain thus accessible at the stated location until at least one
-year after the last time you distribute an Opaque copy (directly or through
+ If the required texts for either cover are too voluminous to fit
+legibly,
+you should put the first ones listed (as many as fit reasonably) on the
+actual cover, and continue the rest onto adjacent pages.
+If you publish or distribute Opaque copies of the Document numbering
+more than 100, you must either include a machine-readable Transparent
+copy along
+with each Opaque copy, or state in or with each Opaque copy a
+publicly-accessible computer-network location containing a complete
+Transparent copy of the Document,
+free of added material, which the general network-using public has
+access
+to download anonymously at no charge using public-standard network
+protocols.
+If you use the latter option, you must take reasonably prudent steps,
+when
+you begin distribution of Opaque copies in quantity, to ensure that
+this Transparent
+copy will remain thus accessible at the stated location until at least
+one
+year after the last time you distribute an Opaque copy (directly or
+through
your agents or retailers) of that edition to the public.
-
-It is requested, but not required, that you contact the authors of the
-Document well before redistributing any large number of copies, to give them
+ It is requested, but not required, that you contact the authors of
+the Document well before redistributing any large number of copies, to
+give them
a chance to provide you with an updated version of the Document.
-
4. MODIFICATIONS
-
-You may copy and distribute a Modified Version of the Document under the
-conditions of sections 2 and 3 above, provided that you release the Modified
-Version under precisely this License, with the Modified Version filling the
-role of the Document, thus licensing distribution and modification of the
-Modified Version to whoever possesses a copy of it. In addition, you must
+ You may copy and distribute a Modified Version of the Document under
+the conditions of sections 2 and 3 above, provided that you release the
+Modified Version under precisely this License, with the Modified
+Version filling the
+role of the Document, thus licensing distribution and modification of
+the
+Modified Version to whoever possesses a copy of it. In addition, you
+must
do these things in the Modified Version:
-
-
-
+
- - A. Use in the Title Page (and on the covers, if any)
-a title distinct from that of the Document, and from those of previous
-versions (which should, if there were any, be listed in the History section
-of the Document). You may use the same title as a previous version if the
-original publisher of that version gives permission.
- - B. List on the Title Page, as authors, one or more
- persons or entities responsible for authorship of the modifications in
-the Modified Version, together with at least five of the principal authors
-of the Document (all of its principal authors, if it has less than five).
-
- - C. State on the Title page the name of the publisher
-of the Modified Version, as the publisher.
- - D. Preserve all the copyright notices of the Document.
-
- - E. Add an appropriate copyright notice for your
- modifications adjacent to the other copyright notices.
- - F. Include, immediately after the copyright notices,
-a license notice giving the public permission to use the Modified Version
-under the terms of this License, in the form shown in the Addendum below.
-
- - G. Preserve in that license notice the full lists
-of Invariant Sections and required Cover Texts given in the Document's
-license notice.
- - H. Include an unaltered copy of this License.
- - I. Preserve the section entitled "History", and its
- title, and add to it an item stating at least the title, year, new authors,
- and publisher of the Modified Version as given on the Title Page. If there
-is no section entitled "History" in the Document, create one stating the
-title, year, authors, and publisher of the Document as given on its Title
-Page, then add an item describing the Modified Version as stated in the
-previous sentence.
- - J. Preserve the network location, if any, given in
-the Document for public access to a Transparent copy of the Document, and
-likewise the network locations given in the Document for previous versions
-it was based on. These may be placed in the "History" section. You may
-omit a network location for a work that was published at least four years
-before the Document itself, or if the original publisher of the version
-it refers to gives permission.
- - K. In any section entitled "Acknowledgements" or
- "Dedications", preserve the section's title, and preserve in the section
-all the substance and tone of each of the contributor acknowledgements
-and/or dedications given therein.
- - L. Preserve all the Invariant Sections of the Document,
- unaltered in their text and in their titles. Section numbers or the equivalent
- are not considered part of the section titles.
- - M. Delete any section entitled "Endorsements". Such
-a section may not be included in the Modified Version.
- - N. Do not retitle any existing section as "Endorsements"
- or to conflict in title with any Invariant Section.
-
+ - A. Use in the Title Page (and on the covers, if
+any)
+a title distinct from that of the Document, and from those of previous
+versions (which should, if there were any, be listed in the History
+section
+of the Document). You may use the same title as a previous version if
+the
+original publisher of that version gives permission.
+ - B. List on the Title Page, as authors, one or
+more persons or entities responsible for authorship of the
+modifications in
+the Modified Version, together with at least five of the principal
+authors
+of the Document (all of its principal authors, if it has less than
+five).
+ - C. State on the Title page the name of the
+publisher
+of the Modified Version, as the publisher.
+ - D. Preserve all the copyright notices of the
+Document.
+ - E. Add an appropriate copyright notice for your
+modifications adjacent to the other copyright notices.
+ - F. Include, immediately after the copyright
+notices,
+a license notice giving the public permission to use the Modified
+Version
+under the terms of this License, in the form shown in the Addendum
+below.
+ - G. Preserve in that license notice the full
+lists
+of Invariant Sections and required Cover Texts given in the Document's
+license notice.
+ - H. Include an unaltered copy of this License.
+ - I. Preserve the section entitled "History", and
+its title, and add to it an item stating at least the title, year, new
+authors, and publisher of the Modified Version as given on the Title
+Page. If there
+is no section entitled "History" in the Document, create one stating
+the
+title, year, authors, and publisher of the Document as given on its
+Title
+Page, then add an item describing the Modified Version as stated in the
+previous sentence.
+ - J. Preserve the network location, if any, given
+in
+the Document for public access to a Transparent copy of the Document,
+and
+likewise the network locations given in the Document for previous
+versions
+it was based on. These may be placed in the "History" section. You may
+omit a network location for a work that was published at least four
+years
+before the Document itself, or if the original publisher of the version
+it refers to gives permission.
+ - K. In any section entitled "Acknowledgements" or
+"Dedications", preserve the section's title, and preserve in the
+section
+all the substance and tone of each of the contributor acknowledgements
+and/or dedications given therein.
+ - L. Preserve all the Invariant Sections of the
+Document, unaltered in their text and in their titles. Section numbers
+or the equivalent are not considered part of the section titles.
+ - M. Delete any section entitled "Endorsements".
+Such
+a section may not be included in the Modified Version.
+ - N. Do not retitle any existing section as
+"Endorsements" or to conflict in title with any Invariant Section.
-
-If the Modified Version includes new front-matter sections or appendices
-that qualify as Secondary Sections and contain no material copied from the
-Document, you may at your option designate some or all of these sections
-as invariant. To do this, add their titles to the list of Invariant Sections
-in the Modified Version's license notice. These titles must be distinct from
+ If the Modified Version includes new front-matter sections or
+appendices
+that qualify as Secondary Sections and contain no material copied from
+the
+Document, you may at your option designate some or all of these
+sections
+as invariant. To do this, add their titles to the list of Invariant
+Sections
+in the Modified Version's license notice. These titles must be distinct
+from
any other section titles.
-
-You may add a section entitled "Endorsements", provided it contains nothing
-but endorsements of your Modified Version by various parties--for example,
-statements of peer review or that the text has been approved by an organization
-as the authoritative definition of a standard.
-
-You may add a passage of up to five words as a Front-Cover Text, and a
-passage of up to 25 words as a Back-Cover Text, to the end of the list of
-Cover Texts in the Modified Version. Only one passage of Front-Cover Text
-and one of Back-Cover Text may be added by (or through arrangements made
-by) any one entity. If the Document already includes a cover text for the
-same cover, previously added by you or by arrangement made by the same entity
-you are acting on behalf of, you may not add another; but you may replace
-the old one, on explicit permission from the previous publisher that added
+ You may add a section entitled "Endorsements", provided it contains
+nothing but endorsements of your Modified Version by various
+parties--for example, statements of peer review or that the text has
+been approved by an organization as the authoritative definition of a
+standard.
+You may add a passage of up to five words as a Front-Cover Text, and
+a passage of up to 25 words as a Back-Cover Text, to the end of the
+list of
+Cover Texts in the Modified Version. Only one passage of Front-Cover
+Text
+and one of Back-Cover Text may be added by (or through arrangements
+made
+by) any one entity. If the Document already includes a cover text for
+the
+same cover, previously added by you or by arrangement made by the same
+entity
+you are acting on behalf of, you may not add another; but you may
+replace
+the old one, on explicit permission from the previous publisher that
+added
the old one.
-
-The author(s) and publisher(s) of the Document do not by this License
-give permission to use their names for publicity for or to assert or imply
-endorsement of any Modified Version.
-
+The author(s) and publisher(s) of the Document do not by this
+License
+give permission to use their names for publicity for or to assert or
+imply endorsement of any Modified Version.
5. COMBINING DOCUMENTS
-
-You may combine the Document with other documents released under this License,
-under the terms defined in section 4 above for modified versions, provided
-that you include in the combination all of the Invariant Sections of all
-of the original documents, unmodified, and list them all as Invariant Sections
+ You may combine the Document with other documents released under
+this License,
+under the terms defined in section 4 above for modified versions,
+provided
+that you include in the combination all of the Invariant Sections of
+all
+of the original documents, unmodified, and list them all as Invariant
+Sections
of your combined work in its license notice.
-
-The combined work need only contain one copy of this License, and multiple
-identical Invariant Sections may be replaced with a single copy. If there
-are multiple Invariant Sections with the same name but different contents,
-make the title of each such section unique by adding at the end of it, in
-parentheses, the name of the original author or publisher of that section
-if known, or else a unique number. Make the same adjustment to the section
-titles in the list of Invariant Sections in the license notice of the combined
+ The combined work need only contain one copy of this License, and
+multiple identical Invariant Sections may be replaced with a single
+copy. If there
+are multiple Invariant Sections with the same name but different
+contents,
+make the title of each such section unique by adding at the end of it,
+in
+parentheses, the name of the original author or publisher of that
+section
+if known, or else a unique number. Make the same adjustment to the
+section
+titles in the list of Invariant Sections in the license notice of the
+combined
work.
-
-In the combination, you must combine any sections entitled "History" in
-the various original documents, forming one section entitled "History"; likewise
-combine any sections entitled "Acknowledgements", and any sections entitled
-"Dedications". You must delete all sections entitled "Endorsements."
-
+In the combination, you must combine any sections entitled "History"
+in
+the various original documents, forming one section entitled "History";
+likewise combine any sections entitled "Acknowledgements", and any
+sections entitled "Dedications". You must delete all sections entitled
+"Endorsements."
6. COLLECTIONS OF DOCUMENTS
-
-You may make a collection consisting of the Document and other documents
-released under this License, and replace the individual copies of this License
-in the various documents with a single copy that is included in the collection,
-provided that you follow the rules of this License for verbatim copying of
+ You may make a collection consisting of the Document and other
+documents released under this License, and replace the individual
+copies of this License in the various documents with a single copy that
+is included in the collection, provided that you follow the rules of
+this License for verbatim copying of
each of the documents in all other respects.
-
-You may extract a single document from such a collection, and distribute
-it individually under this License, provided you insert a copy of this License
-into the extracted document, and follow this License in all other respects
+ You may extract a single document from such a collection, and
+distribute
+it individually under this License, provided you insert a copy of this
+License
+into the extracted document, and follow this License in all other
+respects
regarding verbatim copying of that document.
-
7. AGGREGATION WITH INDEPENDENT WORKS
-
-A compilation of the Document or its derivatives with other separate and
-independent documents or works, in or on a volume of a storage or distribution
-medium, does not as a whole count as a Modified Version of the Document, provided
-no compilation copyright is claimed for the compilation. Such a compilation
-is called an "aggregate", and this License does not apply to the other self-contained
-works thus compiled with the Document, on account of their being thus compiled,
+ A compilation of the Document or its derivatives with other separate
+and independent documents or works, in or on a volume of a storage or
+distribution medium, does not as a whole count as a Modified Version of
+the Document, provided
+no compilation copyright is claimed for the compilation. Such a
+compilation
+is called an "aggregate", and this License does not apply to the other
+self-contained
+works thus compiled with the Document, on account of their being thus
+compiled,
if they are not themselves derivative works of the Document.
-
-If the Cover Text requirement of section 3 is applicable to these copies
-of the Document, then if the Document is less than one quarter of the entire
-aggregate, the Document's Cover Texts may be placed on covers that surround
-only the Document within the aggregate. Otherwise they must appear on covers
+ If the Cover Text requirement of section 3 is applicable to these
+copies
+of the Document, then if the Document is less than one quarter of the
+entire aggregate, the Document's Cover Texts may be placed on covers
+that surround
+only the Document within the aggregate. Otherwise they must appear on
+covers
around the whole aggregate.
-
8. TRANSLATION
-
-Translation is considered a kind of modification, so you may distribute
-translations of the Document under the terms of section 4. Replacing Invariant
-Sections with translations requires special permission from their copyright
-holders, but you may include translations of some or all Invariant Sections
-in addition to the original versions of these Invariant Sections. You may
-include a translation of this License provided that you also include the
-original English version of this License. In case of a disagreement between
-the translation and the original English version of this License, the original
+ Translation is considered a kind of modification, so you may
+distribute translations of the Document under the terms of section 4.
+Replacing Invariant Sections with translations requires special
+permission from their copyright holders, but you may include
+translations of some or all Invariant Sections
+in addition to the original versions of these Invariant Sections. You
+may
+include a translation of this License provided that you also include
+the
+original English version of this License. In case of a disagreement
+between
+the translation and the original English version of this License, the
+original
English version will prevail.
-
9. TERMINATION
-
-You may not copy, modify, sublicense, or distribute the Document except
-as expressly provided for under this License. Any other attempt to copy,
-modify, sublicense or distribute the Document is void, and will automatically
-terminate your rights under this License. However, parties who have received
-copies, or rights, from you under this License will not have their licenses
+ You may not copy, modify, sublicense, or distribute the Document
+except
+as expressly provided for under this License. Any other attempt to
+copy,
+modify, sublicense or distribute the Document is void, and will
+automatically
+terminate your rights under this License. However, parties who have
+received
+copies, or rights, from you under this License will not have their
+licenses
terminated so long as such parties remain in full compliance.
-
10. FUTURE REVISIONS OF THIS LICENSE
-
-The Free Software Foundation may publish new, revised versions of the
-GNU Free Documentation License from time to time. Such new versions will
-be similar in spirit to the present version, but may differ in detail to
+ The Free Software Foundation may publish new, revised versions of
+the
+GNU Free Documentation License from time to time. Such new versions
+will
+be similar in spirit to the present version, but may differ in detail
+to
address new problems or concerns. See http://www.gnu.org/copyleft/.
-
-Each version of the License is given a distinguishing version number.
-If the Document specifies that a particular numbered version of this License
-"or any later version" applies to it, you have the option of following the
-terms and conditions either of that specified version or of any later version
-that has been published (not as a draft) by the Free Software Foundation.
-If the Document does not specify a version number of this License, you may
-choose any version ever published (not as a draft) by the Free Software Foundation.
+ Each version of the License is given a distinguishing version
+number.
+If the Document specifies that a particular numbered version of this
+License
+"or any later version" applies to it, you have the option of following
+the
+terms and conditions either of that specified version or of any later
+version
+that has been published (not as a draft) by the Free Software
+Foundation.
+If the Document does not specify a version number of this License, you
+may
+choose any version ever published (not as a draft) by the Free Software
+Foundation.
-
-
-
+
+
diff --git a/Shorewall-docs/IPIP.htm b/Shorewall-docs/IPIP.htm
index 28370194a..74069fa5d 100644
--- a/Shorewall-docs/IPIP.htm
+++ b/Shorewall-docs/IPIP.htm
@@ -1,98 +1,71 @@
-
GRE/IPIP Tunnels
-
-
-
-
-
-
-
-
- GRE and IPIP Tunnels
- |
-
-
-
-
-
-Warning: GRE and IPIP Tunnels are insecure
-when used over the internet; use them at your own risk
-
-GRE and IPIP tunneling with Shorewall can be used to bridge two masqueraded
-networks.
-
-The simple scripts described in the Linux
-Advanced Routing and Shaping HOWTO work fine with Shorewall. Shorewall
-also includes a tunnel script for automating tunnel configuration. If you
-have installed the RPM, the tunnel script may be found in the Shorewall documentation
-directory (usually /usr/share/doc/shorewall-<version>/).
-
+
+GRE and IPIP Tunnels
+
+Warning: GRE and IPIP Tunnels are
+insecure when used over the internet; use them at your own risk
+GRE and IPIP tunneling with Shorewall can be used to bridge two
+masqueraded networks.
+The simple scripts described in the Linux
+Advanced Routing and Shaping HOWTO work fine with Shorewall.
+Shorewall also includes a tunnel script for automating tunnel
+configuration. If you have installed the RPM, the tunnel script may be
+found in the Shorewall documentation directory (usually
+/usr/share/doc/shorewall-<version>/).
Bridging two Masqueraded Networks
-
Suppose that we have the following situation:
-
- 
-
-
-We want systems in the 192.168.1.0/24 subnetwork to be able
-to communicate with the systems in the 10.0.0.0/8 network. This is accomplished
-through use of the /etc/shorewall/tunnels file, the /etc/shorewall/policy
-file and the /etc/shorewall/tunnel script that is included with Shorewall.
-
-The 'tunnel' script is not installed in /etc/shorewall by
-default -- If you install using the tarball, the script is included in the
-tarball; if you install using the RPM, the file is in your Shorewall documentation
-directory (normally /usr/share/doc/shorewall-<version>).
-
-In the /etc/shorewall/tunnel script, set the 'tunnel_type'
-parameter to the type of tunnel that you want to create.
-
+
+We want systems in the 192.168.1.0/24 subnetwork to be
+able to communicate with the systems in the 10.0.0.0/8 network. This is
+accomplished through use of the /etc/shorewall/tunnels file, the
+/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
+included with Shorewall.
+The 'tunnel' script is not installed in /etc/shorewall
+by default -- If you install using the tarball, the script is included
+in the tarball; if you install using the RPM, the file is in your
+Shorewall documentation directory (normally
+/usr/share/doc/shorewall-<version>).
+In the /etc/shorewall/tunnel script, set the
+'tunnel_type' parameter to the type of tunnel that you want to create.
Example:
-
-
+
tunnel_type=gre
-
-
-On each firewall, you will need to declare a zone to represent
- the remote subnet. We'll assume that this zone is called 'vpn' and declare
-it in /etc/shorewall/zones on both systems as follows.
-
-
+
+On each firewall, you will need to declare a zone to
+represent the remote subnet. We'll assume that this zone is called
+'vpn' and declare it in /etc/shorewall/zones on both systems as follows.
+
-
-
- | ZONE |
- DISPLAY |
- COMMENTS |
-
-
- | vpn |
- VPN |
- Remote Subnet |
-
-
-
+
+
+ | ZONE |
+ DISPLAY |
+ COMMENTS |
+
+
+ | vpn |
+ VPN |
+ Remote Subnet |
+
+
-
-
-On system A, the 10.0.0.0/8 will comprise the vpn zone.
+
+On system A, the 10.0.0.0/8 will comprise the vpn
+zone.
In /etc/shorewall/interfaces:
-
-
+
-
-
+
+
| ZONE |
INTERFACE |
BROADCAST |
@@ -102,19 +75,17 @@ In /etc/shorewall/interfaces:
vpn |
tosysb |
10.255.255.255 |
- |
+ |
-
-
+
-
-
-In /etc/shorewall/tunnels on system A, we need the following:
-
-
+
+In /etc/shorewall/tunnels on system A, we need the
+following:
+
-
-
+
+
| TYPE |
ZONE |
GATEWAY |
@@ -124,34 +95,29 @@ In /etc/shorewall/interfaces:
ipip |
net |
134.28.54.2 |
- |
+ |
-
-
+
-
-
-This entry in /etc/shorewall/tunnels, opens the firewall so that the IP
- encapsulation protocol (4) will be accepted to/from the remote gateway.
-
+
+This entry in /etc/shorewall/tunnels, opens the firewall so that the
+IP encapsulation protocol (4) will be accepted to/from the remote
+gateway.
In the tunnel script on system A:
-
-
+
tunnel=tosysb
- myrealip=206.161.148.9 (for GRE tunnel only)
- myip=192.168.1.1
- hisip=10.0.0.1
- gateway=134.28.54.2
- subnet=10.0.0.0/8
-
-
-Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn
+myrealip=206.161.148.9 (for GRE tunnel only)
+myip=192.168.1.1
+hisip=10.0.0.1
+gateway=134.28.54.2
+subnet=10.0.0.0/8
+
+Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn
zone. In /etc/shorewall/interfaces:
-
-
+
-
-
+
+
| ZONE |
INTERFACE |
BROADCAST |
@@ -161,19 +127,16 @@ zone. In /etc/shorewall/interfaces:
vpn |
tosysa |
192.168.1.255 |
- |
+ |
-
-
+
-
-
+
In /etc/shorewall/tunnels on system B, we have:
-
-
+
-
-
+
+
| TYPE |
ZONE |
GATEWAY |
@@ -183,67 +146,59 @@ zone. In /etc/shorewall/interfaces:
ipip |
net |
206.191.148.9 |
- |
+ |
-
-
+
-
-
+
And in the tunnel script on system B:
-
-
+
tunnel=tosysa
- myrealip=134.28.54.2 (for GRE tunnel only)
- myip=10.0.0.1
- hisip=192.168.1.1
- gateway=206.191.148.9
- subnet=192.168.1.0/24
-
-
-You can rename the modified tunnel scripts if you like; be sure that they
-are secured so that root can execute them.
-
- You will need to allow traffic between the "vpn" zone and
- the "loc" zone on both systems -- if you simply want to admit all traffic
- in both directions, you can use the policy file:
-
-
+myrealip=134.28.54.2 (for GRE tunnel only)
+myip=10.0.0.1
+hisip=192.168.1.1
+gateway=206.191.148.9
+subnet=192.168.1.0/24
+
+You can rename the modified tunnel scripts if you like; be sure that
+they are secured so that root can execute them.
+ You will need to allow traffic between the "vpn" zone
+and the "loc" zone on both systems -- if you simply want to admit all
+traffic in both directions, you can use the policy file:
+
-
-
- | SOURCE |
- DEST |
- POLICY |
- LOG LEVEL |
-
-
- | loc |
- vpn |
- ACCEPT |
- |
-
-
- | vpn |
- loc |
- ACCEPT |
- |
-
-
-
+
+
+ | SOURCE |
+ DEST |
+ POLICY |
+ LOG LEVEL |
+
+
+ | loc |
+ vpn |
+ ACCEPT |
+ |
+
+
+ | vpn |
+ loc |
+ ACCEPT |
+ |
+
+
-
-
-On both systems, restart Shorewall and run the modified tunnel script with
-the "start" argument on each system. The systems in the two masqueraded subnetworks
+
+On both systems, restart Shorewall and run the modified tunnel
+script with
+the "start" argument on each system. The systems in the two masqueraded
+subnetworks
can now talk to each other
-
-Updated 2/22/2003 - Tom Eastep
+Updated 2/22/2003 - Tom Eastep
-
-Copyright © Copyright © 2001, 2002, 2003Thomas M. Eastep.
-
-
+
+
diff --git a/Shorewall-docs/IPSEC.htm b/Shorewall-docs/IPSEC.htm
index 537282ba3..9d832e994 100644
--- a/Shorewall-docs/IPSEC.htm
+++ b/Shorewall-docs/IPSEC.htm
@@ -8,17 +8,8 @@
-
-
-
-
- IPSEC Tunnels
- |
-
-
-
+IPSEC Tunnels
+
Configuring FreeS/Wan
There is an excellent guide to configuring IPSEC tunnels at
@@ -34,10 +25,40 @@ to debug this problem so I can't say if it is a bug in the Kernel or in
FreeS/Wan.
You might be able to work around this problem using the
following (I haven't tried it):
-In /etc/shorewall/init, include:
- qt service ipsec stop
-In /etc/shorewall/start, include:
- qt service ipsec start
+In /etc/shorewall/init, include:
+
+ qt service ipsec
+stop
+
+In /etc/shorewall/start, include:
+
+ qt service ipsec start
+
+Also, the documentation below assumes that you have disabled
+opportunistic encryption feature in FreeS/Wan 2.0 using the following
+additional entries in ipsec.conf:
+
+conn block
+ auto=ignore
+
+conn private
+ auto=ignore
+
+conn private-or-clear
+ auto=ignore
+
+conn clear-or-private
+ auto=ignore
+
+conn clear
+ auto=ignore
+
+conn packetdefault
+ auto=ignore
+
+For further information see http://www.freeswan.org/freeswan_trees/freeswan-2.03/doc/policygroups.html.
+
IPSec Gateway on the Firewall System
Suppose that we have the following sutuation:
@@ -631,7 +652,7 @@ issue the command":
/sbin/shorewall add ipsec0:134.28.54.2 vpn2
and the 'down' part will:
-/sbin/shorewall delete ipsec0:134.28.54.2 vpn
+/sbin/shorewall delete ipsec0:134.28.54.2 vpn2
Limitations of Dynamic Zones
@@ -664,7 +685,7 @@ DESTINATION
DNAT
|
- z:dyn
+ | z!dyn
|
loc:192.168.1.3
|
@@ -682,7 +703,7 @@ DESTINATION
Dynamic changes to the zone dyn will have no effect on the
above rule.
-Last updated 8/12//2003 - Last updated 10/292003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/Install.htm b/Shorewall-docs/Install.htm
index 7c69068e7..d8daa5be8 100644
--- a/Shorewall-docs/Install.htm
+++ b/Shorewall-docs/Install.htm
@@ -1,221 +1,189 @@
-
Shorewall Installation
-
-
-
-
-
-
-
-
- Shorewall Installation and
- Upgrade
- |
-
-
-
-
-
+
+Shorewall Installation and Upgrade
+
Before upgrading, be sure to review the Upgrade Issues
-
-
-Before attempting installation, I strongly urge you
-to read and print a copy of the Shorewall QuickStart Guide
- for the configuration that most closely matches your own.
-
-
+
+Before attempting installation, I strongly urge
+you
+to read and print a copy of the Shorewall QuickStart Guide
+for the configuration that most closely matches your own.
+
Install using RPM
- Install using tarball
- Install the .lrp
- Upgrade using RPM
- Upgrade using tarball
- Upgrade the .lrp
- Configuring Shorewall
- Uninstall/Fallback
-
+Install using tarball
+Install the .lrp
+Upgrade using RPM
+Upgrade using tarball
+Upgrade the .lrp
+Configuring Shorewall
+Uninstall/Fallback
To install Shorewall using the RPM:
-
-If you have RedHat 7.2 and are running iptables version 1.2.3 (at a
- shell prompt, type "/sbin/iptables --version"), you must upgrade to version
- 1.2.4 either from the RedHat update
- site or from the Shorewall Errata page before
- attempting to start Shorewall.
-
+If you have RedHat 7.2 and are running iptables version 1.2.3 (at
+a shell prompt, type "/sbin/iptables --version"), you must upgrade to
+version 1.2.4 either from the RedHat
+update site or from the Shorewall Errata page
+before attempting to start Shorewall.
- - Install the RPM (rpm -ivh <shorewall rpm>).
-
- Note1: Some SuSE users have encountered a problem whereby
- rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel
- is installed. If this happens, simply use the --nodeps option to rpm
- (rpm -ivh --nodeps <shorewall rpm>.
-
- Note2: Beginning with Shorewall 1.4.0, Shorewall is dependent
- on the iproute package. Unfortunately, some distributions call this package
- iproute2 which will cause the installation of Shorewall to fail with the
- diagnostic:
-
- error: failed dependencies:iproute is needed by shorewall-1.4.x-1
-
-
- This may be worked around by using the --nodeps option of rpm (rpm -ivh
- --nodeps <shorewall rpm>).
-
-
- - Edit the configuration files
- to match your configuration. WARNING - YOU CAN
- NOT SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start"
-COMMAND. SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START.
-IF YOU ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR
-SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS, ISSUE
-A "shorewall clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.
- - Start the firewall by typing "shorewall start"
-
+ - Install the RPM (rpm -ivh <shorewall rpm>).
+
+ Note1: Some SuSE users have encountered a problem
+whereby rpm reports a conflict with kernel <= 2.2 even though a 2.4
+kernel is installed. If this happens, simply use the --nodeps option to
+rpm (rpm -ivh --nodeps <shorewall rpm>.
+
+ Note2: Beginning with Shorewall 1.4.0, Shorewall is
+dependent on the iproute package. Unfortunately, some distributions
+call this package iproute2 which will cause the installation of
+Shorewall to fail with the diagnostic:
+
+ error: failed dependencies:iproute is needed by
+shorewall-1.4.x-1
+
+This may be worked around by using the --nodeps option of rpm (rpm -ivh
+--nodeps <shorewall rpm>).
+
+
+ - Edit the configuration files to
+match your configuration. WARNING - YOU CAN NOT
+SIMPLY INSTALL THE RPM AND ISSUE A "shorewall start"
+COMMAND. SOME CONFIGURATION IS REQUIRED BEFORE THE FIREWALL WILL START.
+IF YOU ISSUE A "start" COMMAND AND THE FIREWALL FAILS TO START, YOUR
+SYSTEM WILL NO LONGER ACCEPT ANY NETWORK TRAFFIC. IF THIS HAPPENS,
+ISSUE
+A "shorewall clear" COMMAND TO RESTORE NETWORK CONNECTIVITY.
+ - Start the firewall by typing "shorewall start"
-
-To install Shorewall using the tarball
- and install script:
-
+To install Shorewall using the tarball
+and install script:
- - unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
- - cd to the shorewall directory (the version is encoded in
-the directory name as in "shorewall-1.1.10").
- - If you are using unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
+ - cd to the shorewall directory (the version is encoded in the
+directory name as in "shorewall-1.1.10").
+ - If you are using Caldera, RedHat, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
- - If you are using SuSe
-then type "./install.sh /etc/init.d"
- - If your distribution has directory /etc/rc.d/init.d
- or /etc/init.d then type "./install.sh"
- - For other distributions, determine where your
- distribution installs init scripts and type "./install.sh
- <init script directory>
- - Edit the configuration files
- to match your configuration.
- - Start the firewall by typing "shorewall start"
- - If the install script was unable to configure Shorewall
-to be started automatically at boot, see these instructions.
-
+ href="http://www.corel.com">Corel, Slackware or Debian then type "./install.sh"
+ - If you are using SuSe
+then type "./install.sh /etc/init.d"
+ - If your distribution has directory /etc/rc.d/init.d or
+/etc/init.d then type "./install.sh"
+ - For other distributions, determine where your distribution
+installs init scripts and type "./install.sh <init script
+directory>
+ - Edit the configuration files to
+match your configuration.
+ - Start the firewall by typing "shorewall start"
+ - If the install script was unable to configure Shorewall
+to be started automatically at boot, see these instructions.
-
-To install my version of Shorewall on a fresh Bering
- disk, simply replace the "shorwall.lrp" file on the image with the file
- that you downloaded. See the two-interface
-QuickStart Guide for information about further steps required.
-
-If you already have the Shorewall RPM installed
- and are upgrading to a new version:
-
-If you are upgrading from a 1.2 version of Shorewall to a 1.4 version or
-and you have entries in the /etc/shorewall/hosts file then please check
-your /etc/shorewall/interfaces file to be sure that it contains an entry
- for each interface mentioned in the hosts file. Also, there are certain
- 1.2 rule forms that are no longer supported under 1.4 (you must use the
- new 1.4 syntax). See the upgrade issues for
- details.
-
+To install my version of Shorewall on a fresh
+Bering disk, simply replace the "shorwall.lrp" file on the image with
+the file that you downloaded. See the two-interface
+QuickStart Guide for information about further steps required.
+If you already have the Shorewall RPM
+installed and are upgrading to a new version:
+If you are upgrading from a 1.2 version of Shorewall to a 1.4
+version or
+and you have entries in the /etc/shorewall/hosts file then please check
+your /etc/shorewall/interfaces file to be sure that it contains an
+entry for each interface mentioned in the hosts file. Also, there are
+certain 1.2 rule forms that are no longer supported under 1.4 (you must
+use the new 1.4 syntax). See the upgrade
+issues for details.
- - Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note:
- If you are installing version 1.2.0 and have one of the 1.2.0
- Beta RPMs installed, you must use the "--oldpackage" option to rpm
-(e.g., "rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
-
-
Note1: Some SuSE users have encountered a problem whereby
- rpm reports a conflict with kernel <= 2.2 even though a 2.4 kernel
- is installed. If this happens, simply use the --nodeps option to rpm
- (rpm -Uvh --nodeps <shorewall rpm>).
-
- Note3: Beginning with Shorewall 1.4.0, Shorewall is dependent
- on the iproute package. Unfortunately, some distributions call this package
- iproute2 which will cause the upgrade of Shorewall to fail with the diagnostic:
-
- error: failed dependencies:iproute is needed by shorewall-1.4.0-1
-
-
- This may be worked around by using the --nodeps option of rpm (rpm
--Uvh --nodeps <shorewall rpm>).
-
- - See if there are any incompatibilities between your configuration
- and the new Shorewall version (type "shorewall check") and correct as
- necessary.
- - Restart the firewall (shorewall restart).
-
+ - Upgrade the RPM (rpm -Uvh <shorewall rpm file>) Note: If
+you are installing version 1.2.0 and have one of the 1.2.0 Beta RPMs
+installed, you must use the "--oldpackage" option to rpm (e.g., "rpm
+-Uvh --oldpackage shorewall-1.2-0.noarch.rpm").
+
Note1: Some SuSE users have encountered a problem
+whereby rpm reports a conflict with kernel <= 2.2 even though a 2.4
+kernel is installed. If this happens, simply use the --nodeps option to
+rpm (rpm -Uvh --nodeps <shorewall rpm>).
+
+ Note3: Beginning with Shorewall 1.4.0, Shorewall is
+dependent on the iproute package. Unfortunately, some distributions
+call this package iproute2 which will cause the upgrade of Shorewall to
+fail with the diagnostic:
+
+ error: failed dependencies:iproute is needed by
+shorewall-1.4.0-1
+
+This may be worked around by using the --nodeps option of rpm (rpm
+-Uvh --nodeps <shorewall rpm>).
+
+ - See if there are any incompatibilities between your configuration
+and the new Shorewall version (type "shorewall check") and correct as
+necessary.
+ - Restart the firewall (shorewall restart).
-
-If you already have Shorewall installed
+ If you already have Shorewall
+installed
and are upgrading to a new version using the tarball:
-
-If you are upgrading from a 1.2 version of Shorewall to a 1.4 version
-and you have entries in the /etc/shorewall/hosts file then please check
-your /etc/shorewall/interfaces file to be sure that it contains an entry
-for each interface mentioned in the hosts file. Also, there are certain
-1.2 rule forms that are no longer supported under 1.4 (you must use the
-new 1.4 syntax). See the upgrade issues
+ If you are upgrading from a 1.2 version of Shorewall to a 1.4
+version
+and you have entries in the /etc/shorewall/hosts file then please check
+your /etc/shorewall/interfaces file to be sure that it contains an
+entry
+for each interface mentioned in the hosts file. Also, there are
+certain
+1.2 rule forms that are no longer supported under 1.4 (you must use the
+new 1.4 syntax). See the upgrade issues
for details.
-
- - unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
- - cd to the shorewall directory (the version is encoded in
-the directory name as in "shorewall-3.0.1").
- - If you are using unpack the tarball (tar -zxf shorewall-x.y.z.tgz).
+ - cd to the shorewall directory (the version is encoded in the
+directory name as in "shorewall-3.0.1").
+ - If you are using Caldera, RedHat, RedHat, Mandrake, Corel, Slackware or Debian then type "./install.sh"
- - If you are using SuSe
-then type "./install.sh /etc/init.d"
- - If your distribution has directory /etc/rc.d/init.d
- or /etc/init.d then type "./install.sh"
- - For other distributions, determine where your
- distribution installs init scripts and type "./install.sh
- <init script directory>
- - See if there are any incompatibilities between your configuration
- and the new Shorewall version (type "shorewall check") and correct as
- necessary.
- - Restart the firewall by typing "shorewall restart"
-
+ href="http://www.corel.com">Corel, Slackware or Debian then type "./install.sh"
+ - If you are using SuSe
+then type "./install.sh /etc/init.d"
+ - If your distribution has directory /etc/rc.d/init.d or
+/etc/init.d then type "./install.sh"
+ - For other distributions, determine where your distribution
+installs init scripts and type "./install.sh <init script
+directory>
+ - See if there are any incompatibilities between your configuration
+and the new Shorewall version (type "shorewall check") and correct as
+necessary.
+ - Restart the firewall by typing "shorewall restart"
- If you already have a running
-Bering installation and wish to upgrade to a later version of Shorewall:
-
- UNDER CONSTRUCTION...
-
+If you already have a running
+Bering installation and wish to upgrade to a later version of Shorewall:
+
+ UNDER CONSTRUCTION...
Configuring Shorewall
-
-You will need to edit some or all of the configuration files to match your
- setup. In most cases, the Shorewall
- QuickStart Guides contain all of the information you need.
-
+You will need to edit some or all of the configuration files to
+match your setup. In most cases, the Shorewall QuickStart Guides
+contain all of the information you need.
-
-Updated 4/8/2003 - Tom Eastep
-
-
-Copyright © Updated 4/8/2003 - Tom Eastep
+
+Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
+
+
+
diff --git a/Shorewall-docs/MAC_Validation.html b/Shorewall-docs/MAC_Validation.html
index 4242b0e5a..55e1416e7 100644
--- a/Shorewall-docs/MAC_Validation.html
+++ b/Shorewall-docs/MAC_Validation.html
@@ -2,123 +2,103 @@
MAC Verification
-
-
-
-
-
-
-
-
- MAC Verification
-
-
- |
-
-
-
-
-
- All traffic from an interface or from a subnet on an interface
- can be verified to originate from a defined set of MAC addresses. Furthermore,
- each MAC address may be optionally associated with one or more IP addresses.
-
-
- Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC
- - module name ipt_mac.o).
-
- There are four components to this facility.
-
+
+
+MAC Verification
+
+All traffic from an interface or from a subnet on an interface can be
+verified to originate from a defined set of MAC addresses. Furthermore,
+each MAC address may be optionally associated with one or more IP
+addresses.
+
+Your kernel must include MAC match support (CONFIG_IP_NF_MATCH_MAC -
+module name ipt_mac.o).
+
+There are four components to this facility.
- - The maclist interface option in /etc/shorewall/interfaces. When
-this option is specified, all traffic arriving on the interface is subjet
+
- The maclist interface option in /etc/shorewall/interfaces.
+When
+this option is specified, all traffic arriving on the interface is
+subjet
to MAC verification.
- - The maclist option in /etc/shorewall/hosts. When this option
- is specified for a subnet, all traffic from that subnet is subject to
-MAC verification.
- - The /etc/shorewall/maclist file. This file is used to associate
- MAC addresses with interfaces and to optionally associate IP addresses
- with MAC addresses.
- - The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL
- variables in /etc/shorewall/shorewall.conf.
- The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
- and determines the disposition of connection requests that fail MAC verification.
- The MACLIST_LOG_LEVEL variable gives the syslogd level at which connection
- requests that fail verification are to be logged. If set the the empty
- value (e.g., MACLIST_LOG_LEVEL="") then failing connection requests are
- not logged.
-
-
+ - The maclist option in /etc/shorewall/hosts.
+When this option is specified for a subnet, all traffic from that
+subnet is subject to
+MAC verification.
+ - The /etc/shorewall/maclist file. This file is used to associate
+MAC addresses with interfaces and to optionally associate IP addresses
+with MAC addresses.
+ - The MACLIST_DISPOSITION and MACLIST_LOG_LEVEL variables
+in /etc/shorewall/shorewall.conf.
+The MACLIST_DISPOSITION variable has the value DROP, REJECT or ACCEPT
+and determines the disposition of connection requests that fail MAC
+verification. The MACLIST_LOG_LEVEL variable gives the syslogd level at
+which connection requests that fail verification are to be logged. If
+set the the empty value (e.g., MACLIST_LOG_LEVEL="") then failing
+connection requests are not logged.
+
- The columns in /etc/shorewall/maclist are:
-
+The columns in /etc/shorewall/maclist are:
- - INTERFACE - The name of an ethernet interface on the Shorewall
- system.
- - MAC - The MAC address of a device on the ethernet segment
- connected by INTERFACE. It is not necessary to use the Shorewall MAC
-format in this column although you may use that format if you so choose.
- - IP Address - An optional comma-separated list of IP addresses
- for the device whose MAC is listed in the MAC column.
-
+ - INTERFACE - The name of an ethernet interface on the Shorewall
+system.
+ - MAC - The MAC address of a device on the ethernet segment
+connected by INTERFACE. It is not necessary to use the Shorewall MAC
+format in this column although you may use that format if you so choose.
+ - IP Address - An optional comma-separated list of IP addresses for
+the device whose MAC is listed in the MAC column.
-
-Example 1: Here are my files (look here for
-details about my setup):
- /etc/shorewall/shorewall.conf:
-
+Example 1: Here are my files (look here
+for details about my setup):
+/etc/shorewall/shorewall.conf:
+
MACLIST_DISPOSITION=REJECT
MACLIST_LOG_LEVEL=info
- /etc/shorewall/interfaces:
-
-
+/etc/shorewall/interfaces:
+
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags
loc eth2 192.168.1.255 dhcp
dmz eth1 192.168.2.255
WiFi eth3 192.168.3.255 dhcp,maclist
- texas 192.168.9.255
-
- /etc/shorewall/maclist:
-
-
+
+/etc/shorewall/maclist:
+
#INTERFACE MAC IP ADDRESSES (Optional)
eth3 00:A0:CC:A2:0C:A0 192.168.3.7 #Work Laptop
eth3 00:04:5a:fe:85:b9 192.168.3.250 #WAP11
eth3 00:06:25:56:33:3c 192.168.3.225,192.168.3.8 #WET11
eth3 00:0b:cd:C4:cc:97 192.168.3.8 #TIPPER
-
- As shown above, I use MAC Verification on my wireless zone.
-
- Note: While marketed as a wireless bridge, the WET11 behaves like
-a wireless router with DHCP relay. When forwarding DHCP traffic, it uses the
-MAC address of the host (TIPPER) but for other forwarded traffic it uses it's
-own MAC address. Consequently, I list the IP addresses of both devices in
+
+As shown above, I use MAC Verification on my wireless zone.
+
+Note: While marketed as a wireless bridge, the WET11 behaves
+like a wireless router with DHCP relay. When forwarding DHCP traffic,
+it uses the
+MAC address of the host (TIPPER) but for other forwarded traffic it
+uses it's
+own MAC address. Consequently, I list the IP addresses of both devices
+in
/etc/shorewall/maclist.
-
Example 2: Router in Wireless Zone
- Suppose now that I add a second wireless segment to my wireless
- zone and gateway that segment via a router with MAC address 00:06:43:45:C6:15
- and IP address 192.168.3.253. Hosts in the second segment have IP addresses
- in the subnet 192.168.4.0/24. I would add the following entry to my /etc/shorewall/maclist
- file:
-
+Suppose now that I add a second wireless segment to my wireless zone
+and gateway that segment via a router with MAC address
+00:06:43:45:C6:15 and IP address 192.168.3.253. Hosts in the second
+segment have IP addresses in the subnet 192.168.4.0/24. I would add the
+following entry to my /etc/shorewall/maclist file:
eth3 00:06:43:45:C6:15 192.168.3.253,192.168.4.0/24
- This entry accomodates traffic from the router itself (192.168.3.253)
- and from the second wireless segment (192.168.4.0/24). Remember that
-all traffic being sent to my firewall from the 192.168.4.0/24 segment
-will be forwarded by the router so that traffic's MAC address will be
-that of the router (00:06:43:45:C6:15) and not that of the host sending
-the traffic.
- Updated 6/30/2002 - Tom Eastep
-
-
-Copyright ©
- 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
-
-
+This entry accomodates traffic from the router itself (192.168.3.253)
+and from the second wireless segment (192.168.4.0/24). Remember that
+all traffic being sent to my firewall from the 192.168.4.0/24 segment
+will be forwarded by the router so that traffic's MAC address will be
+that of the router (00:06:43:45:C6:15) and not that of the host sending
+the traffic.
+ Updated 6/30/2002 - Tom Eastep
+
+Copyright © 2001, 2002, 2003 Thomas M. Eastep.
+
+
+
+
+
+
+
diff --git a/Shorewall-docs/Multiple_Zones.html b/Shorewall-docs/Multiple_Zones.html
new file mode 100755
index 000000000..4f45281b1
--- /dev/null
+++ b/Shorewall-docs/Multiple_Zones.html
@@ -0,0 +1,551 @@
+
+
+
+
+ Multiple Zones per Interface
+
+
+
+
+
+
+
+Multiple Zones per Interface
+
+While most configurations can be handled with each of the firewall's
+network interfaces assigned to a single zone, there are cases where you
+will want to divide the hosts accessed through an interface between two
+or more zones.
+
+ - The interface has multiple addresses on multiple subnetworks.
+This case is covered in the Aliased Interface
+documentation.
+ - You are using some form of NAT and want to access a server by its
+external IP address from the same LAN segment. This is covered in FAQs 2 and 2a.
+
+ - There are routers accessible through the interface and you want
+to treat the networks accessed through that router as a separate zone.
+ - Some of the hosts accessed through an interface have
+significantly different firewalling requirements from the others so you
+want to assign them to a different zone.
+
+The key points to keep in mind when setting up multiple zones per
+interface are:
+
+ - Shorewall generates rules for zones in the order that the zone
+declarations appear in /etc/shorewall/zones.
+ - The order of entries in /etc/shorewall/hosts is immaterial as far
+as the generated ruleset is concerned.
+
+These examples use the local zone but
+the same technique works for any zone. Remember that Shorewall
+doesn't have any conceptual knowledge of "Internet", "Local", or "DMZ"
+so all zones except the firewall itself ($FW) are the same as far as
+Shorewall is concerned. Also, the examples use private (RFC 1918)
+addresses but public IP addresses can be used in exactly the same way.
+Router in the Local Zone
+
+Here is an example of a router in the local zone. Note that the box called "Router" could be a VPN
+server or other such device; from the point of view of this
+discussion, it makes no difference.
+
+
+
+
+
+
+Can You Use the Standard Configuration?
+
+In many cases, the standard two-interface
+Shorewall setup will work fine in this configuration. It will
+work if:
+
+ - The firewall requirements to/from the internet are the same for
+192.168.1.0/24 and 192.168.2.0/24.
+ - The hosts in 192.168.1.0/24 know that the route to 192.168.2.0/24
+is through the router.
+
+All you have to do on the firewall is add a route to 192.168.2.0/24
+through the router and restart
+Shorewall.
+Will One Zone be Enough?
+If the firewalling requirements for the two local networks is the same
+but the hosts in 192.168.1.0/24 don't know how to route to
+192.168.2.0/24 then you need to configure the firewall slightly
+differently. This type of configuration is rather stupid from an IP
+networking point of view but it is sometimes necessary because you
+simply don't want to have to reconfigure all of the hosts in
+192.168.1.0/24 to add a persistent route to 192.168.2.0/24. On the
+firewall:
+
+ - Add a route to 192.168.2.0/24 through the Router.
+ - Set the 'routeback' and 'newnotsyn' options for eth1 (the local
+firewall interface) in /etc/shorewall/interfaces.
+ - Restart Shorewall.
+
+
+I Need Separate Zones
+If you need to make 192.168.2.0/24 into it's own zone, you can do it
+one of two ways; Nested Zones or Parallel Zones.
+Nested Zones:
+You can define one zone (called it 'loc') as being all hosts connectied
+to eth1 and a second zone 'loc1' (192.168.2.0/24) as a sub-zone.
+
+
+
+The advantage of this approach is that the zone 'loc1' can use CONTINUE
+policies such that if a connection request doesn't match a 'loc1' rule,
+it will be matched against the 'loc' rules. For example, if your
+loc1->net policy is CONTINUE then if a connection request from loc1
+to the internet doesn't match any rules for loc1->net then it will
+be checked against the loc->net rules.
+
+/etc/shorewall/zones:
+
+
+
+
+
+ ZONE
+ |
+ DISPLAY
+ |
+ COMMENTS
+ |
+
+
+ loc1
+ |
+ Local2
+ |
+ Hosts access through internal
+router
+ |
+
+
+ loc
+ |
+ Local
+ |
+ All hosts accessed via eth1
+ |
+
+
+
+
+Note that the sub-zone (loc1) is defined first!
+
+
+
+
+
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ loc
+ |
+ eth1
+ |
+ 192.168.1.255
+ |
+ ...
+ |
+
+
+
+
+
+
+
+
+
+
+ ZONE
+ |
+ HOSTS
+ |
+ OPTIONS
+ |
+
+
+ loc1
+ |
+ eth1:192.168.2.0/24
+ |
+
+ |
+
+
+
+
+If you don't need Shorewall to set up infrastructure to route traffic
+between 'loc' and 'loc1', add these two policies:
+
+
+
+
+
+ SOURCE
+ |
+ DEST
+ |
+ POLICY
+ |
+ LOG
+LEVEL
+ |
+ RATE:BURST
+ |
+
+
+ loc
+ |
+ loc1 |
+ NONE
+ |
+
+ |
+
+ |
+
+
+ loc1
+ |
+ loc
+ |
+ NONE
+ |
+
+ |
+
+ |
+
+
+
+ Parallel Zones:
+You define both zones in the /etc/shorewall/hosts file to create two
+disjoint zones.
+
+
+
+/etc/shorewall/zones:
+
+
+
+
+
+ ZONE
+ |
+ DISPLAY
+ |
+ COMMENTS
+ |
+
+
+ loc1
+ |
+ Local1
+ |
+ Hosts accessed Directly from
+Firewall
+ |
+
+
+ loc2
+ |
+ Local2
+ |
+ Hosts accessed via internal
+Router
+ |
+
+
+
+
+Here it doesn't matter which zone is defined first.
+
+
+
+
+
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ -
+ |
+ eth1
+ |
+ 192.168.1.255
+ |
+ ...
+ |
+
+
+
+
+
+
+
+
+
+
+ ZONE
+ |
+ HOSTS
+ |
+ OPTIONS
+ |
+
+
+ loc1
+ |
+ eth1:192.168.1.0/24
+ |
+
+ |
+
+
+ loc2
+ |
+ eth1:192.168.2.0/24
+ |
+
+ |
+
+
+
+
+If you don't need Shorewall to set up infrastructure to route traffic
+between 'loc' and 'loc1', add these two policies:
+
+
+
+
+
+ SOURCE
+ |
+ DEST
+ |
+ POLICY
+ |
+ LOG
+LEVEL
+ |
+ RATE:BURST
+ |
+
+
+ loc
+ |
+ loc1 |
+ NONE
+ |
+
+ |
+
+ |
+
+
+ loc1
+ |
+ loc
+ |
+ NONE
+ |
+
+ |
+
+ |
+
+
+
+ Some Hosts have Special Firewalling Requirements
+There are cases where a subset of the addresses associated with an
+interface need special handling. Here's an example.
+
+
+
+In this example, addresses 192.168.1.8 - 192.168.1.15 (192.168.1.8/29)
+are to be treated as their own zone (loc1).
+
+/etc/shorewall/zones:
+
+
+
+
+
+ ZONE
+ |
+ DISPLAY
+ |
+ COMMENTS
+ |
+
+
+ loc1
+ |
+ Local2
+ |
+ 192.168.1.8 - 192.168.1.15
+ |
+
+
+ loc
+ |
+ Local
+ |
+ All hosts accessed via eth1
+ |
+
+
+
+
+Note that the sub-zone (loc1) is defined first!
+
+
+
+
+
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ loc
+ |
+ eth1
+ |
+ 192.168.1.255
+ |
+ ...
+ |
+
+
+
+
+
+
+
+
+
+
+ ZONE
+ |
+ HOSTS
+ |
+ OPTIONS
+ |
+
+
+ loc1
+ |
+ eth1:192.168.1.8/29
+ |
+
+ |
+
+
+
+
+You probably don't want Shorewall to set up infrastructure to route
+traffic
+between 'loc' and 'loc1' so you should add these two policies:
+
+
+
+
+ SOURCE
+ |
+ DEST
+ |
+ POLICY
+ |
+ LOG
+LEVEL
+ |
+ RATE:BURST
+ |
+
+
+ loc
+ |
+ loc1 |
+ NONE
+ |
+
+ |
+
+ |
+
+
+ loc1
+ |
+ loc
+ |
+ NONE
+ |
+
+ |
+
+ |
+
+
+
+
+ Last updated 11/21/2003 - Tom Eastep
+Copyright © 2003 Thomas M. Eastep.
+
+
diff --git a/Shorewall-docs/NAT.htm b/Shorewall-docs/NAT.htm
index dec289ba3..5c1492d65 100644
--- a/Shorewall-docs/NAT.htm
+++ b/Shorewall-docs/NAT.htm
@@ -1,119 +1,107 @@
-
Shorewall NAT
-
-
-
-
-
-
-
-
- Static Nat
- |
-
-
-
-
+
-
-
-IMPORTANT: If all you want to do is forward
- ports to servers behind your firewall, you do NOT want to use static
- NAT. Port forwarding can be accomplished with simple entries in the
- rules file.
-
-Static NAT is a way to make systems behind a firewall and configured
- with private IP addresses (those reserved for private use in RFC1918)
- appear to have public IP addresses. Before you try to use this technique,
- I strongly recommend that you read the Shorewall Setup Guide.
-
-The following figure represents a static NAT environment.
-
- 
-
-
-
-
-Static NAT can be used to make the systems with the 10.1.1.*
- addresses appear to be on the upper (130.252.100.*) subnet. If we assume
- that the interface to the upper subnet is eth0, then the following /etc/shorewall/NAT
- file would make the lower left-hand system appear to have IP address
-130.252.100.18 and the right-hand one to have IP address 130.252.100.19.
-
-
-
-
- | EXTERNAL |
- INTERFACE |
- INTERNAL |
- ALL INTERFACES |
- LOCAL |
-
-
- | 130.252.100.18 |
- eth0 |
- 10.1.1.2 |
- yes |
- yes |
-
-
- | 130.252.100.19 |
- eth0 |
- 10.1.1.3 |
- yes |
- yes |
-
-
-
-
-
-Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the above
- example) is (are) not included in any specification in /etc/shorewall/masq
- or /etc/shorewall/proxyarp.
-
-Note 1: The "ALL INTERFACES" column is used
- to specify whether access to the external IP from all firewall interfaces
- should undergo NAT (Yes or yes) or if only access from the interface in
- the INTERFACE column should undergo NAT. If you leave this column empty,
- "Yes" is assumed. The ALL INTERFACES column was added in version 1.1.6.
-
-Note 2: Shorewall will automatically add the external address to the
- specified interface unless you specify ADD_IP_ALIASES="no" (or "No") in
- /etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or
-if you set it to "Yes" or "yes" then you must NOT configure your own alias(es).
- RESTRICTION: Shorewall versions earlier than 1.4.6 can only add
- external addresses to an interface that is configured with a single subnetwork
- -- if your external interface has addresses in more than one subnetwork,
-Shorewall 1.4.5 and earlier can only add addresses to the first one.
-
-Note 3: The contents of the "LOCAL" column
- determine whether packets originating on the firewall itself and destined
- for the EXTERNAL address are redirected to the internal ADDRESS. If
- this column contains "yes" or "Yes" (and the ALL INTERFACES COLUMN
-also contains "Yes" or "yes") then such packets are redirected; otherwise,
-such packets are not redirected. The LOCAL column was added in version
-1.1.8.
-
+One-to-one NAT
+
+IMPORTANT: If all you want to do is forward
+ports to servers behind your firewall, you do NOT want to use
+one-to-one NAT. Port forwarding can be accomplished with simple entries
+in the rules file.
-
-Last updated 7/6/2003 - One-to-one NAT is a way to make systems behind a firewall and
+configured
+with private IP addresses (those reserved for private use in RFC 1918)
+appear to have public IP addresses. Before you try to use this
+technique, I strongly recommend that you read the Shorewall Setup Guide.
+
+The following figure represents a one-to-one NAT environment.
+
+
+
+
+One-to-one NAT can be used to make the systems with the
+10.1.1.* addresses appear to be on the upper (130.252.100.*) subnet. If
+we assume that the interface to the upper subnet is eth0, then the
+following /etc/shorewall/NAT file would make the lower left-hand system
+appear to have IP address 130.252.100.18 and the right-hand one to have
+IP address 130.252.100.19.
+
+
+
+ | EXTERNAL |
+ INTERFACE |
+ INTERNAL |
+ ALL INTERFACES |
+ LOCAL |
+
+
+ | 130.252.100.18 |
+ eth0 |
+ 10.1.1.2 |
+ yes |
+ yes |
+
+
+ | 130.252.100.19 |
+ eth0 |
+ 10.1.1.3 |
+ yes |
+ yes |
+
+
+
+Be sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the
+above example) is (are) not included in any specification in
+/etc/shorewall/masq or /etc/shorewall/proxyarp.
+Note 1: The "ALL INTERFACES" column is
+used to specify whether access to the external IP from all firewall
+interfaces should undergo NAT (Yes or yes) or if only access from the
+interface in the INTERFACE column should undergo NAT. If you leave this
+column empty, "Yes" is assumed. The ALL INTERFACES column was
+added in version 1.1.6. Specifying
+"Yes" in this column will not allow systems on the lower LAN to access
+each other using their public IP addresses. For example, the
+lower left-hand system (10.1.1.2) cannot connect to 130.252.100.19 and
+expect to be connected to the lower right-hand system. See FAQ 2a.
+
+Note 2: Shorewall will automatically add the external address to the
+specified interface unless you specify ADD_IP_ALIASES="no" (or "No") in
+/etc/shorewall/shorewall.conf; If you do not set ADD_IP_ALIASES or
+if you set it to "Yes" or "yes" then you must NOT configure your own
+alias(es). RESTRICTION: Shorewall versions earlier than 1.4.6
+can only add external addresses to an interface that is configured with
+a single subnetwork -- if your external interface has addresses in more
+than one subnetwork,
+Shorewall 1.4.5 and earlier can only add addresses to the first one.
+Note 3: The contents of the "LOCAL"
+column determine whether packets originating on the firewall itself and
+destined for the EXTERNAL address are redirected to the internal
+ADDRESS. If this column contains "yes" or "Yes" (and the ALL INTERFACES
+COLUMN
+also contains "Yes" or "yes") then such packets are redirected;
+otherwise,
+such packets are not redirected. The LOCAL column was added in version
+1.1.8.
+
+Last updated 11/222003 - Tom Eastep
- Copyright © Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
-
+
+
diff --git a/Shorewall-docs/NetfilterOverview.html b/Shorewall-docs/NetfilterOverview.html
new file mode 100755
index 000000000..6050d6bfa
--- /dev/null
+++ b/Shorewall-docs/NetfilterOverview.html
@@ -0,0 +1,104 @@
+
+
+
+
+
+
+
+ Netfilter Overview
+
+
+
+
+Netfilter Overview
+
+Netfilter consists of three tables: Filter, Nat and Mangle. Each table has a number of
+build-in chains: PREROUTING,
+INPUT, FORWARD, OUTPUT and POSTROUTING.
+
+Rules in the various tables are used as follows:
+
+ - Filter: Packet filtering
+(rejecting, dropping or accepting packets)
+ - Nat: Network Address
+Translation including DNAT, SNAT and Masquerading
+ - Mangle: General packet
+header modification such as setting the TOS value or marking packets
+for policy routing and traffic shaping.
+
+
+The following diagram shows how packets traverse the various builtin
+chains within Netfilter. Note that not all table/chain combinations are
+used.
+
+
+
+
+"Local Process" means a process running on the Shorewall system itself.
+
+In the above diagram are boxes similar to this:
+
+ 
+
+The above box gives the name of the built-in chain ( INPUT) along with the names of the tables ( Mangle and Filter) that the chain exists in and
+in the order that the chains are traversed. The above sample indicates
+that packets go first through the INPUT
+chain of the Mangle table
+then
+through the INPUT chain of the
+ Filter table. When a chain is
+enclosed in parentheses, Shorewall does not use the named chain ( INPUT) in that table (Mangle).
+
+ IMPORTANT: Keep in mind that
+chains in the Nat table are only traversed for new connection
+requests (including those related to existing connections) while
+the chains in the other tables are traversed on every packet.
+
+The above diagram should help you understand the output of "shorewall
+status".
+
+Here are some excerpts from "shorewall status" on a server with one
+interface (eth0):
+
+ [root@lists html]# shorewall status
Shorewall-1.4.7 Status at lists.shorewall.net - Mon Oct 13 12:51:13 PDT 2003
Counters reset Sat Oct 11 08:12:57 PDT 2003
+The first table shown is the Filter table.
+
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
679K 182M ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0
785K 93M accounting all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
+The following rule indicates that all traffic destined for the firewall
+that comes into the firewall on eth0 is passed to a chain called
+"eth0_in". That chain will be shown further down.
+ 785K 93M eth0_in all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 accounting all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
0 0 eth0_fwd all -- eth0 * 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:FORWARD:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination
679K 182M ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0
922K 618M accounting all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
922K 618M fw2net all -- * eth0 0.0.0.0/0 0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0 0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:OUTPUT:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
+Here is the eth0_in chain:
+ Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
785K 93M dynamic all -- * * 0.0.0.0/0 0.0.0.0/0
785K 93M net2fw all -- * * 0.0.0.0/0 0.0.0.0/0
+The "dynamic" chain above is where dynamic blacklisting is done.
+
+Next comes the Nat table:
+ NAT Table
Chain PREROUTING (policy ACCEPT 182K packets, 12M bytes)
pkts bytes target prot opt in out source destination
20005 1314K net_dnat all -- eth0 * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 678K packets, 44M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 678K packets, 44M bytes)
pkts bytes target prot opt in out source destination
Chain net_dnat (1 references)
pkts bytes target prot opt in out source destination
638 32968 REDIRECT tcp -- * * 0.0.0.0/0 !206.124.146.177 tcp dpt:80 redir ports 3128
+And finally, the Mangle table:
+ Mangle Table
Chain PREROUTING (policy ACCEPT 14M packets, 2403M bytes)
pkts bytes target prot opt in out source destination
1464K 275M pretos all -- * * 0.0.0.0/0 0.0.0.0/0
Chain INPUT (policy ACCEPT 14M packets, 2403M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 15M packets, 7188M bytes)
pkts bytes target prot opt in out source destination
1601K 800M outtos all -- * * 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 15M packets, 7188M bytes)
pkts bytes target prot opt in out source destination
Chain outtos (1 references)
pkts bytes target prot opt in out source destination
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 TOS set 0x10
315K 311M TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 TOS set 0x10
683 59143 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 TOS set 0x10
3667 5357K TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20 TOS set 0x08
Chain pretos (1 references)
pkts bytes target prot opt in out source destination
271K 15M TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:22 TOS set 0x10
730 41538 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:20 TOS set 0x08
2065 111K TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20 TOS set 0x08
+
+
+ Last updated 10/14/2003 - Tom Eastep
+Copyright
+© 2003 Thomas M. Eastep.
+
+
+
+
diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm
index 2497af2f7..090e316b3 100644
--- a/Shorewall-docs/News.htm
+++ b/Shorewall-docs/News.htm
@@ -8,17 +8,287 @@
-
-
-
-
- Shorewall News Archive
- |
-
-
-
+Shorewall News Archive
+
+11/07/2003 - Shorewall 1.4.8
+
+Problems Corrected since version 1.4.7:
+
+
+ - Tuomo Soini has supplied a correction to a problem that occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+ - Andres Zhoglo has supplied a correction that avoids trying to use
+the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued, Shorewall
+was left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has been
+corrected.
+ - In Shorewall 1.4.2, an optimization was added. This optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F" or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
+ - An incorrect comment concerning Debian's use of the SUBSYSLOCK
+option has been removed from shorewall.conf.
+ - Previously, neither the 'routefilter' interface option nor the
+ROUTE_FILTER parameter were working properly. This has been corrected
+(thanks to Eric Bowles for his analysis and patch). The definition of
+the ROUTE_FILTER option has changed however. Previously,
+ROUTE_FILTER=Yes was documented as enabling route filtering on all
+interfaces (which didn't work). Beginning with this release, setting
+ROUTE_FILTER=Yes will enable route filtering of all interfaces brought
+up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can
+coexist with the use of the 'routefilter' option in the interfaces file.
+ - If MAC verification was enabled on an interface with a /32
+address and a broadcast address then an error would occur during
+startup.
+ - The NONE policy's intended use is to suppress the generating of
+rules that can't possibly be traversed. This means that a policy of
+NONE is inappropriate where the source or destination zone is $FW or
+"all". Shorewall now generates an error message if such a policy is
+given in /etc/shorewall/policy. Previously such a policy caused
+"shorewall start" to fail.
+ - The 'routeback' option was broken for wildcard interfaces (e.g.,
+"tun+"). This has been corrected so that 'routeback' now works as
+expected in this case.
+
+
+Migration Issues:
+
+ - The definition of the ROUTE_FILTER option in shorewall.conf has
+changed as described in item 8) above.
+
+
+New Features:
+
+ - A new QUEUE action has been introduced for rules. QUEUE allows
+you to pass connection requests to a user-space filter such as ftwall
+(http://p2pwall.sourceforge.net). The ftwall program allows for
+effective filtering of p2p applications such as Kazaa. For example, to
+use ftwall to filter P2P clients in the 'loc' zone, you would add the
+following rules:
+
+ QUEUE loc
+ net tcp
+ QUEUE loc
+ net udp
+ QUEUE loc
+ fw udp
+
+You would normally want to place those three rules BEFORE any ACCEPT
+rules for loc->net udp or tcp.
+
+Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
+Shorewall will only pass connection requests (SYN packets) to user
+space. This is for compatibility with ftwall.
+ - A BLACKLISTNEWNONLY option has been added to shorewall.conf. When
+this option is set to "Yes", the blacklists (dynamic and static) are
+only consulted for new connection requests. When set to "No" (the
+default if the variable is not set), the blacklists are consulted on
+every packet.
+
+Setting this option to "No" allows blacklisting to stop existing
+connections from a newly blacklisted host but is more expensive in
+terms of packet processing time. This is especially true if the
+blacklists contain a large number of entries.
+ - Chain names used in the /etc/shorewall/accounting file may now
+begin with a digit ([0-9]) and may contain embedded dashes ("-").
+
+10/30/2003 - Shorewall 1.4.8 RC1
+
+Given the small number of new features and the relatively few lines of
+code that were changed, there will be no Beta for 1.4.8.
+http://shorewall.net/pub/shorewall/Beta
+ftp://shorewall.net/pub/shorewall/Beta
+
+Problems Corrected since version 1.4.7:
+
+
+ - Tuomo Soini has supplied a correction to a problem that occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+ - Andres Zhoglo has supplied a correction that avoids trying to use
+the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued, Shorewall
+was left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has been
+corrected.
+ - In Shorewall 1.4.2, an optimization was added. This optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F" or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
+ - An incorrect comment concerning Debian's use of the SYBSYSLOCK
+option has been removed from shorewall.conf.
+ - Previously, neither the 'routefilter' interface option nor the
+ROUTE_FILTER parameter were working properly. This has been corrected
+(thanks to Eric Bowles for his analysis and patch). The definition of
+the ROUTE_FILTER option has changed however. Previously,
+ROUTE_FILTER=Yes was documented as enabling route filtering on all
+interfaces (which didn't work). Beginning with this release, setting
+ROUTE_FILTER=Yes will enable route filtering of all interfaces brought
+up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can
+coexist with the use of the 'routefilter' option in the interfaces file.
+
+Migration Issues:
+
+ - The definition of the ROUTE_FILTER option in shorewall.conf has
+changed as described in item 8) above.
+
+
+New Features:
+
+ - A new QUEUE action has been introduced for rules. QUEUE allows
+you to pass connection requests to a user-space filter such as ftwall
+(http://p2pwall.sourceforge.net). The ftwall program allows for
+effective filtering of p2p applications such as Kazaa. For example, to
+use ftwall to filter P2P clients in the 'loc' zone, you would add the
+following rules:
+
+ QUEUE loc
+ net tcp
+ QUEUE loc
+ net udp
+ QUEUE loc
+ fw udp
+
+You would normally want to place those three rules BEFORE any ACCEPT
+rules for loc->net udp or tcp.
+
+Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
+Shorewall will only pass connection requests (SYN packets) to user
+space. This is for compatibility with ftwall.
+ - A BLACKLISTNEWNONLY option has been added to shorewall.conf. When
+this option is set to "Yes", the blacklists (dynamic and static) are
+only consulted for new connection requests. When set to "No" (the
+default if the variable is not set), the blacklists are consulted on
+every packet.
+
+Setting this option to "No" allows blacklisting to stop existing
+connections from a newly blacklisted host but is more expensive in
+terms of packet processing time. This is especially true if the
+blacklists contain a large number of entries.
+ - Chain names used in the /etc/shorewall/accounting file may now
+begin with a digit ([0-9]) and may contain embedded dashes ("-").
+
+
+
+10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper bag
+awards  Shorewall
+1.4.7c released.
+
+ - The saga with "<zone>_frwd" chains continues. The 1.4.7c
+script produces a ruleset that should work for everyone even if it is
+not quite optimal. My apologies for this ongoing mess.
+
+
+10/24/2003 - Shorewall 1.4.7b
+This is a bugfx rollup of the 1.4.7a fixes plus:
+
+ - The fix for problem 5 in 1.4.7a was wrong with the result that
+"<zone>_frwd" chains might contain too few rules. That wrong code
+is corrected in this release.
+
+
+10/21/2003 - Shorewall 1.4.7a
+
+This is a bugfix rollup of the following problem corrections:
+
+
+ - Tuomo Soini has supplied a correction to a problem that occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+
+
+ - Andres Zhoglo has supplied a correction that avoids trying to use
+the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued, Shorewall
+was left in an inconsistent state.
+
+ Error: Unable to determine the routes through
+interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has been
+corrected.
+ - In Shorewall 1.4.2, an optimization was added. This optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F" or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
+
+
10/06/2003 - Shorewall 1.4.7
Problems Corrected since version 1.4.6 (Those in bold font were
@@ -290,7 +560,7 @@ where we started.
show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
- Output rules (those with $FW as the SOURCE) may now be
limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html
+ href="UserSets.html">http://shorewall.net/UserSets.html
for details.
10/02/2003 - Shorewall 1.4.7 RC2
@@ -555,7 +825,7 @@ where we started.
show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
- Output rules (those with $FW as the SOURCE) may now be
limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html
+ href="UserSets.html">http://shorewall.net/UserSets.html
for details.
9/18/2003 - Shorewall 1.4.7 RC 1
@@ -997,7 +1267,7 @@ where we started.
show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
- Output rules (those with $FW as the SOURCE) may now be
limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html
+ href="UserSets.html">http://shorewall.net/UserSets.html
for details.
8/27/2003 - Shorewall Mirror in Australia
@@ -1554,8 +1824,7 @@ ADDRESS column in /etc/shorewall/masq may now include a comma-separated
list of addresses and/or address ranges. Netfilter will use all listed
addresses/ranges in round-robin fashion. \
- An /etc/shorewall/accounting file has been added to allow for
-traffic accounting. See the accounting
+traffic accounting. See the accounting
documentation for a description of this facility.
- Bridge interfaces (br[0-9]) may now be used in
/etc/shorewall/maclist.
@@ -4550,7 +4819,7 @@ deleted.
an additional "gw" (gateway) zone for tunnels and it supports IPSEC
tunnels with end-points on the firewall. There is also a .lrp available
now.
-Updated 10/06/2003 - Tom Eastep
+Updated 11/07/2003 - Tom Eastep
Copyright © 2001, 2002 Thomas M. Eastep.
diff --git a/Shorewall-docs/OPENVPN.html b/Shorewall-docs/OPENVPN.html
index 8a673f957..fdf39157b 100755
--- a/Shorewall-docs/OPENVPN.html
+++ b/Shorewall-docs/OPENVPN.html
@@ -1,284 +1,232 @@
-
OpenVPN Tunnels
-
-
-
-
-
-
-
-
- OpenVPN Tunnels
- |
-
-
-
-
-
-
-
-
-OpenVPN is a robust and highly configurable VPN (Virtual Private Network)
- daemon which can be used to securely link two or more private networks using
- an encrypted tunnel over the internet. OpenVPN is an Open Source project
-and is licensed under
-the GPL. OpenVPN can be downloaded from
+OpenVPN Tunnels
+
+OpenVPN is a robust and highly configurable VPN (Virtual Private
+Network) daemon which can be used to securely link two or more private
+networks using an encrypted tunnel over the internet. OpenVPN is an
+Open Source project and is licensed under the
+GPL. OpenVPN can be downloaded from http://openvpn.sourceforge.net/.
-
-
+
OpenVPN support was added to Shorewall in version 1.3.14.
-
-
+
Bridging two Masqueraded Networks
-
Suppose that we have the following situation:
-
-
-
-We want systems in the 192.168.1.0/24 subnetwork to be able
- to communicate with the systems in the 10.0.0.0/8 network. This is accomplished
- through use of the /etc/shorewall/tunnels file and the /etc/shorewall/policy
- file and OpenVPN.
-
-While it was possible to use the Shorewall start and stop
- script to start and stop OpenVPN, I decided to use the init script of OpenVPN
- to start and stop it.
-
-On each firewall, you will need to declare a zone to represent
- the remote subnet. We'll assume that this zone is called 'vpn' and declare
- it in /etc/shorewall/zones on both systems as follows.
-
-
+ height="427">
+We want systems in the 192.168.1.0/24 subnetwork to be
+able to communicate with the systems in the 10.0.0.0/8 network. This is
+accomplished through use of the /etc/shorewall/tunnels file and the
+/etc/shorewall/policy file and OpenVPN.
+While it was possible to use the Shorewall start and
+stop script to start and stop OpenVPN, I decided to use the init script
+of OpenVPN to start and stop it.
+On each firewall, you will need to declare a zone to
+represent the remote subnet. We'll assume that this zone is called
+'vpn' and declare it in /etc/shorewall/zones on both systems as follows.
+
-
-
- | ZONE |
- DISPLAY |
- COMMENTS |
-
-
- | vpn |
- VPN |
- Remote Subnet |
-
-
-
+
+
+ | ZONE |
+ DISPLAY |
+ COMMENTS |
+
+
+ | vpn |
+ VPN |
+ Remote Subnet |
+
+
-
-
-On system A, the 10.0.0.0/8 will comprise the vpn zone.
+
+On system A, the 10.0.0.0/8 will comprise the vpn
+zone.
In /etc/shorewall/interfaces:
-
-
+
-
-
- | ZONE |
- INTERFACE |
- BROADCAST |
- OPTIONS |
-
-
- | vpn |
- tun0 |
-
- |
- |
-
-
-
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ | vpn |
+ tun0 |
+
+ |
+ |
+
+
-
-
-In /etc/shorewall/tunnels on system A, we need the following:
-
-
+
+In /etc/shorewall/tunnels on system A, we need the
+following:
+
-
-
- | TYPE |
- ZONE |
- GATEWAY |
- GATEWAY ZONE |
-
-
- | openvpn |
- net |
- 134.28.54.2 |
- |
-
-
-
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ | openvpn |
+ net |
+ 134.28.54.2 |
+ |
+
+
-
-
-This entry in /etc/shorewall/tunnels opens the firewall so that OpenVPN
- traffic on the default port 5000/udp will be accepted to/from the remote
-gateway. If you change the port used by OpenVPN to 7777, you can define /etc/shorewall/tunnels
- like this:
-
-
-
+
+This entry in /etc/shorewall/tunnels opens the firewall so that
+OpenVPN traffic on the default port 5000/udp will be accepted to/from
+the remote gateway. If you change the port used by OpenVPN to 7777, you
+can define /etc/shorewall/tunnels like this:
+
+
-
-
- | TYPE |
- ZONE |
- GATEWAY |
- GATEWAY ZONE |
-
-
- | openvpn:7777 |
- net |
- 134.28.54.2 |
- |
-
-
-
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ | openvpn:7777 |
+ net |
+ 134.28.54.2 |
+ |
+
+
-
-
+
This is the OpenVPN config on system A:
-
-
+
-
-
-
+
+
dev tun
- local 206.162.148.9
- remote 134.28.54.2
- ifconfig 192.168.99.1 192.168.99.2
- up ./route-a.up
- tls-server
- dh dh1024.pem
- ca ca.crt
- cert my-a.crt
- key my-a.key
- comp-lzo
- verb 5
-
-
-
-Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn
- zone. In /etc/shorewall/interfaces:
-
-
-
-
-
- | ZONE |
- INTERFACE |
- BROADCAST |
- OPTIONS |
-
-
- | vpn |
- tun0 |
- 192.168.1.255 |
- |
-
-
-
-
-
-
-In /etc/shorewall/tunnels on system B, we have:
-
-
-
-
-
- | TYPE |
- ZONE |
- GATEWAY |
- GATEWAY ZONE |
-
-
- | openvpn |
- net |
- 206.191.148.9 |
- |
-
-
-
-
-
-
-And in the OpenVPN config on system B:
-
-
- dev tun
- local 134.28.54.2
- remote 206.162.148.9
- ifconfig 192.168.99.2 192.168.99.1
- up ./route-b.up
- tls-client
- ca ca.crt
- cert my-b.crt
- key my-b.key
- comp-lzo
- verb 5
-
-
-
-You will need to allow traffic between the "vpn" zone and
- the "loc" zone on both systems -- if you simply want to admit all traffic
- in both directions, you can use the policy file:
-
-
-
-
-
- | SOURCE |
- DEST |
- POLICY |
- LOG LEVEL |
-
-
- | loc |
- vpn |
- ACCEPT |
- |
-
-
- | vpn |
- loc |
- ACCEPT |
- |
-
-
-
-
-
-
-On both systems, restart Shorewall and start OpenVPN. The systems in the
- two masqueraded subnetworks can now talk to each other.
-
-Updated 2/4/2003 - Tom Eastep
-and Simon Mater
+local 206.162.148.9
+remote 134.28.54.2
+ifconfig 192.168.99.1 192.168.99.2
+up ./route-a.up
+tls-server
+dh dh1024.pem
+ca ca.crt
+cert my-a.crt
+key my-a.key
+comp-lzo
+verb 5
-
+
+Similarly, On system B the 192.168.1.0/24 subnet will comprise the vpn
+zone. In /etc/shorewall/interfaces:
+
+
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ | vpn |
+ tun0 |
+ 192.168.1.255 |
+ |
+
+
+
+
+In /etc/shorewall/tunnels on system B, we have:
+
+
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ | openvpn |
+ net |
+ 206.191.148.9 |
+ |
+
+
+
+
+And in the OpenVPN config on system B:
+
+ dev tun
+local 134.28.54.2
+remote 206.162.148.9
+ifconfig 192.168.99.2 192.168.99.1
+up ./route-b.up
+tls-client
+ca ca.crt
+cert my-b.crt
+key my-b.key
+comp-lzo
+verb 5
+
+
+You will need to allow traffic between the "vpn" zone
+and the "loc" zone on both systems -- if you simply want to admit all
+traffic in both directions, you can use the policy file:
+
+
+
+
+ | SOURCE |
+ DEST |
+ POLICY |
+ LOG LEVEL |
+
+
+ | loc |
+ vpn |
+ ACCEPT |
+ |
+
+
+ | vpn |
+ loc |
+ ACCEPT |
+ |
+
+
+
+
+On both systems, restart Shorewall and start OpenVPN. The systems in
+the two masqueraded subnetworks can now talk to each other.
+Updated 2/4/2003 - Tom Eastep
+and Simon Mater
+
-
-Copyright
- © 2003 Thomas M. Eastep. and Simon Mater
-
-
-
-
-
+Copyright
+© 2003 Thomas M. Eastep. and Simon Mater
+
+
+
+
+
diff --git a/Shorewall-docs/PPTP.htm b/Shorewall-docs/PPTP.htm
index aac549f73..9951bdb42 100644
--- a/Shorewall-docs/PPTP.htm
+++ b/Shorewall-docs/PPTP.htm
@@ -9,17 +9,8 @@
Shorewall PPTP
-
+PPTP
+
NOTE: I am no longer attempting to maintain MPPE patches for
current
Linux kernel's and pppd. I recommend that you refer to the following
@@ -263,9 +254,191 @@ status)
esac
Configuring Shorewall
-I consider hosts connected to my PPTP server to be just like local
-systems.
-My key Shorewall entries are:
+Basic Setup
+
+Here' a basic setup that treats your remote users as if they were
+part of your loc zone. Note
+that if your primary internet connection uses ppp0, then be sure that loc follows net in /etc/shorewall/zones.
+
+/etc/shorewall/tunnels:
+
+
+
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ pptpserver
+ |
+ net |
+ 0.0.0.0/0
+ |
+ |
+
+
+
+
+/etc/shorewall/interfaces:
+
+
+
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ loc
+ |
+ ppp+ |
+ - |
+
+ |
+
+
+
+
+Remote Users in a Separate Zone
+If you want to place your remote users in their own zone so that you
+can control connections between these users and the local network,
+follow this example. Note that if your primary internet connection uses
+ppp0 then be sure that vpn
+follows net in
+/etc/shorewall/zones as shown below.
+
+/etc/shorewall/tunnels:
+
+
+
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ pptpserver
+ |
+ net |
+ 0.0.0.0/0
+ |
+ |
+
+
+
+
+/etc/shorewall/zones:
+
+
+
+
+
+ | ZONE |
+ DISPLAY |
+ COMMENTS |
+
+
+ | net |
+ Internet |
+ The Internet |
+
+
+ | loc |
+ Local |
+ Local Network
+ |
+
+
+ | vpn |
+ VPN
+ |
+ Remote Users
+ |
+
+
+
+
+/etc/shorewall/interfaces:
+
+
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ | net |
+ eth0 |
+ 206.124.146.255 |
+ norfc1918 |
+
+
+ | loc |
+ eth2 |
+ 192.168.10.255 |
+ |
+
+
+ vpn
+ |
+ ppp+ |
+ - |
+
+ |
+
+
+
+
+Your policies and rules may now be configured for traffic to/from the vpn zone.
+Multiple Remote Networks
+
+Often there will be situations where you want multiple connections
+from remote networks with these networks having different firewalling
+requirements.
+
+
+ Here's how you configure this in Shorewall. Note that if your
+primary internet connection uses ppp0 then be sure that the vpn{1-3} zones follows net in /etc/shorewall/zones as shown
+below.
+
+/etc/shorewall/tunnels:
+
+
+
+
+
+ | TYPE |
+ ZONE |
+ GATEWAY |
+ GATEWAY ZONE |
+
+
+ pptpserver
+ |
+ net |
+ 0.0.0.0/0
+ |
+ |
+
+
+
+
/etc/shorewall/zones:
@@ -283,7 +456,31 @@ My key Shorewall entries are:
| loc |
Local |
- My Local Network including remote PPTP clients |
+ Local Network
+ |
+
+
+ | vpn1 |
+ Remote1
+ |
+ Remote Network 1
+ |
+
+
+ vpn2
+ |
+ Remote2
+ |
+ Remote Network 2
+ |
+
+
+ vpn3
+ |
+ Remote3
+ |
+ Remote Network 3
+ |
@@ -307,13 +504,13 @@ My key Shorewall entries are:
| loc |
eth2 |
- 192.168.1.255 |
+ 192.168.10.255 |
|
| - |
ppp+ |
- |
+ - |
|
|
@@ -329,151 +526,32 @@ My key Shorewall entries are:
OPTIONS |
- | loc |
- eth2:192.168.1.0/24 |
-
+ | vpn1
|
-
-
- | loc |
ppp+:192.168.1.0/24 |
|
-
-
-
-/etc/shorewall/policy:
-
-
-
- | SOURCE |
- DEST |
- POLICY |
- LOG LEVEL |
-
-
- | loc |
- loc |
- ACCEPT |
- |
-
-
-
-
-/etc/shorewall/rules (For Shorewall versions up to and including
-1.3.9b):
-
-
-
-
- | ACTION |
- SOURCE |
- DEST |
- PROTO |
- DEST
-PORT(S) |
- SOURCE
-PORT(S) |
- ORIGINAL
-DEST |
-
-
- | ACCEPT |
- net |
- fw |
- tcp |
- 1723 |
- |
- |
-
-
- | ACCEPT |
- net |
- fw |
- 47 |
- - |
- |
- |
-
-
- | ACCEPT |
- fw |
- net |
- 47 |
- - |
- |
- |
-
-
-
-
-/etc/shoreawll/tunnels (For Shorewall versions
-1.3.10 and
-later)
-
-
-
-
-
- TYPE
- |
- ZONE
- |
- GATEWAY
- |
- GATEWAY ZONE
- |
-
-
- pptpserver
+ | vpn2
|
- net
+ | ppp+:192.168.2.0/24
|
- 0.0.0.0/0
+ |
|
-
+ |
+
+ vpn3
+ |
+ ppp+:192.168.3.0/24
+ |
+
|
-
-Note: I have multiple ppp interfaces on my firewall. If you have a
-single
-ppp interface, you probably want:
-/etc/shorewall/interfaces:
-
-
-
-
- | ZONE |
- INTERFACE |
- BROADCAST |
- OPTIONS |
-
-
- | net |
- eth0 |
- 206.124.146.255 |
- norfc1918 |
-
-
- | loc |
- eth2 |
- 192.168.1.255 |
- |
-
-
- | loc |
- ppp0 |
- |
- |
-
-
-
-
-and no entries in /etc/shorewall/hosts.
+Your policies and rules can now be configured using separate zones
+(vpn1, vpn2, and vpn3) for the three remote network.
2. PPTP Server Running
Behind
your Firewall
@@ -968,7 +1046,7 @@ as described in the QuickStart Guide corresponding to your setup.
That entry allows a PPTP tunnel to be established between your
Shorewall system and the PPTP server in the modem.
-Last modified 8/11/2003 - Tom
+Last modified 11/22/2003 - Tom
Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/ProxyARP.htm b/Shorewall-docs/ProxyARP.htm
index 538a880b4..69828a93a 100644
--- a/Shorewall-docs/ProxyARP.htm
+++ b/Shorewall-docs/ProxyARP.htm
@@ -1,192 +1,165 @@
-
Shorewall Proxy ARP
-
-
-
-
-
-
-
-
-
- Proxy ARP
- |
-
-
-
-
-
-Proxy ARP allows you to insert a firewall in front of a set of servers
- without changing their IP addresses and without having to re-subnet.
- Before you try to use this technique, I strongly recommend that you read
-the Shorewall Setup Guide.
-
-The following figure represents a Proxy ARP environment.
-
-
- 
-
-
-
-
-
-Proxy ARP can be used to make the systems with addresses
- 130.252.100.18 and 130.252.100.19 appear to be on the upper (130.252.100.*)
- subnet. Assuming that the upper firewall interface is eth0 and the
- lower interface is eth1, this is accomplished using the following entries
- in /etc/shorewall/proxyarp:
-
-
+
+Proxy ARP
+
+Proxy ARP allows you to insert a firewall in front of a set of
+servers without changing their IP addresses and without having to
+re-subnet. Before you try to use this technique, I strongly recommend
+that you read the Shorewall Setup
+Guide.
+The following figure represents a Proxy ARP environment.
+
+
+
+
+Proxy ARP can be used to make the systems with
+addresses 130.252.100.18 and 130.252.100.19 appear to be on the upper
+(130.252.100.*) subnet. Assuming that the upper firewall
+interface is eth0 and the lower interface is eth1, this is accomplished
+using the following entries in /etc/shorewall/proxyarp:
+
-
-
- | ADDRESS |
- INTERFACE |
- EXTERNAL |
- HAVEROUTE |
-
-
- | 130.252.100.18 |
- eth1 |
- eth0 |
- no |
-
-
- | 130.252.100.19 |
- eth1 |
- eth0 |
- no |
-
-
-
+
+
+ | ADDRESS |
+ INTERFACE |
+ EXTERNAL |
+ HAVEROUTE |
+
+
+ | 130.252.100.18 |
+ eth1 |
+ eth0 |
+ no |
+
+
+ | 130.252.100.19 |
+ eth1 |
+ eth0 |
+ no |
+
+
-
-
-Be sure that the internal systems (130.242.100.18 and 130.252.100.19
- in the above example) are not included in any specification in /etc/shorewall/masq
-or /etc/shorewall/nat.
-
-Note that I've used an RFC1918 IP address for eth1 - that IP address is
- irrelevant.
-
-The lower systems (130.252.100.18 and 130.252.100.19) should have their
- subnet mask and default gateway configured exactly the same way that
- the Firewall system's eth0 is configured. In other words, they should
-be configured just like they would be if they were parallel to the firewall
-rather than behind it.
-
-
-NOTE: Do not add the Proxy ARP'ed address(es)
-(130.252.100.18 and 130.252.100.19 in the above example) to the external
-interface (eth0 in this example) of the firewall.
-
-
-
-
-
-
A word of warning is in order here. ISPs typically configure
- their routers with a long ARP cache timeout. If you move a system from
- parallel to your firewall to behind your firewall with Proxy ARP, it
-will probably be HOURS before that system can communicate with the internet.
- There are a couple of things that you can try:
-
-
+
+
Be sure that the internal systems (130.242.100.18 and
+130.252.100.19 in the above example) are not included in any
+specification in /etc/shorewall/masq or /etc/shorewall/nat.
+
Note that I've used an RFC1918 IP address for eth1 - that IP address
+is irrelevant.
+
The lower systems (130.252.100.18 and 130.252.100.19) should have
+their subnet mask and default gateway configured exactly the same way
+that the Firewall system's eth0 is configured. In other words, they
+should be configured just like they would be if they were parallel to
+the firewall rather than behind it.
+
+
NOTE: Do not add the Proxy ARP'ed
+address(es) (130.252.100.18 and 130.252.100.19 in the above
+example) to the external interface (eth0 in this example) of the
+firewall.
+
+
+
+
A word of warning is in order here. ISPs typically
+configure their routers with a long ARP cache timeout. If you move a
+system from parallel to your firewall to behind your firewall with
+Proxy ARP, it
+will probably be HOURS before that system can communicate with the
+internet. There are a couple of things that you can try:
+
- - (Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
-Illustrated, Vol 1 reveals that a
-
- "gratuitous" ARP packet should cause the ISP's router to refresh their
-ARP cache (section 4.7). A gratuitous ARP is simply a host requesting the
-MAC address for its own IP; in addition to ensuring that the IP address
-isn't a duplicate...
-
- "if the host sending the gratuitous ARP has just changed its hardware
-address..., this packet causes any other host...that has an entry in its
-cache for the old hardware address to update its ARP cache entry accordingly."
-
- Which is, of course, exactly what you want to do when you switch a host
- from being exposed to the Internet to behind Shorewall using proxy ARP (or
- static NAT for that matter). Happily enough, recent versions of Redhat's
-iputils package include "arping", whose "-U" flag does just that:
-
- arping -U -I <net if> <newly
-proxied IP>
- arping -U -I eth0 66.58.99.83 # for example
-
- Stevens goes on to mention that not all systems respond correctly to
-gratuitous ARPs, but googling for "arping -U" seems to support the idea
-that it works most of the time.
-
- To use arping with Proxy ARP in the above example, you would have to:
-
- shorewall clear
- ip addr add 130.252.100.18
-dev eth0
- ip addr add 130.252.100.19 dev eth0
- arping -U -I eth0 130.252.100.18
- arping -U -I eth0 130.252.100.19
- ip addr del 130.252.100.18 dev eth0
- ip addr del 130.252.100.19 dev eth0
- shorewall start
-
-
- - You can call your ISP and ask them to purge the stale ARP cache
- entry but many either can't or won't purge individual entries.
-
-
- You can determine if your ISP's gateway ARP cache is stale using ping
- and tcpdump. Suppose that we suspect that the gateway router has a stale
- ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as follows:
-
-
-
tcpdump -nei eth0 icmp
-
-
-
-
Now from 130.252.100.19, ping the ISP's gateway (which we
- will assume is 130.252.100.254):
-
-
-
-
-
-
We can now observe the tcpdump output:
-
-
-
-
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply
-
-
-
-
Notice that the source MAC address in the echo request is
- different from the destination MAC address in the echo reply!! In this
- case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while 0:c0:a8:50:b2:57
- was the MAC address of the system on the lower left. In other words,
-the gateway's ARP cache still associates 130.252.100.19 with the NIC
-in that system rather than with the firewall's eth0.
-
-
-
Last updated 3/21/2003 - Tom Eastep
-
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
+
(Courtesy of Bradey Honsinger) A reading of Stevens' TCP/IP
+Illustrated, Vol 1 reveals that a
-
-
-
+"gratuitous" ARP packet should cause the ISP's router to refresh their
+ARP cache (section 4.7). A gratuitous ARP is simply a host requesting
+the MAC address for its own IP; in addition to ensuring that the IP
+address
+isn't a duplicate...
+
+"if the host sending the gratuitous ARP has just changed its hardware
+address..., this packet causes any other host...that has an entry in
+its cache for the old hardware address to update its ARP cache entry
+accordingly."
+
+Which is, of course, exactly what you want to do when you switch a host
+from being exposed to the Internet to behind Shorewall using proxy ARP
+(or one-to-one NAT for that matter). Happily enough, recent versions of
+Redhat's iputils package include "arping", whose "-U" flag does just
+that:
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens goes on to mention that not all systems respond correctly to
+gratuitous ARPs, but googling for "arping -U" seems to support the idea
+that it works most of the time.
+
+To use arping with Proxy ARP in the above example, you would have to:
+
+ shorewall clear
+ ip addr add
+130.252.100.18 dev eth0
+ ip addr add 130.252.100.19 dev eth0
+ arping -U -I eth0
+130.252.100.18
+ arping -U -I eth0 130.252.100.19
+ ip addr del 130.252.100.18 dev
+eth0
+ ip addr del 130.252.100.19 dev eth0
+ shorewall start
+
+
+
You can call your ISP and ask them to purge the stale ARP cache
+entry but many either can't or won't purge individual entries.
+
+You can determine if your ISP's gateway ARP cache is stale using ping
+and tcpdump. Suppose that we suspect that the gateway router has a
+stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump
+as follows:
+
tcpdump -nei eth0 icmp
+
+
Now from 130.252.100.19, ping the ISP's gateway (which
+we will assume is 130.252.100.254):
+
+
We can now observe the tcpdump output:
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo reply
+
+
Notice that the source MAC address in the echo request
+is different from the destination MAC address in the echo reply!! In
+this case 0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
+0:c0:a8:50:b2:57 was the MAC address of the system on the lower left.
+In other words,
+the gateway's ARP cache still associates 130.252.100.19 with the NIC
+in that system rather than with the firewall's eth0.
+
Last updated 11/13/2003 - Tom Eastep
+Copyright © 2001, 2002, 2003 Thomas M. Eastep.
+
+
+
+
diff --git a/Shorewall-docs/SeattleInTheSpring.html b/Shorewall-docs/SeattleInTheSpring.html
index a3207f8b3..31c8c8231 100755
--- a/Shorewall-docs/SeattleInTheSpring.html
+++ b/Shorewall-docs/SeattleInTheSpring.html
@@ -1,53 +1,34 @@
-
Springtime in Seattle!!!
-
-
-
-
-
-
-
-
- Visit Seattle in the Springtime!!!!
- |
-
-
-
-
-
+
+-+
- 
-
-
- March 6, 2003 - Nice day for a walk....
-
- 
-
-
-
- 
-
-The view from my office window -- think I'll go out and enjoy the deck
-(Yes -- that is snow on the deck...).
-
-
-Updated 3/7/2003 - Tom Eastep
+Visit Seattle in the Springtime!!!
+
+
+
+March 6, 2003 - Nice day for a walk....
+
+
+
+
+
+The view from my office window -- think I'll go out and enjoy the
+deck (Yes -- that is snow on the deck...).
+
+Updated 3/7/2003 - Tom Eastep
-
-Copyright © Copyright © 2001, 2002 Thomas M. Eastep.
-
-
-
+
+
+
diff --git a/Shorewall-docs/Shorewall_CA_html.html b/Shorewall-docs/Shorewall_CA_html.html
index cd7d40ec9..c26ac9c80 100644
--- a/Shorewall-docs/Shorewall_CA_html.html
+++ b/Shorewall-docs/Shorewall_CA_html.html
@@ -2,93 +2,79 @@
Shorewall Certificate Authority
-
-
-
-
-
-
-
-
- Shorewall Certificate Authority
- (CA) Certificate
- |
-
-
-
-
-
- Given that I develop and support Shorewall without asking for any renumeration,
- I can hardly justify paying $200US+ a year to a Certificate Authority such
- as Thawte (A Division of VeriSign) for an X.509 certificate to prove that
- I am who I am. I have therefore established my own Certificate Authority
-(CA) and sign my own X.509 certificates. I use these certificates on my list
-server (https://lists.shorewall.net)
+
+Shorewall Certificate Authority (CA)
+Certificate
+
+Given that I develop and support Shorewall without asking for any
+renumeration, I can hardly justify paying $200US+ a year to a
+Certificate Authority such as Thawte (A Division of VeriSign) for an
+X.509 certificate to prove that I am who I am. I have therefore
+established my own Certificate Authority (CA) and sign my own X.509
+certificates. I use these certificates on my list server (https://lists.shorewall.net)
which hosts parts of this web site.
-
- X.509 certificates are the basis for the Secure Socket Layer (SSL). As
-part of establishing an SSL session (URL https://...), your browser verifies
-the X.509 certificate supplied by the HTTPS server against the set of Certificate
- Authority Certificates that were shipped with your browser. It is expected
- that the server's certificate was issued by one of the authorities whose
-identities are known to your browser.
-
- This mechanism, while supposedly guaranteeing that when you connect to
-https://www.foo.bar you are REALLY connecting to www.foo.bar, means that
-the CAs literally have a license to print money -- they are selling a string
-of bits (an X.509 certificate) for $200US+ per year!!!I
-
- I wish that I had decided to become a CA rather that designing and writing
- Shorewall.
-
- What does this mean to you? It means that the X.509 certificate that my
-server will present to your browser will not have been signed by one of the
-authorities known to your browser. If you try to connect to my server using
-SSL, your browser will frown and give you a dialog box asking if you want
-to accept the sleezy X.509 certificate being presented by my server.
-
- There are two things that you can do:
-
+
+X.509 certificates are the basis for the Secure Socket Layer (SSL). As
+part of establishing an SSL session (URL https://...), your browser
+verifies the X.509 certificate supplied by the HTTPS server against the
+set of Certificate Authority Certificates that were shipped with your
+browser. It is expected that the server's certificate was issued by one
+of the authorities whose identities are known to your browser.
+
+This mechanism, while supposedly guaranteeing that when you connect to
+https://www.foo.bar you are REALLY connecting to www.foo.bar, means
+that the CAs literally have a license to print money -- they are
+selling a string of bits (an X.509 certificate) for $200US+ per
+year!!!I
+
+I wish that I had decided to become a CA rather that designing and
+writing Shorewall.
+
+What does this mean to you? It means that the X.509 certificate that my
+server will present to your browser will not have been signed by one of
+the authorities known to your browser. If you try to connect to my
+server using SSL, your browser will frown and give you a dialog box
+asking if you want to accept the sleezy X.509 certificate being
+presented by my server.
+
+There are two things that you can do:
- - You can accept the mail.shorewall.net certificate when your browser
- asks -- your acceptence of the certificate can be temporary (for that access
- only) or perminent.
- - You can download and install my (self-signed) CA
-certificate. This will make my Certificate Authority known to your browser
-so that it will accept any certificate signed by me.
-
-
+ - You can accept the mail.shorewall.net certificate when your
+browser asks -- your acceptence of the certificate can be temporary
+(for that access only) or perminent.
+ - You can download and install my (self-signed)
+CA certificate. This will make my Certificate Authority known to
+your browser so that it will accept any certificate signed by me.
+
- What are the risks?
-
+What are the risks?
- - If you install my CA certificate then you assume that I am trustworthy
- and that Shorewall running on your firewall won't redirect HTTPS requests
- intented to go to your bank's server to one of my systems that will present
-your browser with a bogus certificate claiming that my server is that of
+
- If you install my CA certificate then you assume that I am
+trustworthy and that Shorewall running on your firewall won't redirect
+HTTPS requests intented to go to your bank's server to one of my
+systems that will present your browser with a bogus certificate
+claiming that my server is that of
your bank.
- - If you only accept my server's certificate when prompted then the
-most that you have to loose is that when you connect to https://mail.shorewall.net,
- the server you are connecting to might not be mine.
-
+ - If you only accept my server's certificate when prompted then the
+most that you have to loose is that when you connect to
+https://mail.shorewall.net, the server you are connecting to might not
+be mine.
- I have my CA certificate loaded into all of my browsers but I certainly
+I have my CA certificate loaded into all of my browsers but I certainly
won't be offended if you decline to load it into yours... :-)
-
Last Updated 1/17/2003 - Tom Eastep
-
Copyright © 2001, 2002, 2003 Thomas M.
+ size="2">Copyright © 2001, 2002, 2003
+Thomas M.
Eastep.
-
-
-
-
+
+
+
+
diff --git a/Shorewall-docs/Shorewall_CVS_Access.html b/Shorewall-docs/Shorewall_CVS_Access.html
index e8fd279e7..e57b52b90 100644
--- a/Shorewall-docs/Shorewall_CVS_Access.html
+++ b/Shorewall-docs/Shorewall_CVS_Access.html
@@ -2,56 +2,38 @@
Shorewall CVS Access
-
-
-
-
-
-
-
-
- Shorewall CVS Access
-
-
- |
-
-
-
-
-
- Lots of people try to download the entire Shorewall website for off-line
- browsing, including the CVS portion. In addition to being an enormous volume
- of data (HTML versions of all versions of all Shorewall files), all of the
- pages in Shorewall CVS access are cgi-generated which places a tremendous
- load on my little server. I have therefore resorted to making CVS access
- password controlled. When you are asked to log in, enter "Shorewall" (NOTE
- THE CAPITALIZATION!!!!!) for both the user name and the password.
-
-
-
+
+
+
Shorewall CVS Access
+
+Lots of people try to download the entire Shorewall website for
+off-line browsing, including the CVS portion. In addition to being an
+enormous volume of data (HTML versions of all versions of all Shorewall
+files), all of the pages in Shorewall CVS access are cgi-generated
+which places a tremendous load on my little server. I have therefore
+resorted to making CVS access password controlled. When you are asked
+to log in, enter "Shorewall" (NOTE THE CAPITALIZATION!!!!!) for both
+the user name and the password.
+
+
-
-
Updated 1/14/2002
- - Tom Eastep
-
-
-
Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
-
-
+ target="_top">CVS Login
+
+
Updated
+1/14/2002 - Tom Eastep
+Copyright
+© 2001, 2002, 2003 Thomas M. Eastep.
+
+
+
+
+
+
+
diff --git a/Shorewall-docs/Shorewall_Doesnt.html b/Shorewall-docs/Shorewall_Doesnt.html
index e96368499..5023a3942 100644
--- a/Shorewall-docs/Shorewall_Doesnt.html
+++ b/Shorewall-docs/Shorewall_Doesnt.html
@@ -9,20 +9,11 @@
-
-
-
-
- Some things that
-Shorewall Cannot Do
- |
-
-
-
-Shorewall cannot:
+
+Some things that Shorewall Cannot Do
+
+Shorewall cannot:
- Be used to filter traffic through a Layer 2 Bridge
- Act as a "Personal Firewall" that allows internet access by
@@ -30,18 +21,28 @@ application.
- Be used with an Operating System other than Linux (version >=
2.4.0)
- - Do content filtering -- better to use Squid for that.
+ - Do content filtering:
+
In addition:
- - Shorewall does not contain any support for Netfilter Patch-O-Matic features -- Shorewall
+
- Shorewall does not contain any support for Netfilter Patch-O-Matic features --
+Shorewall
only supports features from released kernels.
-Last updated 9/28/2003 - Tom
+Last updated 10/07/2003 - Tom
Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/Shorewall_Squid_Usage.html b/Shorewall-docs/Shorewall_Squid_Usage.html
index 49b4ca3ea..e4046acad 100644
--- a/Shorewall-docs/Shorewall_Squid_Usage.html
+++ b/Shorewall-docs/Shorewall_Squid_Usage.html
@@ -7,19 +7,22 @@
-
+
- 
|
-
- Using Shorewall with Squid
+ |
+ Using Shorewall with Squid
|
- 
|
@@ -28,10 +31,14 @@
This page covers Shorewall configuration to use with Squid running as a Transparent
-Proxy. If you are running Shorewall 1.3, please see this documentation.
+ href="http://www.squid-cache.org/">Squid running as a Transparent
+Proxy or as a Manual Proxy.
+If you are running Shorewall 1.3, please see this documentation.
+Squid as a Transparent Proxy
+
Please observe the
following general requirements:
@@ -71,7 +78,7 @@ running on the Firewall.
local network
Squid running in the DMZ
-Squid Running on the Firewall
+Squid (transparent) Running on the Firewall
You want to redirect all local www connection requests
EXCEPT those to your own http server (206.124.146.177) to a Squid
transparent proxy running on the firewall
@@ -123,15 +130,49 @@ DEST
There may be a requirement to exclude additional destination
hosts or networks from being redirected. For example, you might also
want
-requests destined for 130.252.100.0/24 to not be routed to Squid. In
-that
-case, you must add a manual rule in /etc/shorewall/start:
+requests destined for 130.252.100.0/24 to not be routed to Squid.
+
+If you are running Shorewall version 1.4.5 or later, you may just add
+the additional hosts/networks to the ORIGINAL DEST column in your
+REDIRECT rule:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DEST |
+ PROTO |
+ DEST
+PORT(S) |
+ SOURCE
+PORT(S) |
+ ORIGINAL
+DEST |
+
+
+ | REDIRECT |
+ loc |
+ 3128 |
+ tcp |
+ www |
+ -
+ |
+ !206.124.146.177,130.252.100.0/24 |
+
+
+
+
+If you are running a Shorewall version earlier than 1.4.5, you must add
+a manual rule in /etc/shorewall/start:
run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN
To exclude additional hosts or networks, just add additional
similar rules.
-Squid Running in the local network
+Squid (transparent) Running in the local network
You want to redirect all local www connection requests to a Squid
transparent proxy running in your local zone at 192.168.1.3 and
listening
@@ -273,7 +314,8 @@ command above:
color="#009900">
chkconfig --level 35 iptables on
-Squid Running in the DMZ (This is what I do)
+Squid (transparent) Running in the DMZ (This is
+what I do)
You have a single Linux system in your DMZ with IP address 192.0.2.177.
You want to run both a web server and Squid on that system. Your DMZ
interface is eth1 and your local interface is eth2.
@@ -455,7 +497,133 @@ command above:
color="#009900">
chkconfig --level 35 iptables on
- Updated 8/9/2003 - Tom Eastep
+Squid as a Manual Proxy
+Assume that Squid is running in zone SZ and listening on port SP; all
+web sites that are to be accessed through Squid are in the 'net' zone.
+Then for each zone Z that needs access to the Squid server:
+
+
+
+
+
+ ACTION
+ |
+ SOURCE
+ |
+ DEST
+ |
+ PROTO
+ |
+ DEST
+PORT(S)
+ |
+ CLIENT
+PORT(2)
+ |
+ ORIGINAL
+DEST
+ |
+
+
+ ACCEPT
+ |
+ Z
+ |
+ SZ
+ |
+ tcp
+ |
+ SP
+ |
+
+ |
+
+ |
+
+
+ ACCEPT
+ |
+ SZ
+ |
+ net
+ |
+ tcp
+ |
+ 80
+ |
+
+ |
+
+ |
+
+
+
+
+Example:
+
+Squid on the firewall listening on port
+8080 with access from the 'loc' zone:
+
+
+
+
+ ACTION
+ |
+ SOURCE
+ |
+ DEST
+ |
+ PROTO
+ |
+ DEST
+PORT(S)
+ |
+ CLIENT
+PORT(2)
+ |
+ ORIGINAL
+DEST
+ |
+
+
+ ACCEPT
+ |
+ loc
+ |
+ $FW
+ |
+ tcp
+ |
+ 8080
+ |
+
+ |
+
+ |
+
+
+ ACCEPT
+ |
+ $FW
+ |
+ net
+ |
+ tcp
+ |
+ 80
+ |
+
+ |
+
+ |
+
+
+
+
+
Updated 1017/2003 - Tom
+Eastep
Copyright © 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html b/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
index 0a0cd3529..4571a2295 100644
--- a/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
+++ b/Shorewall-docs/Shorewall_and_Aliased_Interfaces.html
@@ -2,670 +2,635 @@
Shorewall and Aliased Interfaces
-
-
-
-
-
-
-
-
-
- Shorewall and Aliased Interfaces
- |
-
-
-
-
-
-
+
+Shorewall and Aliased Interfaces
+
Background
- The traditional net-tools contain a program called ifconfig
- which is used to configure network devices. ifconfig introduced the
-concept of aliased or virtual interfaces. These virtual
-interfaces have names of the form interface:integer (e.g.,
-eth0:0) and ifconfig treats them more or less like real interfaces.
-
- Example:
-
+The traditional net-tools contain a program called ifconfig
+which is used to configure network devices. ifconfig introduced the
+concept of aliased or virtual interfaces. These
+virtual
+interfaces have names of the form interface:integer (e.g.,
+eth0:0) and ifconfig treats them more or less like real interfaces.
+
+Example:
[root@gateway root]# ifconfig eth0:0
eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55
inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Base address:0x2000
[root@gateway root]#
- The ifconfig utility is being gradually phased out in favor of the
- ip utility which is part of the iproute package. The ip
-utility does not use the concept of aliases or virtual interfaces but rather
-treats additional addresses on an interface as objects in their own right.
-The ip utility does provide for interaction with ifconfig in that it allows
-addresses to be labeled where these labels take the form of ipconfig
+The ifconfig utility is being gradually phased out in favor of the ip
+utility which is part of the iproute package. The ip utility
+does not use the concept of aliases or virtual interfaces but rather
+treats additional addresses on an interface as objects in their own
+right.
+The ip utility does provide for interaction with ifconfig in that it
+allows
+addresses to be labeled where these labels take the form of
+ipconfig
virtual interfaces.
-
- Example:
-
-
+
+Example:
+
[root@gateway root]# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0
[root@gateway root]#
- Note that one cannot type "ip addr show dev eth0:0" because
- "eth0:0" is a label for a particular address rather than a device name.
-
+Note that one cannot type "ip addr show dev eth0:0" because
+"eth0:0" is a label for a particular address rather than a device name.
[root@gateway root]# ip addr show dev eth0:0
Device "eth0:0" does not exist.
[root@gateway root]#
- The iptables program doesn't support virtual interfaces in either
- it's "-i" or "-o" command options; as a consequence, Shorewall does not
- allow them to be used in the /etc/shorewall/interfaces file or anywhere
+The iptables program doesn't support virtual interfaces in either it's
+"-i" or "-o" command options; as a consequence, Shorewall does not
+allow them to be used in the /etc/shorewall/interfaces file or anywhere
else except as described in the discussion below.
-
Adding Addresses to Interfaces
-Shorewall provides facilities for automatically adding addresses to interfaces
-as described in the following section. It is also easy to add them yourself
+Most distributions have a facility for adding additional addresses to
+interfaces. If you have already used your distribution's capability to
+add your required addresses, you can skip this section.
+
+Shorewall provides facilities for automatically adding addresses to
+interfaces
+as described in the following section. It is also easy to add them
+yourself
using the ip utility. The above alias was added using:
-ip addr add 206.124.146.178/24 brd 206.124.146.255
+ip addr add 206.124.146.178/24 brd
+206.124.146.255
dev eth0 label eth0:0
-You probably want to arrange to add these addresses when the device is started
-rather than placing commands like the above in one of the Shorewall extension
-scripts. For example, on RedHat systems, you can place the commands in /sbin/ifup-local:
+You probably want to arrange to add these addresses when the device is
+started
+rather than placing commands like the above in one of the Shorewall
+extension
+scripts. For example, on RedHat systems, you can place the commands in
+/sbin/ifup-local:
#!/bin/sh
case $1 in
eth0)
/sbin/ip addr add 206.124.146.177 dev eth0 label eth0:0
;;
esac
-RedHat systems also allow adding such aliases from the network administration
-GUI (which works well if you have a graphical environment on your firewall).
+RedHat systems also allow adding such aliases from the network
+administration
+GUI (which only works well if you have a graphical environment on your
+firewall).
So how do I handle more than one address on an interface?
- The answer depends on what you are trying to do with the interfaces.
- In the sub-sections that follow, we'll take a look at common scenarios.
-
+The answer depends on what you are trying to do with the interfaces. In
+the sub-sections that follow, we'll take a look at common scenarios.
Separate Rules
- If you need to make a rule for traffic to/from the firewall itself
- that only applies to a particular IP address, simply qualify the $FW zone
- with the IP address.
-
- Example (allow SSH from net to eth0:0 above):
-
-
-
+If you need to make a rule for traffic to/from the firewall itself that
+only applies to a particular IP address, simply qualify the $FW zone
+with the IP address.
+
+Example (allow SSH from net to eth0:0 above):
+
+
-
-
- ACTION
- |
- SOURCE
- |
- DESTINATION
- |
- PROTOCOL
- |
- PORT(S)
- |
- SOURCE PORT(S)
- |
- ORIGINAL DESTINATION
- |
-
-
- ACCEPT
- |
- net
- |
- $FW:206.124.146.178
- |
- tcp
- |
- 22
- |
-
- |
-
- |
-
-
-
+
+
+ ACTION
+ |
+ SOURCE
+ |
+ DESTINATION
+ |
+ PROTOCOL
+ |
+ PORT(S)
+ |
+ SOURCE PORT(S)
+ |
+ ORIGINAL DESTINATION
+ |
+
+
+ ACCEPT
+ |
+ net
+ |
+ $FW:206.124.146.178
+ |
+ tcp
+ |
+ 22
+ |
+
+ |
+
+ |
+
+
-
-
-
+
+
DNAT
- Suppose that I had set up eth0:0 as above and I wanted to port
-forward from that virtual interface to a web server running in my local
-zone at 192.168.1.3. That is accomplised by a single rule in the /etc/shorewall/rules
- file:
-
-
-
+Suppose that I had set up eth0:0 as above and I wanted to port
+forward from that virtual interface to a web server running in my local
+zone at 192.168.1.3. That is accomplised by a single rule in the
+/etc/shorewall/rules file:
+
+
-
-
- ACTION
- |
- SOURCE
- |
- DESTINATION
- |
- PROTOCOL
- |
- PORT(S)
- |
- SOURCE PORT(S)
- |
- ORIGINAL DESTINATION
- |
-
-
- DNAT
- |
- net
- |
- loc:192.168.1.3
- |
- tcp
- |
- 80
- |
- -
- |
- 206.124.146.178
- |
-
-
-
+
+
+ ACTION
+ |
+ SOURCE
+ |
+ DESTINATION
+ |
+ PROTOCOL
+ |
+ PORT(S)
+ |
+ SOURCE PORT(S)
+ |
+ ORIGINAL DESTINATION
+ |
+
+
+ DNAT
+ |
+ net
+ |
+ loc:192.168.1.3
+ |
+ tcp
+ |
+ 80
+ |
+ -
+ |
+ 206.124.146.178
+ |
+
+
-
-
-
+
+
SNAT
- If you wanted to use eth0:0 as the IP address for outbound connections
- from your local zone (eth1), then in /etc/shorewall/masq:
-
-
-
+If you wanted to use eth0:0 as the IP address for outbound connections
+from your local zone (eth1), then in /etc/shorewall/masq:
+
+
-
-
- INTERFACE
- |
- SUBNET
- |
- ADDRESS
- |
-
-
- eth0
- |
- eth1
- |
- 206.124.146.178
- |
-
-
-
+
+
+ INTERFACE
+ |
+ SUBNET
+ |
+ ADDRESS
+ |
+
+
+ eth0
+ |
+ eth1
+ |
+ 206.124.146.178
+ |
+
+
-
-
- Shorewall can create the alias (additional address) for you if
-you set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning
-with Shorewall 1.3.14, Shorewall can actually create the "label" (virtual
-interface) so that you can see the created address using ifconfig. In
-addition to setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface
-name in the INTERFACE column as follows:
-
-
+
+
+Shorewall can create the alias (additional address) for you if
+you set ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
+Beginning
+with Shorewall 1.3.14, Shorewall can actually create the "label"
+(virtual
+interface) so that you can see the created address using ifconfig. In
+addition to setting ADD_SNAT_ALIASES=Yes, you specify the virtual
+interface
+name in the INTERFACE column as follows:
+
-
-
- INTERFACE
- |
- SUBNET
- |
- ADDRESS
- |
-
-
- eth0:0
- |
- eth1
- |
- 206.124.146.178
- |
-
-
-
+
+
+ INTERFACE
+ |
+ SUBNET
+ |
+ ADDRESS
+ |
+
+
+ eth0:0
+ |
+ eth1
+ |
+ 206.124.146.178
+ |
+
+
-
- Shorewall can also set up SNAT to round-robin over a range of IP addresses.
- Do do that, you specify a range of IP addresses in the ADDRESS column. If
- you specify a label in the INTERFACE column, Shorewall will use that label
- for the first address of the range and will increment the label by one for
- each subsequent label.
-
-
-
+
+Shorewall can also set up SNAT to round-robin over a range of IP
+addresses. Do do that, you specify a range of IP addresses in the
+ADDRESS column. If you specify a label in the INTERFACE column,
+Shorewall will use that label for the first address of the range and
+will increment the label by one for each subsequent label.
+
+
-
-
- INTERFACE
- |
- SUBNET
- |
- ADDRESS
- |
-
-
- eth0:0
- |
- eth1
- |
- 206.124.146.178-206.124.146.180
- |
-
-
-
+
+
+ INTERFACE
+ |
+ SUBNET
+ |
+ ADDRESS
+ |
+
+
+ eth0:0
+ |
+ eth1
+ |
+ 206.124.146.178-206.124.146.180
+ |
+
+
-
- The above would create three IP addresses:
-
- eth0:0 = 206.124.146.178
- eth0:1 = 206.124.146.179
- eth0:2 = 206.124.146.180
-
-STATIC NAT
- If you wanted to use static NAT to link eth0:0 with local address
- 192.168.1.3, you would have the following in /etc/shorewall/nat:
-
-
-
+
+The above would create three IP addresses:
+
+ eth0:0 = 206.124.146.178
+ eth0:1 = 206.124.146.179
+ eth0:2 = 206.124.146.180
+One-to-one NAT
+If you wanted to use one-to-one NAT to link eth0:0 with local address
+192.168.1.3, you would have the following in /etc/shorewall/nat:
+
+
-
-
- EXTERNAL
- |
- INTERFACE
- |
- INTERNAL
- |
- ALL INTERFACES
- |
- LOCAL
- |
-
-
- 206.124.146.178
- |
- eth0
- |
- 192.168.1.3
- |
- no
- |
- no
- |
-
-
-
+
+
+ EXTERNAL
+ |
+ INTERFACE
+ |
+ INTERNAL
+ |
+ ALL INTERFACES
+ |
+ LOCAL
+ |
+
+
+ 206.124.146.178
+ |
+ eth0
+ |
+ 192.168.1.3
+ |
+ no
+ |
+ no
+ |
+
+
-
-
- Shorewall can create the alias (additional address) for you if
-you set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning
-with Shorewall 1.3.14, Shorewall can actually create the "label" (virtual
-interface) so that you can see the created address using ifconfig. In
-addition to setting ADD_IP_ALIASES=Yes, you specify the virtual interface
-name in the INTERFACE column as follows:
-
-
-
+
+
+Shorewall can create the alias (additional address) for you if
+you set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf. Beginning
+with Shorewall 1.3.14, Shorewall can actually create the "label"
+(virtual
+interface) so that you can see the created address using ifconfig. In
+addition to setting ADD_IP_ALIASES=Yes, you specify the virtual
+interface
+name in the INTERFACE column as follows:
+
+
-
-
- EXTERNAL
- |
- INTERFACE
- |
- INTERNAL
- |
- ALL INTERFACES
- |
- LOCAL
- |
-
-
- 206.124.146.178
- |
- eth0:0
- |
- 192.168.1.3
- |
- no
- |
- no
- |
-
-
-
+
+
+ EXTERNAL
+ |
+ INTERFACE
+ |
+ INTERNAL
+ |
+ ALL INTERFACES
+ |
+ LOCAL
+ |
+
+
+ 206.124.146.178
+ |
+ eth0:0
+ |
+ 192.168.1.3
+ |
+ no
+ |
+ no
+ |
+
+
-
-
- In either case, to create rules that pertain only to this NAT pair,
- you simply qualify the local zone with the internal IP address.
-
- Example: You want to allow SSH from the net to 206.124.146.178 a.k.a.
- 192.168.1.3.
-
-
-
+
+
+In either case, to create rules that pertain only to this NAT pair, you
+simply qualify the local zone with the internal IP address.
+
+Example: You want to allow SSH from the net to 206.124.146.178 a.k.a.
+192.168.1.3.
+
+
-
-
- ACTION
- |
- SOURCE
- |
- DESTINATION
- |
- PROTOCOL
- |
- PORT(S)
- |
- SOURCE PORT(S)
- |
- ORIGINAL DESTINATION
- |
-
-
- ACCEPT
- |
- net
- |
- loc:192.168.1.3
- |
- tcp
- |
- 22
- |
-
- |
-
- |
-
-
-
+
+
+ ACTION
+ |
+ SOURCE
+ |
+ DESTINATION
+ |
+ PROTOCOL
+ |
+ PORT(S)
+ |
+ SOURCE PORT(S)
+ |
+ ORIGINAL DESTINATION
+ |
+
+
+ ACCEPT
+ |
+ net
+ |
+ loc:192.168.1.3
+ |
+ tcp
+ |
+ 22
+ |
+
+ |
+
+ |
+
+
-
-
-
+
+
MULTIPLE SUBNETS
- Sometimes multiple IP addresses are used because there are multiple
- subnetworks configured on a LAN segment. This technique does not provide
- for any security between the subnetworks if the users of the systems have
- administrative privileges because in that case, the users can simply manipulate
- their system's routing table to bypass your firewall/router. Nevertheless,
- there are cases where you simply want to consider the LAN segment itself
- as a zone and allow your firewall/router to route between the two subnetworks.
-
- Example 1: Local interface eth1 interfaces to 192.168.1.0/24
- and 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254
-and eth1:0 is 192.168.20.254. You want to simply route all requests between
- the two subnetworks.
-
+Sometimes multiple IP addresses are used because there are multiple
+subnetworks configured on a LAN segment. This technique does not
+provide for any security between the subnetworks if the users of the
+systems have administrative privileges because in that case, the users
+can simply manipulate their system's routing table to bypass your
+firewall/router. Nevertheless, there are cases where you simply want to
+consider the LAN segment itself as a zone and allow your
+firewall/router to route between the two subnetworks.
+
+Example 1: Local interface eth1 interfaces to 192.168.1.0/24 and
+192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254
+and eth1:0 is 192.168.20.254. You want to simply route all requests
+between the two subnetworks.
If you are running Shorewall 1.4.1 or Later
- In /etc/shorewall/interfaces:
-
-
+In /etc/shorewall/interfaces:
+
-
-
- ZONE
- |
- INTERFACE
- |
- BROADCAST
- |
- OPTIONS
- |
-
-
- -
- |
- eth1
- |
- 192.168.1.255,192.168.20.255
- |
-
- |
-
-
-
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ -
+ |
+ eth1
+ |
+ 192.168.1.255,192.168.20.255
+ |
+
+ |
+
+
-
-
- In /etc/shorewall/hosts:
-
-
+
+
+In /etc/shorewall/hosts:
+
-
-
- ZONE
- |
- HOSTS
- |
- OPTIONS
- |
-
-
- loc
- |
- eth1:192.168.1.0/24
- |
-
- |
-
-
- loc
- |
- eth1:192.168.20.0/24
- |
-
- |
-
-
-
+
+
+ ZONE
+ |
+ HOSTS
+ |
+ OPTIONS
+ |
+
+
+ loc
+ |
+ eth1:192.168.1.0/24
+ |
+
+ |
+
+
+ loc
+ |
+ eth1:192.168.20.0/24
+ |
+
+ |
+
+
-
-
- Note that you do NOT need any entry in /etc/shorewall/policy as Shorewall
- 1.4.1 and later releases default to allowing intra-zone traffic.
-
+
+
+Note that you do NOT need any entry in /etc/shorewall/policy as
+Shorewall 1.4.1 and later releases default to allowing intra-zone
+traffic.
If you are running Shorewall 1.4.0 or earlier
-
- In /etc/shorewall/interfaces:
-
-
-
+
+In /etc/shorewall/interfaces:
+
+
-
-
- ZONE
- |
- INTERFACE
- |
- BROADCAST
- |
- OPTIONS
- |
-
-
- loc
- |
- eth1
- |
- 192.168.1.255,192.168.20.255
- |
- Note 1:
- |
-
-
-
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ loc
+ |
+ eth1
+ |
+ 192.168.1.255,192.168.20.255
+ |
+ Note 1:
+ |
+
+
-
-
- Note 1: If you are running Shorewall 1.3.10 or earlier then you
-must specify the multi option.
-
- In /etc/shorewall/policy:
-
-
-
+
+
+Note 1: If you are running Shorewall 1.3.10 or earlier then you must
+specify the multi option.
+
+In /etc/shorewall/policy:
+
+
-
-
- SOURCE
- |
- DESTINATION
- |
- POLICY
- |
- LOG LEVEL
- |
- BURST:LIMIT
- |
-
-
- loc
- |
- loc
- |
- ACCEPT
- |
-
- |
-
- |
-
-
-
+
+
+ SOURCE
+ |
+ DESTINATION
+ |
+ POLICY
+ |
+ LOG LEVEL
+ |
+ BURST:LIMIT
+ |
+
+
+ loc
+ |
+ loc
+ |
+ ACCEPT
+ |
+
+ |
+
+ |
+
+
-
-
- Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and
- 192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
-eth1:0 is 192.168.20.254. You want to make these subnetworks into separate
-zones and control the access between them (the users of the systems do
-not have administrative privileges).
-
- In /etc/shorewall/zones:
-
-
-
+
+
+Example 2: Local interface eth1 interfaces to 192.168.1.0/24 and
+192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
+eth1:0 is 192.168.20.254. You want to make these subnetworks into
+separate
+zones and control the access between them (the users of the systems do
+not have administrative privileges).
+
+In /etc/shorewall/zones:
+
+
-
-
- ZONE
- |
- DISPLAY
- |
- DESCRIPTION
- |
-
-
- loc
- |
- Local
- |
- Local Zone 1
- |
-
-
- loc2
- |
- Local2
- |
- Local Zone 2
- |
-
-
-
+
+
+ ZONE
+ |
+ DISPLAY
+ |
+ DESCRIPTION
+ |
+
+
+ loc
+ |
+ Local
+ |
+ Local Zone 1
+ |
+
+
+ loc2
+ |
+ Local2
+ |
+ Local Zone 2
+ |
+
+
-
-
- In /etc/shorewall/interfaces:
-
-
-
+
+
+In /etc/shorewall/interfaces:
+
+
-
-
- ZONE
- |
- INTERFACE
- |
- BROADCAST
- |
- OPTIONS
- |
-
-
- -
- |
- eth1
- |
- 192.168.1.255,192.168.20.255
- |
- Note 1:
- |
-
-
-
+
+
+ ZONE
+ |
+ INTERFACE
+ |
+ BROADCAST
+ |
+ OPTIONS
+ |
+
+
+ -
+ |
+ eth1
+ |
+ 192.168.1.255,192.168.20.255
+ |
+ Note 1:
+ |
+
+
-
-
- Note 1: If you are running Shorewall 1.3.10 or earlier then you
-must specify the multi option.
-
- In /etc/shorewall/hosts:
-
-
+
+
+Note 1: If you are running Shorewall 1.3.10 or earlier then you must
+specify the multi option.
+
+In /etc/shorewall/hosts:
+
-
-
- ZONE
- |
- HOSTS
- |
- OPTIONS
- |
-
-
- loc
- |
- eth1:192.168.1.0/24
- |
-
- |
-
-
- loc2
- |
- eth1:192.168.20.0/24
- |
-
- |
-
-
-
+
+
+ ZONE
+ |
+ HOSTS
+ |
+ OPTIONS
+ |
+
+
+ loc
+ |
+ eth1:192.168.1.0/24
+ |
+
+ |
+
+
+ loc2
+ |
+ eth1:192.168.20.0/24
+ |
+
+ |
+
+
-
-
- In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
- that you want to permit.
-
-
-Last Updated 7/29/2003 A -
+
+In /etc/shorewall/rules, simply specify ACCEPT rules for the traffic
+that you want to permit.
+
+Last Updated 11/13/2003 A - Tom Eastep
-
-Copyright ©
- 2001, 2002, 2003 Thomas M. Eastep.
-
-
+Copyright © 2001, 2002, 2003 Thomas M. Eastep.
+
+
diff --git a/Shorewall-docs/Shorewall_and_Kazaa.html b/Shorewall-docs/Shorewall_and_Kazaa.html
new file mode 100644
index 000000000..a4b9fe8ad
--- /dev/null
+++ b/Shorewall-docs/Shorewall_and_Kazaa.html
@@ -0,0 +1,32 @@
+
+
+
+
+ Shorewall and Kazaa
+
+
+
+Kazaa Filtering
+
+Beginning with Shorewall version 1.4.8, Shorewall can interface to ftwall. ftwall is part of the
+p2pwall project and is a user-space filter for applications based on
+the "Fast Track" peer to peer protocol. Applications using this
+protocol include Kazaa, KazaaLite, iMash and Grokster.
+
+To filter traffic from your 'loc' zone with ftwall, you insert the
+following rules near the top of your
+/etc/shorewall/rules file (before and ACCEPT rules whose source is the
+'loc' zone).
+QUEUE loc net tcp
QUEUE loc net udp
QUEUE loc fw udp
+Now simply configure ftwall as described in the ftwall documentation
+and restart Shorewall.
+Last updated 10/22/2003 - Tom Eastep
+Copyright
+© 2003 Thomas M. Eastep.
+
+
+
diff --git a/Shorewall-docs/Shorewall_index_frame.htm b/Shorewall-docs/Shorewall_index_frame.htm
index 87a4f6357..2a0b114f3 100644
--- a/Shorewall-docs/Shorewall_index_frame.htm
+++ b/Shorewall-docs/Shorewall_index_frame.htm
@@ -1,138 +1,66 @@
-
-
-
-
-
-
-
-
Shorewall Index
-
-
-
-
+
-
-
+
-
-
- |
-
-
-
- 
-
-
-
- |
-
-
- |
-
-
-
-
+ |
+
+ |
- |
-
-
-
-
+
+
+
-
-Copyright © Copyright © 2001-2003 Thomas M. Eastep.
-
-
-
+
diff --git a/Shorewall-docs/Shorewall_sfindex_frame.htm b/Shorewall-docs/Shorewall_sfindex_frame.htm
index 49bf2dd7e..491f2666b 100644
--- a/Shorewall-docs/Shorewall_sfindex_frame.htm
+++ b/Shorewall-docs/Shorewall_sfindex_frame.htm
@@ -1,120 +1,68 @@
-
-
-
-
Shorewall Index
-
-
+
-
-
+
-
-
-
-
-
- Shorewall
- |
-
-
- |
-
-
-
-
-
-
-
-
+ |
+
+ |
- |
-
-
-
+
+
+
-
-Copyright © Copyright © 2001-2003 Thomas M. Eastep.
-
-
+
+
+
diff --git a/Shorewall-docs/SourceforgeBanner.html b/Shorewall-docs/SourceforgeBanner.html
new file mode 100755
index 000000000..cd2fe8127
--- /dev/null
+++ b/Shorewall-docs/SourceforgeBanner.html
@@ -0,0 +1,45 @@
+
+
+
+
+ Banner
+
+
+
+
+
+
+
diff --git a/Shorewall-docs/UserSets.html b/Shorewall-docs/UserSets.html
new file mode 100755
index 000000000..33b457072
--- /dev/null
+++ b/Shorewall-docs/UserSets.html
@@ -0,0 +1,141 @@
+
+
+
+
+
+
+
+ Controlling Traffic by UID/GID
+
+
+
+
+
+
+
+ Controlling Output
+Traffic by UID/GID
+
+ |
+
+
+
+This capability was added in Shorewall release
+1.4.7.
+
+Netfilter provides the capability to filter packets generated on the
+firewall system by User Id and/or Group Id. Shorewall provides two
+separate but related ways to use this Netfilter capability:
+
+ - Shorewall allows you to
+define collections of users called "User Sets"
+and then to restrict
+certain rules in /etc/shorewall/rules to a given User Set.
+ - Shorewall also allows you to restrict a given rule
+ to a particular user and/or group.
+
+
+Since only packets created by programs running on the Shorewall box
+itself, only rules whose SOURCE is the firewall ($FW) may be restricted
+using either of the facilities.
+User Sets
+
+Given the way that this facility is implemented in Shorewall, it is not
+possible to control logging of individual rules using a User Set and
+logging is rather specified on the User Set itself.
+
+User Sets are defined in the /etc/shorewall/usersets file. Columns in
+that file include:
+
+USERSET
+ The name of a User Set. Must be a legal
+shell
+identifier of no more than six (6) characters in length.
+REJECT
+Log level for connections rejected for this User Set.
+ACCEPT Log
+level for connections accepted for this User Set.
+DROP
+ Log level for connections dropped for this User Set.
+
+
+In the REJECT and ACCEPT columns, if you don't want to specify a value
+in the column but you want to specify a value in a following column,
+you may enter "-".
+
+Users and/or groups are added to User Sets using the
+/etc/shorewall/users file. Columns in that file are:
+
+USERSET
+ The name of a User Set defined in
+/etc/shorewall/usersets.
+USER
+ The name of a user defined on the system or a user number.
+GROUP
+The name of a group defined on the system or a number.
+
+Only one of the USER and GROUP
+column needs to be non-empty. If you wish to specify a GROUP but not a
+USER, enter "-" in the user column.
+
+If both USER and GROUP are
+specified then only programs running under that USER:GROUP pair will
+match rules specifying the User Set named in the USERSET column.
+
+Once a user set has been defined, its name may be
+placed in the USER SET column of the /etc/shorewall/rules file. IMPORTANT:
+When
+the name of a user set is given in the USER SET column, you may not
+include a log level in the ACTION column; logging of such rules is
+governed solely by the user set's definition in the
+/etc/shorewall/userset file.
+
+Example: You want members of the
+'admin' group and 'root' to be able to use ssh on the firewall to
+connect to local systems. You want to log all connections accepted for
+these users using syslog at the 'info' level.
+
+
+/etc/shorewall/usersets
+
+#USERSET REJECT ACCEPT DROP
admins - info
+
+/etc/shorewall/users
+
+
+#USERSET USER GROUP
admins - admin
admins root
+/etc/shorewall/rules
+
+#ACTION SOURCE DESTINATION PROTO PORT SOURCE ORIGINAL RATE USER
# PORT(S) DESTINATION SET
ACCEPT $FW loc tcp 22 - - - admins
+Restricting a rule to a particular user and/or
+group
+
+In cases where you may want to restrict a rule to a particular user
+and/or group, the USER SET column in the rules file may be specified as:
+
+[ <
user
+name or number> ] : [ <
group
+name or number> ]
+
+
+
+
+Example: You want user mail to
+be able to send email from the firewall to the local net zone
+
+/etc/shorewall/rules (be sure to note
+the ":" in the USER SET column entry).
+
#ACTION SOURCE DESTINATION PROTO PORT SOURCE ORIGINAL RATE USER
# PORT(S) DESTINATION SET
ACCEPT $FW loc tcp 25 - - - mail:
+
Last updated 9/19/2003 - Tom Eastep
+Copyright
+© 2003 Thomas M. Eastep.
+
+
diff --git a/Shorewall-docs/VPN.htm b/Shorewall-docs/VPN.htm
index 334005fb6..4ee6b5aea 100755
--- a/Shorewall-docs/VPN.htm
+++ b/Shorewall-docs/VPN.htm
@@ -1,78 +1,59 @@
-
-
-
-
VPN
-
-
-
-
-It is often the case that a system behind the firewall needs to be able
-to access a remote network through Virtual Private Networking (VPN). The
-two most common means for doing this are IPSEC and PPTP. The basic setup
-is shown in the following diagram:
-
+
+VPN
+
+It is often the case that a system behind the firewall needs to be
+able to access a remote network through Virtual Private Networking
+(VPN). The two most common means for doing this are IPSEC and PPTP. The
+basic setup is shown in the following diagram:
-
-
-A system with an RFC 1918 address needs to access a remote
- network through a remote gateway. For this example, we will assume that the
- local system has IP address 192.168.1.12 and that the remote gateway has
-IP address 192.0.2.224.
-
-If PPTP is being used, there are no firewall requirements
-beyond the default loc->net ACCEPT policy. There is one restriction however:
-Only one local system at a time can be connected to a single remote gateway
-unless you patch your kernel from the 'Patch-o-matic' patches available at
+ height="796">
+A system with an RFC 1918 address needs to access a
+remote network through a remote gateway. For this example, we will
+assume that the local system has IP address 192.168.1.12 and that the
+remote gateway has
+IP address 192.0.2.224.
+If PPTP is being used, there are no firewall
+requirements beyond the default loc->net ACCEPT policy. There is one
+restriction however: Only one local system at a time can be connected
+to a single remote gateway unless you patch your kernel from the
+'Patch-o-matic' patches available at
http://www.netfilter.org.
-
-If IPSEC is being used then only one system may connect to
-the remote gateway and there are firewall configuration requirements as follows:
-
-
+If IPSEC is being used then only one system may connect
+to the remote gateway and there are firewall configuration requirements
+as follows:
+
-
-
+
+
| ACTION |
SOURCE |
DESTINATION |
PROTOCOL |
PORT |
CLIENT
- PORT |
+PORT
ORIGINAL
- DEST |
+DEST
| DNAT |
net:192.0.2.224 |
loc:192.168.1.12 |
50 |
- |
- |
- |
+ |
+ |
+ |
| DNAT |
@@ -80,27 +61,24 @@ the remote gateway and there are firewall configuration requirements as follows
loc:192.168.1.12 |
udp |
500 |
- |
- |
+ |
+ |
-
-
+
-
-
-If you want to be able to give access to all of your local systems to the
- remote network, you should consider running a VPN client on your firewall.
-As starting points, see http://www.shorewall.net/Documentation.htm#Tunnels
-or http://www.shorewall.net/PPTP.htm.
-
-Last modified 12/21/2002 - Tom Eastep
-
- Copyright
+
+If you want to be able to give access to all of your local systems
+to the remote network, you should consider running a VPN client on your
+firewall. As starting points, see
+http://www.shorewall.net/Documentation.htm#Tunnels or http://www.shorewall.net/PPTP.htm.
+Last modified 12/21/2002 - Tom
+Eastep
+ Copyright
© 2002 Thomas M. Eastep.
-
-
-
-
+
+
+
diff --git a/Shorewall-docs/blacklisting_support.htm b/Shorewall-docs/blacklisting_support.htm
index e8e955e64..f21c88ed9 100644
--- a/Shorewall-docs/blacklisting_support.htm
+++ b/Shorewall-docs/blacklisting_support.htm
@@ -1,102 +1,91 @@
-
-
-
-
Blacklisting Support
-
-
-
-
-
-
- Blacklisting Support
- |
-
-
-
-
-
-Shorewall supports two different forms of blacklisting; static and dynamic.
-
+
+Shorewall Blacklisting Support
+
+Shorewall supports two different forms of blacklisting; static and
+dynamic. Beginning with Shorewall version 1.4.8, the BLACKLISTNEWONLY
+option in /etc/shorewall/shorewall.conf controls the degree of
+blacklist filtering:
+
+
+ - BLACKLISTNEWONLY=No -- All incoming packets are checked
+against the blacklist. New blacklist entries can be used to terminate
+existing connections. Versions of Shorewall prior to 1.4.8 behave in
+this manner.
+
+ - BLACKLISTNEWONLY=Yes -- The blacklists are only consulted for new
+connection requests. Blacklists may not be used to terminate existing
+connections.
+
+Only the source address is checked against the blacklists.
Static Blacklisting
-
-Shorewall static blacklisting support has the following configuration
+
Shorewall static blacklisting support has the following
+configuration
parameters:
-
- - You specify whether you want packets from blacklisted hosts dropped
- or rejected using the BLACKLIST_DISPOSITION
- setting in /etc/shorewall/shorewall.conf
- - You specify whether you want packets from blacklisted hosts logged
- and at what syslog level using the BLACKLIST_LOGLEVEL setting in
- /etc/shorewall/shorewall.conf
- - You list the IP addresses/subnets that you wish to blacklist in
- /etc/shorewall/blacklist.
-Beginning with Shorewall version 1.3.8, you may also specify PROTOCOL and
-Port numbers/Service names in the blacklist file.
-
- - You specify the interfaces whose incoming packets you want checked
- against the blacklist using the "blacklist" option in /etc/shorewall/interfaces.
- - The black list is refreshed from /etc/shorewall/blacklist by the
- "shorewall refresh" command.
-
+ - You specify whether you want packets from blacklisted hosts
+dropped or rejected using the BLACKLIST_DISPOSITION
+setting in /etc/shorewall/shorewall.conf
+ - You specify whether you want packets from blacklisted hosts
+logged and at what syslog level using the BLACKLIST_LOGLEVEL setting in
+/etc/shorewall/shorewall.conf
+ - You list the IP addresses/subnets that you wish to blacklist in /etc/shorewall/blacklist.
+Beginning with Shorewall version 1.3.8, you may also specify PROTOCOL
+and
+Port numbers/Service names in the blacklist file.
+
+ - You specify the interfaces whose incoming packets you want
+checked against the blacklist using the "blacklist" option in
+/etc/shorewall/interfaces.
+ - The black list is refreshed from /etc/shorewall/blacklist by the "shorewall refresh" command.
-
Dynamic Blacklisting
-
-Dynamic blacklisting support was added in version 1.3.2. Dynamic blacklisting
- doesn't use any configuration parameters but is rather controlled using
- /sbin/shorewall commands:
-
+Dynamic blacklisting support was added in version 1.3.2. Dynamic
+blacklisting doesn't use any configuration parameters but is rather
+controlled using /sbin/shorewall commands:
- - drop <ip address list> - causes packets from the
-listed IP addresses to be silently dropped by the firewall.
- - reject <ip address list> - causes packets from the
- listed IP addresses to be rejected by the firewall.
- - allow <ip address list> - re-enables receipt of packets
- from hosts previously blacklisted by a drop or reject
+
- drop <ip address list> - causes packets from the
+listed IP addresses to be silently dropped by the firewall.
+ - reject <ip address list> - causes packets from the
+listed IP addresses to be rejected by the firewall.
+ - allow <ip address list> - re-enables receipt of
+packets from hosts previously blacklisted by a drop or reject
command.
- - save - save the dynamic blacklisting configuration so that it
-will be automatically restored the next time that the firewall is restarted.
- - show dynamic - displays the dynamic blacklisting configuration.
-
+ - save - save the dynamic blacklisting configuration so that it
+will be automatically restored the next time that the firewall is
+restarted.
+ - show dynamic - displays the dynamic blacklisting configuration.
- Dynamic blacklisting is not dependent on the "blacklist" option
-in /etc/shorewall/interfaces.
-
+Dynamic blacklisting is not dependent on the "blacklist" option
+in /etc/shorewall/interfaces.
Example 1:
-
shorewall drop 192.0.2.124 192.0.2.125
-
- Drops packets from hosts 192.0.2.124 and 192.0.2.125
-
+ Drops packets from hosts 192.0.2.124 and
+192.0.2.125
Example 2:
-
shorewall allow 192.0.2.125
-
- Reenables access from 192.0.2.125.
-
-Last updated 7/27/2003 - Tom Eastep
-
+ Reenables access from 192.0.2.125.
+Last updated 11/14/2003 - Tom
+Eastep
Copyright
- © 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
+© 2002, 2003 Thomas M. Eastep.
+
+
+
+
+
diff --git a/Shorewall-docs/configuration_file_basics.htm b/Shorewall-docs/configuration_file_basics.htm
index d75361d8d..f7aeb5895 100644
--- a/Shorewall-docs/configuration_file_basics.htm
+++ b/Shorewall-docs/configuration_file_basics.htm
@@ -9,17 +9,8 @@
Configuration File Basics
-
-
-
-
- Configuration Files
- |
-
-
-
+Configuration Files
+
Warning: If you copy or edit your
configuration files on a system running Microsoft Windows, you must
run them through
modules.
/etc/shorewall/rules - defines rules that are exceptions to the
overall policies established in /etc/shorewall/policy.
- /etc/shorewall/nat - defines static NAT
+ /etc/shorewall/nat - defines one-to-one NAT
rules.
/etc/shorewall/proxyarp - defines use of Proxy ARP.
/etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines
@@ -254,18 +245,21 @@ that you can then use in some of the other configuration files.
It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally
within the Shorewall programs
-Example:
+Example:
+
+ /etc/shorewall/params
+
- NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918
+ NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918
-
-Example (/etc/shorewall/interfaces record):
+ /etc/shorewall/interfaces record:
net $NET_IF $NET_BCAST $NET_OPTIONS
-The result will be the same as if the record had been written
+ The result will be the same as if the record had
+been written
net eth0 130.252.100.255 routefilter,norfc1918
@@ -331,7 +325,8 @@ The try command
allows you to attempt to restart using an alternate configuration and
if an
error occurs to automatically restart the standard configuration.
- Updated 8/22/2003 - Tom Eastep
+ Updated 11/20/2003 - Tom
+Eastep
Copyright
© 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/copyright.htm b/Shorewall-docs/copyright.htm
index b18869cfe..05fccb49b 100644
--- a/Shorewall-docs/copyright.htm
+++ b/Shorewall-docs/copyright.htm
@@ -1,46 +1,30 @@
-
-
-
-
Copyright
-
-
-
-
-
-
- Copyright
- |
-
-
-
-
-
-Copyright © 2000, 2001,
-2003 Thomas M Eastep
-
-
-
- Permission is granted to copy, distribute and/or modify
-this document under the terms of the GNU Free Documentation License, Version
-1.1 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 "GNU Free Documentation License".
-
-
-
-
+
+Copyright
+
+Copyright ©
+2000, 2001, 2003 Thomas M Eastep
+
+
+ Permission is granted to copy, distribute and/or
+modify this document under the terms of the GNU Free Documentation
+License, Version 1.1 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 "GNU Free Documentation
+License".
+
+
+
+
diff --git a/Shorewall-docs/dhcp.htm b/Shorewall-docs/dhcp.htm
index 14816e07f..84954d805 100644
--- a/Shorewall-docs/dhcp.htm
+++ b/Shorewall-docs/dhcp.htm
@@ -1,85 +1,65 @@
-
-
-
-
DHCP
-
-
-
-
+
+DHCP
+
If you want to Run a DHCP Server on your firewall
-
- -
-
Specify the "dhcp" option on each interface to be served
-by your server in the /etc/shorewall/interfaces
- file. This will generate rules that will allow DHCP to and from your firewall
-system.
-
- -
-
When starting "dhcpd", you need to list those interfaces
-on the run line. On a RedHat system, this is done by modifying /etc/sysconfig/dhcpd.
-
-
-
+ -
+
Specify the "dhcp" option on each interface to be
+served
+by your server in the /etc/shorewall/interfaces
+file. This will generate rules that will allow DHCP to and from your
+firewall
+system.
+
+ -
+
When starting "dhcpd", you need to list those
+interfaces on the run line. On a RedHat system, this is done by
+modifying /etc/sysconfig/dhcpd.
+
-
If a Firewall Interface gets its IP Address via DHCP
-
- -
-
Specify the "dhcp" option for this interface in the
- /etc/shorewall/interfaces
- file. This will generate rules that will allow DHCP to and from your firewall
-system.
-
- -
-
If you know that the dynamic address is always going to
-be in the same subnet, you can specify the subnet address in the interface's
- entry in the /etc/shorewall/interfaces
- file.
-
- -
-
If you don't know the subnet address in advance, you should
- specify "detect" for the interface's subnet address in the /etc/shorewall/interfaces file
-and start Shorewall after the interface has started.
-
- -
-
In the event that the subnet address might change while
- Shorewall is started, you need to arrange for a "shorewall refresh"
-command to be executed when a new dynamic IP address gets assigned to
-the interface. Check your DHCP client's documentation.
-
-
+ -
+
Specify the "dhcp" option for this interface in the
+ /etc/shorewall/interfaces
+file. This will generate rules that will allow DHCP to and from
+your firewall system.
+
+ -
+
If you know that the dynamic address is always
+going to
+be in the same subnet, you can specify the subnet address in the
+interface's entry in the /etc/shorewall/interfaces
+file.
+
+ -
+
If you don't know the subnet address in advance,
+you should specify "detect" for the interface's subnet address in the /etc/shorewall/interfaces file
+and start Shorewall after the interface has started.
+
+ -
+
In the event that the subnet address might change
+while Shorewall is started, you need to arrange for a "shorewall
+refresh" command to be executed when a new dynamic IP address gets
+assigned to the interface. Check your DHCP client's documentation.
+
-
Last updated 11/03/2002 - Tom Eastep
-
-Copyright
- © 2001, 2002 Thomas M. Eastep.
-
-
+Copyright
+© 2001, 2002 Thomas M. Eastep.
+
+
diff --git a/Shorewall-docs/download.htm b/Shorewall-docs/download.htm
index 425321a66..d1c9f4e37 100644
--- a/Shorewall-docs/download.htm
+++ b/Shorewall-docs/download.htm
@@ -9,17 +9,8 @@
Download
-
-
-
-
- Shorewall Download
- |
-
-
-
+Shorewall Download
+
I strongly urge you to read and print a copy of the Shorewall QuickStart Guide
for the configuration that most closely matches your own.
@@ -86,20 +77,20 @@ removing the file /etc/shorewall/startup_disabled.
HTTP |
FTP |
-
- SourceForge
- |
- sf.net |
- Browse |
- N/A |
-
| Slovak Republic |
Shorewall.net |
Browse |
Browse |
+
+
+ | Washington State, USA |
+ Shorewall.net |
+ Browse |
+ Browse |
| Texas, USA |
@@ -144,7 +135,8 @@ Unavailable)
Browse
|
- N/A
+ | Browse
|
@@ -159,11 +151,14 @@ Unavailable)
- | Washington State, USA |
- Shorewall.net |
- Browse |
- Browse |
+ Sourceforge - California, USA (Incomplete)
+ |
+ Sourceforge.net
+ |
+ Browse
+ |
+ N/A
+ |
@@ -187,7 +182,7 @@ These snapshots have undergone initial testing and will have been
installed and run at shorewall.net.
-Last Updated 9/25/2003 - Last Updated 11/14/2003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/errata.htm b/Shorewall-docs/errata.htm
index 247361e6f..5d14cceca 100644
--- a/Shorewall-docs/errata.htm
+++ b/Shorewall-docs/errata.htm
@@ -10,43 +10,36 @@
-
-
-
-
- Shorewall Errata/Upgrade
-Issues
- |
-
-
-
- IMPORTANT
+
+Shorewall Errata
+
+IMPORTANT
-
If you use a Windows system to download
a corrected script, be sure to run the script through dos2unix after you have moved
-it to your Linux system.
+it
+to your Linux system.
If you are installing Shorewall for the first
-time and plan to use the .tgz and install.sh script, you can untar
-the archive, replace the 'firewall' script in the untarred directory
-with the one you downloaded below, and then run install.sh.
+time and plan to use the .tgz and install.sh script, you can untar the
+archive, replace the 'firewall' script in the untarred directory with
+the one you downloaded below, and then run install.sh.
When the instructions say to install a
-corrected firewall script in /usr/share/shorewall/firewall,
-you may rename the existing file before copying in the new file.
+corrected firewall script in /usr/share/shorewall/firewall, you may
+rename the existing file before copying in the new file.
DO NOT INSTALL CORRECTED
COMPONENTS ON A RELEASE EARLIER THAN THE ONE THAT THEY ARE LISTED UNDER
-BELOW. For example, do NOT install the 1.3.9a firewall script
-if you are running 1.3.7c.
+BELOW. For example, do NOT install the 1.3.9a firewall script if you
+are
+running 1.3.7c.
@@ -61,8 +54,7 @@ Version 1.1
Problem with
iptables version 1.2.3 on RH7.2
Problems with kernels >= 2.4.18 and
-RedHat
-iptables
+RedHat iptables
Problems installing/upgrading RPM on SuSE
Problems with iptables version 1.2.7 and
MULTIPORT=Yes
@@ -75,12 +67,38 @@ REJECT (also applies to 2.4.21-RC1) 
Problems in Version 1.4
+1.4.7
+
+ - Using some versions of 'ash' (such as from RH8) as the
+SHOREWALL_SHELL causes "shorewall [re]start" to fail with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+ - When more than one ICMP type is listed in a rule and your kernel
+includes multiport match support, the firewall fails to
+start.
+ - Regardless of the setting of LOGUNCLEAN, the value
+LOGUNCLEAN=info was used.
+ - After the following error message, Shorewall was left in an
+inconsistent state:
+
+Error: Unable to determine the routes through interface xxx
+
+
+These problems have been corrected in this firewall
+script which may be installed in /var/share/shorewall/firewall as
+described above.
1.4.6
- If TC_ENABLED is set to yes in shorewall.conf then Shorewall
would fail to start with the error "ERROR: Traffic Control
-requires Mangle";
-that problem has been corrected in this
firewall script which may be installed in
/var/share/shorewall/firewall as described above. This problem is also
@@ -95,13 +113,10 @@ follows:
For Shorewall 1.4.6 and 1.4.6a users, this problem has been corrected
in this
firewall script which may be installed in
-/var/share/shorewall/firewall
-as described above. For all other versions, you will have to edit your
-'firewall'
-script (in versions 1.4.*, it is located in
-/usr/share/shorewall/firewall).
-Locate the function add_tcrule_() and in that function, replace this
-line:
+/var/share/shorewall/firewall as described above. For all other
+versions, you will have to edit your 'firewall' script (in versions
+1.4.*, it is located in /usr/share/shorewall/firewall). Locate the
+function add_tcrule_() and in that function, replace this line:
r=`mac_match
$source`
@@ -116,13 +131,13 @@ Note that there must be a space before the ending quote!
1.4.4b
1.4.4
@@ -158,7 +173,8 @@ to allow integration of Shorewall with Fireparse
of the integration problem. I have implimented a new LOGFORMAT variable
which will replace LOGMARKER which has completely solved this problem
and is currently in production with fireparse here at shorewall.net.
-The updated files may be found at ftp://ftp1.shorewall.net/pub/shorewall/errata/1.4.3/fireparse/.
See the 0README.txt file for details.
@@ -171,8 +187,8 @@ directory created in /tmp is not being removed. This problem may be
corrected by installing this firewall script in
-/usr/share/shorewall/firewall as
-described above.
+/usr/share/shorewall/firewall
+as described above.
1.4.1a, 1.4.1 and 1.4.0
@@ -191,7 +207,8 @@ in /etc/shorewall/common.def.
produces the harmless additional message:
/usr/share/shorewall/firewall: line 2174: [: =:
-unary operator expected
+unary operator
+expected
You may correct the problem by installing 1.4.0
- When running under certain shells Shorewall will attempt to
-create ECN rules even when /etc/shorewall/ecn is empty. You may
-either just remove /etc/shorewall/ecn or you can install this
correct script in /usr/share/shorewall/firewall as described above.
@@ -222,17 +239,19 @@ released this buggy iptables in RedHat 7.2.
I have built a
corrected 1.2.3 rpm which you can download here and I have
-also built an
iptables-1.2.4 rpm which you can download here. If you are
-currently running RedHat 7.1, you can install either of these RPMs before
- you upgrade to RedHat 7.2.
+currently
+running RedHat 7.1, you can install either of these RPMs before
+ you
+upgrade to RedHat 7.2.
Update 11/9/2001: RedHat
-has released an iptables-1.2.4 RPM of their own which
-you can download from http://www.redhat.com/support/errata/RHSA-2001-144.html.
- I have installed this RPM on my firewall and
-it works fine.
+has released an iptables-1.2.4 RPM of their own which you can download
+from http://www.redhat.com/support/errata/RHSA-2001-144.html.I
+have installed this RPM on my firewall and it works fine.
If you would like to patch iptables 1.2.3 yourself,
the patches are available for download. This patch
@@ -246,8 +265,8 @@ corrects a problem in handling the TOS target.
- patch -p0 < the-patch-file
-Problems with kernels >= 2.4.18 and
-RedHat iptables
+Problems with kernels >= 2.4.18 and RedHat
+iptables
Users who use RedHat iptables RPMs and who upgrade to kernel
2.4.18/19 may experience the following:
@@ -259,10 +278,9 @@ user-space debugging code was not updated to reflect recent changes in
the Netfilter 'mangle' table. You can correct the problem by installing
-this iptables RPM. If you are already running a
-1.2.5 version of iptables, you will need to specify the
---oldpackage option to rpm (e.g., "iptables -Uvh --oldpackage
-iptables-1.2.5-1.i386.rpm").
+this iptables RPM. If you are already running a 1.2.5 version of
+iptables, you will need to specify the --oldpackage option to rpm
+(e.g., "iptables -Uvh --oldpackage iptables-1.2.5-1.i386.rpm").
Problems installing/upgrading RPM on SuSE
If you find that rpm complains about a conflict with kernel <=
@@ -275,7 +293,8 @@ MULTIPORT=Yes
The iptables 1.2.7 release of iptables has made an incompatible
change to the syntax used to specify multiport match rules; as a
consequence, if you install iptables 1.2.7 you must be running
-Shorewall 1.3.7a or later or:
+Shorewall
+1.3.7a or later or:
- set MULTIPORT=No in /etc/shorewall/shorewall.conf; or
- if you are running Shorewall 1.3.6 you may install
Setting up NAT...
iptables: Invalid argument
Terminated
The solution is to put "no" in the LOCAL column. Kernel support for
LOCAL=yes has never worked properly and 2.4.18-10 has disabled it. The
-2.4.19 kernel contains corrected support
-under a new kernel configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
+2.4.19 kernel contains corrected support under a new kernel
+configuraiton option; see http://www.shorewall.net/Documentation.htm#NAT
Problems with RH Kernels after 2.4.20-9
-and REJECT
-(also applies to 2.4.21-RC1)
+and
+REJECT (also applies to 2.4.21-RC1)
Beginning with errata kernel 2.4.20-13.9, "REJECT --reject-with
tcp-reset" is broken. The symptom most commonly seen is that REJECT
rules act just like DROP rules when dealing with TCP. A kernel patch
-and precompiled modules to fix this problem are available at ftp://ftp1.shorewall.net/pub/shorewall/errata/kernel.
- Last updated 7/23/2003 - Tom
-Eastep
-
+ Last updated 10/11/2003 - Tom
+Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
diff --git a/Shorewall-docs/fallback.htm b/Shorewall-docs/fallback.htm
index 1141bd0b6..88b2cd87d 100644
--- a/Shorewall-docs/fallback.htm
+++ b/Shorewall-docs/fallback.htm
@@ -1,77 +1,61 @@
-
Shorewall Fallback and Uninstall
-
-
-
-
-
-
-
-
- Fallback and Uninstall
- |
-
-
-
-
-
+
+
+
Fallback and Uninstall
+
+
+
+
Shorewall includes a fallback
script and an uninstall
script.
-
-Falling Back to the Previous Version of Shorewall
-using the Fallback Script
-
-If you install Shorewall and discover that it doesn't work for you, you
+
Falling Back to the Previous Version of
+Shorewall using the Fallback Script
+If you install Shorewall and discover that it doesn't work for you,
+you
can fall back to your previously installed version. To do that:
-
- - cd to the distribution directory for the version of Seattle
-Firewall that you are currently running (NOT the version
- that you want to fall back to).
- - Type "./fallback.sh"
-
+ - cd to the distribution directory for the version of Seattle
+Firewall that you are currently running (NOT the version that
+you want to fall back to).
+ - Type "./fallback.sh"
-
-Warning: The fallback script will replace /etc/shorewall/policy,
-/etc/shorewall/rules, /etc/shorewall/interfaces, /etc/shorewall/nat, /etc/shorewall/proxyarp
-and /etc/shorewall/masq with the version of these files from before the current
+Warning: The fallback script will replace
+/etc/shorewall/policy,
+/etc/shorewall/rules, /etc/shorewall/interfaces, /etc/shorewall/nat,
+/etc/shorewall/proxyarp
+and /etc/shorewall/masq with the version of these files from before the
+current
version was installed. Any changes to any of these files will be lost.
-
-Falling Back to the Previous Version of Shorewall using
-rpm
-
-If your previous version of Shorewall was installed using RPM, you may
-fall back to that version by typing "rpm -Uvh --force <old rpm>" at
-a root shell prompt (Example: "rpm -Uvh --force /downloads/shorewall-3.1=0noarch.rpm"
+
Falling Back to the Previous Version of Shorewall
+using rpm
+If your previous version of Shorewall was installed using RPM, you
+may
+fall back to that version by typing "rpm -Uvh --force <old rpm>"
+at
+a root shell prompt (Example: "rpm -Uvh --force
+/downloads/shorewall-3.1=0noarch.rpm"
would fall back to the 3.1-0 version of Shorewall).
-
Uninstalling Shorewall
-
If you no longer wish to use Shorewall, you may remove it by:
-
- - cd to the distribution directory for the version of Shorewall
+
- cd to the distribution directory for the version of Shorewall
that you have installed.
- - type "./uninstall.sh"
-
+ - type "./uninstall.sh"
-
-If you installed using an rpm, at a root shell prompt type "rpm -e shorewall".
-
+If you installed using an rpm, at a root shell prompt type "rpm -e
+shorewall".
Last updated 3/26/2001 - Tom Eastep
- Copyright © Copyright © 2001, 2002 Thomas M. Eastep.
diff --git a/Shorewall-docs/gnu_mailman.htm b/Shorewall-docs/gnu_mailman.htm
index 74c55a49b..dd2d374ae 100644
--- a/Shorewall-docs/gnu_mailman.htm
+++ b/Shorewall-docs/gnu_mailman.htm
@@ -1,80 +1,57 @@
-
-
-
-
GNU Mailman
-
-
-
-
-
-
- GNU Mailman/Postfix the Easy
- Way
- |
-
-
-
-
-
-
-
-The following was posted on the Postfix mailing list on 5/4/2002 by Michael
- Tokarev as a suggested addition to the Postfix FAQ.
-
+
+GNU Mailman/Postfix the Easy Way
+The following was posted on the Postfix mailing list on 5/4/2002 by
+Michael Tokarev as a suggested addition to the Postfix FAQ.
Q: Mailman does not work with Postfix, complaining about GID mismatch
-
- A: Mailman uses a setgid wrapper that is designed to be used in system-wide
- aliases file so that rest of mailman's mail handling processes will run
-with proper uid/gid. Postfix has an ability to run a command specified in
-an alias as owner of that alias, thus mailman's wrapper is not needed here.
- The best method to invoke mailman's mail handling via aliases is to use
-separate alias file especially for mailman, and made it owned by mailman
-and group mailman. Like:
-
- alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
-
- Make sure that /var/mailman/aliases.db is owned by mailman user (this
-may be done by executing postalias as mailman userid).
-
- Next, instead of using mailman-suggested aliases entries with wrapper,
-use the following:
-
- instead of
- mailinglist: /var/mailman/mail/wrapper post mailinglist
- mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
- mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
- ...
-
- use
- mailinglist: /var/mailman/scripts/post mailinglist
- mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
- mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
- ...
-
-The above tip works with Mailman 2.0; Mailman 2.1 has adopted something
-very similar so that no workaround is necessary. See the README.POSTFIX file
-included with Mailman-2.1.
-
+
+A: Mailman uses a setgid wrapper that is designed to be used in
+system-wide aliases file so that rest of mailman's mail handling
+processes will run with proper uid/gid. Postfix has an ability to run a
+command specified in an alias as owner of that alias, thus mailman's
+wrapper is not needed here. The best method to invoke mailman's mail
+handling via aliases is to use separate alias file especially for
+mailman, and made it owned by mailman and group mailman. Like:
+
+alias_maps = hash:/etc/postfix/aliases, hash:/var/mailman/aliases
+
+Make sure that /var/mailman/aliases.db is owned by mailman user (this
+may be done by executing postalias as mailman userid).
+
+Next, instead of using mailman-suggested aliases entries with wrapper,
+use the following:
+
+instead of
+mailinglist: /var/mailman/mail/wrapper post mailinglist
+mailinglist-admin: /var/mailman/mail/wrapper mailowner mailinglist
+mailinglist-request: /var/mailman/mail/wrapper mailcmd mailinglist
+...
+
+use
+mailinglist: /var/mailman/scripts/post mailinglist
+mailinglist-admin: /var/mailman/scripts/mailowner mailinglist
+mailinglist-request: /var/mailman/scripts/mailcmd mailinglist
+...
+The above tip works with Mailman 2.0; Mailman 2.1 has adopted
+something very similar so that no workaround is necessary. See the
+README.POSTFIX file included with Mailman-2.1.
Last updated 12/29/2002 - Tom Eastep
-
Copyright © 2001, 2002 Thomas M. Eastep.
-
-
-
-
+ size="2">Copyright © 2001, 2002 Thomas M.
+Eastep.
+
+
+
+
diff --git a/Shorewall-docs/images/Legend.png b/Shorewall-docs/images/Legend.png
index 8ae90a1ec..e97521e00 100755
Binary files a/Shorewall-docs/images/Legend.png and b/Shorewall-docs/images/Legend.png differ
diff --git a/Shorewall-docs/images/Logo.png b/Shorewall-docs/images/Logo.png
new file mode 100755
index 000000000..e8c518ca9
Binary files /dev/null and b/Shorewall-docs/images/Logo.png differ
diff --git a/Shorewall-docs/images/Logo1.gif b/Shorewall-docs/images/Logo1.gif
new file mode 100644
index 000000000..5f44fb3f8
Binary files /dev/null and b/Shorewall-docs/images/Logo1.gif differ
diff --git a/Shorewall-docs/images/Logo2.gif b/Shorewall-docs/images/Logo2.gif
new file mode 100644
index 000000000..801560300
Binary files /dev/null and b/Shorewall-docs/images/Logo2.gif differ
diff --git a/Shorewall-docs/images/Logo3.png b/Shorewall-docs/images/Logo3.png
new file mode 100755
index 000000000..ef7860115
Binary files /dev/null and b/Shorewall-docs/images/Logo3.png differ
diff --git a/Shorewall-docs/images/MultiPPTP.png b/Shorewall-docs/images/MultiPPTP.png
new file mode 100755
index 000000000..899790d9d
Binary files /dev/null and b/Shorewall-docs/images/MultiPPTP.png differ
diff --git a/Shorewall-docs/images/MultiZone1.png b/Shorewall-docs/images/MultiZone1.png
new file mode 100755
index 000000000..a2391cab9
Binary files /dev/null and b/Shorewall-docs/images/MultiZone1.png differ
diff --git a/Shorewall-docs/images/MultiZone1A.png b/Shorewall-docs/images/MultiZone1A.png
new file mode 100755
index 000000000..b374f705d
Binary files /dev/null and b/Shorewall-docs/images/MultiZone1A.png differ
diff --git a/Shorewall-docs/images/MultiZone1B.png b/Shorewall-docs/images/MultiZone1B.png
new file mode 100755
index 000000000..c46ddd7ba
Binary files /dev/null and b/Shorewall-docs/images/MultiZone1B.png differ
diff --git a/Shorewall-docs/images/MultiZone2.png b/Shorewall-docs/images/MultiZone2.png
new file mode 100755
index 000000000..ec3b74cac
Binary files /dev/null and b/Shorewall-docs/images/MultiZone2.png differ
diff --git a/Shorewall-docs/images/Netfilter.png b/Shorewall-docs/images/Netfilter.png
index 170752fb3..c4d393d98 100755
Binary files a/Shorewall-docs/images/Netfilter.png and b/Shorewall-docs/images/Netfilter.png differ
diff --git a/Shorewall-docs/images/ProtectedBy.png b/Shorewall-docs/images/ProtectedBy.png
new file mode 100755
index 000000000..985a5de27
Binary files /dev/null and b/Shorewall-docs/images/ProtectedBy.png differ
diff --git a/Shorewall-docs/images/netfilterconf.png b/Shorewall-docs/images/netfilterconf.png
new file mode 100644
index 000000000..6531ae265
Binary files /dev/null and b/Shorewall-docs/images/netfilterconf.png differ
diff --git a/Shorewall-docs/images/staticnat.png b/Shorewall-docs/images/staticnat.png
index a147089b7..bd566608e 100644
Binary files a/Shorewall-docs/images/staticnat.png and b/Shorewall-docs/images/staticnat.png differ
diff --git a/Shorewall-docs/images/staticnat.vsd b/Shorewall-docs/images/staticnat.vsd
index 3ce9724bd..5f73334df 100644
Binary files a/Shorewall-docs/images/staticnat.vsd and b/Shorewall-docs/images/staticnat.vsd differ
diff --git a/Shorewall-docs/index.htm b/Shorewall-docs/index.htm
index 6bf808fdb..831ef6161 100644
--- a/Shorewall-docs/index.htm
+++ b/Shorewall-docs/index.htm
@@ -1,22 +1,19 @@
+
-
-
Shoreline Firewall
-
-
-
-
-
-Last modified 8/17/2002 - Tom
+To pass traffic SMB/Samba traffic between zones Z1 and Z2:
+/etc/shorewall/rules:
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DEST |
+ PROTO |
+ DEST
+PORT(S) |
+ SOURCE
+PORT(S) |
+ ORIGINAL
+DEST |
+
+
+ | ACCEPT |
+ Z1
+ |
+ Z2
+ |
+ udp |
+ 137:139 |
+ |
+ |
+
+
+ | ACCEPT |
+ Z1
+ |
+ Z2
+ |
+ tcp |
+ 137,139,445 |
+ |
+ |
+
+
+ | ACCEPT |
+ Z1
+ |
+ Z2
+ |
+ udp |
+ 1024: |
+ 137 |
+ |
+
+
+ | ACCEPT |
+ Z2
+ |
+ Z1
+ |
+ udp |
+ 137:139 |
+ |
+ |
+
+
+ | ACCEPT |
+ Z2
+ |
+ Z1
+ |
+ tcp |
+ 137,139,445 |
+ |
+ |
+
+
+ | ACCEPT |
+ Z2
+ |
+ Z1
+ |
+ udp |
+ 1024: |
+ 137 |
+ |
+
+
+
+
+
+To make network browsing ("Network Neighborhood") work properly between
+Z1 and Z2 requires a Windows Domain Controller and/or a WINS server. I
+run Samba on my firewall to handle browsing between two zones connected
+to my firewall. Details are here.
+Last modified 10/22/2002 - Tom
Eastep
Copyright
© 2002 Thomas M. Eastep.
diff --git a/Shorewall-docs/seattlefirewall_index.htm b/Shorewall-docs/seattlefirewall_index.htm
index 52c7053a4..b15df5a38 100644
--- a/Shorewall-docs/seattlefirewall_index.htm
+++ b/Shorewall-docs/seattlefirewall_index.htm
@@ -7,30 +7,38 @@
-
+ style="border-collapse: collapse; width: 100%; height: 100%;"
+ id="AutoNumber4">
- Introduction
+ Site Problem
+The server that normally hosts www.shorewall.net and ftp.shorewall.net
+is currently down. Until it is back up, a small server with very
+limited bandwidth is being used temporarly. You will likely experience
+better response time from the Sourceforge site
+or from one of the other mirrors.
+Sorry for the inconvenience.
+
+ Introduction to Shorewall
+ This is the Shorewall 1.4 Web Site
+The information on this site applies only to 1.4.x releases of
+Shorewall. For older versions:
+
+ - The 1.3 site is here.
+ - The 1.2 site is here.
+
+ Glossary
+
- Netfilter - the
packet filter facility built into the 2.4 and later Linux kernels.
@@ -40,12 +48,12 @@ and control that facility. Netfilter can be used in ipchains
compatibility mode.
- iptables - the utility program used to configure and
-control
-Netfilter. The term 'iptables' is often used to refer to the
-combination of iptables+Netfilter (with Netfilter not in
-ipchains compatibility mode).
-
+control Netfilter. The term 'iptables' is often used to refer to the
+combination of iptables+Netfilter (with Netfilter not in ipchains
+compatibility mode).
+ What is Shorewall?
+
The Shoreline Firewall, more commonly known as "Shorewall", is
high-level tool for configuring Netfilter. You describe your
firewall/gateway requirements using entries in a set of configuration
@@ -57,367 +65,237 @@ system. Shorewall does not use Netfilter's ipchains compatibility mode
and can thus take advantage of Netfilter's connection state tracking
capabilities.
+Shorewall is not a
+daemon. Once Shorewall has configured Netfilter, it's job is complete
+although the /sbin/shorewall
+program can be used at any time to monitor the Netfilter firewall.
+ Getting Started with Shorewall
+New to Shorewall? Start by selecting the QuickStart Guide that most
+closely match your environment and follow the step by step instructions.
+ Looking for Information?
+The Documentation
+Index is a good place to start as is the Quick Search in the frame
+above.
+ License
+
This program is free software; you can redistribute it and/or modify it
under the terms of Version
-2 of the GNU
-General Public License as published by the Free Software Foundation.
+2 of the GNU General Public License as published by the Free
+Software Foundation.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
+General
+Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
675 Mass Ave, Cambridge, MA 02139, USA
Copyright 2001, 2002, 2003 Thomas M.
-Eastep
- This is the Shorewall 1.4 Web Site
-The information on this site applies only to 1.4.x releases of
-Shorewall. For older versions:
-
- - The 1.3 site is here.
- - The 1.2 site is here.
-
-
- Getting Started with Shorewall
-New to Shorewall? Start by selecting the QuickStart Guide that most
-closely match your environment
-and follow the step by step instructions.
- Looking for Information?
-The Documentation
-Index is a good place to start as is the Quick Search to your
-right.
- Running Shorewall on Mandrake with a two-interface setup?
-If so, the documentation on
-this site will not apply directly to your setup. If you want
-to use the documentation that you find here, you will want to consider
-uninstalling what you have and installing a setup that matches the
-documentation on this site. See the Two-interface
-QuickStart Guide for details.
- News
- 10/06/2003 - Shorewall 1.4.7
-
- Problems Corrected since version 1.4.6 (Those in bold font
-were corrected since 1.4.7 RC2)
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
-variable was being tested before it was set.
- - Corrected handling of MAC addresses in the SOURCE column of
-the tcrules file. Previously, these addresses resulted in an invalid
-iptables command.
- - The "shorewall stop" command is now disabled when
-/etc/shorewall/startup_disabled exists. This prevents people from
-shooting themselves in the foot prior to having configured Shorewall.
- - A change introduced in version 1.4.6 caused error messages
-during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses
-were being added to a PPP interface; the addresses were successfully
-added in spite of the messages.
-
-The firewall script has been modified to eliminate the error messages
- - Interface-specific dynamic blacklisting chains are
-now displayed by "shorewall monitor" on the "Dynamic Chains" page
-(previously named "Dynamic Chain").
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
- - The 'shorewall reject' and
-'shorewall drop' commands now delete any existing rules for the subject
-IP address before adding a new DROP or REJECT rule. Previously, there
-could be many rules for the same IP address in the dynamic chain so
-that multiple 'allow' commands were required to re-enable traffic
-to/from the address.
- - When ADD_SNAT_ALIASES=Yes in
-shorewall.conf, the following entry in /etc/shorewall/masq resulted in
-a startup error:
-
- eth0 eth1
-206.124.146.20-206.124.146.24
-
-
- - Shorewall previously choked over
-IPV6 addresses configured on interfaces in contexts where Shorewall
-needed to detect something about the interface (such as when "detect"
-appears in the BROADCAST column of the /etc/shorewall/interfaces file).
- - Shorewall will now load
-module files that are formed from the module name by appending ".o.gz".
- - When Shorewall adds a route to a
-proxy ARP host and such a route already exists, two routes resulted
-previously. This has been corrected so that the existing route is
-replaced if it already exists.
- - The rfc1918 file has been
-updated to reflect recent allocations.
- - The documentation of the
-USER SET column in the rules file has been corrected.
- - If there is no policy
-defined for
-the zones specified in a rule, the firewall script previously
-encountered a shell syntax error:
-
-
- [: NONE: unexpected operator
-
-
-Now, the absence of a policy generates an error message and the
-firewall is stopped:
-
-
- No policy defined from zone
-<source> to zone <dest>
-
-
- - Previously, if neither
-/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
-would fail to start and would not remove the lock file. Failure to
-remove the lock file resulted in the following during subsequent
-attempts to start:
-
-
- Loading /usr/share/shorewall/functions...
- Processing /etc/shorewall/params ...
- Processing /etc/shorewall/shorewall.conf...
- Giving up on lock file /var/lib/shorewall/lock
- Shorewall Not Started
-
-Shorewall now reports a fatal error if neither of these two files exist
-and correctly removes the lock fille.
- - The order of processing
-the
-various options has been changed such that blacklist entries now take
-precedence over the 'dhcp' interface setting.
- - The log message generated
-from the
-'logunclean' interface option has been changed to reflect a disposition
-of LOG rather than DROP.
- - When a user name and/or a
-group
-name was specified in the USER SET column and the destination zone was
-qualified with a IP address, the user and/or group name was not being
-used to qualify the rule.
-
- Example:
-
- ACCEPT fw net:192.0.2.12 tcp 23 - - - vladimir:
-
-
- - The /etc/shorewall/masq
-file has had the spurious "/" character at the front removed.
-
- Migration Issues:
-
- - Shorewall IP Traffic Accounting has changed since snapshot
-20030813 -- see the Accounting Page for
-details.
- - The Uset Set capability introduced in SnapShot 20030821 has
-changed -- see the User Set page for
-details.
- - The per-interface Dynamic Blacklisting facility introduced
-in the first post-1.4.6 Snapshot has been removed. The facility had too
-many idiosyncrasies for dial-up users to be a viable part of Shorewall.
-
-
- New Features:
-
- - Thanks to Steve Herber, the 'help' command can now give
-command-specific help (e.g., shorewall help <command>).
- - A new option "ADMINISABSENTMINDED" has been added to
-/etc/shorewall/shorewall.conf. This option has a default value of "No"
-for existing users which causes Shorewall's 'stopped' state to
-continue as it has been; namely, in the stopped state only traffic
-to/from hosts listed in /etc/shorewall/routestopped is accepted.
-
-With ADMINISABSENTMINDED=Yes (the default for new installs), in
-addition to traffic to/from the hosts listed in
-/etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall itself; and
- b) All traffic that is part of or related to an
-already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
-entered through an ssh session will not kill the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it is still
-possible for people to shoot themselves in the foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
-eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
-loc:192.168.1.5 tcp 22
- ACCEPT loc
-fw tcp 22
-
-From a remote system, I ssh to 206.124.146.178 which establishes an SSH
-connection with local system 192.168.1.5. I then create a second SSH
-connection
-from that computer to the firewall and confidently type "shorewall
-stop".
-As part of its stop processing, Shorewall removes eth0:0 which kills my
-SSH
-connection to 192.168.1.5!!!
- - Given the wide range of VPN software, I can never hope to
-add specific support for all of it. I have therefore decided to add
-"generic" tunnel support.
-
-Generic tunnels work pretty much like any of the other tunnel types.
-You usually add a zone to represent the systems at the other end of the
-tunnel and you add the appropriate rules/policies to
-implement your security policy regarding traffic to/from those systems.
-
-In the /etc/shorewall/tunnels file, you can have entries of the form:
-
-generic:<protocol>[:<port>] <zone> <ip
-address> <gateway zones>
-
-where:
-
- <protocol> is the protocol
-used by the tunnel
- <port> if the protocol
-is 'udp' or 'tcp' then this is the destination port number used by the
-tunnel.
- <zone> is the zone of
-the remote tunnel gateway
- <ip address> is the IP
-address of the remote tunnel gateway.
- <gateway zone>
-Optional. A comma-separated list of zone names. If specified, the
-remote gateway is to be considered part of these zones.
- - An 'arp_filter' option has been added to the
-/etc/shorewall/interfaces file. This option causes
-/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
-result that this interface will only answer ARP 'who-has' requests from
-hosts that are routed out through that interface. Setting this option
-facilitates testing of your firewall where multiple firewall interfaces
-are connected to the same HUB/Switch (all interfaces connected to the
-single HUB/Switch should have this option specified). Note that using
-such a configuration in a production environment is strongly
-recommended against.
- - The ADDRESS column in /etc/shorewall/masq may now include a
-comma-separated list of addresses and/or address ranges. Netfilter will
-use all listed addresses/ranges in round-robin fashion. \
- - An /etc/shorewall/accounting file has been added to allow
-for traffic accounting. See the accounting
-documentation for a description of this facility.
- - Bridge interfaces (br[0-9]) may now be used in
-/etc/shorewall/maclist.
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
-/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
-rules, rate limiting occurs in the nat table DNAT rule; the
-corresponding ACCEPT rule in the filter table is not rate limited. If
-you want to limit the filter table rule, you will need o create two
-rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
-separately.
-
- Warning: When rate
-limiting is specified on a rule with "all" in the SOURCE or DEST
-fields, the limit will apply to each pair of zones individually rather
-than as a single limit for all pairs of covered by the rule.
-
-To specify a rate limit,
-
-a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
-<rate>/<interval>[:<burst>] >
-
-
-where
-
- <rate> is the sustained rate per
-<interval>
- <interval> is "sec" or "min"
- <burst> is the largest burst
-accepted within an <interval>. If not given, the default of 5 is
-assumed.
-
-There may be no white space between the ACTION and "<" nor there may
-be any white space within the burst specification. If you want to
-specify logging of a rate-limited rule, the ":" and log level comes
-after the ">" (e.g., ACCEPT<2/sec:4>:info ).
-
-b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
-file. You may specify the rate limit there in the format:
-
-
-<rate>/<interval>[:<burst>]
-
-Let's take an example:
-
-
-ACCEPT<2/sec:4>
-net dmz
-tcp 80
-
-The first time this rule is reached, the packet will be accepted; in
-fact, since the burst is 4, the first four packets will be accepted.
-After this, it will be 500ms (1 second divided by the rate
-of 2) before a packet will be accepted from this rule, regardless of
-how many packets reach it. Also, every 500ms which passes without
-matching a packet, one of the bursts will be regained; if no packets
-hit the rule for 2 second, the burst will be fully recharged; back
-where we started.
-
- - Multiple chains may now be displayed in one "shorewall
-show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
- - Output rules (those with $FW as the SOURCE) may now be
-limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html
-for details.
-
-
-
- 8/27/2003 - Shorewall Mirror in Australia
- Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au),
-there is now a Shorewall Mirror in Australia:
- http://www.shorewall.com.au
- ftp://ftp.shorewall.com.au
+Eastep
- 8/26/2003 - French Version of the Shorewall Setup
-Guide
-Thanks to Fabien Demassieux, there is now a French translation of the
-Shorewall Setup Guide. Merci Beacoup, Fabien!
-
- 8/5/2003 - Shorewall-1.4.6b
-
- Problems Corrected since version 1.4.6:
-
- - Previously, if TC_ENABLED is set to yes in shorewall.conf
-then Shorewall would fail to start with the error "ERROR: Traffic
-Control requires Mangle"; that problem has been corrected.
- - Corrected handling of MAC addresses in the SOURCE column of
-the
-tcrules file. Previously, these addresses resulted in an invalid
-iptables
-command.
- - The "shorewall stop" command is now disabled when
-/etc/shorewall/startup_disabled
-exists. This prevents people from shooting themselves in the foot prior
+
Running Shorewall on Mandrake with a two-interface setup?
+If so, the documentation on this site will not apply directly
to
-having configured Shorewall.
- - A change introduced in version 1.4.6 caused error messages
-during
-"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
-being
-added to a PPP interface; the addresses were successfully added in
-spite
-of the messages.
-
-The firewall script has been modified to eliminate the error messages.
+your setup. If you want to use the documentation that you find here,
+you will want to consider uninstalling what you have and installing a
+setup that matches the documentation on this site. See the Two-interface QuickStart Guide for
+details.
+ News
+ 11/07/2003 - Shorewall 1.4.8
+
+ Problems Corrected since version 1.4.7:
+
+
+ - Tuomo Soini has supplied a correction to a problem that
+occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+ - Andres Zhoglo has supplied a correction that avoids trying
+to use the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+ - Previously, if the following error message was issued,
+Shorewall was left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has
+been corrected.
+ - In Shorewall 1.4.2, an optimization was added. This
+optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F"
+or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
+ - An incorrect comment concerning Debian's use of the
+SUBSYSLOCK option has been removed from shorewall.conf.
+ - Previously, neither the 'routefilter' interface option nor
+the
+ROUTE_FILTER parameter were working properly. This has been corrected
+(thanks to Eric Bowles for his analysis and patch). The definition of
+the ROUTE_FILTER option has changed however. Previously,
+ROUTE_FILTER=Yes was documented as enabling route filtering on all
+interfaces (which didn't work). Beginning with this release, setting
+ROUTE_FILTER=Yes will enable route filtering of all interfaces brought
+up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can
+coexist with the use of the 'routefilter' option in the interfaces file.
+ - If MAC verification was enabled on an interface with a /32
+address and
+a broadcast address then an error would occur during startup.
+ - he NONE policy's intended use is to suppress the generating
+of
+rules that can't possibly be traversed. This means that a policy of
+NONE is inappropriate where the source or destination zone is $FW or
+"all". Shorewall now generates an error message if such a policy is
+given in /etc/shorewall/policy. Previously such a policy caused
+"shorewall start" to fail.
+ - The 'routeback' option was broken for wildcard interfaces
+(e.g.,
+"tun+"). This has been corrected so that 'routeback' now works as
+expected in this case.
+
+
+Migration Issues:
+
+ - The definition of the ROUTE_FILTER option in shorewall.conf
+has changed as described in item 8) above.
+
+
+New Features:
+
+ - A new QUEUE action has been introduced for rules. QUEUE
+allows
+you to pass connection requests to a user-space filter such as ftwall
+(http://p2pwall.sourceforge.net). The ftwall program
+allows for effective filtering of p2p applications such as Kazaa. For
+example, to use ftwall to filter P2P clients in the 'loc' zone, you
+would add the following rules:
+
+ QUEUE loc
+ net tcp
+ QUEUE loc
+ net udp
+ QUEUE loc
+ fw udp
+
+You would normally want to place those three rules BEFORE any ACCEPT
+rules for loc->net udp or tcp.
+
+Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
+Shorewall will only pass connection requests (SYN packets) to user
+space. This is for compatibility with ftwall.
+ - A BLACKLISTNEWNONLY option has been added to
+shorewall.conf. When this option is set to "Yes", the blacklists
+(dynamic and static) are only consulted for new connection requests.
+When set to "No" (the default if the variable is not set), the
+blacklists are consulted on every packet.
+
+Setting this option to "No" allows blacklisting to stop existing
+connections from a newly blacklisted host but is more expensive in
+terms of packet processing time. This is especially true if the
+blacklists contain a large number of entries.
+ - Chain names used in the /etc/shorewall/accounting file may
+now begin with a digit ([0-9]) and may contain embedded dashes ("-").
+
+ 10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper
+bag awards Shorewall
+1.4.7c released.
+
+ - The saga with "<zone>_frwd" chains continues. The
+1.4.7c
+script produces a ruleset that should work for everyone even if it is
+not
+quite optimal. My apologies for this ongoing mess.
+
+
+ 10/24/2003 - Shorewall 1.4.7b
+ This is a bugfx rollup of the 1.4.7a fixes plus:
+
+
+ - The fix for problem 5 in 1.4.7a was wrong with the result
+that
+"<zone>_frwd" chains might contain too few rules. That wrong code
+is corrected in this release.
+
+
+ 10/21/2003 - Shorewall 1.4.7a
+ This is a bugfix rollup of the following problem corrections:
+
+
+ - Tuomo Soini has supplied a correction to a problem that
+occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+
+
+ - Andres Zhoglo has supplied a correction that avoids trying
+to use the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued,
+Shorewall was left in an inconsistent state.
+
+ Error: Unable to determine the routes through
+interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has
+been corrected.
+ - In Shorewall 1.4.2, an optimization was added. This
+optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F"
+or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
+
+
+
@@ -432,56 +310,33 @@ You can find their work at:
http://leaf.sourceforge.net/devel/jnilo
- Congratulations to Jacques
-and Eric on the recent release of Bering 1.2!!!
- Donations
- |
-
-
- Extended Search
+ Congratulations to Jacques and Eric on the recent release of
+Bering 1.2!!!
+
+
+ Donations
+ 
+ Shorewall is free but if you try it and find it useful,
+please consider making a donation to Starlight
+Children's Foundation. Thanks!
+
|
-
-Updated 10/06/2003 - Tom Eastep
+
Updated 11/13/2003 - Tom Eastep
-
diff --git a/Shorewall-docs/shoreline.htm b/Shorewall-docs/shoreline.htm
index 8fc3fecbd..3e7f9bdb1 100644
--- a/Shorewall-docs/shoreline.htm
+++ b/Shorewall-docs/shoreline.htm
@@ -9,18 +9,10 @@
-
-
-
-
- Tom Eastep
- |
-
-
-
- 
+Tom Eastep
+
+
"The Aging Geek" -- June 2003
diff --git a/Shorewall-docs/shorewall_extension_scripts.htm b/Shorewall-docs/shorewall_extension_scripts.htm
index a18b8b96a..96fcbf33a 100644
--- a/Shorewall-docs/shorewall_extension_scripts.htm
+++ b/Shorewall-docs/shorewall_extension_scripts.htm
@@ -1,118 +1,89 @@
-
-
-
-
Shorewall Extension Scripts
-
-
-
-
-
-
- Extension Scripts
- |
-
-
-
-
-
- Extension scripts are user-provided scripts that are invoked at various
- points during firewall start, restart, stop and clear. The scripts are
- placed in /etc/shorewall and are processed using the Bourne shell "source"
- mechanism.
-
-
+
+Extension Scripts
+
+Extension scripts are user-provided scripts that are invoked at
+various points during firewall start, restart, stop and clear. The
+scripts are placed in /etc/shorewall and are processed using the Bourne
+shell "source" mechanism.
+
Caution:
-
-
+
- - Be sure that you actually need to use an
-extension script to do what you want. Shorewall has a wide range of features
-that cover most requirements.
- - DO NOT SIMPLY COPY RULES THAT YOU FIND ON
-THE NET INTO AN EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT BREAK
- SHOREWALL. TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT YOU ARE
+
- Be sure that you actually need to use an
+extension script to do what you want. Shorewall has a wide range of
+features
+that cover most requirements.
+ - DO NOT SIMPLY COPY RULES THAT YOU FIND
+ON THE NET INTO AN EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT
+BREAK SHOREWALL. TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT
+YOU ARE
DOING WITH RESPECT TO iptables/Netfilter
-
-
-The following scripts can be supplied:
-
+The following scripts can be supplied:
- - init -- invoked early in "shorewall start" and "shorewall
- restart"
- - start -- invoked after the firewall has been started or restarted.
- - stop -- invoked as a first step when the firewall is being stopped.
- - stopped -- invoked after the firewall has been stopped.
- - clear -- invoked after the firewall has been cleared.
- - refresh -- invoked while the firewall is being refreshed but
-before the common and/or blacklst chains have been rebuilt.
- - newnotsyn (added in version 1.3.6) -- invoked after the 'newnotsyn'
- chain has been created but before any rules have been added to it.
-
+ - init -- invoked early in "shorewall start" and "shorewall restart"
+ - start -- invoked after the firewall has been started or restarted.
+ - stop -- invoked as a first step when the firewall is being
+stopped.
+ - stopped -- invoked after the firewall has been stopped.
+ - clear -- invoked after the firewall has been cleared.
+ - refresh -- invoked while the firewall is being refreshed but
+before the common and/or blacklst chains have been rebuilt.
+ - newnotsyn (added in version 1.3.6) -- invoked after the
+'newnotsyn' chain has been created but before any rules have been added
+to it.
-
-If your version of Shorewall doesn't have the file that you want
- to use from the above list, you can simply create the file yourself.
-
- You can also supply a script with the same name as any of the filter
- chains in the firewall and the script will be invoked after the /etc/shorewall/rules
- file has been processed but before the /etc/shorewall/policy file has
- been processed.
-
-The /etc/shorewall/common file receives special treatment. If this file
- is present, the rules that it defines will totally replace the default
- rules in the common chain. These default rules are contained in the
- file /etc/shorewall/common.def which may be used as a starting point
- for making your own customized file.
-
- Rather than running iptables directly, you should run it using the
-function run_iptables. Similarly, rather than running "ip" directly, you
- should use run_ip. These functions accept the same arguments as the underlying
- command but cause the firewall to be stopped if an error occurs during
+
If your version of Shorewall doesn't have the file that you
+want to use from the above list, you can simply create the file
+yourself.
+ You can also supply a script with the same name as any of the
+filter chains in the firewall and the script will be invoked after the
+/etc/shorewall/rules file has been processed but before the
+/etc/shorewall/policy file has been processed.
+The /etc/shorewall/common file receives special treatment. If this
+file is present, the rules that it defines will totally replace the
+default rules in the common chain. These default rules are contained in
+the file /etc/shorewall/common.def which may be used as a starting
+point for making your own customized file.
+ Rather than running iptables directly, you should run it using the
+function run_iptables. Similarly, rather than running "ip" directly,
+you should use run_ip. These functions accept the same arguments as the
+underlying command but cause the firewall to be stopped if an error
+occurs during
processing of the command.
-
- If you decide to create /etc/shorewall/common it is a good idea to
-use the following technique
-
- /etc/shorewall/common:
-
-
+ If you decide to create /etc/shorewall/common it is a good idea to
+use the following technique
+ /etc/shorewall/common:
+
. /etc/shorewall/common.def
<add your rules here>
-
-
-If you need to supercede a rule in the released common.def file, you can
- add the superceding rule before the '.' command. Using this technique allows
- you to add new rules while still getting the benefit of the latest common.def
- file.
-
-Remember that /etc/shorewall/common defines rules that are only applied
- if the applicable policy is DROP or REJECT. These rules are NOT applied
- if the policy is ACCEPT or CONTINUE
-
-
+
+If you need to supercede a rule in the released common.def file, you
+can add the superceding rule before the '.' command. Using this
+technique allows you to add new rules while still getting the benefit
+of the latest common.def file.
+Remember that /etc/shorewall/common defines rules that are only
+applied if the applicable policy is DROP or REJECT. These rules are NOT
+applied if the policy is ACCEPT or CONTINUE
+
-
Last updated 6/30/2003 - Tom Eastep
-
-Copyright 2002, 2003
- Thomas M. Eastep
-
-
-
-
-
+Copyright 2002,
+2003 Thomas M. Eastep
+
+
+
+
+
diff --git a/Shorewall-docs/shorewall_features.htm b/Shorewall-docs/shorewall_features.htm
index c043b43f7..70b212d83 100644
--- a/Shorewall-docs/shorewall_features.htm
+++ b/Shorewall-docs/shorewall_features.htm
@@ -1,119 +1,98 @@
-
-
-
-
Shorewall Features
-
-
-
-
-
-
- Shorewall Features
- |
-
-
-
-
-
+
+Shorewall Features
+
-
-Last updated 2/5/2003 - Tom Eastep
-
+Last updated 11/13/2003 - Tom
+Eastep
Copyright © 2001-2003 Thomas M. Eastep.
-
-
-
-
+
+
+
+
diff --git a/Shorewall-docs/shorewall_firewall_structure.htm b/Shorewall-docs/shorewall_firewall_structure.htm
deleted file mode 100644
index d738a23dc..000000000
--- a/Shorewall-docs/shorewall_firewall_structure.htm
+++ /dev/null
@@ -1,332 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
- Shorewall Firewall Structure
-
-
-
-
-
-
-
- Firewall Structure (Under
-Construction)
- |
-
-
-
-
-
- Shorewall views the network in which it is running as a set of
- zones. Shorewall itself defines exactly one zone called "fw" which
- refers to the firewall system itself . The /etc/shorewall/zones file
-is used to define additional zones and the example file provided with
-Shorewall defines the zones:
-
-
- - net -- the (untrusted) internet.
- - dmz - systems that must be accessible from the internet
- and from the local network. These systems cannot be trusted completely
-since their servers may have been compromised through a security exploit.
- - loc - systems in your local network(s). These systems
- must be protected from the internet and from the DMZ and in some
-cases, from each other.
-
-
-
-Note: You can specify the name of the firewall
-zone. For ease of description in this documentation, it is assumed
-that the firewall zone is named "fw".
-
-It can't be stressed enough that with the exception of the firewall zone,
- Shorewall itself attaches no meaning to zone names. Zone names are simply
- labels used to refer to a collection of network hosts.
-
-While zones are normally disjoint (no two zones have a host in common),
- there are cases where nested or overlapping zone definitions are appropriate.
-
-Netfilter has the concept of tables and chains. For the purpose
-of this document, we will consider Netfilter to have three tables:
-
-
- - Filter table -- this is the main table for packet filtering and
-can be displayed with the command "shorewall show".
- - Nat table -- used for all forms of Network Address Translation (NAT);
- SNAT, DNAT and MASQUERADE.
- - Mangle table -- used to modify fields in the packet header.
-
-
-
-
-Netfilter defines a number of inbuilt chains: PREROUTING, INPUT, OUTPUT,
- FORWARD and POSTROUTING. Not all inbuilt chains are present in all tables
- as shown in this table.
-
-
-
-
-
-
- CHAIN
- |
- Filter
- |
- Nat
- |
- Mangle
- |
-
-
- PREROUTING
- |
-
- |
- X
- |
- X
- |
-
-
- INPUT
- |
- X
- |
-
- |
- X
- |
-
-
- OUTPUT
- |
- X
- |
- X
- |
- X
- |
-
-
- FORWARD
- |
- X
- |
-
- |
- X
- |
-
-
- POSTROUTING
- |
-
- |
- X
- |
- X
- |
-
-
-
-
-
Shorewall doesn't create rules in all of the builtin chains. In the large
- diagram below are boxes such as shown below. This box represents in INPUT
- chain and shows that packets first flow through the INPUT chain in the Mangle
- table followed by the INPUT chain in the Filter table. The parentheses around
- "Mangle" indicate that while the packets will flow through the INPUT chain
- in the Mangle table, Shorewall does not create any rules in that chain.
-
-
-
-
-
Here is a picture of how packets traverse the various chains and tables
- in Netfilter. In that diagram, "Local Process" refers to a process running
- on the Firewall itself (in the 'fw' zone).
-
-
-
-
- In the text that follows, the paragraph numbers correspond to the box
-number in the diagram above.
-
-
-
- - Packets entering the firewall first pass through the mangle table's
- PREROUTING chain (you can see the mangle table by typing "shorewall show
- mangle"). If the packet entered through an interface that has the norfc1918
- option and if iptables/netfilter doesn't support the connection tracking
-match extension, then the packet is sent down the man1918 chain which
-will drop the packet if its destination IP address is reserved (as specified
- in the /etc/shorewall/rfc1918 file). Next the packet passes through the
- pretos chain to set its TOS field as specified in the /etc/shorewall/tos
- file. Finally, if traffic control/shaping is being used, the packet is
-sent through the tcpre chain to be marked for later use in policy
-routing or traffic control.
-
- Next, if the packet isn't part of an established connection, it passes
- through the nat table's PREROUTING chain (you can see the nat table
- by typing "shorewall show nat"). If you are doing both static nat and
- port forwarding, the order in which chains are traversed is dependent on
-the setting of NAT_BEFORE_RULES in shorewall.conf. If NAT_BEFORE_RULES is
-on then packets will ender a chain called interface_in where
- interface is the name of the interface on which the packet entered.
- Here it's destination IP is compared to each of the EXTERNAL IP
-addresses from /etc/shorewall/nat that correspond to this interface; if
-there is a match, DNAT is applied and the packet header is modified to
-the IP in the INTERNAL column of the nat file record. If the destination
-address doesn't match any of the rules in the interface_in
-chain then the packet enters a chain called sourcezone_dnat
- where sourcezone is the source zone of the packet. There it is compared
- for a match against each of the DNAT records in the rules file that specify
- sourcezone as the source zone. If a match is found, the
-destination IP address (and possibly the destination port) is modified based
-on the rule matched. If NAT_BEFORE_RULES is off, then the order of traversal
-of the interface_in and sourcezone_dnat is
-reversed.
-
-
- - Depending on whether the packet is destined for the firewall itself
- or for another system, it follows either the left or the right path. Traffic
- going to the firewall goes through chain called INPUT in the mangle table.
- Shorewall doesn't add any rules to that chain.
-
-
- - Traffic that is to be forwarded to another host goes through the chains
-called FORWARD in the mangle table. If MARK_IN_FORWARD=Yes in shorewall.conf,
-all rules in /etc/shorewall/tcrules that do not specify Prerouting (:P) are
-processed in a chain called
-
-
-
-
-
-
- - Traffic is next sent to an interface chain in the main Netfilter
- table (called 'filter'). If the traffic is destined for the firewall
-itself, the name of the interface chain is formed by appending "_in" to
- the interface name. So traffic on eth0 destined for the firewall will
-enter a chain called eth0_in. The interface chain for traffic
-that will be routed to another system is formed by appending "_fwd" to
-the interface name. So traffic from eth1 that is going to be forwarded
-enters a chain called eth1_fwd. Interfaces described with the wild-card
-character ("+") in /etc/shorewall/interfaces, share input chains. if ppp+
- appears in /etc/shorewall/interfaces then all PPP interfaces (ppp0,
-ppp1, ...) will share the interface chains ppp_in and ppp_fwd.
-In other words, "+" is deleted from the name before forming the input chain
-names.
-
- While the use of interfacechains may seem wasteful in simple environments,
- in complex setups it substantially reduces the number of rules that each
- packet must traverse.
-
-
-
- Traffic directed from a zone to the firewall itself is sent through
-a chain named <zone name>2fw. For example, traffic inbound from
- the internet and addressed to the firewall is sent through a chain named
- net2fw. Similarly, traffic originating in the firewall and being sent
-to a host in a given zone is sent through a chain named fw2<zone
-name>. For example, traffic originating in the firewall and
-destined for a host in the local network is sent through a chain named
-fw2loc.
-
- Traffic being forwarded between two zones (or from one interface to
-a zone to another interface to that zone) is sent through a chain named
- <source zone>2 <destination zone>. So for example,
- traffic originating in a local system and destined for a remote web server
- is sent through chain loc2net. This chain is referred to
-as the canonical chain from <source zone> to <destination
- zone>. Any destination NAT will have occurred before the packet
- traverses one of these chains so rules in /etc/shorewall/rules should
-be expressed in terms of the destination system's real IP address as opposed
- to its apparent external address. Similarly, source NAT will occur after
- the packet has traversed the appropriate forwarding chain so the rules
- again will be expressed using the source system's real IP address.
-
- For each record in the /etc/shorewall/policy file, a chain is created.
- Policies in that file are expressed in terms of a source zone and destination
- zone where these zones may be a zone defined in /etc/shorewall/zones,
-"fw" or "all". Policies specifying the pseudo-zone "all" matches all defined
- zones and "fw". These chains are referred to as Policy Chains. Notice
- that for an ordered pair of zones (za,zb), the canonical chain (za2zb)
- may also be the policy chain for the pair or the policy chain may be
-a different chain (za2all, for example). Packets from one zone to another
- will traverse chains as follows:
-
-
- - If the canonical chain exists, packets first traverse
-that chain.
- - If the canonical chain and policy chain are different
-and the packet does not match a rule in the canonical chain, it then
-is sent to the policy chain.
- - If the canonical chain does not exist, packets are sent
- immediately to the policy chain.
-
-
-
- The canonical chain from zone za to zone zb will be created only if
-there are exception rules defined in /etc/shorewall/rules for packets going
-from za to zb.
-
- Shorewall is built on top of the Netfilter kernel facility. Netfilter
- implements connection tracking function that allow what is often referred
- to as "statefull inspection" of packets. This statefull property allows
- firewall rules to be defined in terms of "connections" rather than in
- terms of "packets". With Shorewall, you:
-
-
- - Identify the client's zone.
- - Identify the server's zone.
- - If the POLICY from the client's zone to the server's zone
- is what you want for this client/server pair, you need do nothing further.
- - If the POLICY is not what you want, then you must add
-a rule. That rule is expressed in terms of the client's zone and
-the server's zone.
-
-
-
- Just because connections of a particular type are allowed between zone
- A and the firewall and are also allowed between the firewall and zone
-B DOES NOT mean that these connections
-are allowed between zone A and zone B. It rather means
-that you can have a proxy running on the firewall that accepts a connection
- from zone A and then establishes its own separate connection from the
-firewall to zone B.
-
- If you adopt the default policy of ACCEPT from the local zone to the
- internet zone and you are having problems connecting from a local client
- to an internet server, adding a rule won't
- help (see point 3 above).
-
-Last modified 5/22/2003 - Tom Eastep
-
- Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
-
-
diff --git a/Shorewall-docs/shorewall_logging.html b/Shorewall-docs/shorewall_logging.html
index 9e7d1bc1f..493933164 100644
--- a/Shorewall-docs/shorewall_logging.html
+++ b/Shorewall-docs/shorewall_logging.html
@@ -7,18 +7,37 @@
-
-
+Logging
+How to Log Traffic through a Shorewall Firewall
+The disposition of packets entering a Shorewall firewall is
+determined by one of a number of Shorewall facilities. Only some of
+these facilities permit logging.
+
+ - The packet is part of an established connection. The packet is
+accepted and cannot be logged.
+ - The packet represents a connection request that is related to an
+established connection (such as a data connection
+associated with an FTP control connection). These packets
+also cannot be logged.
+ - The packet is rejected because of an option in /etc/shorewall/shorewall.conf or /etc/shorewall/interfaces.
+These packets can be logged by setting the appropriate logging-related
+option in /etc/shorewall/shorewall.conf.
+ - The packet matches a rule in /etc/shorewall/rules.
+By including a syslog level (see below) in the ACTION column of a rule
+(e.g., "ACCEPT:info
+net fw tcp 22"), the connection attempt will be logged at that level.
+ - The packet doesn't match a rule so is handled by a policy defined
+in /etc/shorewall/policy. These
+may be logged by specifying a syslog level in the LOG LEVEL column of
+the policy entry (e.g., "loc net ACCEPT info"
+
+
+Where the Traffic is logged and how to Change the Destination
+
By default, Shorewall directs NetFilter to log using syslog (8). Syslog
classifies log messages by a facility and a priority
(using the notation facility.priority).
@@ -149,7 +168,8 @@ and
Here
is a post describing configuring syslog-ng to work with Shorewall.
- Updated 9/29/2003 - Tom Eastep
+ Updated 10/30/2003 - Tom
+Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep
diff --git a/Shorewall-docs/shorewall_mirrors.htm b/Shorewall-docs/shorewall_mirrors.htm
index 55ca10c19..f7fef1d06 100644
--- a/Shorewall-docs/shorewall_mirrors.htm
+++ b/Shorewall-docs/shorewall_mirrors.htm
@@ -9,20 +9,12 @@
Shorewall Mirrors
-
-
-
-
- Shorewall Mirrors
- |
-
-
-
+Shorewall Mirrors
+
Remember that updates to the mirrors are often
delayed for 6-12 hours after an update to the primary rsync site. For
-HTML content, the main web site (http://shorewall.sf.net)
+HTML content, the main web site (http://shorewall.sf.net)
is updated at the same time as the rsync site.
The main Shorewall Web Site is http://shorewall.sf.net
@@ -67,6 +59,9 @@ AKA ftp://www.shore
ftp://france.shorewall.net/pub/mirrors/shorewall
(Paris, France)
+ ftp://ftp.syachile.cl/pub/shorewall
+ (Santiago Chile)
+
ftp://shorewall.greshko.com
(Taipei, Taiwan)
ftp://ftp.shorewall.com.au
@@ -78,7 +73,7 @@ AKA ftp://www.shore
Search results and the mailing list archives are always fetched from
the site in Washington State.
-Last Updated 8/27/2003 - Last Updated 11/14/2003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M.
diff --git a/Shorewall-docs/shorewall_prerequisites.htm b/Shorewall-docs/shorewall_prerequisites.htm
index 09689ee34..171dd4006 100644
--- a/Shorewall-docs/shorewall_prerequisites.htm
+++ b/Shorewall-docs/shorewall_prerequisites.htm
@@ -1,86 +1,57 @@
-
-
-
-
Shorewall Prerequisites
-
-
-
-
-
-
- Shorewall Requirements
- |
-
-
-
-
-
- Shorewall Requires:
-
+
+Shorewall Requirements
+Shorewall Requires:
- - A kernel that supports netfilter. I've tested with 2.4.2 -
-2.4.20. With current releases of Shorewall, Traffic Shaping/Control requires
-at least 2.4.18. Check here for kernel configuration
- information. If you are looking for a firewall for use with
- 2.2 kernels, see the Seattle
-Firewall site .
- - iptables 1.2 or later but beware version 1.2.3 -- see the
- Errata. WARNING:
- The buggy iptables version 1.2.3 is included in RedHat
-7.2 and you should upgrade to iptables 1.2.4 prior to installing Shorewall.
-Version 1.2.4 is available from RedHat
- and in the Shorewall Errata.
- - Iproute ("ip" utility). The iproute package is included
- with most distributions but may not be installed by default. The official
- download site is ftp://ftp.inr.ac.ru/ip-routing.
-
- - A Bourne shell or derivative such as bash or ash. This shell
- must have correct support for variable expansion formats ${variable%pattern
- }, ${variable%%pattern}, ${variable#pattern
- } and ${variable##pattern}.
- - Your shell must produce a sensible result when a number n (128 <=
-n <= 255) is left shifted by 24 bits. You can check this at a shell prompt
-by:
-
+ - A kernel that supports netfilter. I've tested with 2.4.2 -
+2.4.23-rc2. With current releases of Shorewall, Traffic
+Shaping/Control
+requires at least 2.4.18. Check here for
+kernel configuration information. If you are looking for a firewall
+for use with 2.2 kernels, see the
+Seattle
+Firewall site .
+ - iptables 1.2 or later but beware version 1.2.3 -- see the Errata. WARNING: The
+buggy iptables version 1.2.3 is included in RedHat 7.2 and you should
+upgrade to iptables 1.2.4 prior to installing Shorewall. Version 1.2.4
+is available from
+RedHat and in the Shorewall Errata.
+ - Iproute ("ip" utility). The iproute package is included with most
+distributions but may not be installed by default. The official
+download site is ftp://ftp.inr.ac.ru/ip-routing.
+
+ - A Bourne shell or derivative such as bash or ash. This shell must
+have correct support for variable expansion formats ${variable%pattern
+}, ${variable%%pattern}, ${variable#pattern
+} and ${variable##pattern}.
+ - Your shell must produce a sensible result when a number n (128
+<= n <= 255) is left shifted by 24 bits. You can check this at a
+shell prompt by:
- - echo $((128 << 24))
-
- - The result must be either 2147483648 or -2147483648.
-
-
+ - echo $((128 << 24))
+
+ - The result must be either 2147483648 or -2147483648.
+
- - The firewall monitoring display is greatly improved if you
-have awk (gawk) installed.
-
+ - The firewall monitoring display is greatly improved if you have
+awk (gawk) installed.
-
-Last updated 7/8/2003 - Last updated 11/20/2003 - Tom Eastep
-
Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
-
-
-
-
-
+ size="2">Copyright © 2001, 2002, 2003 Thomas M.
+Eastep.
diff --git a/Shorewall-docs/shorewall_quickstart_guide.htm b/Shorewall-docs/shorewall_quickstart_guide.htm
index 34042e47d..9e4dbff5c 100644
--- a/Shorewall-docs/shorewall_quickstart_guide.htm
+++ b/Shorewall-docs/shorewall_quickstart_guide.htm
@@ -10,22 +10,10 @@
-
-
-
-
- Shorewall QuickStart
-Guides (HOWTO's)
-
- |
-
-
-
+Shorewall QuickStart Guides (HOWTOs)
+
With thanks to Richard who reminded me once again
-that we
-must all first walk before we can run.
+that we must all first walk before we can run.
The French Translations of the single-IP guides are courtesy of Patrice
Vetsel
The French Translation of the Shorewall Setup Guide is courtesy of
@@ -51,15 +39,16 @@ acting as a firewall/router for a small local network and a DMZ. (Shorewall
-Setup Guide (See Index Below) is for you.
+Setup
+Guide (See Index Below) is for you.
If you have more than one public
IP address:
The Shorewall Setup
Guide (See Index Below) outlines the steps necessary to set up a
-firewall where there are multiple public IP
-addresses involved or if you
+firewall where there are multiple public IP addresses involved or if
+you
want to learn more about Shorewall than is explained in the
single-address guides above (Version
Française).
@@ -79,13 +68,11 @@ Interfaces (e.g., eth0:0)
Blacklisting
- Static Blacklisting using /etc/shorewall/blacklist
- - Dynamic Blacklisting using
-/sbin/shorewall
+ - Dynamic Blacklisting using /sbin/shorewall
Commands
-(Description of
-all /sbin/shorewall commands)
+(Description of all /sbin/shorewall commands)
Common configuration file
features
- Installation/Upgrade
+ Installation/Upgrade
+ IPSEC
+ Kazaa Filtering
Kernel Configuration
Logging
MAC Verification
- Mailing Lists
+ Mailing Lists
+ Multiple Zones Through One Interface
+
+ Netfilter Overview
My Shorewall Configuration (How I
personally use Shorewall)
+ One-to-one NAT (Formerly
+referred to as Static NAT)
+
+ OpenVPN
Operating Shorewall
'Ping' Management
@@ -178,8 +177,8 @@ personally use Shorewall)
Ports used by Trojans
- Proxy
-ARP
+ PPTP
+ Proxy ARP
Requirements
Samba
@@ -197,8 +196,7 @@ Subnets and Routing
5.3 Rules
@@ -235,14 +234,11 @@ Starting and Stopping the Firewall
href="starting_and_stopping_shorewall.htm">Starting/stopping the
Firewall
- - Description of all /sbin/shorewall
-commands
+ - Description of all /sbin/shorewall commands
- How to safely test a Shorewall configuration change
- Static NAT
- Squid as a Transparent Proxy
-with Shorewall
+ Squid with Shorewall
Traffic Accounting
Traffic Shaping/QOS
@@ -255,14 +251,14 @@ doesn't work)
VPN
If you use one of these guides and have a suggestion for improvement
please let me know.
-Last modified 9/23/2003 - Tom
+Last modified 11/22/2003 - Tom
Eastep
Copyright 2002, 2003 Thomas
M. Eastep
diff --git a/Shorewall-docs/shorewall_setup_guide.htm b/Shorewall-docs/shorewall_setup_guide.htm
index 3df10dd9e..d66583d76 100644
--- a/Shorewall-docs/shorewall_setup_guide.htm
+++ b/Shorewall-docs/shorewall_setup_guide.htm
@@ -10,18 +10,8 @@
-
-
-
-
- Shorewall Setup Guide
- |
-
-
-
-
+Shorewall Setup Guide
+
1.0 Introduction
2.0 Shorewall Concepts
3.0 Network Interfaces
@@ -41,7 +31,7 @@
5.2.1 SNAT
5.2.2 DNAT
5.2.3 Proxy ARP
- 5.2.4 Static NAT
+ 5.2.4 One-to-one NAT
5.3 Rules
5.4 Odds and Ends
@@ -929,7 +919,15 @@ a VPN relationship.
So it's a good idea to check with your ISP to see if
they are using (or are planning to use) private addresses before you
-decide the addresses that you are going to use.
+decide the addresses that you are going to use.
+
+
NOTE: In this
+document, external "real" IP addresses are of the form 192.0.2.x.
+192.0.2.0/24 is reserved by RFC 3330 for use as public IP addresses in
+printed examples. These addresses are not to be confused with addresses
+in 192.168.0.0/16; as described above, these addresses are reserved by
+RFC 1918 for private use.
+
5.0 Setting up your Network
@@ -1077,7 +1075,7 @@ also known as
Port Forwarding.
Network Address Translation (NAT) also
-referred to as Static NAT.
+referred to as One-to-one NAT.
@@ -1230,12 +1228,13 @@ your public IP addresses (A) and is assigned the same netmask (M)
When H issues an ARP "who has" request for
an address in the subnetwork defined by A and M, the
firewall will
-respond (with the MAC if the firewall interface to H).
+respond (with the MAC if the firewall interface) to H.
-
Let suppose that we decide to use Proxy ARP on the DMZ
+
Let us suppose that we decide to use Proxy ARP on the
+DMZ
in our example network.
@@ -1323,7 +1322,7 @@ accordingly."
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP
-(or static NAT for that matter). Happily enough, recent versions
+(or one-to-one NAT for that matter). Happily enough, recent versions
of Redhat's iputils package include "arping", whose "-U" flag does just
that:
@@ -1371,10 +1370,10 @@ words, the gateway's ARP cache still associates 192.0.2.177 with
the NIC in DMZ 1 rather than with the firewall's eth0.
-
5.2.4 Static NAT
+
5.2.4 One-to-one NAT
-
With static NAT, you assign local systems RFC 1918
+
With one-to-one NAT, you assign local systems RFC 1918
addresses then establish a one-to-one mapping between those addresses
and
public IP addresses. For outgoing connections SNAT (Source Network
@@ -1486,7 +1485,7 @@ daughter's web server -- you would rather just use an ACCEPT rule:
A word of warning is in order here. ISPs typically
configure their routers with a long ARP cache timeout. If you move a
system from parallel to your firewall to behind your firewall with
-static NAT, it will probably be HOURS before that system can
+one-to-one NAT, it will probably be HOURS before that system can
communicate
with the internet. There are a couple of things that you can try:
@@ -1506,7 +1505,7 @@ accordingly."
Which is, of course, exactly what you want to do when you switch a host
from being exposed to the Internet to behind Shorewall using proxy ARP
-(or static NAT for that matter). Happily enough, recent versions
+(or one-to-one NAT for that matter). Happily enough, recent versions
of Redhat's iputils package include "arping", whose "-U" flag does just
that:
@@ -2367,7 +2366,7 @@ create an
alternate
configuration and test it using the
"shorewall try" command.
Last updated 7/6/2003 - Last updated 11/18/2003 - Tom Eastep
Copyright 2002,
2003 Thomas M. Eastep
diff --git a/Shorewall-docs/shorewall_setup_guide_fr.htm b/Shorewall-docs/shorewall_setup_guide_fr.htm
new file mode 100755
index 000000000..ec9e15533
--- /dev/null
+++ b/Shorewall-docs/shorewall_setup_guide_fr.htm
@@ -0,0 +1,2515 @@
+
+
+
+
+
+ Shorewall Setup Guide
+
+
+Guide de Configuration de Shorewall
+
+Note du traducteur :
+Je remercie l'équipe Shorewall, pour ce firewall
+formidable et l'aide personnelle que m'a donné Tom
+Eastep.
+J'espère que cette traduction vous aidera à utiliser efficacement ce
+firewall.
+Toutefois, si ce manuel comporte des lacunes, des incohérences ou afin
+d'améliorer sa compréhension,
+n'hésitez pas à me contacter fabien
+demassieux
+1.0 Introduction
+2.0 Concepts de Shorewall
+3.0 Interfaces Réseaux
+4.0 Adresses, Sous/Réseaux et Routage
+
+ 4.1 Adresses IP
+ 4.2 Sous-réseaux
+ 4.3 Routage
+ 4.4 Protocole de Résolution d'Adresses (ARP)
+ 4.5 RFC 1918
+
+5.0 Configurer votre Réseau
+
+ 5.1 Routé
+ 5.2 Non-routé
+
+ 5.2.1 SNAT
+ 5.2.2 DNAT
+ 5.2.3 Proxy ARP
+ 5.2.4 One-to-one NAT
+
+ 5.3 Règles
+ 5.4 D'autres petites choses
+
+
+6.0 DNS
+7.0 Démarrer et Arrêter le firewall
+1.0 Introduction
+Ce guide est destiné aux utilisateurs qui configurent Shorewall dans
+un environnement ou un ensemble d'adresses IP publiques doivent être
+prises en compte ou à ceux qui souhaitent en savoir plus à propos de
+Shorewall que ce que contient le guide pour une utilisation Simple Adresse.
+Parce que le champ d'utilisation est si élevé, le guide vous donnera
+les
+indications générales à suivre et vous renseignera sur d'autres
+ressources si nécessaire.
+ Si vous
+utilisez LEAF
+Bering, votre configuration Shorewall n'est PAS ce que je publie
+-- Je suggère de prendre en considération l'installation de Shorewall
+LPR disponible sur le site de shorewall.net avant de poursuivre.
+Shorewall nécessite que le package iproute/iproute2 soit installé
+(sur RedHat, le package s'appelle iproute). Vous pouvez
+voir si le package est installé grâce au programme ip sur votre
+système firewall. En tant que root, vous pouvez utiliser la commande
+'which' pour vérifier que le programme est présent:
+ [root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
+Je vous recommande de parcourir en premier le guide pour vous
+familiariser avec ce que cela implique puis de le reprendre afin de
+modifier votre configuration. Les Points de configuration à changer
+sont
+précédés du symbole .
+ Si vous
+éditez vos fichiers
+de configuration sous un système d'exploitation Windows, vous devez
+sauvegarder ceux-ci en tant que fichiers formatés Unix si votre éditeur
+le permet ou utiliser la commande dos2unix avant de les utiliser avec
+Shorewall. Idem si vous transférez vos fichiers par l'intermédiaire du
+lecteur de disquette de Windows.
+
+2.0 Concepts de Shorewall
+
+Les fichiers de configuration de Shorewall se trouvent dans le
+répertoire /etc/shorewall -- pour la plus par des paramétrages, vous
+avez juste besoin de quelques-uns d'entre eux comme cela est décrit
+dans
+le manuel. Des squelettes de fichiers sont créés durant La procédure d'installation de
+Shorewall.
+Comme chaque fichier est abordé, je vous suggère de regarder celui
+de votre système -- chaque fichier contient des instructions détaillées
+de configuration et d'autres des entrées par défaut.
+Shorewall voit le réseau ou il opère comme composé d'un ensemble de zones.
+Dans la configuration par défaut, les zones suivantes sont utilisées:
+
+
+
+ | Nom |
+ Description |
+
+
+ | net |
+ L'Internet |
+
+
+ | loc |
+ Votre réseau local
+ |
+
+
+ | dmz |
+ Zone Démilitarisée
+ |
+
+
+
+Les Zones sont définies
+dans
+le fichier
+/etc/shorewall/zones.
+Shorewall reconnaît aussi le système firewall comme sa propre zone -
+par défaut, le firewall lui-même est connu sous le nom fw
+cela peut être modifié dans le fichier /etc/shorewall/shorewall.conf
+. Dans ce guide, le nom par défaut (fw) sera utilisé.
+
+Mise à par fw, Shorewall n'attache aucune importance au nom
+des zones. Les Zones sont entièrement ce que VOUS en faites. Cela veut
+dire que vous ne devez pas vous attendre à ce que Shorewall fasse
+quelque chose de spécial "car il s'agit de la zone Internet" ou "car
+c'est la zone DMZ".
+ Editez
+le fichier
+/etc/shorewall/zones et faites tout changement qui s'impose.
+Les Règles qui concernent le trafic à autoriser ou à refuser sous
+exprimés en terme de Zones.
+
+ Shorewall est construit sur les possibilités du noyau (kernel) Netfilter. Netfilter implémente
+une fonction
+de tracking qui autorise ce qui est souvent désigné comme une
+inspection déclarée de paquets. Les propriétés de déclaration permettent au firewall
+d'être définie en terme de connexions plutôt qu'en terme de
+paquet. Avec Shorewall, vous:
+
+ - Identifiez la zone source.
+ - Identifiez la zone destination.
+ - Si la POLICE de la zone client vers la zone destination est ce
+que
+vous souhaitez pour cette paire client/serveur, vous n'avez besoin de
+rien de plus.
+ - Si la POLICE n'est pas ce que vous souhaitez, alors vous devez
+ajouter une règle. Cette règle est exprimé en terme de zone client et
+de zone serveur.
+
+Si les connexions d'un certain type sont autorisés de la zone A au
+firewall et sont aussi autorisés du firewall à la zone B cela NE VEUT PAS dire que ces connections sont
+autorisés de la zone A à la zone B. Cela veut plutôt
+dire que vous avez un proxy qui tourne sur le firewall qui accepte les
+connections de la zone A et qui ensuite établit ces propres connections
+du firewall à la zone B.
+Pour chaque requête de connexion sur le firewall, la requête est
+d'abord évalué à travers le fichier /etc/shorewall/rules file. Si
+aucune
+règle dans ce fichier ne correspond, la connexion interroge ensuite la
+première police dans /etc/shorewall/policy qui correspond à la
+requête et l'applique. Si cette police est REJECT ou DROP, la
+requête est a nouveau évaluée à travers les règles du fichier
+/etc/shorewall/common.def.
+Le fichier de défaut /etc/shorewall/policy a les polices suivantes:
+
+
+
+
+ Zone Source
+ |
+ Zone Destination
+ |
+ Police |
+ Niveau de Log |
+ Limit:Burst |
+
+
+ | loc |
+ net |
+ ACCEPT |
+ |
+ |
+
+
+ | net |
+ all |
+ DROP |
+ info |
+ |
+
+
+ | all |
+ all |
+ REJECT |
+ info |
+ |
+
+
+
+
+La police précédente:
+
+ - Permet toutes les connexions de votre réseau local vers Internet,
+ - Drop (ignore) toutes les connexions d'Internet vers le firewall
+ou votre réseau local et génère un message au niveau info (ici se trouve la
+description des niveaux de log).
+ - Rejette toutes les autres connexions et génère un message au
+niveau info. Quant la requête est rejeté, le firewall retourne
+un RST (si le protocole est TCP) ou un ICMP port-unreachable paquet
+pour
+les autres protocoles.
+
+
+Maintenant, éditez votre
+/etc/shorewall/policy et apportez tous les changements que vous
+souhaitez.
+3.0 Interfaces Réseau
+Pour le reste de ce guide, nous utiliserons le schéma
+ci-dessous. Bien qu'il ne puisse correspondre à votre propre réseau, il
+peut être utilisé pour illustrer les aspects importants de la
+configuration de Shorewall.
+Sur ce schéma:
+
+ - La zone DMZ est composée des systèmes DMZ 1 et DMZ 2. Une DMZ est
+utilisée pour isoler vos serveurs accessibles depuis Internet de vos
+systèmes locaux. Ainsi si un de ces serveurs est compromis, vous avez
+encore votre firewall entre le système compromis et vos systèmes locaux.
+ - La zone Local est composée des systèmes Local 1, Local 2 et Local
+3.
+ - Tous les systèmes du FAI vers l'extérieur et qui
+
+ - englobe la Zone Internet.
+
+ 
+La façon la plus simple pour définir les zones est
+d'associer le nom de la zone (définie précédemment dans
+/etc/shorewall/zones) avec une interface réseau.
+C'est fait dans le fichier /etc/shorewall/interfaces.
+Le firewall illustré ci-dessus à trois interfaces. Si
+la connexion se fait à travers un câble ou un "modem" DSL , l'Interface
+Externe sera l'adaptateur qui est branché au "Modem" (e.g., eth0) tant
+que vous ne vous n'utilisez pas le Point-to-Point Protocol
+over Ethernet (PPPoE) ou le Point-to-PointTunnelingProtocol(PPTP)
+dans ce cas l'Interface Externe sera de type ppp (e.g., ppp0).
+Si vous vous connectez à travers un modem classique, votre Interface
+Externe sera également ppp0. Si vous utilisez ISDN, votre
+Interface Externe sera ippp0.
+
+ Si votre Interface Externe est ppp0 ou
+ippp0
+alors vous pouvez fixer CLAMPMSS=yes dans
+/etc/shorewall/shorewall.conf.
+Votre Interface Locale doit être un adaptateur
+Ethernet (eth0, eth1 or eth2) et doit être connecté à un hub ou
+un
+switch. Vos ordinateurs locaux doivent être connectés au même
+switch (note: Si vous avez une machine unique, vous pouvez connecter le
+firewall directement à l'ordinateur en utilisant un câble croisé).
+Votre Interface DMZ doit aussi
+être un adaptateur Ethernet (eth0, eth1 or eth2) et doit être connecté
+à un hub ou un switch. Vos ordinateurs DMZ doivent être
+connectés au même switch (note: Si vous avez une machine DMZ unique,
+vous pouvez connecter le firewall directement à l'ordinateur en
+utilisant un câble croisé).
+ Ne
+pas connecter plus d'une interface au même hub ou switch (sauf pour
+tester). Cela ne fonctionne pas comme vous pourriez vous y attendre et
+vous terminerez confus en croyant que le réseau ne fonctionne pas
+entièrement.
+
+Pour le besoin de ce Guide, nous décidons que:
+
+ -
+
L'interface externe est eth0.
+
+ -
+
L'interface locale est eth1.
+
+ -
+
L'interface DMZ est eth2.
+
+
+La configuration par défaut de Shorewall ne définit pas
+le contenu de chaque zone. Pour définir la précédente configuration en
+utilisant le fichier
+/etc/shorewall/interfaces file, ce fichier doit contenir:
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ detect |
+ norfc1918 |
+
+
+ | loc |
+ eth1 |
+ detect |
+ |
+
+
+ | dmz |
+ eth2 |
+ detect |
+ |
+
+
+
+
+
+ Editer le fichier /etc/shorewall/interfaces et
+définissez les interfaces du réseau sur votre firewall et associez
+chaque interface avec une zone. Si vous avez une zone qui est
+interfacée
+avec plus d'une interface, incluez simplement une entrée pour chaque
+interface et répéter le nom de zone autant de fois que nécessaire.
+Exemple:
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ detect |
+ norfc1918 |
+
+
+ | loc |
+ eth1 |
+ detect |
+ |
+
+
+ | loc |
+ eth2 |
+ detect |
+ dhcp |
+
+
+
+
+
+
Si vous avez plus d'une interface pour une zone, vous
+voudrez probablement une police qui permet le trafic intra-zone:
+
+
+
+
+
+ | Source Zone |
+ Destination Zone |
+ Policy |
+ Log Level |
+ Limit:Burst |
+
+
+ | loc |
+ loc |
+ ACCEPT |
+ |
+ |
+
+
+
+
+
+ Vous pouvez définir des zones plus compliquées en
+utilisant le fichier /etc/shorewall/hosts
+mais dans la plus part des cas, ce n'est pas nécessaire.
+4.0 Adressage, Sous-réseaux
+et Routage
+Normalement, votre FAI vous assigne des adresses
+Publiques. Vous pouvez configurer l'interface externe du firewall
+en utilisant l'une de ces adresses permanentes et vous pouvez décider
+comment utiliser le reste de vos adresses.
+Si vous êtes déjà familier avec l'adressage IP et le
+routage, vous pouvez aller à la prochaine section.
+La discussion suivante aborde tout juste les concepts
+d'adressage et de routage. Si vous souhaitez approfondir vos
+connaissances sur ce sujet, je vous recommande vivement l'ouvrage
+"IP
+Fundamentals: What Everyone Needs to Know about Addressing &
+Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
+4.1 Adressage IP
+
+L'adressage IP version 4 (IPv4) est codé sur
+32-bit. La notation w.x.y.z se réfère à une adresse dont le byte
+d'ordre
+supérieur est "w", le suivant à pour valeur "x", etc. Si nous prenons
+l'adresse 192.0.2.14 et l'exprimons en hexadécimal, nous obtenons:
+
+ C0.00.02.0E
+
+ou l'exprimons comme un entier de 32-bit
+
+ C000020E
+
+4.2 Sous -réseaux
+
+Vous entendrez toujours les termes "réseaux de Class
+A", "réseaux de Class B" et "réseaux de Class C". Au début de
+l'existence de l'IP, les réseaux ne comportez que trois tailles (il y
+avait aussi le réseau de Class D mais il étaient utilisés différemment):
+
+ Classe A - masque réseau 255.0.0.0, taille = 2 ** 24
+ Classe B - masque réseau 255.255.0.0, taille = 2 ** 16
+ Classe C - masque réseau 255.255.255.0, taille = 256
+
+La taille d'un réseau était uniquement déterminé par la
+valeur du byte de l'ordre supérieur, ainsi vous pouviez regarder une
+adresse IP et déterminer immédiatement le masque réseau. Le masque réseau est
+un nombre qui se termine logiquement avec une adresse qui isole le numéro de réseau; le reste de
+l'adresse est le numéro d'hôte. Par exemple, dans la Classe C
+l'adresse 192.0.2.14, le numéro hexadécimal du réseau est C00002 et le
+numéro hexadécimal d'hôte est 0E.
+Comme l'Internet se développait, il semblait clair que
+la classification en adressage 32-bit allait devenir très limité
+(rapidement, les grandes sociétés et les universités s'étaient assigné
+leur propre réseau de classe A!). Après quelques faux départs, la
+technique courante du sous-adressage
+de
+ces réseaux en plus petits sous-réseaux
+évolua; cette technique est consignée par le Classless Inter Domain
+Routing (CIDR). Aujourd'hui, tous les systèmes avec lesquels vous
+travaillerez comprennent probablement la notation CIDR. Le réseau
+basé sur les Classes est du domaine du passé .
+Un sous-réseau (aussi appelé subnetwork et subnet)
+est un ensemble d'adresses IP tel que:
+
+ -
+
Le nombre d'adresses dans le jeu est un multiple de
+2; et
+
+ -
+
La première adresse dans le jeu est un multiple de
+la taille du jeu.
+
+ -
+
La première adresse du sous-réseau est réservée et
+se réfère à l'adresse du sous-réseau.
+
+ -
+
La dernière adresse du sous-réseau est réservée
+comme adresse broadcast du sous-réseau.
+
+
+Comme vous pouvez voir dans cette définition, dans
+chacun des sous-réseau de taille n il y a (n - 2)
+adresses
+utilisables (adresses qui peuvent être assignées aux hôtes). La
+première
+et la dernière adresse du sous-réseau sont respectivement utilisées
+pour
+l'adresse du sous-réseau et de l'adresse broadcast du sous-réseau. En
+conséquence, les petits réseaux sont plus gaspilleur d'adresses IP que
+les grands.
+Comme n est un multiple de deux, nous pouvons
+facilement calculer le Logarithme
+Naturel (log2) de n. Pour les sous-réseaux
+les plus communs, la taille et son logarithme naturel sont donnés dans
+la table suivante:
+
+
+
+
+ | n |
+ log2 n |
+ (32 - log2 n) |
+
+
+ | 8 |
+ 3 |
+ 29 |
+
+
+ | 16 |
+ 4 |
+ 28 |
+
+
+ | 32 |
+ 5 |
+ 27 |
+
+
+ | 64 |
+ 6 |
+ 26 |
+
+
+ | 128 |
+ 7 |
+ 25 |
+
+
+ | 256 |
+ 8 |
+ 24 |
+
+
+ | 512 |
+ 9 |
+ 23 |
+
+
+ | 1024 |
+ 10 |
+ 22 |
+
+
+ | 2048 |
+ 11 |
+ 21 |
+
+
+ | 4096 |
+ 12 |
+ 20 |
+
+
+ | 8192 |
+ 13 |
+ 19 |
+
+
+ | 16384 |
+ 14 |
+ 18 |
+
+
+ | 32768 |
+ 15 |
+ 17 |
+
+
+ | 65536 |
+ 16 |
+ 16 |
+
+
+
+
+Vous pourrez voir que la table ci-dessus contient aussi
+une colonne (32 - log2 n). Ce nombre est la Variable de Longueur du Masque de
+Sous-réseau (VLSM Variable Length Subnet Mask) pour
+un réseau de taille n. De la
+table ci-dessus, nous pouvons dériver celle-ci, ce qui est plus facile
+à
+utiliser.
+
+
+
+
+ Taille du sous-réseau
+ |
+ VLSM |
+ Masque sous-réseau
+ |
+
+
+ | 8 |
+ /29 |
+ 255.255.255.248 |
+
+
+ | 16 |
+ /28 |
+ 255.255.255.240 |
+
+
+ | 32 |
+ /27 |
+ 255.255.255.224 |
+
+
+ | 64 |
+ /26 |
+ 255.255.255.192 |
+
+
+ | 128 |
+ /25 |
+ 255.255.255.128 |
+
+
+ | 256 |
+ /24 |
+ 255.255.255.0 |
+
+
+ | 512 |
+ /23 |
+ 255.255.254.0 |
+
+
+ | 1024 |
+ /22 |
+ 255.255.252.0 |
+
+
+ | 2048 |
+ /21 |
+ 255.255.248.0 |
+
+
+ | 4096 |
+ /20 |
+ 255.255.240.0 |
+
+
+ | 8192 |
+ /19 |
+ 255.255.224.0 |
+
+
+ | 16384 |
+ /18 |
+ 255.255.192.0 |
+
+
+ | 32768 |
+ /17 |
+ 255.255.128.0 |
+
+
+ | 65536 |
+ /16 |
+ 255.255.0.0 |
+
+
+ | 2 ** 24 |
+ /8 |
+ 255.0.0.0 |
+
+
+
+
+Notez que le VLSM est écrit avec un slash ("/") -- vous
+pouvez souvent entendre un sous-réseau de taille 64 qui fait référence
+à
+un sous-réseau "slash 26" et un de taille 8 faisant référence à un
+"slash 29".
+Le masque de sous-réseau (aussi référencé par son netmask) est
+simplement un nombre de 32-bit avec le premier bit "VLSM" à un et
+les autres à zéro. Par exemple, pour un sous-réseau de taille 64, le
+masque de sous-réseau débute par 26 bits à un:
+
+ 11111111111111111111111111000000 = FFFFFFC0 =
+FF.FF.FF.C0 = 255.255.255.192
+
+Le masque de sous-réseau a la propriété suivante: si
+vous terminez logiquement le masque de sous-réseau avec une adresse
+dans
+le sous-réseau, le résultat est l'adresse du sous-réseau. Attention, si
+vous terminez logiquement le masque de sous-réseau avec une adresse en
+dehors du sous-réseau, le résultat n'est PAS l'adresse du sous-réseau.
+Comme nous l'avons vu précédemment, la propriété du masque de
+sous-réseau est très importante dans le routage.
+Pour un sous-réseau dont l'adresse est a.b.c.d
+et dont la VLSM est /v, nous notons le sous-réseau par "a.b.c.d/v"
+en utilisant la Notation CIDR.
+Exemple:
+
+
+
+
+ | Sous-réseau: |
+ 10.10.10.0 - 10.10.10.127 |
+
+
+ | Taille Sous-réseau: |
+ 128 |
+
+
+ | Adresse Sous-réseau: |
+ 10.10.10. |
+
+
+ | Adresse Broadcast: |
+ 10.10.10.127 |
+
+
+ Notation CIDR:
+ |
+ 10.10.10.0/25 |
+
+
+
+
+Il y a deux sous-réseaux dérivés qui doivent être
+mentionnés; A savoir, le sous-réseau avec un membre et le sous-réseau
+avec 2 ** 32 membres.
+
+
+
+
+ Taille du Sous-réseau
+ |
+ Longueur VLSM
+ |
+ Masque Sous-réseau |
+ Notation CIDR |
+
+
+ | 1 |
+ 32 |
+ 255.255.255.255 |
+ a.b.c.d/32 |
+
+
+ | 2 ** 32 |
+ 0 |
+ 0.0.0.0 |
+ 0.0.0.0/0 |
+
+
+
+
+Ainsi, chaque adresse a.b.c.d peut aussi être
+écrite a.b.c.d/32 et l'ensemble des adresses possibles est
+écrit 0.0.0.0/0.
+Plus loin dans ce manuel, vous verrez la notation a.b.c.d/v
+utilisé pour décrire la configuration IP d'une interface réseau
+(l'utilitaire 'ip' utilise aussi cette syntaxe). cela veut simplement
+dire que l'interface est configuré avec une adresse ip a.b.c.d
+et
+avec le masque de réseau qui correspond à la variable VLSM /v.
+Exemple: 192.0.2.65/29
+ L'interface est configuré avec
+l'adresse IP 192.0.2.65 et le masque de réseau 255.255.255.248.
+
+A partir de Shorewall version 1.4.6, /sbin/shorewall
+supporte la commande ipcalc qui calcule automatiquement
+l'information du [sous]-réseau.
+
+Exemple 1:
+
+
+ ipcalc 10.10.10.0/25
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
+
+Exemple 2
+
+ ipcalc 10.10.10.0 255.255.255.128
CIDR=10.10.10.0/25
NETMASK=255.255.255.128
NETWORK=10.10.10.0
BROADCAST=10.10.10.127
+
+4.3 Routage
+L'un des buts des sous-réseaux est la base du routage.
+Ci-dessous se trouve la table de routage de mon firewall:
+
+
+ [root@gateway root]# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.9.1 0.0.0.0 255.255.255.255 UH 40 0 0 texas
206.124.146.177 0.0.0.0 255.255.255.255 UH 40 0 0 eth1
206.124.146.180 0.0.0.0 255.255.255.255 UH 40 0 0 eth3
192.168.3.0 0.0.0.0 255.255.255.0 U 40 0 0 eth3
192.168.2.0 0.0.0.0 255.255.255.0 U 40 0 0 eth1
192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
206.124.146.0 0.0.0.0 255.255.255.0 U 40 0 0 eth0
192.168.9.0 192.0.2.223 255.255.255.0 UG 40 0 0 texas
127.0.0.0 0.0.0.0 255.0.0.0 U 40 0 0 lo
0.0.0.0 206.124.146.254 0.0.0.0 UG 40 0 0 eth0
[root@gateway root]#
+
+
Le périphérique texas est le tunnel GRE vers un
+site peer à Dallas, la zone Texas.
+
+Les trois premières routes sont des routes
+hôte puisqu'elles indiquent comment aller vers un hôte unique.
+Dans la sortie de 'netstat' cela peut-être vu par le "Genmask" (Masque
+sous-réseau) de 255.255.255.255 et le "H" dans la colonne
+"Flags".
+Les autres sont des routes 'net' car elles indiquent au noyau comment
+router des paquets à un sous-réseau. La dernière route est la route par défaut est la passerelle
+(gateway) mentionnée est appelé passerelle par défaut (default
+gateway).
+Quant le noyau essaye d'envoyer un paquet à une adresse
+IP A, il commence au début de la table de routage et :
+
+ -
+
A est logiquement terminé avec la valeur du
+'Genmask' dans l'entrée de la table.
+
+ -
+
Le résultat est comparé avec la valeur de la
+destination 'Destination' dans l'entrée de la table.
+
+ -
+
Si le résultat et la valeur de la
+'Destination' sont identiques, alors:
+
+ -
+
Si la colonne 'Gateway' est n'est pas nulle, le
+paquet est envoyé au gateway à travers l'interface nommée dans la
+colonne 'Iface'.
+
+ -
+
Sinon, le paquet est directement envoyé à A à
+travers l'interface nommée dans la colonne 'iface'.
+
+
+
+ -
+
Autrement, les étapes précédentes sont répétées sur
+l'entrée suivante de la table.
+
+
+Puisque la route par défaut correspond à toutes les
+adresses IP (A donne 0.0.0.0 = 0.0.0.0), les paquets qui ne
+correspondent à aucune des autres entrées de la table de routage sont
+envoyés au gateway par défaut
+qui généralement est un routeur vers le FAI.
+Voici un exemple. Supposez que vous souhaitez router un
+paquet à 192.168.1.5. Cette adresse ne correspond à aucune route d'hôte
+dans la table mais si nous terminons logiquement cette adresse avec
+255.255.255.0, le résultat est 192.168.1.0 qui correspond à la l'entrée
+dans la table:
+
+
+ 192.168.1.0 0.0.0.0 255.255.255.0 U 40 0 0 eth2
+
+
Donc le paquet vers 192.168.1.5 est directement envoyé à travers
+eth2.
+
Un des points qui doit être souligné -- tous les
+paquets sont envoyés en utilisant la table de routage et les réponses
+ne
+sont pas exclues de ce principe. Il semble y avoir une croyance
+de la part des ceux qui croient que les paquets réponses sont comme les
+saumons et contiennent un code génétique qui leur permet de suivre la
+route emprunté par les paquets envoyés. Ce n'est pas le cas; La réponse
+peut prendre un chemin totalement différent de celui de la requête du
+client -- les routes requête/réponse sont totalement indépendantes.
+4.4 Protocole de Résolution
+d'Adresse (ARP)
+Quant on envoie des paquets à travers Ethernet, les
+adresses IP ne sont pas utilisées. Bien que l'adressage Ethernet soit
+basé sur les adresses Media Access Control (MAC). Chaque
+périphérique Ethernet à sa propre adresse MAC qui est contenu
+dans
+une PROM lors de la fabrication. Vous pouvez obtenir l'adresse MAC
+grâce
+à l'utilitaire 'ip':
+
+
+
[root@gateway root]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0
inet 206.124.146.179/24 brd 206.124.146.255 scope global secondary eth0
[root@gateway root]#
+
+
+
Comme vous pouvez le constater ci-dessus, l'adresse MAC
+codé sur 6 bytes (48 bits). Une carte MAC est généralement aussi
+imprimé sur la carte elle-même.
+
+
Parce que IP utilise les adresses IP et Ethernet les
+adresses MAC, un mécanisme est nécessaire pour transcrire une adresse
+IP
+en adresse MAC; C'est ce dont est chargé le protocole de résolution
+d'adresse Address Resolution Protocol (ARP). Voici ARP en
+action:
+
+
+
+
[root@gateway root]# tcpdump -nei eth2 arp
tcpdump: listening on eth2
09:56:49.766757 2:0:8:e3:4c:48 0:6:25:aa:8a:f0 arp 42: arp who-has 192.168.1.19 tell 192.168.1.254
09:56:49.769372 0:6:25:aa:8a:f0 2:0:8:e3:4c:48 arp 60: arp reply 192.168.1.19 is-at 0:6:25:aa:8a:f0
2 paquets received by filter
0 paquets dropped by kernel
[root@gateway root]#
+
+
Dans cet échange , 192.168.1.254 (MAC 2:0:8:e3:4c:48)
+veut connaître l'adresse MAC du périphérique avec l'adresse IP
+192.168.1.19. Le système ayant cette adresse IP répond que l'adresse
+MAC
+du périphérique avec l'adresse IP 192.168.1.19 est 0:6:25:aa:8a:f0.
+Afin de rendre disponible les informations d'échange
+ARP chaque fois qu'un paquet est envoyé, le système maintient un cache ARP des
+correspondances IP<->MAC. Vous pouvez voir le cache ARP sur votre
+système (également sur les systèmes Windows) en utilisant la commande
+'arp':
+
+
+
[root@gateway root]# arp -na
? (206.124.146.177) at 00:A0:C9:15:39:78 [ether] on eth1
? (192.168.1.3) at 00:A0:CC:63:66:89 [ether] on eth2
? (192.168.1.5) at 00:A0:CC:DB:31:C4 [ether] on eth2
? (206.124.146.254) at 00:03:6C:8A:18:38 [ether] on eth0
? (192.168.1.19) at 00:06:25:AA:8A:F0 [ether] on eth2
+
+Les détails de réponse sont le résultat de
+l'utilisation de l'option 'n' (Windows 'arp' n'accepte pas cette
+option)
+qui force le programme 'arp' à la translation de résolution de noms
+IP->DNS. Si je n'utilise pas cette option, la marque de question
+aurait été remplacé par le FQDN correspondant à chaque adresse IP.
+Notez
+que la dernière information dans la table d'enregistrement est celle
+que
+nous voyons en utilisant précédemment tcpdump.
+4.5 RFC 1918
+Les adresses IP sont alloués par l'autorité Internet Assigned Number Authority (IANA)
+qui délégue des allocations géographiques basés sur le Regional
+Internet Registries (RIRs). Par exemple, les allocations pour les
+Etats-Unis sont déléguées à American
+Registry for Internet Numbers (ARIN). Ces RIRs peuvent
+déléguer à des bureaux nationaux. La plus part d'entre nous ne traite
+pas avec autorités mais obtienne plutôt leur adresse IP par leur FAI.
+Dans la réalité, généralement on ne peut se permettre
+autant d'adresses IP Publiques que de périphériques à assigner si bien
+que nous utiliseront des adresses IP Privées.
+RFC 1918 réserve plusieurs plages d'adresse IP à cet usage:
+
+
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
+
+
Les adresses réservées par la RFC 1918 sont parfois
+appelées non-routable car le routeur passerelle Internet ne
+renvoit pas les paquets qui ont une adresse de destination RFC-1918.
+cela est compréhensible car tout le monde peut choisir ces adresses
+pour
+un usage privé.
+
+
Quant on choisit des adresses de ces plages, il y a
+deux choses à garder en mémoire:
+
+
+ -
+
Comme l'espace des adresses IPv4 s'épuise, de plus
+en plus d'organisation (comprenant les FAI) commencent à utiliser les
+adresses RFC 1918 dans leur infrastructures.
+
+ -
+
Vous ne voulez pas utiliser des adresses IP qui
+sont utilisés par votre FAI ou une autre organisation avec laquelle
+vous
+souhaiter établir une liaison VPN.
+
+
+
+
C'est pourquoi c'est une bonne idée de vérifier avec
+votre FAI s'il n'utilise pas (ou ne prévoie pas d'utiliser) des
+adresses
+privées avant de décider les adresses que vous allez utiliser.
+
+
5.0 Configurer votre Réseau
+
+
+
Le choix de configuration de votre réseau dépend
+d'abord du nombre d'adresses Public IP dont vous avez besoin, c'est à
+dire du nombre d'entités adressables que vous avez sur votre réseau. En
+fonction du nombre d'adresses que vous avez, votre FAI peut servir ce
+jeu d'adresses de deux manières:
+
+
+
+ -
+
Routé - Le trafic vers chacune de vos
+adresses sera routé à travers une unique adresse passerelle.
+Cela sera généralement fait si votre FAI vous assigne un sous-réseau
+complet (/29 ou plus). Dans ce cas, vous assignerez l'adresse
+passerelle comme adresse IP de l'interface externe de votre
+firewall/router.
+
+ -
+
Non-routé - Votre FAI vous enverra
+directement le trafic de chaque adresse directement.
+
+
+
+
Dans les paragraphes qui suivent, nous étudierons
+chaque cas séparément.
+
+
Avant de commencer, il y a une chose que vous devez
+vérifier:
+
Si vous
+utilisez le package Debian, vérifier
+svp votre fichier shorewall.conf afin de contrôler les paramètres
+suivants; si ce n'est pas juste, appliquer les changements
+nécessaires:
+
+
+ - NAT_ENABLED=Yes (Shorewall versions antérieures à 1.4.6)
+ - IP_FORWARDING=On
+
+
+
+
Supposons que votre fournisseur d'accès FAI vous a
+assigné le sous-réseau 192.0.2.64/28 routé à travers 192.0.2.65. cela
+veut dire que vous avez les adresses IP 192.0.2.64 - 192.0.2.79
+et que l'adresse externe de votre firewall est 192.0.2.65. Votre FAI
+vous a aussi dit que vous pouvez utiliser le masque de réseau
+255.255.255.0 (ainsi votre /28 est une partie de /24). Avec ces
+adresses
+IP, vous pouvez scinder votre réseau /28 en deux /29 et configurer
+votre
+réseau comme l'indique le diagramme suivant.
+
+
+
+
Ici, la zone démilitarisé DMZ comprend le sous-réseau
+192.0.2.64/29 et le réseau Local 192.0.2.72/29. La passerelle par
+défaut
+pour les hôtes dans la DMZ pourra être configuré à 192.0.2.66 et la
+passerelle par défaut pour les hôtes du réseau local pourra être
+192.0.2.73.
+
+
Notez que cet arrangement est plus gourmand en adresses
+publiques puisqu'il utilise 192.0.2.64 et 192.0.2.72 pour les adresses
+du sous-réseau, 192.0.2.71 et 192.0.2.79 pour les adresses
+broadcast du réseau, de même que 192.0.2.66 et 168.0.2.73 pour les
+adresses internes que le firewall/routeur. Néanmoins, cela montre
+comment nous pouvons faire avec un réseau /24 plutôt qu'un /28,
+l'utilisation de 6 adresses IP parmi les 256 peut être justifié par la
+simplicité du paramétrage.
+
+
Le lecteur astucieux aura remarqué que l'interface
+externe du firewall/Routeur est actuellement inclus dans le sous-réseau
+DMZ (192.0.2.64/29). Que se passe-t-il si DMZ 1 (192.0.2.67) essaye de
+communiquer avec 192.0.2.65? La table de routage sur DMZ 1 peut
+ressembler à cela:
+
+
+ Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.0.2.64 0.0.0.0 255.255.255.248 U 40 0 0 eth0
0.0.0.0 192.0.2.66 0.0.0.0 UG 40 0 0 eth0
+
+
+
Cela indique que DMZ 1 enverra une requête ARP "qui-a
+192.0.2.65" et aucune interface sur le segment Ethernet DMZ à
+cette adresse IP. Assez bizarrement, le firewall répondra à la
+requête avec l'adresse MAC de sa propre Interface DMZ!! DMZ 1
+peut alors envoyer des trames Ethernet frames adressées à cette
+adresse MAC et les trames seront reçues (correctement) par le
+firewall/routeur.
+
+
C'est plutôt une possibilité inattendue d'ARP sur la
+partie du Noyau Linux qui pousse cet avertissement très tôt dans ce
+manuel à propos de la connexion de plusieurs interfaces
+firewall/routeur
+au même hub ou switch. Quant une requête ARP destiné à une des
+adresses firewall/routeur est envoyé par un autre système connecté au
+hub/switch, toutes les interfaces du firewall qui se connectent au
+hub/switch peuvent répondre! C'est alors une course à la réponse qui
+"est-là" qui atteindra en premier l'émetteur.
+
+
Avec la situation précédente mais non-routé, vous
+pouvez configurer votre réseau exactement comme décrit ci-dessus avec
+une condition supplémentaire; spécifiez simplement l'option "proxyarp"
+sur les trois interfaces du firewall dans le fichier
+/etc/shorewall/interfaces.
+
+
La plus part d'entre nous n'a pas le luxe d'avoir assez
+d'adresses publiques IP pour configurer notre réseau comme montré dans
+le précédent exemple (même si la configuration est routé).
+
+
Pour le besoin de cette section, admettons que notre
+FAI nous a assigné les adresses IP 192.0.2.176-180 et nous a dit
+d'utiliser le masque de réseau 255.255.255.0 et la passerelle par
+défaut
+192.0.2.254.
+
+
Clairement, ce jeu d'adresses ne comprend pas de
+sous-réseau et n'a pas suffisamment d'adresses pour toutes les
+interfaces de notre réseau. Il y a quatre possibilités qui peuvent être
+utilisées pour règler ce problème.
+
+
+ -
+
Translation d'Adresses Réseau Source : Source
+Network Address Translation (SNAT).
+
+ -
+
Translation d'Adresses Réseau Destination :
+Destination Network Address Translation (DNAT) aussi nommé Port
+Forwarding.
+
+ -
+
Proxy ARP.
+
+ -
+
Translation d''Adresses Réseau : Network
+Address Translation (NAT) aussi appelé One-to-one NAT.
+
+
+
+
Souvent une combinaison de ces techniques est utilisée.
+Chacune d'entre elle sera détaillée dans la section suivante.
+
+
Avec SNAT, un segment interne LAN est configuré en
+utilisant les adresses RFC 1918. Quant un hôte A sur ce segment interne
+initialise une connexion à l'hôte B sur Internet, le
+firewall/routeur réécrit les entêtes IP dans la requête pour utiliser
+une de vos adresses publiques IP en tant qu'adresse source. Quant B
+répond et que la réponse est reçu par le firewall, le firewall change
+l'adresse destination par celle RFC 1918 de A et renvoi la
+réponse à A.
+
+
Supposons que vous décidiez d'utiliser SNAT sur votre
+zone locale et utilisiez l'adresse publique 192.0.2.176 à la fois comme
+adresse externe du firewall et l'adresse source des requêtes Internet
+envoyées depuis cette zone.
+
+
+
La zone locale a été assigné au sous-réseau
+192.168.201.0/29 (netmask 255.255.255.248).
+
+
+ Le système dans la zone locale pourra être configuré
+avec la passerelle par défaut 192.168.201.1 (L'adresse IP de
+l'interface local du firewall).
+
+
+
+
+
+
+
+ | INTERFACE |
+ SOUS-RESEAU |
+ ADDRESSE |
+
+
+ | eth0 |
+ 192.168.201.0/29 |
+ 192.0.2.176 |
+
+
+
+
+
+
Cet exemple utilise la technique normale pour assigner
+la même adresse publique IP pour l'interface externe du firewall et
+pour
+SNAT. Si vous souhaitez utiliser une adresse IP différente, vous pouvez
+soit utiliser les outils de configuration réseau de votre distribution
+pour ajouter cette adresse IP ou vous pouvez mettre la variable
+ADD_SNAT_ALIASES=Yes dans /etc/shorewall/shorewall.conf si bien que
+Shorewall ajoutera l'adresse pour vous.
+
+
Quant SNAT est utilisé, il est impossible pour les
+hôtes sur Internet d'initialiser une connexion avec un des systèmes
+puisque ces systèmes n'ont pas d'adresses publiques IP. DNAT fournit
+une
+méthode pour autoriser des connexions sélectionnés depuis Internet.
+
+
+Supposons que votre fille souhaite héberger un
+server web sur son système "Local 3". Vous pouvez autoriser les
+connexions d'Internet à son serveur en ajoutant l'entrée suivante dans
+le fichier /etc/shorewall/rules:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL DESTINATION |
+
+
+ | DNAT |
+ net |
+ loc:192.168.201.4 |
+ tcp |
+ www |
+ - |
+ 192.0.2.176 |
+
+
+
+
+
+
Si une des amies de votre fille avec une adresse A veut
+accéder au serveur de votre fille, elle peut se connecter à l'adresse
+http://192.0.2.176 (l'adresse IP externe
+de votre firewall) et le firewall réécrira l'adresse IP à 192.168.201.4
+(le système de votre fille) et enverra la requête. Quant le serveur de
+votre fille répond, le firewall réécrira la source de réponse avec
+192.0.2.176 et retournera la réponse à A.
+
+
Cet exemple l'adresse externe IP du firewall pour DNAT.
+Vous pouvez utiliser une autre de vos adresses IP publiques, mais
+Shorewall n'ajoutera pas pour vous cette adresse à l'interface externe
+du firewall.
+
+
Le principe du proxy ARP est:
+
+
+ -
+
Un hôte H derrière votre firewall est
+assigné à une de vos adresses publiques (A), a le même masque de
+réseau (M) que l'interface externe du firewall.
+
+ -
+
Le firewall répond à ARP "qui a" demandé A.
+
+
+ -
+
Quant H délivre une requête ARP "qui a"
+pour
+une adresse du sous -réseau définit par A et M,
+le
+firewall répondra (avec l'adresse MAC si le firewall s'interface à H).
+
+
+
+
Supposons que nous décidons d'utiliser Proxy ARP sur
+DMZ de notre exemple réseau.
+
+
+
Ici, nous avons assigné les adresses IP 192.0.2.177
+au système DMZ 1 et 192.0.2.178 à DMZ 2. Notez que nous avons juste
+assigné une adresse arbitraire RFC 1918 et un masque de sous-réseau à
+l'interface DMZ de notre firewall. Cette adresse et le masque ne sont
+pas pertinentes - vérifiez juste que celle-ci n'écrase pas un autre
+sous-réseau déjà définit.
+
+
+
+
+
+
+
+ | ADDRESS |
+ INTERFACE |
+ EXTERNAL |
+ HAVE ROUTE |
+
+
+ | 192.0.2.177 |
+ eth2 |
+ eth0 |
+ No |
+
+
+ | 192.0.2.178 |
+ eth2 |
+ eth0 |
+ No |
+
+
+
+
+
+
Parce que la variable HAVE ROUTE contient No,
+Shorewall ajoutera les routes d'hôte à travers eth2 à 192.0.2.177 et
+192.0.2.178.
+
+
Les interfaces ethernet de DMZ 1 et DMZ 2 pourront être
+configurées pour avoir les adresses IP apparentes mais devront avoir la
+même passerelle par défaut que le firewall lui-même -- nommé
+192.0.2.254. En d'autres termes, elles pourront être configurées juste
+comme elles devraient être si elles étaient parallèles au firewall
+plutôt que derrière lui.
+
+
NOTE: Ne pas ajouter le(s) adresse(s) ARP
+(192.0.2.177 et 192.0.2.178 dans l'exemple ci-dessus) à
+l'interface externe (eth0 dans cet exemple) du firewall.
+
+
+
+
+
+
Un mot de mise en garde à sa place ici. Les FAIs
+configure(nt) typiquement leur routeur avec un timeout de cache ARP
+élevé. Si vous déplacer un système parallèle à votre firewall derrière
+le Proxy ARP du firewall, cela peut mettre des HEURES avant que le
+système puisse communiquer avec Internet. Il y a deux choses que vous
+pouvez essayer de faire:
+
+
+ - (Courtoisement de Bradey Honsinger) Une lecture de Stevens' TCP/IP
+Illustrated, Vol 1 révèle qu'un paquet ARP
+
+"gratuitous" peut entraîner le routeur de votre FAI à rafraîchir son
+cache(section 4.7). Une "gratuitous" ARP est simplement une requête
+d'un
+hôte demandant l'adresse MAC de sa propre adresse IP; éventuellement
+pour vérifier que l'adresse IP n'est pas dupliquée,...
+
+si l'hôte envoyant la commande "gratuitous" ARP vient juste de changer
+son adresse IP..., ce paquet entraîne tous les autres hôtes...qui ont
+une entrée dans son cache pour l'ancienne adresse matériel de mettre à
+jour également ses caches ARP."
+
+Ce qui est exactement, bien sûr, ce que vous souhaitez faire lorsque
+vous basculez un hôte vulnérable à Internet derrière Shorewall
+utilisant
+proxy ARP (ou one-to-one NAT). Heureusement, des packages récents
+(Redhat)
+iputils incluent "arping", avec l'option "-U" qui fait cela:
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens continue en mentionnant que tous les systèmes répondent
+correctement au gratuitous ARPs, et "googling" pour "arping
+-U" semble aller dans ce sens.
+
+
+ - Vous pouvez appeler votre FAI et dire de purger l'ancienne entrée
+du cache ARP mais la plupart ne veulent ou ne peuvent le faire.
+
+Vous pouvez vérifier si le cache ARP de votre FAI est ancien en
+utilisant ping et tcpdump. Supposez que vous pensez que la
+passerelle routeur a une ancienne entrée ARP pour 192.0.2.177.
+Sur
+le firewall, lancez tcpdump de cette façon:
+
+
tcpdump -nei eth0 icmp
+
+
+
Maintenant depuis 192.0.2.177, utilisez ping vers la
+passerelle du FAI (que nous supposons être 192.0.2.254):
+
+
+
+
Nous pouvons maintenant observer le résultat de tcpdump:
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
+
+
Notez que l'adresse source MAC dans la
+requête echo est différente de l'adresse de
+destination dans la réponse echo!! Dans le cas ou
+0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du firewall
+tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En
+d'autre termes, le cache ARP de la passerelle associe encore
+192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall.
+
+
Avec one-to-one NAT, vous assignez les adresses
+systèmes
+RFC 1918 puis établissez une à une l'assignation entre ces adresses et
+les adresses publiques. Pour les occurrences des connexions sortantes
+SNAT (Source Network Address Translation) et pour les occurrences
+des connexions entrantes DNAT (Destination Network Address
+Translation). Voyons avec l'exemple précédent du serveur web de votre
+fille tournant sur le système Local 3.
+
+
+
+
Rappel du paramétrage, le réseau local utilise SNAT et
+partage l'IP externe du firewall (192.0.2.176) pour les connexions
+sortantes. cela est obtenu avec l'entrée suivante dans le fichier
+/etc/shorewall/masq:
+
+
+
+
+
+ | INTERFACE |
+ SOUS-RESEAU |
+ ADDRESSE |
+
+
+ | eth0 |
+ 192.168.201.0/29 |
+ 192.0.2.176 |
+
+
+
+
+
+
+Supposons maintenant que vous avez décidé d'allouer à
+votre fille sa propre adresse IP (192.0.2.179) pour l'ensemble des
+connexions entrantes et sortantes. Vous devrez faire cela en
+ajoutant une entrée dans le fichier /etc/shorewall/nat.
+
+
+
+
+
+ | EXTERNAL |
+ INTERFACE |
+ INTERNAL |
+ ALL INTERFACES |
+ LOCAL |
+
+
+ | 192.0.2.179 |
+ eth0 |
+ 192.168.201.4 |
+ No |
+ No |
+
+
+
+
+
+
Avec cette entrée active, votre fille a sa propre
+adresse IP et les deux autres systèmes locaux partagent l'adresse IP du
+firewall.
+
+
Une fois
+que la relation entre 192.0.2.179
+et192.168.201.4 est établie par l'entrée ci-dessus, ce n'est pas
+nécessaire d'utiliser une règle DNAT pour le serveur web de votre fille
+-- vous devez simplement utiliser une règle ACCEPT:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL DESTINATION |
+
+
+ | ACCEPT |
+ net |
+ loc:192.168.201.4 |
+ tcp |
+ www |
+ |
+ |
+
+
+
+
+
+
+
+
Un mot de mise en garde à sa place ici. FAIs
+configure(nt) typiquement leur routeur avec un timeout de cache ARP
+élevé. Si vous déplacer un système parallèle à votre firewall derrière
+le Proxy ARP du firewall, cela peut mettre des HEURES avant que le
+système puisse communiquer avec Internet. Il y a deux choses que vous
+pouvez essayer de faire:
+
+
+ - (Courtoisement de Bradey Honsinger) Une lecture de Stevens' TCP/IP
+Illustrated, Vol 1 révèle qu'un paquet ARP
+
+"gratuitous" peut entraîner le routeur de votre FAI à rafraîchir son
+cache(section 4.7). Une "gratuitous" ARP est simplement une requête
+d'un
+hôte demandant l'adresse MAC de sa propre adresse IP; éventuellement
+pour vérifier que l'adresse IP n'est pas dupliquée,...
+
+"si l'hôte envoyant la "gratuitous" ARP vient juste de changer son
+adresse IP..., ce paquet entraîne tous les autres hôtes...qui ont une
+entrée dans son cache pour l'ancienne adresse matériel de mettre à jour
+également ses caches ARP."
+
+Ce qui est exactement, bien sûr, ce que vous souhaitez faire lorsque
+vous basculez un hôte vulnérable à Internet derrière Shorewall
+utilisant
+proxy ARP (ou one-to-one NAT). Heureusement, les versions récentes des
+packages Redhat's iputils incluent "arping", avec l'option "-U" qui
+fait
+cela:
+
+ arping -U -I <net
+if> <newly proxied IP>
+ arping -U -I eth0
+66.58.99.83 # for example
+
+Stevens continue en mentionnant que tous les systèmes répondent
+correctement au gratuitous ARPs, et "googling" pour "arping
+-U" semble aller dans ce sens.
+
+
+ - Vous pouvez appeler votre FAI et dire de purger l'ancienne entrée
+du cache ARP mais la plupart ne veulent ou ne peuvent le faire.
+
+Vous pouvez vérifier si le cache ARP de votre FAI est ancien en
+utilisant ping et tcpdump. Supposez que vous pensez que la
+passerelle routeur a une ancienne entrée ARP pour 192.0.2.177.
+Sur
+le firewall, lancez tcpdump de cette façon:
+
+
tcpdump -nei eth0 icmp
+
+
+
Maintenant depuis 192.0.2.177, utilisez ping vers la
+passerelle du FAI (que nous supposons être 192.0.2.254):
+
+
+
+
+
Nous pouvons maintenant observer le résultat de tcpdump:
+
+
+
13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 192.0.2.177 > 192.0.2.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 192.0.2.254 > 192.0.2.177 : icmp: echo reply
+
+
+
Notez que l'adresse source MAC dans la
+requête echo est différente de l'adresse de
+destination dans la réponse echo!! Dans le cas ou
+0:4:e2:20:20:33 était l'adresse MAC de l'interface NIC eth0 du firewall
+tandis que 0:c0:a8:50:b2:57 était l'adresse MAC de DMZ 1. En
+d'autre termes, le cache ARP de la passerelle associe encore
+192.0.2.177 avec la NIC de DMZ 1 plutôt qu'avec eth0 du firewall.
+
+
5.3 Règles
+
+
Avec les
+polices par défaut, vos systèmes locaux
+(Local 1-3) peuvent accéder à tous les serveurs sur Internet et la DMZ
+ne peut accéder à aucun autre hôte (incluant le firewall). Avec les
+exceptions des règles règles NAT qui entraîne la
+translation d'adresses et permet aux requêtes de connexion translatées
+de passer à travers le firewall, la façon d'autoriser des
+requêtes
+à travers le firewall est d'utiliser des règles ACCEPT.
+
+
+
NOTE: Puisque les colonnes SOURCE PORT et ORIG.
+DEST. ne sont pas utilisées dans cette section, elle ne sont pas
+affichées.
+
+
Vous souhaiter certainement autoriser ping entre vos
+zones:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+
+
+ | ACCEPT |
+ net |
+ dmz |
+ icmp |
+ echo-request |
+
+
+ | ACCEPT |
+ net |
+ loc |
+ icmp |
+ echo-request |
+
+
+ | ACCEPT |
+ dmz |
+ loc |
+ icmp |
+ echo-request |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ icmp |
+ echo-request |
+
+
+
+
+
+
En supposant que vous avez des serveurs mail et pop3
+actifs sur DMZ 2 et un serveur Web sur DMZ 1. Les règles dont vous avez
+besoin sont:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis Internet
+ |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis Internet |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le Réseau Local |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis le Réseau Local |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le firewall |
+
+
+ | ACCEPT |
+ dmz:192.0.2.178 |
+ net |
+ tcp |
+ smtp |
+ # Mails vers Internet
+ |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ http |
+ # WWW depuis le Net
+ |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Net |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Réseau Local |
+
+
+
+
+
+
Si vous utilisez un serveur DNS publique sur
+192.0.2.177, vous devez ajouter les règles suivantes:
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis Internet |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le Réseau local
+ |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le Réseau local |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ udp |
+ domain |
+ # UDP DNS vers Internet |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ tcp |
+ domain |
+ # TCP DNS vers Internet |
+
+
+
+
+
+
Vous souhaitez probablement communiquer entre votre
+firewall et les systèmes DMZ depuis le réseau local -- Je recommande
+SSH
+qui, grâce à son utilitaire scp peut aussi faire de la diffusion
+et de la mise à jour de logiciels.
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ tcp |
+ ssh |
+ # SSH vers la DMZ |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ tcp |
+ ssh |
+ # SSH vers le firewall |
+
+
+
+
+
+
5.4 D'autres petites choses
+
+
+
La discussion précédente reflète ma préférence
+personnelle pour l'utilisation de Proxy ARP associé à mes serveurs de
+la
+DMZ et SNAT/NAT pour mes systèmes locaux. Je préfère utiliser NAT
+seulement dans le cas ou un système qui fait partie d'un sous-réseau
+RFC
+1918 à besoin d'avoir sa propre adresse IP.
+
+
Si vous
+ne l'avez pas fait, ce peut-être une bonne
+idée de parcourir le fichier /etc/shorewall/shorewall.conf
+afin de voir si autre chose pourrait être intéressant. Vous pouvez
+aussi
+regarder aux autres fichiers de configuration que vous n'avez pas
+touché
+pour un aperçu des autres possibilités de Shorewall.
+
+
Dans le cas ou vous n'auriez pas validé les étapes,
+ci-dessous se trouve un jeu final des fichiers de configuration pour
+notre réseau exemple. Uniquement ceux qui auraient étés modifiés de la
+configuration originale sont montrés.
+
+
/etc/shorewall/interfaces (Les "options" seront
+spécifiques aux sites).
+
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ detect |
+ norfc1918,routefilter |
+
+
+ | loc |
+ eth1 |
+ detect |
+ |
+
+
+ | dmz |
+ eth2 |
+ detect |
+ |
+
+
+
+
+
+
La configuration décrit nécessite que votre réseau soit
+démarré avant que Shorewall puisse se lancer. Cela ouvre un
+lapse de temps durant lequel vous n'avez pas de protection firewall.
+Si vous remplacez 'detect' par les valeurs des adresses broadcoast dans
+les entrées suivantes, vous pouvez activer Shorewall avant les
+interfaces réseau.
+
+
+
+
+
+
+ | Zone |
+ Interface |
+ Broadcast |
+ Options |
+
+
+ | net |
+ eth0 |
+ 192.0.2.255 |
+ norfc1918,routefilter |
+
+
+ | loc |
+ eth1 |
+ 192.168.201.7 |
+ |
+
+
+ | dmz |
+ eth2 |
+ 192.168.202.7 |
+ |
+
+
+
+
+
+
/etc/shorewall/masq - Sous-réseau Local
+
+
+
+
+
+
+ | INTERFACE |
+ SOUS-RESEAU |
+ ADDRESS |
+
+
+ | eth0 |
+ 192.168.201.0/29 |
+ 192.0.2.176 |
+
+
+
+
+
+
/etc/shorewall/proxyarp - DMZ
+
+
+
+
+
+ | ADDRESS |
+ INTERFACE |
+ EXTERNAL |
+ HAVE ROUTE |
+
+
+ | 192.0.2.177 |
+ eth2 |
+ eth0 |
+ No |
+
+
+ | 192.0.2.178 |
+ eth2 |
+ eth0 |
+ No |
+
+
+
+
+
+
/etc/shorewall/nat- Le système de ma fille
+
+
+
+
+
+
+ | EXTERNAL |
+ INTERFACE |
+ INTERNAL |
+ ALL INTERFACES |
+ LOCAL |
+
+
+ | 192.0.2.179 |
+ eth0 |
+ 192.168.201.4 |
+ No |
+ No |
+
+
+
+
+
+
+
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ COMMENTS |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis Internet |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le Réseau Local
+ |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ pop3 |
+ # Pop3 depuis le Réseau Local |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.178 |
+ tcp |
+ smtp |
+ # Mail depuis le firewall |
+
+
+ | ACCEPT |
+ dmz:192.0.2.178 |
+ net |
+ tcp |
+ smtp |
+ # Mail vers Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ http |
+ # WWW depuis le Net |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.178 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Net |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.178 |
+ tcp |
+ https |
+ # HTTP sécurisé depuis le Réseau Local |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis Internet |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ fw |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le firewall |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ udp |
+ domain |
+ # UDP DNS depuis le Réseau Local |
+
+
+ | ACCEPT |
+ loc |
+ dmz:192.0.2.177 |
+ tcp |
+ domain |
+ # TCP DNS depuis le Réseau Local |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ udp |
+ domain |
+ # UDP DNS vers Internet |
+
+
+ | ACCEPT |
+ dmz:192.0.2.177 |
+ net |
+ tcp |
+ domain |
+ # TCP DNS vers Internet |
+
+
+ | ACCEPT |
+ net |
+ dmz |
+ icmp |
+ echo-request |
+ # Ping |
+
+
+ | ACCEPT |
+ net |
+ loc |
+ icmp |
+ echo-request |
+ # " |
+
+
+ | ACCEPT |
+ dmz |
+ loc |
+ icmp |
+ echo-request |
+ # " |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ icmp |
+ echo-request |
+ # " |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ tcp |
+ ssh |
+ # SSH vers DMZ |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ tcp |
+ ssh |
+ # SSH vers le firewall |
+
+
+
+
+
+
En donnant une collection d'adresses RFC 1918 et
+publiques dans la configuration, cela justifie d'avoir des serveurs DNS
+interne et externe. Vous pouvez combiner les deux dans un unique
+serveur BIND 9 utilisant les vues (Views). Si vous n'êtes pas
+intéressé par les vues BIND 9, vous pouvez allez à la section suivante.
+
+
Supposons que votre domain est foobar.net et vous
+voulez que les deux systèmes DMZ s'appellent www.foobar.net et
+mail.foobar.net, les trois systèmes locaux "winken.foobar.net,
+blinken.foobar.net et nod.foobar.net. Vous voulez que le firewall soit
+connu à l'extérieur sous le nom firewall.foobar.net, son interface vers
+le réseau local gateway.foobar.net et son interface vers la DMZ
+dmz.foobar.net. Mettons le serveur DNS sur 192.0.2.177 qui sera aussi
+connu sous le nom ns1.foobar.net.
+
+
Le fichier /etc/named.conf devrait ressembler à
+cela:
+
+
+
+
options {
directory "/var/named";
listen-on { 127.0.0.1 ; 192.0.2.177; };
};
logging {
channel xfer-log {
file "/var/log/named/bind-xfer.log";
print-category yes;
print-severity yes;
print-time yes;
severity info;
};
category xfer-in { xfer-log; };
category xfer-out { xfer-log; };
category notify { xfer-log; };
};
+
+
#
# Ceci est la vue présente sur vos systèmes internes.
#
view "internal" {
#
# Les clients suivants peuvent voir le serveur
#
match-clients { 192.168.201.0/29;
192.168.202.0/29;
127.0.0.0/8;
192.0.2.176/32;
192.0.2.178/32;
192.0.2.179/32;
192.0.2.180/32; };
#
# Si le serveur ne peut répondre à la requête, il utilisera des serveurs externes
#
#
recursion yes;
zone "." in {
type hint;
file "int/root.cache";
};
zone "foobar.net" in {
type master;
notify no;
allow-update { none; };
file "int/db.foobar";
};
zone "0.0.127.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.127.0.0";
};
zone "201.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.201";
};
zone "202.168.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "int/db.192.168.202";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.176";
};
(or status NAT for that matter)
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify no;
allow-update { none; };
file "db.206.124.146.179";
};
};
#
# Ceci est la vue qui sera présente pour le monde extérieur
#
view "external" {
match-clients { any; };
#
# Si nous pouvons répondre à la requéte, nous le disons
#
recursion no;
zone "foobar.net" in {
type master;
notify yes;
allow-update {none; };
allow-transfer { <secondary NS IP>; };
file "ext/db.foobar";
};
zone "176.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.176";
};
zone "177.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.177";
};
zone "178.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.178";
};
zone "179.2.0.192.in-addr.arpa" in {
type master;
notify yes;
allow-update { none; };
allow-transfer { <secondary NS IP>; };
file "db.192.0.2.179";
};
};
+
+
+
Voici les fichiers de /var/named (ceux qui ne sont pas
+présents font partis de votre distribution BIND).
+
db.192.0.2.176 - Zone inverse de l'interface externe du
+firewall
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.176/32
; Filename: db.192.0.2.176
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
176.2.0.192.in-addr.arpa. 86400 IN PTR firewall.foobar.net.
+
+
+
db.192.0.2.177 - Zone inverse pour le serveur
+www/DNS
+server
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.177/32
; Filename: db.192.0.2.177
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
177.2.0.192.in-addr.arpa. 86400 IN PTR www.foobar.net.
+
+
+
+
db.192.0.2.178 - Zone inverse du serveur mail
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.178/32
; Filename: db.192.0.2.178
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
178.2.0.192.in-addr.arpa. 86400 IN PTR mail.foobar.net.
+
+
+
+
db.192.0.2.179 - Zone inverse du serveur web
+publique
+de votre fille
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.0.2.179/32
; Filename: db.192.0.2.179
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001102303 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
;
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
@ 604800 IN NS <name of secondary ns>.
;
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
179.2.0.192.in-addr.arpa. 86400 IN PTR nod.foobar.net.
+
+
+
+
int/db.127.0.0 - Zone inverse pour localhost
+
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 127.0.0.0/8
; Filename: db.127.0.0
; ############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2001092901 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR localhost.foobar.net.
+
+
+
int/db.192.168.201 - Zone inverse pour le réseau local.
+cela n'est montré qu'aux clients internes
+
+
+
+ ; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.201.0/29
; Filename: db.192.168.201
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
2002032501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR gateway.foobar.net.
2 86400 IN PTR winken.foobar.net.
3 86400 IN PTR blinken.foobar.net.
4 86400 IN PTR nod.foobar.net.
+
+
+
int/db.192.168.202 - Zone inverse de l'interface DMZ du
+firewall
+
+
+
+
; ############################################################
; Start of Authority (Inverse Address Arpa) for 192.168.202.0/29
; Filename: db.192.168.202
; ############################################################
@ 604800 IN SOA ns1.foobar.net netadmin.foobar.net. (
2002032501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ) ; minimum (1 day)
; ############################################################
; Specify Name Servers for all Reverse Lookups (IN-ADDR.ARPA)
; ############################################################
@ 604800 IN NS ns1.foobar.net.
; ############################################################
; Iverse Address Arpa Records (PTR's)
; ############################################################
1 86400 IN PTR dmz.foobar.net.
+
+
+
int/db.foobar - Forward zone pour l'utilisation des
+clients internes.
+
+
+ ;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 604800 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2002071501 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ); minimum (1 day)
;############################################################
; foobar.net Nameserver Records (NS)
;############################################################
@ 604800 IN NS ns1.foobar.net.
;############################################################
; Foobar.net Office Records (ADDRESS)
;############################################################
localhost 86400 IN A 127.0.0.1
firewall 86400 IN A 192.0.2.176
www 86400 IN A 192.0.2.177
ns1 86400 IN A 192.0.2.177
www 86400 IN A 192.0.2.177
gateway 86400 IN A 192.168.201.1
winken 86400 IN A 192.168.201.2
blinken 86400 IN A 192.168.201.3
nod 86400 IN A 192.168.201.4
+
+
+
ext/db.foobar - Forward zone pour les clients externes
+
+
+
+
+
;##############################################################
; Start of Authority for foobar.net.
; Filename: db.foobar
;##############################################################
@ 86400 IN SOA ns1.foobar.net. netadmin.foobar.net. (
2002052901 ; serial
10800 ; refresh (3 hour)
3600 ; retry (1 hour)
604800 ; expire (7 days)
86400 ); minimum (1 day)
;############################################################
; Foobar.net Nameserver Records (NS)
;############################################################
@ 86400 IN NS ns1.foobar.net.
@ 86400 IN NS <secondary NS>.
;############################################################
; Foobar.net Foobar Wa Office Records (ADDRESS)
;############################################################
localhost 86400 IN A 127.0.0.1
;
; The firewall itself
;
firewall 86400 IN A 192.0.2.176
;
; The DMZ
;
ns1 86400 IN A 192.0.2.177
www 86400 IN A 192.0.2.177
mail 86400 IN A 192.0.2.178
;
; The Local Network
;
nod 86400 IN A 192.0.2.179
;############################################################
; Current Aliases for foobar.net (CNAME)
;############################################################
;############################################################
; foobar.net MX Records (MAIL EXCHANGER)
;############################################################
foobar.net. 86400 IN A 192.0.2.177
86400 IN MX 0 mail.foobar.net.
86400 IN MX 1 <backup MX>.
+
+
+
7.0 Démarrer et
+Stopper le firewall
+
+
Le firewall est démarré en utilisant la commande
+"shorewall start" et arrêté avec "shorewall stop". Quand le firewall
+est
+arrêté, le routage est actif sur les hôtes qui ont une entrée dans le
+fichier /etc/shorewall/routestopped.
+Le firewall actif peut-être relancé grâce à la commande "shorewall
+restart". Si vous voulez retirer toute trace de Shorewall de votre
+configuration Netfilter, utilisez "shorewall clear".
+
+
Editez
+le fichier /etc/shorewall/routestopped
+file et ajouter les systèmes qui doivent pouvoir se connecter au
+firewall quant il est arrêté.
+
+
ATTENTION: Si vous êtes connecté à votre
+firewall depuis Internet, ne pas exécutez la commande "shorewall
+stop" tant que vous n'avez pas une entrée active pour l'adresse IP de
+votre hôte dans le fichier /etc/shorewall/routestopped.
+Egalement, je ne recommande pas d'utiliser "shorewall restart"; il est
+préférable d'utiliser une configuration
+alternative et la tester avec la commande "shorewall try".
+
Last updated 11/13/2003 - Fabien
+Demassieux and Tom Eastep
+Copyright 2002,
+2003 Fabien Demassieux and Thomas M. Eastep
+
+
+
+
+
diff --git a/Shorewall-docs/sourceforge_index.htm b/Shorewall-docs/sourceforge_index.htm
index 05cb287ed..b730008b1 100644
--- a/Shorewall-docs/sourceforge_index.htm
+++ b/Shorewall-docs/sourceforge_index.htm
@@ -7,18 +7,6 @@
-
-
-
- 
- |
-
-
-
+ Site Problem
+The server that normally hosts www.shorewall.net and ftp.shorewall.net
+is currently down. Until it is back up, a small server with very
+limited bandwidth is being used temporarly. You will likely experience
+better response time from the Sourceforge site
+or from one of the other mirrors.
+Sorry for the inconvenience.
+
Introduction
@@ -37,14 +34,12 @@ and control that facility. Netfilter can be used in ipchains
compatibility mode.
- iptables - the utility program used to configure and
-control
-Netfilter. The term 'iptables' is often used to refer to the
-combination of iptables+Netfilter (with Netfilter not in
-ipchains compatibility mode).
+control Netfilter. The term 'iptables' is often used to refer to the
+combination of iptables+Netfilter (with Netfilter not in ipchains
+compatibility mode).
-The
-Shoreline Firewall, more commonly known as "Shorewall", is
+The Shoreline Firewall, more commonly known as "Shorewall", is
high-level tool for configuring Netfilter. You describe your
firewall/gateway requirements using entries in a set of configuration
files. Shorewall reads those configuration files and with the help of
@@ -56,14 +51,14 @@ and can thus take advantage of Netfilter's connection state tracking
capabilities.
This program is free software; you can redistribute it and/or
modify it under the terms of Version 2 of the
-GNU General Public License as published by the Free Software
-Foundation.
+ href="http://www.gnu.org/licenses/gpl.html">Version 2 of the GNU
+General Public License as published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-General Public License for more details.
+General
+Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
@@ -81,356 +76,205 @@ Shorewall. For older versions:
Getting Started with Shorewall
-New to Shorewall? Start by
-selecting the QuickStart Guide
-that most closely match your environment and
-follow the step by step instructions.
+New to Shorewall? Start by selecting the QuickStart Guide that most
+closely match your environment and follow the step by step instructions.
Looking for Information?
The Documentation
-Index is a good place to start as is the Quick Search to your
-right.
+Index is a good place to start as is the Quick Search in the frame
+above.
Running Shorewall on Mandrake with a two-interface setup?
If so, the documentation on this site will not apply directly
-to your setup. If you want to
-use the documentation that you find here, you will want to consider
-uninstalling what you have and installing a setup that matches the
-documentation on this site. See the Two-interface
-QuickStart Guide for
+to
+your setup. If you want to use the documentation that you find here,
+you will want to consider uninstalling what you have and installing a
+setup that matches the documentation on this site. See the Two-interface QuickStart Guide for
details.
News
- 10/06/2003 - Shorewall 1.4.7 ![]() 11/01/2003 - Shorewall 1.4.8 RC2
-
-Problems Corrected since version 1.4.6 (Those in bold font
-were corrected since 1.4.7 RC2).
-
- - Corrected problem in 1.4.6 where the MANGLE_ENABLED
-variable was being tested before it was set.
- - Corrected handling of MAC addresses in the SOURCE column of
-the tcrules file. Previously, these addresses resulted in an invalid
-iptables command.
- - The "shorewall stop" command is now disabled when
-/etc/shorewall/startup_disabled exists. This prevents people from
-shooting themselves in the foot prior to having configured Shorewall.
- - A change introduced in version 1.4.6 caused error messages
-during "shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses
-were being added to a PPP interface; the addresses were successfully
-added in spite of the messages.
-
-The firewall script has been modified to eliminate the error messages
- - Interface-specific dynamic blacklisting chains are
-now displayed by "shorewall monitor" on the "Dynamic Chains" page
-(previously named "Dynamic Chain").
- - Thanks to Henry Yang, LOGRATE and LOGBURST now work again.
- - The 'shorewall reject'
-and
-'shorewall drop' commands now delete any existing rules for the subject
-IP address before adding a new DROP or REJECT rule. Previously, there
-could be many rules for the same IP address in the dynamic chain so
-that multiple 'allow' commands were required to re-enable traffic
-to/from the address.
- - When ADD_SNAT_ALIASES=Yes in
-shorewall.conf, the following entry in /etc/shorewall/masq resulted in
-a startup error:
-
- eth0 eth1
-206.124.146.20-206.124.146.24
-
-
- - Shorewall previously choked over
-IPV6
-addresses configured on interfaces in contexts where Shorewall needed
-to detect something about the interface (such as when "detect" appears
-in the BROADCAST column of the /etc/shorewall/interfaces file).
- - Shorewall will now load
-module files that are formed from the module name by appending ".o.gz".
- - When Shorewall adds a route to a
-proxy
-ARP host and such a route already exists, two routes resulted
-previously. This has been corrected so that the existing route is
-replaced if it already exists.
- - The rfc1918 file has been
-updated to reflect recent allocations.
- - The documentation of the
-USER SET column in the rules file has been corrected.
- - If there is no policy
-defined for
-the zones specified in a rule, the firewall script previously
-encountered a shell syntax error:
-
-
- [: NONE: unexpected operator
-
-
-Now, the absence of a policy generates an error message and the
-firewall is stopped:
-
-
- No policy defined from zone
-<source> to zone <dest>
-
-
- - Previously, if neither
-/etc/shorewall/common nor /etc/shorewall/common.def existed, Shorewall
-would fail to start and would not remove the lock file. Failure to
-remove the lock file resulted in the following during subsequent
-attempts to start:
-
-
- Loading /usr/share/shorewall/functions...
- Processing /etc/shorewall/params ...
- Processing /etc/shorewall/shorewall.conf...
- Giving up on lock file /var/lib/shorewall/lock
- Shorewall Not Started
-
-Shorewall now reports a fatal error if neither of these two files exist
-and correctly removes the lock fille.
- - The order of processing
-the
-various options has been changed such that blacklist entries now take
-precedence over the 'dhcp' interface setting.
- - The log message generated
-from the
-'logunclean' interface option has been changed to reflect a disposition
-of LOG rather than DROP.
- - When a user name and/or a
-group
-name was specified in the USER SET column and the destination zone was
-qualified with a IP address, the user and/or group name was not being
-used to qualify the rule.
-
- Example:
-
- ACCEPT fw net:192.0.2.12 tcp 23 - - - vladimir:
-
-
- - The /etc/shorewall/masq
-file has had the spurious "/" character at the front removed.
-
- Migration Issues:
-
- - Shorewall IP Traffic Accounting has changed since snapshot
-20030813 -- see the Accounting Page for
-details.
- - The Uset Set capability introduced in SnapShot 20030821 has
-changed -- see the User Set page for
-details.
- - The
-per-interface Dynamic Blacklisting facility introduced in the first
-post-1.4.6 Snapshot has been removed. The facility had too many
-idiosyncrasies for dial-up users to be a viable part of Shorewall.
-
-
- New Features:
-
- - Shorewall now creates a dynamic blacklisting chain for each
-interface defined in /etc/shorewall/interfaces. The 'drop' and 'reject'
-commands use the routing table to determine which of these chains is to
-be used for blacklisting the specified IP address(es).
-
-Two new commands ('dropall' and 'rejectall') have been introduced that
-do what 'drop' and 'reject' used to do; namely, when an address is
-blacklisted using these new commands, it will be blacklisted on all of
-your firewall's interfaces.
- - Thanks to Steve Herber, the 'help' command can now give
-command-specific help (e.g., shorewall help <command>).
- - A new option "ADMINISABSENTMINDED" has been added to
-/etc/shorewall/shorewall.conf. This option has a default value of "No"
-for existing users which causes Shorewall's 'stopped' state to
-continue as it has been; namely, in the stopped state only traffic
-to/from hosts listed in /etc/shorewall/routestopped is accepted.
-
-With ADMINISABSENTMINDED=Yes (the default for new installs), in
-addition to traffic to/from the hosts listed in
-/etc/shorewall/routestopped, Shorewall will allow:
-
- a) All traffic originating from the firewall itself; and
- b) All traffic that is part of or related to an
-already-existing connection.
-
- In particular, with ADMINISABSENTMINDED=Yes, a "shorewall stop"
-entered through an ssh session will not kill the session.
-
- Note though that even with ADMINISABSENTMINDED=Yes, it is still
-possible for people to shoot themselves in the foot.
-
- Example:
-
- /etc/shorewall/nat:
-
- 206.124.146.178
-eth0:0 192.168.1.5
-
- /etc/shorewall/rules:
-
- ACCEPT net
-loc:192.168.1.5 tcp 22
- ACCEPT loc
-fw tcp 22
-
-From a remote system, I ssh to 206.124.146.178 which establishes an SSH
-connection with local system 192.168.1.5. I then create a second SSH
-connection
-from that computer to the firewall and confidently type "shorewall
-stop".
-As part of its stop processing, Shorewall removes eth0:0 which kills my
-SSH
-connection to 192.168.1.5!!!
- - Given the wide range of VPN software, I can never hope to
-add specific support for all of it. I have therefore decided to add
-"generic" tunnel support.
-
-Generic tunnels work pretty much like any of the other tunnel types.
-You usually add a zone to represent the systems at the other end of the
-tunnel and you add the appropriate rules/policies to
-implement your security policy regarding traffic to/from those systems.
-
-In the /etc/shorewall/tunnels file, you can have entries of the form:
-
-generic:<protocol>[:<port>] <zone> <ip
-address> <gateway zones>
-
-where:
-
- <protocol> is the protocol
-used by the tunnel
- <port> if the protocol
-is 'udp' or 'tcp' then this is the destination port number used by the
-tunnel.
- <zone> is the zone of
-the remote tunnel gateway
- <ip address> is the IP
-address of the remote tunnel gateway.
- <gateway zone>
-Optional. A comma-separated list of zone names. If specified, the
-remote gateway is to be considered part of these zones.
- - An 'arp_filter' option has been added to the
-/etc/shorewall/interfaces file. This option causes
-/proc/sys/net/ipv4/conf/<interface>/arp_filter to be set with the
-result that this interface will only answer ARP 'who-has' requests from
-hosts that are routed out through that interface. Setting this option
-facilitates testing of your firewall where multiple firewall interfaces
-are connected to the same HUB/Switch (all interfaces connected to the
-single HUB/Switch should have this option specified). Note that using
-such a configuration in a production environment is strongly
-recommended against.
- - The ADDRESS column in /etc/shorewall/masq may now include a
-comma-separated list of addresses and/or address ranges. Netfilter will
-use all listed addresses/ranges in round-robin fashion. \
- - An /etc/shorewall/accounting file has been added to allow
-for traffic accounting. See the accounting
-documentation for a description of this facility.
- - Bridge interfaces (br[0-9]) may now be used in
-/etc/shorewall/maclist.
- - ACCEPT, DNAT[-], REDIRECT[-] and LOG rules defined in
-/etc/shorewall/rules may now be rate-limited. For DNAT and REDIRECT
-rules, rate limiting occurs in the nat table DNAT rule; the
-corresponding ACCEPT rule in the filter table is not rate limited. If
-you want to limit the filter table rule, you will need o create two
-rules; a DNAT- rule and an ACCEPT rule which can be rate-limited
-separately.
-
- Warning: When rate
-limiting is specified on a rule with "all" in the SOURCE or DEST
-fields, the limit will apply to each pair of zones individually rather
-than as a single limit for all pairs of covered by the rule.
-
-To specify a rate limit,
-
-a) Follow ACCEPT, DNAT[-], REDIRECT[-] or LOG with
-
- <
-<rate>/<interval>[:<burst>] >
-
-
-where
-
- <rate> is the sustained rate per
-<interval>
- <interval> is "sec" or "min"
- <burst> is the largest burst
-accepted within an <interval>. If not given, the default of 5 is
-assumed.
-
-There may be no white space between the ACTION and "<" nor there may
-be any white space within the burst specification. If you want to
-specify logging of a rate-limited rule, the ":" and log level comes
-after the ">" (e.g., ACCEPT<2/sec:4>:info ).
-
-b) A new RATE LIMIT column has been added to the /etc/shorewall/rules
-file. You may specify the rate limit there in the format:
-
-
-<rate>/<interval>[:<burst>]
-
-Let's take an example:
-
-
-ACCEPT<2/sec:4>
-net dmz
-tcp 80
-
-The first time this rule is reached, the packet will be accepted; in
-fact, since the burst is 4, the first four packets will be accepted.
-After this, it will be 500ms (1 second divided by the rate
-of 2) before a packet will be accepted from this rule, regardless of
-how many packets reach it. Also, every 500ms which passes without
-matching a packet, one of the bursts will be regained; if no packets
-hit the rule for 2 second, the burst will be fully recharged; back
-where we started.
-
- - Multiple chains may now be displayed in one "shorewall
-show" command (e.g., shorewall show INPUT FORWARD OUTPUT).
- - Output rules (those with $FW as the SOURCE) may now be
-limited to a set of local users and/or groups. See http://shorewall.net/UserSets.html for
-details.
-
- 8/27/2003 - Shorewall Mirror in Australia
- Thanks to Dave Kempe and Solutions First (http://www.solutionsfirst.com.au),
-there is now a Shorewall Mirror in Australia:
-
- 8/26/2003 - French Version of the Shorewall Setup
-Guide
-Thanks to Fabien Demassieux, there is now a French translation of the
-Shorewall Setup Guide. Merci Beacoup, Fabien! 9/15/2003
-- Shorewall 1.4.7 Beta 2 
- 8/5/2003 - Shorewall-1.4.6b
+ src="file:///vfat/Shorewall-docs/images/new10.gif" alt="(New)" title="">
- Problems Corrected since version 1.4.6:
+Given the small number of new features and the relatively few lines of
+code that were changed, there will be no Beta for 1.4.8.
+ http://shorewall.net/pub/shorewall/Beta
+ ftp://shorewall.net/pub/shorewall/Beta
+
+ Problems Corrected since version 1.4.7:
+
- - Previously, if TC_ENABLED is set to yes in shorewall.conf
-then Shorewall would fail to start with the error "ERROR: Traffic
-Control requires Mangle"; that problem has been corrected.
- - Corrected handling of MAC addresses in the SOURCE column of
+
- Tuomo Soini has supplied a correction to a problem that
+occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+ - Andres Zhoglo has supplied a correction that avoids trying
+to use the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued,
+Shorewall was left in an inconsistent state.
+
+ Error: Unable to determine the routes through interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has
+been corrected.
+ - In Shorewall 1.4.2, an optimization was added. This
+optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F"
+or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
+ - An incorrect comment concerning Debian's use of the
+SUBSYSLOCK option has been removed from shorewall.conf.
+ - Previously, neither the 'routefilter' interface option nor
the
-tcrules file. Previously, these addresses resulted in an invalid
-iptables
-command.
- - The "shorewall stop" command is now disabled when
-/etc/shorewall/startup_disabled
-exists. This prevents people from shooting themselves in the foot prior
-to
-having configured Shorewall.
- - A change introduced in version 1.4.6 caused error messages
-during
-"shorewall [re]start" when ADD_IP_ALIASES=Yes and ip addresses were
-being
-added to a PPP interface; the addresses were successfully added in
-spite
-of the messages.
-
-The firewall script has been modified to eliminate the error messages.
+ROUTE_FILTER parameter were working properly. This has been corrected
+(thanks to Eric Bowles for his analysis and patch). The definition of
+the ROUTE_FILTER option has changed however. Previously,
+ROUTE_FILTER=Yes was documented as enabling route filtering on all
+interfaces (which didn't work). Beginning with this release, setting
+ROUTE_FILTER=Yes will enable route filtering of all interfaces brought
+up while Shorewall is started. As a consequence, ROUTE_FILTER=Yes can
+coexist with the use of the 'routefilter' option in the interfaces file.
+ - If MAC verification was enabled on an interface with a /32
+address and
+a broadcast address then an error would occur during startup.
+
+Migration Issues:
+
+ - The definition of the ROUTE_FILTER option in shorewall.conf
+has changed as described in item 8) above.
+
+
+New Features:
+
+ - A new QUEUE action has been introduced for rules. QUEUE
+allows
+you to pass connection requests to a user-space filter such as ftwall
+(http://p2pwall.sourceforge.net). The ftwall program
+allows for effective filtering of p2p applications such as Kazaa. For
+example, to use ftwall to filter P2P clients in the 'loc' zone, you
+would add the following rules:
+
+ QUEUE loc
+ net tcp
+ QUEUE loc
+ net udp
+ QUEUE loc
+ fw udp
+
+You would normally want to place those three rules BEFORE any ACCEPT
+rules for loc->net udp or tcp.
+
+Note: When the protocol specified is TCP ("tcp", "TCP" or "6"),
+Shorewall will only pass connection requests (SYN packets) to user
+space. This is for compatibility with ftwall.
+ - A
+BLACKLISTNEWNONLY option has been added to shorewall.conf. When this
+option is set to "Yes", the blacklists (dynamic and static) are only
+consulted for new connection requests. When set to "No" (the default if
+the variable is not set), the blacklists are consulted on every packet.
+
+Setting this option to "No" allows blacklisting to stop existing
+connections from a newly blacklisted host but is more expensive in
+terms of packet processing time. This is especially true if the
+blacklists contain a large number of entries.
+ - Chain names used in the /etc/shorewall/accounting file may
+now begin with a digit ([0-9]) and may contain embedded dashes ("-").
+
+ 10/26/2003 - Shorewall 1.4.7a and 1.4.7b win brown paper
+bag awards Shorewall
+1.4.7c released.
+
+ - The saga with "<zone>_frwd" chains continues. The
+1.4.7c script
+produces a ruleset that should work for everyone even if it is not
+quite optimal. My apologies for this ongoing mess.
+
+ 10/24/2003 - Shorewall 1.4.7b
+ This is a bugfx rollup of the 1.4.7a fixes plus:
+
+
+ - The fix for problem 5 in 1.4.7a was wrong with the result
+that
+"<zone>_frwd" chains might contain too few rules. That wrong code
+is corrected in this release.
+
+
+ 10/21/2003 - Shorewall 1.4.7a
+ This is a bugfix rollup of the following problem corrections:
+
+
+ - Tuomo Soini has supplied a correction to a problem that
+occurs
+using some versions of 'ash'. The symptom is that "shorewall start"
+fails with:
+
+ local: --limit: bad variable name
+ iptables v1.2.8: Couldn't load match
+`-j':/lib/iptables/libipt_-j.so:
+ cannot open shared object file: No such file or directory
+ Try `iptables -h' or 'iptables --help' for more
+information.
+
+
+ - Andres Zhoglo has supplied a correction that avoids trying
+to use the multiport match iptables facility on ICMP rules.
+
+ Example of rule that previously caused "shorewall start"
+to fail:
+
+
+ACCEPT loc $FW
+icmp 0,8,11,12
+
+
+ - Previously, if the following error message was issued,
+Shorewall was left in an inconsistent state.
+
+ Error: Unable to determine the routes through
+interface xxx
+
+
+ - Handling of the LOGUNCLEAN option in shorewall.conf has
+been corrected.
+ - In Shorewall 1.4.2, an optimization was added. This
+optimization
+involved creating a chain named "<zone>_frwd" for most zones
+defined using the /etc/shorewall/hosts file. It has since been
+discovered that in many cases these new chains contain redundant rules
+and that the "optimization" turns out to be less than optimal. The
+implementation has now been corrected.
+ - When the MARK value in a tcrules entry is followed by ":F"
+or
+":P", the ":F" or ":P" was previously only applied to the first
+Netfilter rule generated by the entry. It is now applied to all entries.
More News
@@ -453,44 +297,22 @@ Bering 1.2!!!
This site is hosted by the generous folks at SourceForge.net
-
+ href="http://www.sf.net">SourceForge.net
+
+
Donations
|
-
-
- Extended Search
-
- |
+ style="border-collapse: collapse; width: 100%; background-color: rgb(51, 102, 255);"
+ id="AutoNumber2">
- |
+ |
@@ -503,7 +325,7 @@ Children's Foundation. Thanks!
|
-Updated 10/06/2003 - Tom Eastep
+
Updated 11/17/2003 - Tom Eastep
diff --git a/Shorewall-docs/standalone.htm b/Shorewall-docs/standalone.htm
index 6a2ca5ec8..dbbc6cd5d 100644
--- a/Shorewall-docs/standalone.htm
+++ b/Shorewall-docs/standalone.htm
@@ -9,17 +9,8 @@
Standalone Firewall
-
-
-
-
- Standalone Firewall
- |
-
-
-
+Standalone Firewall
+
Setting up Shorewall on a standalone Linux system is
very easy if you understand the basics and follow the documentation.
This guide doesn't attempt to acquaint you with all of the features
@@ -113,7 +104,9 @@ first checked against the /etc/shorewall/rules file. If no rule in that
file matches the connection request then the first policy in
/etc/shorewall/policy that matches the request is applied. If that
policy is REJECT or DROP the request is first checked against the
-rules in /etc/shorewall/common (the samples provide that file for you).
+rules in /etc/shorewall/common if that file exists; otherwise the rules
+in /etc/shorewall/common.def are checked.
+
The /etc/shorewall/policy file included with the one-interface
sample
has the following policies:
@@ -365,9 +358,15 @@ to /etc/shorewall/routestopped.
Also, I don't recommend using "shorewall restart"; it is better to
create an alternate
configuration and test it using the "shorewall try" command.
+ href="starting_and_stopping_shorewall.htm">"shorewall try" command.
+
+Additional Recommended Reading
+I highly recommend that you review the Common Configuration File
+Features page -- it contains helpful tips about Shorewall features
+than make administering your firewall easier.
-Last updated 2/08/2003 - Last updated 11/15/2003 - Tom Eastep
Copyright 2002,
2003 Thomas M. Eastep
diff --git a/Shorewall-docs/standalone_fr.html b/Shorewall-docs/standalone_fr.html
index 4b21a122b..fa5380532 100755
--- a/Shorewall-docs/standalone_fr.html
+++ b/Shorewall-docs/standalone_fr.html
@@ -1,471 +1,426 @@
-
-
-
-
Standalone Firewall
-
-
-
-
-
-
- Standalone Firewall
- |
-
-
-
-
-
-Version 2.0.1 Française
-
+
+Standalone Firewall
Notes du traducteur :
- Je ne prétends pas être un vrai traducteur dans le sens ou mon travail
-n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à une
-traduction exacte du texte, mais plutôt à en faire une version française intelligible
-par tous (et par moi). Les termes techniques sont la plupart du temps conservés
-sous leur forme originale et mis entre parenthèses car vous pouvez les retrouver
-dans le reste des documentations ainsi que dans les fichiers de configuration.
+Je ne prétends pas être un vrai traducteur dans le sens ou mon travail
+n'est pas des plus précis (loin de là...). Je ne me suis pas attaché à
+une traduction exacte du texte, mais plutôt à en faire une version
+française intelligible
+par tous (et par moi). Les termes techniques sont la plupart du temps
+conservés
+sous leur forme originale et mis entre parenthèses car vous pouvez les
+retrouver
+dans le reste des documentations ainsi que dans les fichiers de
+configuration.
N?hésitez pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à JMM
-pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP pour
+ href="mailto:vetsel.patrice@wanadoo.fr">VETSEL Patrice (merci à
+JMM
+pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom EASTEP
+pour
son formidable outil et sa disponibilité).
-
-Mettre en place un système Linux en tant que firewall (écluse)
- pour un petit réseau est une chose assez simple, si vous comprenez les bases
- et suivez la documentation.
-
-Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il
-se focalise sur ce qui est nécessaire pour configurer Shorewall, dans son
+
Mettre en place un système Linux en tant que firewall
+(écluse) pour un petit réseau est une chose assez simple, si vous
+comprenez les bases et suivez la documentation.
+Ce guide ne veut pas vous apprendre tous les rouages de Shorewall.
+Il
+se focalise sur ce qui est nécessaire pour configurer Shorewall, dans
+son
utilisation la plus courante :
-
- - Un système Linux
- - Une seule adresse IP externe
- - Une connexion passant par un modem câble, ADSL, ISDN, Frame Relay,
- rtc...
-
+ - Un système Linux
+ - Une seule adresse IP externe
+ - Une connexion passant par un modem câble, ADSL, ISDN, Frame
+Relay, rtc...
-
-Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé.
-Vous pouvez voir si le paquet est installé en vérifiant la présence du programme
- ip sur votre système de firewall. Sous root, utilisez la commande 'which'
- pour rechercher le programme :
-
+Ce guide suppose que vous avez le paquet iproute/iproute2
+d'installé.
+Vous pouvez voir si le paquet est installé en vérifiant la présence du
+programme ip sur votre système de firewall. Sous root, utilisez la
+commande 'which' pour rechercher le programme :
[root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
-
-Je vous recommande dans un premier temps de parcourir tout le guide pour
- vous familiariser avec ce qu'il va se passer, et de revenir au début en
-effectuant le changements dans votre configuration. Les points, où les changements
-dans la configuration sont recommandées, sont signalés par une
- .
-
-
- Si vous éditez vos fichiers de configuration sur un système Windows, vous
- devez les sauver comme des fichiers Unix si votre éditeur supporte cette
-option sinon vous devez les faire passer par dos2unix avant d'essayer de les
-utiliser. De la même manière, si vous copiez un fichier de configuration depuis
-votre disque dur Windows vers une disquette, vous devez lancer dos2unix sur
+
Je vous recommande dans un premier temps de parcourir tout le guide
+pour vous familiariser avec ce qu'il va se passer, et de revenir au
+début en
+effectuant le changements dans votre configuration. Les points, où les
+changements
+dans la configuration sont recommandées, sont signalés par une .
+ Si
+vous éditez vos fichiers de configuration sur un système Windows, vous
+devez les sauver comme des fichiers Unix si votre éditeur supporte
+cette option sinon vous devez les faire passer par dos2unix avant
+d'essayer de les
+utiliser. De la même manière, si vous copiez un fichier de
+configuration depuis
+votre disque dur Windows vers une disquette, vous devez lancer dos2unix
+sur
la copie avant de l'utiliser avec Shorewall.
-
-
Les Concepts de Shorewall
-
- Les fichiers de configuration pour Shorewall sont situés dans le répertoire
- /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec
- quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez le one-interface sample,
-un-tarez le (tar -zxvf one-interface.tgz) et copiez les fichiers vers /etc/shorewall
- (Ils remplaceront les fichiers de même nom déjà existant dans /etc/shorewall
-installés lors de l'installation de Shorewall).
-
-Parallèlement à la description, je vous suggère de jeter un oeil à ceux
- physiquement présents sur votre système -- chacun des fichiers contient
-des instructions de configuration détaillées et des entrées par défaut.
-
-Shorewall voit le réseau où il tourne comme composé par un ensemble de
- zones. Dans les fichiers de configuration fournis pour une unique
+ alt=""> Les fichiers de configuration pour Shorewall sont situés dans
+le répertoire /etc/shorewall -- pour de simples paramétrages, vous
+n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce
+guide. Après avoir installé Shorewall, téléchargez
+le one-interface
+sample, un-tarez le (tar -zxvf one-interface.tgz) et copiez les
+fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même nom
+déjà existant dans /etc/shorewall installés lors de l'installation de
+Shorewall).
+Parallèlement à la description, je vous suggère de jeter un oeil à
+ceux physiquement présents sur votre système -- chacun des fichiers
+contient
+des instructions de configuration détaillées et des entrées par défaut.
+Shorewall voit le réseau où il tourne comme composé par un ensemble
+de zones. Dans les fichiers de configuration fournis pour une
+unique
interface, une seule zone est définie :
-
-
-
- | Name |
- Description |
-
-
- | net |
- The Internet |
-
-
-
+
+
+ | Name |
+ Description |
+
+
+ | net |
+ The Internet |
+
+
-
Les zones de Shorewall sont définies dans /etc/shorewall/zones.
-
-Shorewall reconnaît aussi le système de firewall comme sa propre zone
-- par défaut, le firewall lui-même est connu en tant que fw.
-
-Les règles concernant le trafic à autoriser ou à interdire sont exprimées
- en utilisant les termes de zones.
-
+Shorewall reconnaît aussi le système de firewall comme sa propre
+zone
+- par défaut, le firewall lui-même est connu en tant que fw.
+Les règles concernant le trafic à autoriser ou à interdire sont
+exprimées en utilisant les termes de zones.
- - Vous exprimez les politiques par défaut pour les connexions d'une
-zone à une autre dans le fichier /etc/shorewall/policy
- .
- - Vous définissez les exceptions à ces règles de politiques par défaut
- dans le fichier /etc/shorewall/rules.
-
+ - Vous exprimez les politiques par défaut pour les connexions d'une
+zone à une autre dans le fichier
+/etc/shorewall/policy .
+ - Vous définissez les exceptions à ces règles de politiques par
+défaut dans le fichier /etc/shorewall/rules.
-
-Pour chacune des demandes de connexion entrantes dans le firewall, les
- demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules.
- Si aucune des règles dans ce fichier ne correspondent, alors la première
-politique dans /etc/shorewall/policy qui y correspond est appliquée. Si cette
-politique est REJECT ou DROP la requête est alors comparée par rapport aux
-règles contenues dans /etc/shorewall/common (l'archive d'exemple vous fournit
+
Pour chacune des demandes de connexion entrantes dans le firewall,
+les demandes sont en premier lieu comparées par rapport au fichier
+/etc/shorewall/rules. Si aucune des règles dans ce fichier ne
+correspondent, alors la première
+politique dans /etc/shorewall/policy qui y correspond est appliquée. Si
+cette
+politique est REJECT ou DROP la requête est alors comparée par rapport
+aux
+règles contenues dans /etc/shorewall/common (l'archive d'exemple vous
+fournit
ce fichier).
-
-Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive one-interface
- a les politiques suivantes :
-
-
+Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive
+one-interface a les politiques suivantes :
+
-
-
- | SOURCE ZONE |
- DESTINATION ZONE |
- POLICY |
- LOG LEVEL |
- LIMIT:BURST |
-
-
- | fw |
- net |
- ACCEPT |
-
- |
-
- |
-
-
- | net |
- all
- |
- DROP |
- info |
-
- |
-
-
- | all |
- all |
- REJECT |
- info |
-
- |
-
-
-
+
+
+ | SOURCE ZONE |
+ DESTINATION ZONE |
+ POLICY |
+ LOG LEVEL |
+ LIMIT:BURST |
+
+
+ | fw |
+ net |
+ ACCEPT |
+
+ |
+
+ |
+
+
+ | net |
+ all
+ |
+ DROP |
+ info |
+
+ |
+
+
+ | all |
+ all |
+ REJECT |
+ info |
+
+ |
+
+
-
-
+
- Ces politiques vont :
+Ces politiques vont :
- - permettre toutes demandes de connexion depuis le firewall vers l'Internet
- - drop (ignorer) toutes les demandes de connexion depuis l'Internet
-vers votre firewall
- - rejeter toutes les autres requêtes de connexion (Shorewall à besoin
- de cette politique).
-
+ - permettre toutes demandes de connexion depuis le firewall vers
+l'Internet
+ - drop (ignorer) toutes les demandes de connexion depuis l'Internet
+vers votre firewall
+ - rejeter toutes les autres requêtes de connexion (Shorewall à
+besoin de cette politique).
-
-A ce point, éditez votre /etc/shorewall/policy et faites y les changements
- que vous désirez.
-
+A ce point, éditez votre /etc/shorewall/policy et faites y les
+changements que vous désirez.
Interface Externe
-
-Le firewall possède une seule interface réseau. Lorsque la
- connexion Internet passe par un modem câble ou par un routeur ADSL (pas
-un simple modem), l'External Interface (interface externe) sera l'adaptateur
- ethernet (eth0) qui y est connecté à moins que vous vous connectiez
- par Point-to-Point Protocol over Ethernet
- (PPPoE) ou Point-to-Point TunnelingProtocol(PPTP)
- dans ce cas l'interface externe sera ppp0. Si vous vous connectez
- par un simple modem (RTC), votre interface externe sera aussi ppp0.
- Si vous vous connectez en utilisant l'ISDN (numéris), votre interface externe
- sera ippp0.
-
+Le firewall possède une seule interface réseau. Lorsque
+la connexion Internet passe par un modem câble ou par un routeur ADSL
+(pas
+un simple modem), l'External Interface (interface externe) sera
+l'adaptateur ethernet (eth0) qui y est connecté à moins que
+vous vous connectiez par Point-to-Point Protocol
+over Ethernet (PPPoE) ou Point-to-Point TunnelingProtocol(PPTP)
+dans ce cas l'interface externe sera ppp0. Si vous vous
+connectez par un simple modem (RTC), votre interface externe sera aussi
+ppp0. Si vous vous connectez en utilisant l'ISDN (numéris),
+votre interface externe sera ippp0.
- L'exemple de configuration de Shorewall pour une interface suppose que
-votre interface externe est eth0. Si votre configuration est différente,
- vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces en conséquence.
- Puisque vous y êtes, vous pourriez parcourir la liste d'options qui sont
- spécifiées pour l'interface. Quelques astuces :
-
+ height="13"> L'exemple de configuration de Shorewall pour une
+interface suppose que votre interface externe est eth0. Si
+votre configuration est différente, vous devrez modifier le fichier
+d'exemple /etc/shorewall/interfaces en conséquence. Puisque vous y
+êtes, vous pourriez parcourir la liste d'options qui sont spécifiées
+pour l'interface. Quelques astuces :
- -
-
Si votre interface externe est ppp0 ou ippp0,
- vous pouvez remplacer le "detect" dans la seconde colonne par un "-".
-
-
- -
-
Si votre interface externe est ppp0 ou ippp0
- ou bien si vous avez une adresse IP statique, vous pouvez enlever le "dhcp"
- de la liste d'option.
-
-
+ -
+
Si votre interface externe est ppp0 ou ippp0,
+vous pouvez remplacer le "detect" dans la seconde colonne par un "-".
+
+ -
+
Si votre interface externe est ppp0 ou ippp0
+ou bien si vous avez une adresse IP statique, vous pouvez enlever le
+"dhcp" de la liste d'option.
+
-
-
+
Adresse IP
-
-
-
-
La RFC 1918 définie plusieurs plage d'adresses IP privée
+
+
+
La RFC 1918 définie plusieurs plage d'adresses IP
+privée
(PrivateIP) pour l'utilisation dans des réseaux privés :
-
-
+
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
-
-
-
Ces adresses sont parfois désignées comme étant non-routables
- car les routeurs sur les backbones Internet ne font pas passer les paquets
- dont les adresses de destinations sont définies dans la RFC 1918. Dans certains
- cas, les fournisseurs (provider ou ISP) utilisent ces adresses et utilisent
- le Network Address Translation afin de récrire les entêtes des paquets
- lorsqu'ils les font circuler depuis ou vers l'Internet.
-
+
+
Ces adresses sont parfois désignées comme étant non-routables
+car les routeurs sur les backbones Internet ne font pas passer les
+paquets dont les adresses de destinations sont définies dans la RFC
+1918. Dans certains cas, les fournisseurs (provider ou ISP) utilisent
+ces adresses et utilisent le Network Address Translation afin
+de récrire les entêtes des paquets lorsqu'ils les font circuler depuis
+ou vers l'Internet.
- Avant de lancer Shorewall, vous devriez regarder l'adresse de votre interface
- externe et si elle est comprise dans une des plages précédentes, vous devriez
- enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.
-
-
-
+ width="13" height="13"> Avant de lancer Shorewall, vous devriez
+regarder l'adresse de votre interface externe et si elle est comprise
+dans une des plages précédentes, vous devriez enlever l'option
+'norfc1918' dans le fichier /etc/shorewall/interfaces.
+
+
Permettre d'autres connexions
-
-
-
-
Si vous désirez autoriser d'autres connexions depuis l'Internet
- vers votre firewall, le format général est :
-
-
-
+
+
Si vous désirez autoriser d'autres connexions depuis
+l'Internet vers votre firewall, le format général est :
+
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- net |
- fw |
- <protocol> |
- <port> |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ <protocol> |
+ <port> |
+
+ |
+
+ |
+
+
-
-
-
-
-
Exemple - Vous voulez faire tourner un serveur Web et un
+
+
+
+
Exemple - Vous voulez faire tourner un serveur Web et
+un
serveur POP3 sur votre système de firewall :
-
-
-
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- net |
- fw |
- tcp |
- 80 |
-
- |
-
- |
-
-
- | ACCEPT |
- net |
- fw |
- tcp |
- 110 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ tcp |
+ 80 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ tcp |
+ 110 |
+
+ |
+
+ |
+
+
-
-
-
-
-
Si vous ne savez pas quel port ou protocole une application
- particulière utilise, regardez ici.
-
-
-
-
Important: Je ne vous recommande pas d'autoriser le
- telnet depuis ou vers l'Internet car il utilise du texte en clair (même
-pour le login et le mot de passe !). Si vous voulez avoir un accès au shell
-de votre firewall depuis Internet, utilisez SSH :
-
-
-
+
+
Si vous ne savez pas quel port ou protocole une
+application particulière utilise, regardez ici.
+
+
+
Important: Je ne vous recommande pas
+d'autoriser le telnet depuis ou vers l'Internet car il utilise du texte
+en clair (même
+pour le login et le mot de passe !). Si vous voulez avoir un accès au
+shell
+de votre firewall depuis Internet, utilisez SSH :
+
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- net |
- fw |
- tcp |
- 22 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ tcp |
+ 22 |
+
+ |
+
+ |
+
+
-
-
-
-
+
+
+
-
-
+
+
- A ce point, éditez /etc/shorewall/rules pour rajouter les autres connexions
- désirées.
-
-
-
+ height="13"> A ce point, éditez /etc/shorewall/rules pour rajouter les
+autres connexions désirées.
+
+
Lancer et Arrêter son Firewall
-
-
-
+
+
- La procédure d'installation configure votre
-système pour lancer Shorewall au boot du système, mais au début avec la version
-1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de lancer Shorewall
- avec que la configuration soit finie. Une fois que vous en aurez fini avec
- la configuration du firewall, vous pouvez permettre le lancement de Shorewall
- en supprimant le fichier /etc/shorewall/startup_disabled.
-
-
-
IMPORTANT: Les utilisateurs
-des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
-
-
-
-
-
Le firewall est activé en utilisant la commande "shorewall
- start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé,
-le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un
- firewall qui tourne peut être relancé en utilisant la commande "shorewall
- restart". Si vous voulez enlever toutes traces de Shorewall sur votre
-configuration de Netfilter, utilisez "shorewall clear".
-
-
-
-
ATTENTION: Si vous êtes connecté à votre firewall
-depuis Internet, n'essayez pas une commande "shorewall stop" tant que vous
-n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle
-vous êtes connectée) dans /etc/shorewall/routestopped.
- De la même manière, je ne vous recommande pas d'utiliser "shorewall restart";
- il est plus intéressant de créer une configuration alternative
- et de la tester en utilisant la commande "shorewall try".
-
-
+ height="13" alt="Arrow"> La
procédure
+d'installation configure votre système pour lancer Shorewall au
+boot du système, mais au début avec la version 1.3.9 de Shorewall le
+lancement est désactivé, n'essayer pas de lancer Shorewall avec que la
+configuration soit finie. Une fois que vous en aurez fini avec la
+configuration du firewall, vous pouvez permettre le lancement de
+Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
+
+
IMPORTANT: Les
+utilisateurs
+des paquets .deb doivent éditer /etc/default/shorewall et mettre
+'startup=1'.
+
+
+
Le firewall est activé en utilisant la commande
+"shorewall start" et arrêté avec "shorewall stop". Lorsque le firewall
+est stoppé,
+le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped.
+Un firewall qui tourne peut être relancé en utilisant la commande
+"shorewall restart". Si vous voulez enlever toutes traces de Shorewall
+sur votre
+configuration de Netfilter, utilisez "shorewall clear".
+
+
ATTENTION: Si vous êtes connecté à votre
+firewall
+depuis Internet, n'essayez pas une commande "shorewall stop" tant que
+vous
+n'avez pas ajouté une entrée pour votre adresse IP (celle à partir de
+laquelle
+vous êtes connectée) dans /etc/shorewall/routestopped.
+De la même manière, je ne vous recommande pas d'utiliser "shorewall
+restart"; il est plus intéressant de créer une configuration alternative
+et de la tester en utilisant la commande "shorewall try".
+
Last updated 12/9/2002 - Tom Eastep
-
-Copyright 2002 Thomas
- M. Eastep
-
-
-
-
-
-
-
-
-
-
+Copyright 2002
+Thomas M. Eastep
+
+
+
+
+
+
+
+
+
+
diff --git a/Shorewall-docs/starting_and_stopping_shorewall.htm b/Shorewall-docs/starting_and_stopping_shorewall.htm
index 061924369..cef5ea24c 100644
--- a/Shorewall-docs/starting_and_stopping_shorewall.htm
+++ b/Shorewall-docs/starting_and_stopping_shorewall.htm
@@ -9,19 +9,12 @@
Starting and Stopping Shorewall
-
-
-
-
- Starting/Stopping and
-Monitoring the Firewall
- |
-
-
-
- If you have a permanent internet connection such as DSL or Cable, I
+
+
Starting/Stopping and Monitoring the Firewall
+
+
+
+If you have a permanent internet connection such as DSL or Cable, I
recommend that you start the firewall automatically at boot. Once you
have installed "firewall" in your init.d directory, simply type
"chkconfig --add firewall". This will start the firewall in run levels
@@ -44,7 +37,7 @@ restart" in that script.
You can manually start and stop Shoreline Firewall using the
"shorewall" shell program. Please refer to the Shorewall
+ href="starting_and_stopping_shorewall.htm#StateDiagram">Shorewall
State Diagram is shown at the bottom of this page.
- shorewall start - starts the firewall
diff --git a/Shorewall-docs/support.htm b/Shorewall-docs/support.htm
index 78b4b75d7..76dd2c49c 100644
--- a/Shorewall-docs/support.htm
+++ b/Shorewall-docs/support.htm
@@ -7,19 +7,11 @@
Shorewall Support Guide
-
-
-
-
- Shorewall Support Guide
-
- |
-
-
-
+Shorewall
+Support Guide
Before Reporting a Problem or Asking a Question
There are a number of sources of Shorewall information. Please try
@@ -29,15 +21,15 @@ these before you post.
- More than half of the questions posted on the support list have
answers directly accessible from the Documentation
+ href="shorewall_quickstart_guide.htm#Documentation">Documentation
Index
- - The FAQ has
+
- The FAQ has
solutions to more than 20 common problems.
- - The Troubleshooting
+
- The Troubleshooting
Information contains a number of tips
to help you solve common problems.
- - The Errata
+
- The Errata
has links to download updated components.
- The Site and Mailing List Archives search facility can locate
documents and posts about similar problems:
@@ -98,6 +90,13 @@ error messages, log entries, command output, and other output is
better than a paraphrase or summary.
+ - Please don't describe your problem as "Computer A can't see
+Computer B". Of course it can't -- it hasn't any eyes! If ping from A
+to B fails, say so (and see below for information about reporting
+'ping' problems). If Computer B doesn't show up in "Network
+Neighborhood" then say so.
+
+
- Please don't describe your environment and then ask us to send
you custom configuration files. We're here to answer your questions but
we can't do your job for you.
@@ -143,7 +142,11 @@ problem is that some type of connection to/from or through your
firewall
isn't working then please perform the following four steps:
-1. /sbin/shorewall reset
+1. If
+shorewall isn't running then /sbin/shorewall/start. Otherwise
+/sbin/shorewall reset.
2. Try making the connection that is failing.
@@ -189,7 +192,7 @@ unless one also knows the policies).
- If an error occurs when you try to "shorewall
start", include a trace (See the Troubleshooting
+ href="troubleshoot.htm">Troubleshooting
section for instructions).
@@ -232,7 +235,10 @@ you can post non MNF-specific Shorewall questions to the . Do not expect to get free MNF support on the list
Otherwise, please post your question or problem to the Shorewall users
-mailing list.
+mailing list. IMPORTANT: If
+you are not subscribed to the list, please say so -- otherwise, you
+will not be included in any replies.
+
Subscribing to the Users Mailing List
@@ -245,7 +251,7 @@ mailing list.
For information on other Shorewall mailing lists, go to http://lists.shorewall.net
-Last Updated 9/17/2003 - Tom Eastep
+Last Updated 11/12/2003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M.
Eastep.
diff --git a/Shorewall-docs/three-interface.htm b/Shorewall-docs/three-interface.htm
index c8cd300d3..50b01becf 100644
--- a/Shorewall-docs/three-interface.htm
+++ b/Shorewall-docs/three-interface.htm
@@ -9,17 +9,8 @@
Three-Interface Firewall
-
-
-
-
- Three-Interface Firewall
- |
-
-
-
+Three-Interface Firewall
+
Setting up a Linux system as a firewall for a small
network with DMZ is a fairly straight-forward task if you understand
the basics and follow the documentation.
@@ -28,7 +19,11 @@ of Shorewall. It rather focuses on what is required to configure
Shorewall in one of its more popular configurations:
- Linux system used as a firewall/router for a small local network.
- - Single public IP address.
+ - Single public IP address. If you have
+more than one public IP address, this is not the guide you want -- see
+the Shorewall Setup Guide
+instead.
+
- DMZ connected to a separate ethernet interface.
- Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up,
...
@@ -128,7 +123,9 @@ file matches the connection request then the first policy in
/etc/shorewall/policy that matches the request is applied. If that
policy is REJECT
or DROP the request is first checked against the rules in
-/etc/shorewall/common (the samples provide that file for you).
+/etc/shorewall/common if that file exists; otherwise the file
+/etc/shorewall/common.def is checked
+
The /etc/shorewall/policy file included with the three-interface
sample has the following policies:
@@ -1064,9 +1061,15 @@ from to /etc/shorewall/routestopped
Also, I don't recommend using "shorewall restart"; it is better to
create an alternate
configuration and test it using the "shorewall try" command.
+ href="starting_and_stopping_shorewall.htm">"shorewall try" command.
+
+Additional Recommended Reading
+I highly recommend that you review the Common Configuration File
+Features page -- it contains helpful tips about Shorewall features
+than make administering your firewall easier.
-Last updated 8/8/2003 - Last updated 11/15/2003 - Tom Eastep
Copyright 2002,
2003 Thomas M. Eastep
diff --git a/Shorewall-docs/three-interface_fr.html b/Shorewall-docs/three-interface_fr.html
index 4a0d35712..4165e7db7 100755
--- a/Shorewall-docs/three-interface_fr.html
+++ b/Shorewall-docs/three-interface_fr.html
@@ -1,1197 +1,1125 @@
-
-
-
-
Three-Interface Firewall
-
-
-
-
-
-
- Three-Interface Firewall
- |
-
-
-
-
-
-Version 2.0.1 Française
-
+
+ Three-Interface Firewall
Notes du traducteur :
- Je ne prétends pas être un vrai traducteur dans le sens ou mon travail
- n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à une
- traduction exacte du texte, mais plutôt à en faire une version française
-intelligible par tous (et par moi). Les termes techniques sont la plupart
-du temps conservés sous leur forme originale et mis entre parenthèses car
-vous pouvez les retrouver dans le reste des documentations ainsi que dans
-les fichiers de configuration. N?hésitez pas à me contacter afin d?améliorer
-ce document VETSEL Patrice
-(merci à JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à
-Tom EASTEP pour son formidable outil et sa disponibilité).
-
+Je ne prétends pas être un vrai traducteur dans le sens ou mon travail
+n?est pas des plus précis (loin de là...). Je ne me suis pas attaché à
+une traduction exacte du texte, mais plutôt à en faire une version
+française intelligible par tous (et par moi). Les termes techniques
+sont la plupart du temps conservés sous leur forme originale et mis
+entre parenthèses car vous pouvez les retrouver dans le reste des
+documentations ainsi que dans les fichiers de configuration. N?hésitez
+pas à me contacter afin d?améliorer ce document VETSEL Patrice (merci à
+JMM pour sa relecture et ses commentaires pertinents, ainsi qu'à Tom
+EASTEP pour son formidable outil et sa disponibilité).
- Mettre en place un système linux en tant que firewall pour un petit
-réseau contenant une DMZ est une chose assez simple à réaliser si vous
-comprenez les bases et suivez cette documentation.
-
-Ce guide ne prétend pas vous mettre au courant de toutes les possibilités
- de Shorewall. Il se focalise sur les besoins pour configurer Shorewall
-dans une de ses utilisations les plus populaire :
-
+Mettre en place un système linux en tant que firewall pour un petit
+réseau contenant une DMZ est une chose assez simple à réaliser si vous
+comprenez les bases et suivez cette documentation.
+Ce guide ne prétend pas vous mettre au courant de toutes les
+possibilités de Shorewall. Il se focalise sur les besoins pour
+configurer Shorewall
+dans une de ses utilisations les plus populaire :
- - Un système Linux utilisé en tant que firewall/routeur pour un
-petit réseau local.
- - Une seule adresse IP publique.
- - Une DMZ connectée sur une interface Ethernet séparée.
- - Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame
-Relay, RTC, ...
-
+ - Un système Linux utilisé en tant que firewall/routeur pour un
+petit réseau local.
+ - Une seule adresse IP publique.
+ - Une DMZ connectée sur une interface Ethernet séparée.
+ - Une connexion passant par l'ADSL, un Modem Câble, ISDN, Frame
+Relay, RTC, ...
-
Voici le schéma d'une installation typique.
-
-
-
-Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé.
-Vous pouvez voir si le paquet est installé en vérifiant la présence du programme
- ip sur votre système de firewall. Sous root, utilisez la commande 'which'
- pour rechercher le programme :
-
+ height="635">
+Ce guide suppose que vous avez le paquet iproute/iproute2
+d'installé.
+Vous pouvez voir si le paquet est installé en vérifiant la présence du
+programme ip sur votre système de firewall. Sous root, utilisez la
+commande 'which' pour rechercher le programme :
[root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
-
-Je vous recommande dans un premier temps de parcourir tout le guide pour
- vous familiariser avec ce qu'il va se passer, et de revenir au début en
-effectuant le changements dans votre configuration. Les points où, les changements
-dans la configuration sont recommandées, sont signalés par une
-
-
-
- Si vous éditez vos fichiers de configuration sur un système Windows,
-vous devez les sauver comme des fichiers Unix si votre éditeur offre cette
-option sinon vous devez les faire passer par dos2unix avant d'essayer de
-les utiliser. De la même manière, si vous copiez un fichier de configuration
-depuis votre disque dur Windows vers une disquette, vous devez lancer dos2unix
-sur la copie avant de l'utiliser avec Shorewall.
-
+Je vous recommande dans un premier temps de parcourir tout le guide
+pour vous familiariser avec ce qu'il va se passer, et de revenir au
+début en
+effectuant le changements dans votre configuration. Les points où, les
+changements
+dans la configuration sont recommandées, sont signalés par une
+ Si
+vous éditez vos fichiers de configuration sur un système Windows, vous
+devez les sauver comme des fichiers Unix si votre éditeur offre cette
+option sinon vous devez les faire passer par dos2unix avant d'essayer
+de les utiliser. De la même manière, si vous copiez un fichier de
+configuration depuis votre disque dur Windows vers une disquette, vous
+devez lancer dos2unix sur la copie avant de l'utiliser avec Shorewall.
-
Les Concepts de Shorewall
-
- Les fichiers de configuration pour Shorewall sont situés dans le répertoire
- /etc/shorewall -- pour de simples paramétrages, vous n'avez à faire qu'avec
- quelques un d'entre eux comme décris dans ce guide. Après avoir installé Shorewall, téléchargez la configuration
- d'exemple three-interface
- sample, un-tarez la (tar -zxvf three-interfaces.tgz) et copiez
- les fichiers vers /etc/shorewall (Ils remplaceront les fichiers de même
- nom déjà existant dans /etc/shorewall installés lors de l'installation de
- Shorewall).
-
-En même temps que chacun des fichiers est présenté, je vous suggère de
- jeter un oeil à ceux qui se trouvent réellement sur votre système -- chacun
- des fichiers contient des instructions de configuration détaillées et des
- entrées par défaut.
-
-Shorewall voit le réseau où il tourne comme composé par un ensemble de
- zones. Dans les fichiers de configuration fournis pour trois interfaces,
- trois zones sont définies :
-
+ alt=""> Les fichiers de configuration pour Shorewall sont situés dans
+le répertoire /etc/shorewall -- pour de simples paramétrages, vous
+n'avez à faire qu'avec quelques un d'entre eux comme décris dans ce
+guide. Après avoir installé Shorewall, téléchargez
+la configuration d'exemple three-interface
+sample, un-tarez la (tar -zxvf three-interfaces.tgz) et
+copiez les fichiers vers /etc/shorewall (Ils remplaceront les fichiers
+de même nom déjà existant dans /etc/shorewall installés lors de
+l'installation de Shorewall).
+En même temps que chacun des fichiers est présenté, je vous suggère
+de jeter un oeil à ceux qui se trouvent réellement sur votre système --
+chacun des fichiers contient des instructions de configuration
+détaillées et des entrées par défaut.
+Shorewall voit le réseau où il tourne comme composé par un ensemble
+de zones. Dans les fichiers de configuration fournis pour trois
+interfaces, trois zones sont définies :
-
-
- | Name |
- Description |
-
-
- | net |
- The Internet |
-
-
- | loc |
- Votre réseau local |
-
-
- | dmz |
- Zone Demilitarisée |
-
-
-
+
+
+ | Name |
+ Description |
+
+
+ | net |
+ The Internet |
+
+
+ | loc |
+ Votre réseau local |
+
+
+ | dmz |
+ Zone Demilitarisée |
+
+
-
Les noms de zone sont définis dans /etc/shorewall/zones.
-
-Shorewall reconnaît aussi le système de firewall comme sa propre zone
-- par défaut, le firewall lui même est connu en tant que fw.
-
-Les règles concernant le trafic à autoriser ou à interdire sont exprimées
- en utilisant les termes de zones.
-
+Shorewall reconnaît aussi le système de firewall comme sa propre
+zone
+- par défaut, le firewall lui même est connu en tant que fw.
+Les règles concernant le trafic à autoriser ou à interdire sont
+exprimées en utilisant les termes de zones.
- - Vous exprimez les politiques par défaut pour les connexions d'une
- zone à une autre dans le fichier /etc/shorewall/policy
- .
- - Vous définissez les exceptions à ces règles de politiques par
-défaut dans le fichier /etc/shorewall/rules.
-
+ - Vous exprimez les politiques par défaut pour les connexions d'une
+zone à une autre dans le fichier
+/etc/shorewall/policy .
+ - Vous définissez les exceptions à ces règles de politiques par
+défaut dans le fichier /etc/shorewall/rules.
-
-Pour chacune des demandes de connexion entrantes dans le firewall, les
- demandes sont en premier lieu comparées par rapport au fichier /etc/shorewall/rules.
- Si aucune des règles dans ce fichier ne correspondent, alors la première
- politique dans /etc/shorewall/policy qui y correspond est appliquée. Si
-cette politique est REJECT ou DROP la requête est alors comparée par rapport
-aux règles contenues dans /etc/shorewall/common (l'archive d'exemple vous
-fournit ce fichier).
-
-Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive three-interface
- sample a les politiques suivantes :
-
-
+Pour chacune des demandes de connexion entrantes dans le firewall,
+les demandes sont en premier lieu comparées par rapport au fichier
+/etc/shorewall/rules. Si aucune des règles dans ce fichier ne
+correspondent, alors la première politique dans /etc/shorewall/policy
+qui y correspond est appliquée. Si
+cette politique est REJECT ou DROP la requête est alors comparée par
+rapport
+aux règles contenues dans /etc/shorewall/common (l'archive d'exemple
+vous
+fournit ce fichier).
+Le fichier /etc/shorewall/policy d'exemple contenu dans l'archive
+three-interface sample a les politiques suivantes :
+
-
-
- | Source Zone |
- Destination Zone |
- Policy |
- Log Level |
- Limit:Burst |
-
-
- | loc |
- net |
- ACCEPT |
-
- |
-
- |
-
-
- | net |
- all |
- DROP |
- info |
-
- |
-
-
- | all |
- all |
- REJECT |
- info |
-
- |
-
-
-
+
+
+ | Source Zone |
+ Destination Zone |
+ Policy |
+ Log Level |
+ Limit:Burst |
+
+
+ | loc |
+ net |
+ ACCEPT |
+
+ |
+
+ |
+
+
+ | net |
+ all |
+ DROP |
+ info |
+
+ |
+
+
+ | all |
+ all |
+ REJECT |
+ info |
+
+ |
+
+
-
-
-
- Dans l'archive three-interface, la ligne suivante est existante mais
- elle est commentée. Si vous souhaitez que votre système de firewall puisse
- avoir un accès complet aux serveurs sur Internet, décommentez la.
-
+
+
+ Dans l'archive three-interface, la ligne suivante est existante
+mais elle est commentée. Si vous souhaitez que votre système de
+firewall puisse avoir un accès complet aux serveurs sur Internet,
+décommentez la.
-
-
- | Source Zone |
- Destination Zone |
- Policy |
- Log Level |
- Limit:Burst |
-
-
- | fw |
- net |
- ACCEPT |
-
- |
-
- |
-
-
-
+
+
+ | Source Zone |
+ Destination Zone |
+ Policy |
+ Log Level |
+ Limit:Burst |
+
+
+ | fw |
+ net |
+ ACCEPT |
+
+ |
+
+ |
+
+
-
-
+
Les politiques précédentes vont :
-
- - permettre toutes demandes de connexion depuis le firewall vers
+
- permettre toutes demandes de connexion depuis le firewall vers
l'Internet
- - drop (ignorer) toutes les demandes de connexion depuis l'Internet
- vers votre firewall ou vers votre réseau local
- - Facultativement accepter toutes les demandes de connexion depuis
- votre firewall et vers Internet (si vous decommentez la politique précédente)
- - reject (rejeter) toutes les autres demandes de connexion.
-
+ - drop (ignorer) toutes les demandes de connexion depuis l'Internet
+vers votre firewall ou vers votre réseau local
+ - Facultativement accepter toutes les demandes de connexion depuis
+votre firewall et vers Internet (si vous decommentez la politique
+précédente)
+ - reject (rejeter) toutes les autres demandes de connexion.
-
-
- A ce point, éditez votre /etc/shorewall/policy et faites y les changements
- que vous désire
-
+ A
+ce point, éditez votre /etc/shorewall/policy et faites y les
+changements que vous désire
Les Interfaces Réseau
-
-
-
-Le firewall a trois interfaces de réseau. Lorsque la connexion
- Internet passe par le câble ou par un ROUTEUR (pas un simple modem) ADSL
- (non USB), l'interface vers l'extérieur (External Interface) sera l'adaptateur
- sur lequel est connecté le routeur (e.g., eth0) à moins que vous ne vous
- connectiez par Point-to-PointProtocol overEthernet (PPPoE) ou par Point-to-PointTunneling
- Protocol (PPTP), dans ce cas l'interface extérieure sera une interface
-de type ppp (e.g., ppp0). Si vous vous connectez par un simple modem (RTC),
- votre interface extérieure sera aussi ppp0. Si votre connexion passe par
+ height="635">
+Le firewall a trois interfaces de réseau. Lorsque la
+connexion Internet passe par le câble ou par un ROUTEUR (pas un simple
+modem) ADSL (non USB), l'interface vers l'extérieur (External
+Interface) sera l'adaptateur sur lequel est connecté le routeur (e.g.,
+eth0) à moins que vous ne vous connectiez par Point-to-PointProtocol
+overEthernet (PPPoE) ou par Point-to-PointTunneling Protocol (PPTP),
+dans ce cas l'interface extérieure sera une interface
+de type ppp (e.g., ppp0). Si vous vous connectez par un simple modem
+(RTC), votre interface extérieure sera aussi ppp0. Si votre connexion
+passe par
Numéris (ISDN), votre interface extérieure sera ippp0.
-
- Si votre interface vers l'extérieur est ppp0 ou ippp0 alors vous mettrez
- CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.
-
-Votre Interface locale sera un adaptateur Ethernet
- (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos
-ordinateurs locaux seront connectés à ce même switch (note : si vous n'avez
-qu'un seul ordinateur en local, vous pouvez le connecter directement au
-firewall par un câble croisé).
-
-Votre interface DMZ sera aussi un adaptateur Ethernet
- (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch. Vos ordinateurs
- appartenant à la DMZ seront connectés à ce même switch (note : si vous
-n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter directement
-au firewall par un câble croisé).
-
+ height="13"> Si votre interface vers l'extérieur est ppp0 ou ippp0
+alors vous mettrez CLAMPMSS=yes dans
+/etc/shorewall/shorewall.conf.
+Votre Interface locale sera un adaptateur
+Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch.
+Vos
+ordinateurs locaux seront connectés à ce même switch (note : si vous
+n'avez
+qu'un seul ordinateur en local, vous pouvez le connecter directement au
+firewall par un câble croisé).
+Votre interface DMZ sera aussi un adaptateur
+Ethernet (eth0, eth1 ou eth2) et sera connecté à un hub ou un switch.
+Vos ordinateurs appartenant à la DMZ seront connectés à ce même switch
+(note : si vous
+n'avez qu'un seul ordinateur dans la DMZ, vous pouvez le connecter
+directement
+au firewall par un câble croisé).
- Ne connectez pas l'interface interne et externe sur le même
-hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez
-pas que ce soit shorewall qui ne marche pas.
-
+ width="60" height="60"> Ne connectez pas l'interface interne
+et externe sur le même
+hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez
+pas que ce soit shorewall qui ne marche pas.
- L'exemple de configuration de Shorewall pour trois interfaces suppose
- que l'interface externe est eth0, l'interface locale est eth1
- et que la DMZ est sur l'interface eth2. Si votre configuration
-diffère, vous devrez modifier le fichier d'exemple /etc/shorewall/interfaces
-en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste des
-options qui sont spécifiées pour les interfaces. Quelques trucs :
-
+ height="13"> L'exemple de configuration de Shorewall pour trois
+interfaces suppose que l'interface externe est eth0, l'interface
+locale est eth1
+ et que la DMZ est sur l'interface eth2. Si votre
+configuration
+diffère, vous devrez modifier le fichier d'exemple
+/etc/shorewall/interfaces
+en conséquence. Tant que vous y êtes, vous pourriez parcourir la liste
+des
+options qui sont spécifiées pour les interfaces. Quelques trucs :
- -
-
Si votre interface externe est ppp0 ou ippp0, vous pouvez
- remplacer le "detect" dans la seconde colonne par un "-".
-
- -
-
Si votre interface externe est ppp0 ou ippp0 ou bien
-si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de la
+
-
+
Si votre interface externe est ppp0 ou ippp0, vous
+pouvez remplacer le "detect" dans la seconde colonne par un "-".
+
+ -
+
Si votre interface externe est ppp0 ou ippp0 ou
+bien
+si vous avez une adresse IP statique, vous pouvez enlever le "dhcp" de
+la
liste d'option.
-
-
+
-
Adresses IP
-
-Avant d'aller plus loin, nous devons dire quelques mots au
- sujet du Protocole d'adresse Internet (IP). Normalement, votre fournisseur
- Internet (ISP) vous assignera une seule adresse IP (single Public IP address).
- Cette adresse peut être assignée par le Dynamic Host Configuration Protocol
- (DHCP) ou lors de l'établissement de votre connexion lorsque vous vous
-connectez (modem standard) ou établissez votre connexion PPP. Dans de rares
-cas , votre provider peu vous assigner une adresse statique (staticIP address);
-cela signifie que vous configurez votre interface externe sur votre firewall
-afin d'utiliser cette adresse de manière permanente. Une fois votre adresse
-externe assignée, elle va être partagée par tout vos systèmes lors de l'accès
-à Internet. Vous devrez assigner vos propres adresses à votre réseau local
-(votre interface interne sur le firewall ainsi que les autres ordinateurs).
-La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à
+
Avant d'aller plus loin, nous devons dire quelques mots
+au sujet du Protocole d'adresse Internet (IP). Normalement, votre
+fournisseur Internet (ISP) vous assignera une seule adresse IP (single
+Public IP address). Cette adresse peut être assignée par le Dynamic
+Host Configuration Protocol (DHCP) ou lors de l'établissement de votre
+connexion lorsque vous vous
+connectez (modem standard) ou établissez votre connexion PPP. Dans de
+rares
+cas , votre provider peu vous assigner une adresse statique (staticIP
+address);
+cela signifie que vous configurez votre interface externe sur votre
+firewall
+afin d'utiliser cette adresse de manière permanente. Une fois votre
+adresse
+externe assignée, elle va être partagée par tout vos systèmes lors de
+l'accès
+à Internet. Vous devrez assigner vos propres adresses à votre réseau
+local
+(votre interface interne sur le firewall ainsi que les autres
+ordinateurs).
+La RFC 1918 réserve plusieurs plages d'IP (Private IP address ranges) à
cette fin :
-
-
+
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
-
-
-
+
+
- Avant de lancer Shorewall, vous devriez regarder l'adresse de votre
-interface externe et si elle est comprise dans une des plages précédentes,
-vous devriez enlever l'option 'norfc1918' dans le fichier /etc/shorewall/interfaces.
-
-
-
-
Vous devrez assigner les adresses locales à un sous-réseau
- (sub-network ou subnet) et les adresse pour la DMZ à un autre
- sous-réseau. Pour ce faire, nous pouvons considérer qu'un sous-réseau consiste
- en une plage d'adresse x.y.z.0 à x.y.z.255. Chacun des sous-réseaux possèdera
- une masque (Subnet Mask) de 255.255.255.0. L'adresse x.y.z.0
-est réservée comme l'adresse du sous-réseau (Subnet Address)
-et x.y.z.255 est réservée en tant qu'adresse de broadcast du sous-réseau
-(Subnet Broadcast Address). Sous Shorewall, un sous-réseau
-est décrit/désigné en utilisant la notation Classless InterDomain Routing(CIDR)
-qui consiste en l'adresse du sous-réseau suivie par "/24". Le "24" se réfère
-au nombre de bits "1" consécutifs dans la partie gauche du masque de sous-réseau.
+ height="13"> Avant de lancer Shorewall, vous devriez regarder
+l'adresse de votre
+interface externe et si elle est comprise dans une des plages
+précédentes,
+vous devriez enlever l'option 'norfc1918' dans le fichier
+/etc/shorewall/interfaces.
+
+
+
Vous devrez assigner les adresses locales à un
+sous-réseau (sub-network ou subnet) et les adresse pour
+la DMZ à un autre sous-réseau. Pour ce faire, nous pouvons considérer
+qu'un sous-réseau consiste en une plage d'adresse x.y.z.0 à x.y.z.255.
+Chacun des sous-réseaux possèdera une masque (Subnet Mask) de
+255.255.255.0. L'adresse x.y.z.0
+est réservée comme l'adresse du sous-réseau (Subnet Address)
+et x.y.z.255 est réservée en tant qu'adresse de broadcast du
+sous-réseau
+(Subnet Broadcast Address). Sous Shorewall, un
+sous-réseau
+est décrit/désigné en utilisant la notation Classless InterDomain
+Routing(CIDR)
+qui consiste en l'adresse du sous-réseau suivie par "/24". Le "24" se
+réfère
+au nombre de bits "1" consécutifs dans la partie gauche du masque de
+sous-réseau.
-
-
-
+
+
Exemple de sous-réseau (subnet) :
-
-
-
+
+
-
-
- | Plage: |
- 10.10.10.0 - 10.10.10.255 |
-
-
- | Subnet Address: |
- 10.10.10.0 |
-
-
- | Broadcast Address: |
- 10.10.10.255 |
-
-
- | CIDR Notation: |
- 10.10.10.0/24 |
-
-
-
+
+
+ | Plage: |
+ 10.10.10.0 - 10.10.10.255 |
+
+
+ | Subnet Address: |
+ 10.10.10.0 |
+
+
+ | Broadcast Address: |
+ 10.10.10.255 |
+
+
+ | CIDR Notation: |
+ 10.10.10.0/24 |
+
+
-
-
-
-
-
Il est de convention d'assigner à l'interface interne la
-première adresse utilisable dans le sous-réseau (10.10.10.1 dans l'exemple
-précédent) ou la dernière utilisable (10.10.10.254).
-
-
-
-
L'un des buts d'un sous-réseau est de permettre à tous les
- ordinateurs dans le sous-réseau de savoir avec quels autres ordinateurs
-ils peuvent communiquer directement. Pour communiquer avec des systèmes
-en dehors du sous-réseau, les ordinateurs envoient des paquets à travers
-le gateway (routeur).
-
-
-
+
+
+
+
Il est de convention d'assigner à l'interface interne
+la
+première adresse utilisable dans le sous-réseau (10.10.10.1 dans
+l'exemple
+précédent) ou la dernière utilisable (10.10.10.254).
+
+
+
L'un des buts d'un sous-réseau est de permettre à tous
+les ordinateurs dans le sous-réseau de savoir avec quels autres
+ordinateurs
+ils peuvent communiquer directement. Pour communiquer avec des systèmes
+en dehors du sous-réseau, les ordinateurs envoient des paquets à
+travers
+le gateway (routeur).
+
+
- Vos ordinateurs locaux (ordinateur local 1 et 2) devraient être configurés
- avec leur passerelle par défaut (default gateway)pointant sur l'adresse
- IP de l'interface interne du firewall, et les ordinateurs de la DMZ devraient
- être configurés avec leur passerelle par défaut (default gateway)
- pointant sur l'adresse IP de l'interface DMZ du firewall.
-
-
-
Cette courte description ne fait que survoler les concepts
- de routage et de sous-réseau. Si vous vous voulez en apprendre plus sur
-l'adressage IP et le routage, je vous recommande chaudement "IP Fundamentals:
- What Everyone Needs to Know about Addressing & Routing", Thomas
- A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
-
-
Pour rappel, ce guide supposera que vous avez configuré votre
- réseau comme montrer ci-dessous :
-
+ height="13"> Vos ordinateurs locaux (ordinateur local 1 et 2)
+devraient être configurés avec leur passerelle par défaut (
default
+gateway)pointant sur l'adresse IP de l'interface interne du
+firewall, et les ordinateurs de la DMZ devraient être configurés avec
+leur passerelle par défaut (
default gateway) pointant sur
+l'adresse IP de l'interface DMZ du firewall.
+
Cette courte description ne fait que survoler les
+concepts de routage et de sous-réseau. Si vous vous voulez en apprendre
+plus sur
+l'adressage IP et le routage, je vous recommande chaudement "IP
+Fundamentals: What Everyone Needs to Know about Addressing &
+Routing", Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
+Pour rappel, ce guide supposera que vous avez configuré
+votre réseau comme montrer ci-dessous :
-
-
-La passerelle par défaut (default gateway) pour les ordinateurs
- de la DMZ sera 10.10.11.254 et le passerelle par défaut pour les
-ordinateurs en local sera 10.10.10.254.
-
+ height="635">
+La passerelle par défaut (default gateway) pour les
+ordinateurs de la DMZ sera 10.10.11.254 et le passerelle par défaut
+pour les
+ordinateurs en local sera 10.10.10.254.
IP Masquerading (SNAT)
-
-Les adresses réservées par la RFC 1918 sont parfois désignées
- comme non-routables car les routeurs Internet (backbone) ne font pas circuler
- les paquets qui ont une adresse de destination appartenant à la RFC-1918.
- Lorsqu'un de vos systèmes en local (supposons l'ordinateur1) demande une
- connexion à un serveur par Internet, le firewall doit appliquer un NAT (Network
- Address Translation). Le firewall ré écrit l'adresse source dans le paquet,
- et l'a remplace par l'adresse de l'interface externe du firewall; en d'autres
- mots, le firewall fait croire que c'est lui même qui initie la connexion.
- Ceci est nécessaire afin que l'hôte de destination soit capable de renvoyer
- les paquets au firewall (souvenez vous que les paquets qui ont pour adresse
- de destination, une adresse réservée par la RFC 1918 ne pourront pas être
- routés à travers Internet, donc l'hôte Internet ne pourra adresser sa réponse
- à l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse, il remet
- l'adresse de destination à 10.10.10.1 et fait passer le paquet vers l'ordinateur
- 1.
-
-Sur les systèmes Linux, ce procédé est souvent appelé de
-l'IP Masquerading mais vous verrez aussi le terme de Source Network Address
-Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec Netfilter
+
Les adresses réservées par la RFC 1918 sont parfois
+désignées comme non-routables car les routeurs Internet (backbone) ne
+font pas circuler les paquets qui ont une adresse de destination
+appartenant à la RFC-1918. Lorsqu'un de vos systèmes en local
+(supposons l'ordinateur1) demande une connexion à un serveur par
+Internet, le firewall doit appliquer un NAT (Network Address
+Translation). Le firewall ré écrit l'adresse source dans le paquet, et
+l'a remplace par l'adresse de l'interface externe du firewall; en
+d'autres mots, le firewall fait croire que c'est lui même qui initie la
+connexion. Ceci est nécessaire afin que l'hôte de destination soit
+capable de renvoyer les paquets au firewall (souvenez vous que les
+paquets qui ont pour adresse de destination, une adresse réservée par
+la RFC 1918 ne pourront pas être routés à travers Internet, donc l'hôte
+Internet ne pourra adresser sa réponse à l'ordinateur 1). Lorsque le
+firewall reçoit le paquet de réponse, il remet l'adresse de destination
+à 10.10.10.1 et fait passer le paquet vers l'ordinateur 1.
+Sur les systèmes Linux, ce procédé est souvent appelé
+de
+l'IP Masquerading mais vous verrez aussi le terme de Source Network
+Address
+Translation (SNAT) utilisé. Shorewall suit la convention utilisée avec
+Netfilter
:
-
- -
-
Masquerade désigne le cas ou vous laissez votre firewall
- détecter automatiquement l'adresse de l'interface externe.
-
- -
-
SNAT désigne le cas où vous spécifiez explicitement l'adresse
- source des paquets sortant de votre réseau local.
-
-
+ -
+
Masquerade désigne le cas ou vous laissez votre
+firewall détecter automatiquement l'adresse de l'interface externe.
+
+ -
+
SNAT désigne le cas où vous spécifiez explicitement
+l'adresse source des paquets sortant de votre réseau local.
+
-
-Sous Shorewall, autant le Masquerading que le SNAT sont configuré
- avec des entrés dans le fichier /etc/shorewall/masq.
-
+Sous Shorewall, autant le Masquerading que le SNAT sont
+configuré avec des entrés dans le fichier /etc/shorewall/masq.
- Si votre interface externe est eth0, votre interface locale eth1
- et votre interface pour la DMZ eth2 vous n'avez pas besoin de modifier
- le fichier fourni avec l'exemple. Dans le cas contraire, éditez /etc/shorewall/masq
- et changez le en conséquence.
-
+ height="13"> Si votre interface externe est eth0, votre
+interface locale eth1 et votre interface pour la DMZ eth2
+vous n'avez pas besoin de modifier le fichier fourni avec l'exemple.
+Dans le cas contraire, éditez /etc/shorewall/masq et changez le en
+conséquence.
- Si votre IP externe est statique, vous pouvez la mettre dans la troisième
- colonne dans /etc/shorewall/masq si vous le désirez, de toutes façons votre
- firewall fonctionnera bien si vous laissez cette colonne vide. Le fait
-de mettre votre IP statique dans la troisième colonne permet un traitement
-des paquets sortant un peu plus efficace.
-
-
+ height="13"> Si votre IP externe est statique, vous pouvez la mettre
+dans la troisième colonne dans /etc/shorewall/masq si vous le désirez,
+de toutes façons votre firewall fonctionnera bien si vous laissez cette
+colonne vide. Le fait
+de mettre votre IP statique dans la troisième colonne permet un
+traitement
+des paquets sortant un peu plus efficace.
+
- Si vous utilisez les paquets Debian, vérifiez que votre fichier de configuration
- shorewall.conf contient bien les valeurs suivantes, si elles n'y sont pas
- faite les changements nécessaires :
-
-
+ height="13" alt=""> Si vous utilisez les paquets Debian, vérifiez que
+votre fichier de configuration shorewall.conf contient bien les valeurs
+suivantes, si elles n'y sont pas faite les changements nécessaires :
+
- - NAT_ENABLED=Yes
- - IP_FORWARDING=On
-
-
+ - NAT_ENABLED=Yes
+ - IP_FORWARDING=On
+
-
Port Forwarding (DNAT)
-
-Un de nos buts est de, peut être, faire tourner un ou plusieurs
- serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs on une adresse
- RFC-1918, il n'est pas possible pour les clients sur Internet de se connecter
- directement à eux. Il est nécessaire à ces clients d'adresser leurs demandes
- de connexion au firewall qui ré écrit l'adresse de destination de votre
-serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur répond,
-le firewall applique automatiquement un SNAT pour ré écrire l'adresse source
+
Un de nos buts est de, peut être, faire tourner un ou
+plusieurs serveurs sur nos ordinateurs dans la DMZ. que ces ordinateurs
+on une adresse RFC-1918, il n'est pas possible pour les clients sur
+Internet de se connecter directement à eux. Il est nécessaire à ces
+clients d'adresser leurs demandes de connexion au firewall qui ré écrit
+l'adresse de destination de votre
+serveur, et fait passer le paquet à celui-ci. Lorsque votre serveur
+répond,
+le firewall applique automatiquement un SNAT pour ré écrire l'adresse
+source
dans la réponse.
-
-Ce procédé est appelé Port Forwarding ou Destination Network
- Address Translation(DNAT). Vous configurez le port forwarding en utilisant
- les règles DNAT dans le fichier /etc/shorewall/rules.
-
-La forme générale d'une simple règle de port forwarding dans /etc/shorewall/rules
- est :
-
-
+Ce procédé est appelé Port Forwarding ou Destination
+Network Address Translation(DNAT). Vous configurez le port forwarding
+en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.
+La forme générale d'une simple règle de port forwarding dans
+/etc/shorewall/rules est :
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | DNAT |
- net |
- dmz:<server local ip address> [:<server
- port>] |
- <protocol> |
- <port> |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | DNAT |
+ net |
+ dmz:<server local ip address> [:<server
+port>] |
+ <protocol> |
+ <port> |
+
+ |
+
+ |
+
+
-
-
-Si vous ne spécifiez pas le <server port>, il est supposé
- être le même que <port>.
-
-Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et vous
- voulez faire passer les paquets entrant en TCP sur le port 80 à ce système
- :
-
-
+
+Si vous ne spécifiez pas le <server port>, il est
+supposé être le même que <port>.
+Exemple - vous faites tourner un serveur Web dans votre DMZ (2) et
+vous voulez faire passer les paquets entrant en TCP sur le port 80 à ce
+système :
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | DNAT |
- net |
- dmz:10.10.11.2 |
- tcp |
- 80 |
- # Fait suivre le port 80 |
- depuis Internet |
-
-
- | ACCEPT |
- loc |
- dmz:10.10.11.2 |
- tcp |
- 80 |
- #Permet les connexions |
- depuis le réseau local |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | DNAT |
+ net |
+ dmz:10.10.11.2 |
+ tcp |
+ 80 |
+ # Fait suivre le port 80 |
+ depuis Internet |
+
+
+ | ACCEPT |
+ loc |
+ dmz:10.10.11.2 |
+ tcp |
+ 80 |
+ #Permet les connexions |
+ depuis le réseau local |
+
+
-
-
+
Deux points importants à garder en mémoire :
-
- - Lorsque vous vous connectez à votre serveur à partir de votre
-réseau local, vous devez utiliser l'adresse IP interne du serveur (10.10.11.2).
- - Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes
- de connexion entrantes sur le port 80. Si vous avez des problèmes pour
-vous connecter à votre serveur web, essayez la règle suivante et connectez
-vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est votre
- IP externe).
-
+ - Lorsque vous vous connectez à votre serveur à partir de votre
+réseau local, vous devez utiliser l'adresse IP interne du serveur
+(10.10.11.2).
+ - Quelques fournisseurs Internet (Provider/ISP) bloquent les
+requêtes de connexion entrantes sur le port 80. Si vous avez des
+problèmes pour
+vous connecter à votre serveur web, essayez la règle suivante et
+connectez
+vous sur le port 5000 (c.a.d., connectez vous à http://w.x.y.z:5000 où w.x.y.z est
+votre IP externe).
-
-
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | DNAT |
- net |
- dmz:10.10.11.2:80 |
- tcp |
- 5000 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | DNAT |
+ net |
+ dmz:10.10.11.2:80 |
+ tcp |
+ 5000 |
+
+ |
+
+ |
+
+
-
-
-Si vous voulez avoir la possibilité de vous connecter à votre serveur
-depuis le réseau local en utilisant votre adresse externe, et si vous avez
-une adresse IP externe statique (fixe), vous pouvez remplacer la règle loc->dmz
+
+Si vous voulez avoir la possibilité de vous connecter à votre
+serveur
+depuis le réseau local en utilisant votre adresse externe, et si vous
+avez
+une adresse IP externe statique (fixe), vous pouvez remplacer la règle
+loc->dmz
précédente par :
-
-
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | DNAT |
- net |
- dmz:10.10.11.2:80 |
- tcp |
- 80 |
- - |
- <external IP> |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | DNAT |
+ net |
+ dmz:10.10.11.2:80 |
+ tcp |
+ 80 |
+ - |
+ <external IP> |
+
+
-
-
-Si vous avez une IP dynamique, alors vous devez vous assurer que votre
- interface externe est en route avant de lancer Shorewall et vous devez
-suivre les étapes suivantes (en supposant que votre interface externe est
-eth0) :
-
+
+Si vous avez une IP dynamique, alors vous devez vous assurer que
+votre interface externe est en route avant de lancer Shorewall et vous
+devez
+suivre les étapes suivantes (en supposant que votre interface externe
+est
+eth0) :
- - Insérez ce qui suit dans /etc/shorewall/params :
-
- ETH0_IP=`find_interface_address eth0`
-
- - Faites votre règle loc->dmz :
-
+ - Insérez ce qui suit dans /etc/shorewall/params :
+
+ETH0_IP=`find_interface_address eth0`
+
+ - Faites votre règle loc->dmz :
-
-
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | DNAT |
- loc
- |
- dmz:10.10.11.2:80 |
- tcp |
- 80 |
- - |
- $ETH0_IP |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | DNAT |
+ loc
+ |
+ dmz:10.10.11.2:80 |
+ tcp |
+ 80 |
+ - |
+ $ETH0_IP |
+
+
-
-
-Si vous voulez accéder à votre serveur dans la DMZ en utilisant votre
+
+Si vous voulez accéder à votre serveur dans la DMZ en utilisant
+votre
adresse IP externe, regardez FAQ 2a.
-
-
- A ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..
-
+ A
+ce point, ajoutez les règles DNAT et ACCEPT pour vos serveurs..
Domain Name Server (DNS)
-
-Normalement, quand vous vous connectez à votre fournisseur
- (ISP), une partie consiste à obtenir votre adresse IP, votre DNS pour le
- firewall (Domain Name Service) est configuré automatiquement (c.a.d., le
-fichier /etc/resolv.conf a été écrit). Il arrive que votre provider vous
-donne une paire d'adresse IP pour les DNS (name servers) afin que vous configuriez
-manuellement votre serveur de nom primaire et secondaire. La manière dont
-le DNS est configuré sur votre firewall est de votre responsabilité. Vous
+
Normalement, quand vous vous connectez à votre
+fournisseur (ISP), une partie consiste à obtenir votre adresse IP,
+votre DNS pour le firewall (Domain Name Service) est configuré
+automatiquement (c.a.d., le
+fichier /etc/resolv.conf a été écrit). Il arrive que votre provider
+vous
+donne une paire d'adresse IP pour les DNS (name servers) afin que vous
+configuriez
+manuellement votre serveur de nom primaire et secondaire. La manière
+dont
+le DNS est configuré sur votre firewall est de votre responsabilité.
+Vous
pouvez procéder d'une de ses deux façons :
-
- -
-
Vous pouvez configurer votre système interne pour utiliser
- les noms de serveurs de votre provider. Si votre fournisseur vous donne
-les adresses de leurs serveurs ou si ces adresses sont disponibles sur leur
-site web, vous pouvez configurer votre système interne afin de les utiliser.
-Si cette information n'est pas disponible, regardez dans /etc/resolv.conf
-sur votre firewall -- les noms des serveurs sont donnés dans l'enregistrement
- "nameserver" dans ce fichier.
-
- -
+
-
+
Vous pouvez configurer votre système interne pour
+utiliser les noms de serveurs de votre provider. Si votre fournisseur
+vous donne
+les adresses de leurs serveurs ou si ces adresses sont disponibles sur
+leur
+site web, vous pouvez configurer votre système interne afin de les
+utiliser.
+Si cette information n'est pas disponible, regardez dans
+/etc/resolv.conf
+sur votre firewall -- les noms des serveurs sont donnés dans
+l'enregistrement "nameserver" dans ce fichier.
+
+ -
- Vous pouvez installer/configurer un cache dns (Caching Name Server)
-sur votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre
-en cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour
-les utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette
-approche, vous configurez votre système interne pour utiliser le firewall
-lui même comme étant le seul serveur de nom primaire. Vous pouvez utiliser
-l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) pour l'adresse
-de serveur de nom si vous décidez de faire tourner le serveur de nom sur
-votre firewall. Pour permettre à vos systèmes locaux de discuter avec votre
-serveur cache de nom, vous devez ouvrir le port 53 (UDP ET TCP) sur le
-firewall vers le réseau local; vous ferez ceci en ajoutant les règles suivantes
-dans /etc/shorewall/rules.
-
-
+ width="13" height="13"> Vous pouvez installer/configurer un cache dns
+(Caching Name Server)
+sur votre firewall ou dans la DMZ. Red Hat a un RPM pour mettre
+en cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour
+les utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette
+approche, vous configurez votre système interne pour utiliser le
+firewall
+lui même comme étant le seul serveur de nom primaire. Vous pouvez
+utiliser
+l'adresse IP interne du firewall (10.10.10.254 dans l'exemple) pour
+l'adresse
+de serveur de nom si vous décidez de faire tourner le serveur de nom
+sur
+votre firewall. Pour permettre à vos systèmes locaux de discuter avec
+votre
+serveur cache de nom, vous devez ouvrir le port 53 (UDP ET TCP)
+sur le
+firewall vers le réseau local; vous ferez ceci en ajoutant les règles
+suivantes
+dans /etc/shorewall/rules.
+
-
-
- Si vous faites tourner le serveur de nom sur le firewall
- :
+
+ Si vous faites tourner le serveur de nom sur le
+firewall :
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- loc |
- fw |
- tcp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- loc |
- fw |
- udp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- dmz |
- fw |
- tcp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- dmz |
- fw |
- udp |
- 53 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ tcp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ udp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ dmz |
+ fw |
+ tcp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ dmz |
+ fw |
+ udp |
+ 53 |
+
+ |
+
+ |
+
+
-
-
-
-
-
+
+
+
+
Le serveur de nom tourne sur l'ordinateur 1 de la DMZ
-
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- loc |
- dmz:10.10.11.1 |
- tcp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- loc |
- dmz:10.10.11.1 |
- udp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- fw |
- dmz:10.10.10.1 |
- tcp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- fw |
- dmz:10.10.10.1 |
- udp |
- 53 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ loc |
+ dmz:10.10.11.1 |
+ tcp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ loc |
+ dmz:10.10.11.1 |
+ udp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ fw |
+ dmz:10.10.10.1 |
+ tcp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ fw |
+ dmz:10.10.10.1 |
+ udp |
+ 53 |
+
+ |
+
+ |
+
+
-
-
-
-
+
+
+
Autres Connexions
-
-
-
-
L'exemple pour trois interfaces contient les règles suivantes
- :
-
-
-
+
+
L'exemple pour trois interfaces contient les règles
+suivantes :
+
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- fw |
- net |
- udp |
- 53 |
-
- |
-
- |
-
-
- | ACCEPT |
- fw |
- net |
- tcp |
- 53 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ fw |
+ net |
+ udp |
+ 53 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ fw |
+ net |
+ tcp |
+ 53 |
+
+ |
+
+ |
+
+
-
-
-
-
-
Ces règles permettent l'accès DNS depuis votre firewall et
- peuvent être enlevées si vous avez décommenté la ligne dans /etc/shorewall/policy
- autorisant toutes les connexions depuis votre firewall et vers Internet.
-
-
-
+
+
+
+
Ces règles permettent l'accès DNS depuis votre firewall
+et peuvent être enlevées si vous avez décommenté la ligne dans
+/etc/shorewall/policy autorisant toutes les connexions depuis votre
+firewall et vers Internet.
+
+
L'exemple contient aussi :
-
-
-
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- loc |
- fw |
- tcp |
- 22 |
-
- |
-
- |
-
-
- | ACCEPT |
- loc |
- dmz |
- tcp |
- 22 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ loc |
+ fw |
+ tcp |
+ 22 |
+
+ |
+
+ |
+
+
+ | ACCEPT |
+ loc |
+ dmz |
+ tcp |
+ 22 |
+
+ |
+
+ |
+
+
-
-
-
-
-
Cette règle permet de faire fonctionner une serveur SSH sur
- le firewall et sur tous les systèmes de la DMZ et d'y autoriser la connexion
- à partir de votre réseau local.
-
-
-
-
Si vous désirez permettre d'autres connexions entre vos systèmes,
- la forme générale est :
-
-
-
+
+
Cette règle permet de faire fonctionner une serveur SSH
+sur le firewall et sur tous les systèmes de la DMZ et d'y autoriser la
+connexion à partir de votre réseau local.
+
+
+
Si vous désirez permettre d'autres connexions entre vos
+systèmes, la forme générale est :
+
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- <source zone> |
- <destination zone> |
- <protocol> |
- <port> |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ <source zone> |
+ <destination zone> |
+ <protocol> |
+ <port> |
+
+ |
+
+ |
+
+
-
-
-
-
-
Exemple - Vous voulez faire tourner un serveur DNS disponible
- pour le publique sur votre firewall :
-
-
-
+
+
Exemple - Vous voulez faire tourner un serveur DNS
+disponible pour le publique sur votre firewall :
+
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- net |
- fw |
- tcp |
- 53 |
- #permet les accès DNS |
- depuis Internet |
-
-
- | ACCEPT |
- net |
- fw |
- udp
- |
- 53 |
- #permet les accès DNS |
- depuis Internet |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ tcp |
+ 53 |
+ #permet les accès DNS |
+ depuis Internet |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ udp
+ |
+ 53 |
+ #permet les accès DNS |
+ depuis Internet |
+
+
-
-
-
-
-
Ces deux règles seront, bien sur, ajoutées aux règles décrites
- dans "Vous pouvez installer/configurer un cache dns (Caching Name Server)
- sur votre firewall ou dans la DMZ".
-
-
-
-
Si vous ne savez pas quel port ou protocole une application
- particulière utilise, regardez ici.
-
-
-
-
Important: Je ne vous recommande pas d'autoriser le telnet
- depuis ou vers l'Internet car il utilise du texte en clair (même pour le
- login et le mot de passe !). Si vous voulez avoir un accès au shell de votre
- firewall depuis Internet, utilisez SSH :
-
-
-
+
+
Ces deux règles seront, bien sur, ajoutées aux règles
+décrites dans "Vous pouvez installer/configurer un cache dns (Caching
+Name Server) sur votre firewall ou dans la DMZ".
+
+
+
Si vous ne savez pas quel port ou protocole une
+application particulière utilise, regardez ici.
+
+
+
Important: Je ne vous recommande pas d'autoriser le
+telnet depuis ou vers l'Internet car il utilise du texte en clair (même
+pour le login et le mot de passe !). Si vous voulez avoir un accès au
+shell de votre firewall depuis Internet, utilisez SSH :
+
+
+
-
-
- | ACTION |
- SOURCE |
- DESTINATION |
- PROTOCOL |
- PORT |
- SOURCE PORT |
- ORIGINAL ADDRESS |
-
-
- | ACCEPT |
- net |
- fw |
- tcp |
- 22 |
-
- |
-
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DESTINATION |
+ PROTOCOL |
+ PORT |
+ SOURCE PORT |
+ ORIGINAL ADDRESS |
+
+
+ | ACCEPT |
+ net |
+ fw |
+ tcp |
+ 22 |
+
+ |
+
+ |
+
+
-
-
-
-
+
+
+
- Et maintenant, éditez /etc/shorewall/rules pour rajouter les autres
-connexions désirées.
-
-
-
+ height="13"> Et maintenant, éditez /etc/shorewall/rules pour rajouter
+les autres
+connexions désirées.
+
+
Lancer et Arrêter son Firewall
-
-
-
+
+
- La procédure d'installation configure votre
- système pour lancer Shorewall au boot du système, mais au début avec la
-version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de
-lancer Shorewall avec que la configuration soit finie. Une fois que vous
-en avez fini avec la configuration du firewall, vous pouvez permettre le
-lancement de Shorewall en supprimant le fichier /etc/shorewall/startup_disabled.
-
-
-
IMPORTANT: Les utilisateurs des paquets .deb doivent éditer
- /etc/default/shorewall et mettre 'startup=1'.
-
-
-
-
-
Le firewall est activé en utilisant la commande "shorewall
- start" et arrêté avec "shorewall stop". Lorsque le firewall est stoppé,
-le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped. Un
- firewall qui tourne peut être relancé en utilisant la commande "shorewall
- restart". Si vous voulez enlever toutes traces de Shorewall sur votre configuration
- de Netfilter, utilisez "shorewall clear".
-
-
-
+ height="13" alt="Arrow"> La
procédure
+d'installation configure votre système pour lancer Shorewall au
+boot du système, mais au début avec la
+version 1.3.9 de Shorewall le lancement est désactivé, n'essayer pas de
+lancer Shorewall avec que la configuration soit finie. Une fois que
+vous
+en avez fini avec la configuration du firewall, vous pouvez permettre
+le
+lancement de Shorewall en supprimant le fichier
+/etc/shorewall/startup_disabled.
+
+
IMPORTANT: Les utilisateurs des paquets .deb doivent
+éditer /etc/default/shorewall et mettre 'startup=1'.
+
+
+
+
Le firewall est activé en utilisant la commande
+"shorewall start" et arrêté avec "shorewall stop". Lorsque le firewall
+est stoppé,
+le routage est autorisé sur les hôtes qui possèdent une entrée dans /etc/shorewall/routestopped.
+Un firewall qui tourne peut être relancé en utilisant la commande
+"shorewall restart". Si vous voulez enlever toutes traces de Shorewall
+sur votre configuration de Netfilter, utilisez "shorewall clear".
+
+
- L'exemple pour trois interfaces suppose que vous voulez permettre le
-routage depuis/vers eth1 (votre réseau local) et eth2(DMZ)
- lorsque Shorewall est arrêté. Si ces deux interfaces ne sont pas
-connectées à votre réseau local et votre DMZ, ou si vous voulez permettre
-un ensemble d'hôtes différents, modifiez /etc/shorewall/routestopped en conséquence.
-
-
-
-
ATTENTION: Si vous êtes connecté à votre firewall depuis
-Internet, n'essayez pas une commande "shorewall stop" tant que vous n'avez
-pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle vous
+ height="13"> L'exemple pour trois interfaces suppose que vous voulez
+permettre le routage depuis/vers eth1 (votre réseau local) et
+eth2(DMZ) lorsque Shorewall est arrêté. Si ces deux interfaces ne
+sont pas connectées à votre réseau local et votre DMZ, ou si vous
+voulez permettre un ensemble d'hôtes différents, modifiez
+/etc/shorewall/routestopped en conséquence.
+
+
+
ATTENTION: Si vous êtes connecté à votre firewall
+depuis
+Internet, n'essayez pas une commande "shorewall stop" tant que vous
+n'avez
+pas ajouté une entrée pour votre adresse IP (celle à partir de laquelle
+vous
êtes connectée) dans /etc/shorewall/routestopped.
- De la même manière, je ne vous recommande pas d'utiliser "shorewall restart";
- il est plus intéressant de créer une configuration alternativeet de la
- tester en utilisant la commande "shorewall try".
-
-
+ href="configuration_file_basics.htm#Configs">alternativeet de
+la tester en utilisant la commande
"shorewall try".
+
Last updated 05/19/2003 - Tom Eastep
-
-Copyright 2002, 2003
-Thomas M. Eastep
-
-
+Copyright 2002,
+2003 Thomas M. Eastep
+
+
diff --git a/Shorewall-docs/traffic_shaping.htm b/Shorewall-docs/traffic_shaping.htm
index 4b127c911..40c2c9c5c 100644
--- a/Shorewall-docs/traffic_shaping.htm
+++ b/Shorewall-docs/traffic_shaping.htm
@@ -1,341 +1,306 @@
-
-
-
-
Traffic Shaping
-
-
-
-
-
-
- Traffic Shaping/Control
- |
-
-
-
-
-
-Shorewall has limited support for traffic shaping/control.
- In order to use traffic shaping under Shorewall, it is essential that
- you get a copy of the Linux Advanced Routing
- and Shaping HOWTO, version 0.3.0 or later. It is also necessary
-to be running Linux Kernel 2.4.18 or later.
-
-Shorewall traffic shaping support consists of the following:
-
+
+Traffic Shaping/Control
+
+Shorewall has limited support for traffic
+shaping/control. In order to use traffic shaping under Shorewall, it is
+essential that you get a copy of the Linux
+Advanced Routing and Shaping HOWTO, version 0.3.0 or later. It is
+also necessary to be running Linux Kernel 2.4.18 or later.
+Shorewall traffic shaping support consists of the
+following:
- - A new TC_ENABLED parameter in /etc/shorewall.conf.
- Traffic Shaping also requires that you enable packet mangling.
- - A new CLEAR_TC parameter in /etc/shorewall.conf (Added
- in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes),
- the setting of this variable determines whether Shorewall clears the traffic
- shaping configuration during Shorewall [re]start and Shorewall stop.
-
- - /etc/shorewall/tcrules - A file where you
-can specify firewall marking of packets. The firewall mark value
-may be used to classify packets for traffic shaping/control.
-
- - /etc/shorewall/tcstart - A user-supplied file
- that is sourced by Shorewall during "shorewall start" and which
- you can use to define your traffic shaping disciplines and classes.
- I have provided a sample that does
- table-driven CBQ shaping but if you read the traffic shaping sections
- of the HOWTO mentioned above, you can probably code your own faster
- than you can learn how to use my sample. I personally use
- HTB (see below).
- HTB support may eventually become an integral part of Shorewall
-since HTB is a lot simpler and better-documented than CBQ. As of 2.4.20,
- HTB is a standard part of the kernel but iproute2 must be patched in
- order to use it.
-
- In tcstart, when you want to run the 'tc' utility,
-use the run_tc function supplied by shorewall if you want tc errors
- to stop the firewall.
-
- You can generally use off-the-shelf traffic shaping scripts by
-simply copying them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB version)
- that way (i.e., I just copied wshaper.htb to /etc/shorewall/tcstart
-and modified it according to the Wonder Shaper README). WARNING: If
- you use use Masquerading or SNAT (i.e., you only have one external IP address)
- then listing internal hosts in the NOPRIOHOSTSRC variable in the wshaper[.htb]
- script won't work. Traffic shaping occurs after SNAT has already been
-applied so when traffic shaping happens, all outbound traffic will have
-as a source address the IP addresss of your firewall's external interface.
-
- - /etc/shorewall/tcclear - A user-supplied file
- that is sourced by Shorewall when it is clearing traffic shaping.
- This file is normally not required as Shorewall's method of clearing
- qdisc and filter definitions is pretty general.
-
-
- Shorewall allows you to start traffic shaping when Shorewall itself
- starts or it allows you to bring up traffic shaping when you bring up your
- interfaces.
-
- To start traffic shaping when Shorewall starts:
-
-
- - Set TC_ENABLED=Yes and CLEAR_TC=Yes
- - Supply an /etc/shorewall/tcstart script to configure your traffic
- shaping rules.
- - Optionally supply an /etc/shorewall/tcclear script to stop
-traffic shaping. That is usually unnecessary.
- - If your tcstart script uses the 'fwmark' classifier, you can
-mark packets using entries in /etc/shorewall/tcrules.
-
-
- To start traffic shaping when you bring up your network interfaces,
- you will have to arrange for your traffic shaping configuration script
-to be run at that time. How you do that is distribution dependent and will
-not be covered here. You then should:
-
-
- - Set TC_ENABLED=Yes and CLEAR_TC=No
- - Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear
- scripts.
- - If your tcstart script uses the 'fwmark' classifier,
- you can mark packets using entries in /etc/shorewall/tcrules.
-
-
-
-Kernel Configuration
-
-This screen shot show how I've configured QoS in my Kernel:
-
-
-
-
-/etc/shorewall/tcrules
-
-The fwmark classifier provides a convenient way to classify
- packets for traffic shaping. The /etc/shorewall/tcrules file provides
- a means for specifying these marks in a tabular fashion.
-
-
-Normally, packet marking occurs in the PREROUTING chain before
- any address rewriting takes place. This makes it impossible to mark inbound
- packets based on their destination address when SNAT or Masquerading
-are being used. Beginning with Shorewall 1.3.12, you can cause packet
-marking to occur in the FORWARD chain by using the MARK_IN_FORWARD_CHAIN
-option in shorewall.conf.
-
-
-Columns in the file are as follows:
-
-
- - MARK - Specifies the mark value is to be assigned
-in case of a match. This is an integer in the range 1-255. Beginning
-with Shorewall version 1.3.14, this value may be optionally followed by
-":" and either 'F' or 'P' to designate that the marking will occur in the
-FORWARD or PREROUTING chains respectively. If this additional specification
-is omitted, the chain used to mark packets will be determined by the setting
-of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
-
- Example - 5
-
- - SOURCE - The source of the packet. If the packet
-originates on the firewall, place "fw" in this column. Otherwise,
-this is a comma-separated list of interface names, IP addresses, MAC
-addresses in Shorewall Format and/or
-Subnets.
-
- Examples
- eth0
- 192.168.2.4,192.168.1.0/24
-
- - DEST -- Destination of the packet. Comma-separated
-list of IP addresses and/or subnets.
-
- - PROTO - Protocol - Must be the name of a protocol
-from /etc/protocol, a number or "all"
-
- - PORT(S) - Destination Ports. A comma-separated list
- of Port names (from /etc/services), port numbers or port ranges (e.g.,
- 21:22); if the protocol is "icmp", this column is interpreted as
- the destination icmp type(s).
-
- - CLIENT PORT(S) - (Optional) Port(s) used by the client.
- If omitted, any source port is acceptable. Specified as a comma-separate
- list of port names, port numbers or port ranges.
-
-
-
-Example 1 - All packets arriving on eth1 should be marked
- with 1. All packets arriving on eth2 and eth3 should be marked with
- 2. All packets originating on the firewall itself should be marked with
- 3.
-
-
-
-
- | MARK |
- SOURCE |
- DEST |
- PROTO |
- PORT(S) |
- CLIENT PORT(S) |
-
-
- | 1 |
- eth1 |
- 0.0.0.0/0 |
- all |
- |
- |
-
-
- | 2 |
- eth2 |
- 0.0.0.0/0 |
- all |
- |
- |
-
-
- 2
- |
- eth3
- |
- 0.0.0.0/0
- |
- all
- |
-
- |
-
- |
-
-
- | 3 |
- fw |
- 0.0.0.0/0 |
- all |
- |
- |
-
-
-
-
-
-Example 2 - All GRE (protocol 47) packets not originating
- on the firewall and destined for 155.186.235.151 should be marked
-with 12.
-
-
-
-
- | MARK |
- SOURCE |
- DEST |
- PROTO |
- PORT(S) |
- CLIENT PORT(S) |
-
-
- | 12 |
- 0.0.0.0/0 |
- 155.186.235.151 |
- 47 |
- |
- |
-
-
-
-
-
-Example 3 - All SSH packets originating in 192.168.1.0/24
- and destined for 155.186.235.151 should be marked with 22.
-
-
-
-
- | MARK |
- SOURCE |
- DEST |
- PROTO |
- PORT(S) |
- CLIENT PORT(S) |
-
-
- | 22 |
- 192.168.1.0/24 |
- 155.186.235.151 |
- tcp |
- 22 |
- |
-
-
-
-
-
-My Setup
-
-
-While I am currently using the HTB version of The Wonder Shaper (I just copied
- wshaper.htb to /etc/shorewall/tcstart and modified it as shown
- in the Wondershaper README), I have also run with the following set of
-hand-crafted rules in my /etc/shorewall/tcstart file:
-
-
-
- run_tc qdisc add dev eth0 root handle 1: htb default 30
run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k
echo " Added Top Level Class -- rate 384kbit"
-
- run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit ceil 384kbit burst 15k quantum 1500 prio 1
-
- echo " Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
-
- run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
-
- echo " Enabled PFIFO on Second Level Classes"
-
- run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
-
- echo " Defined fwmark filters"
-
-
-My tcrules file that went with this tcstart file is shown in Example 1
- above. You can look at my configuration to
-see why I wanted shaping of this type.
-
-
-
- - I wanted to allow up to 140kbits/second for traffic outbound
- from my DMZ (note that the ceiling is set to 384kbit so outbound DMZ
-traffic can use all available bandwidth if there is no traffic from the
-local systems or from my laptop or firewall).
- - My laptop and local systems could use up to 224kbits/second.
- - My firewall could use up to 20kbits/second.
-
-
- You see the rest of my Shorewall configuration
- to see how this fit in.
-
-Last Updated 3/19/2003 - Tom Eastep
-
-Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
+ - A new TC_ENABLED parameter in /etc/shorewall.conf.
+Traffic Shaping also requires that you enable packet mangling.
+ - A new CLEAR_TC parameter in /etc/shorewall.conf (Added
+in Shorewall 1.3.13). When Traffic Shaping is enabled (TC_ENABLED=Yes),
+the setting of this variable determines whether Shorewall clears the
+traffic shaping configuration during Shorewall [re]start and Shorewall
+stop.
+
+ - /etc/shorewall/tcrules - A file where you
+can specify firewall marking of packets. The firewall mark value
+may be used to classify packets for traffic shaping/control.
+
+ - /etc/shorewall/tcstart - A user-supplied file that is
+sourced by Shorewall during "shorewall start" and which you can use to
+define your traffic shaping disciplines and classes. I have provided a sample that does
+table-driven CBQ shaping but if you read the traffic shaping sections
+of the HOWTO mentioned above, you can probably code your own faster
+than you can learn how to use my sample. I personally use HTB (see below). HTB
+support may eventually become an integral part of Shorewall since HTB
+is a lot simpler and better-documented than CBQ. As of 2.4.20, HTB is a
+standard part of the kernel but iproute2 must be patched in order to
+use it.
-
-
-
+In tcstart, when you want to run the 'tc' utility,
+use the run_tc function supplied by shorewall if you want tc errors to
+stop the firewall.
+
+You can generally use off-the-shelf traffic shaping scripts by simply
+copying them to /etc/shorewall/tcstart. I use The Wonder Shaper (HTB
+version) that way (i.e., I just copied wshaper.htb to
+/etc/shorewall/tcstart
+and modified it according to the Wonder Shaper README). WARNING: If
+you use use Masquerading or SNAT (i.e., you only have one external IP
+address) then listing internal hosts in the NOPRIOHOSTSRC variable in
+the wshaper[.htb] script won't work. Traffic shaping occurs after SNAT
+has already been
+applied so when traffic shaping happens, all outbound traffic will have
+as a source address the IP addresss of your firewall's external
+interface.
+
+ - /etc/shorewall/tcclear - A user-supplied file that is
+sourced by Shorewall when it is clearing traffic shaping. This file is
+normally not required as Shorewall's method of clearing qdisc and
+filter definitions is pretty general.
+
+Shorewall allows you to start traffic shaping when Shorewall itself
+starts or it allows you to bring up traffic shaping when you bring up
+your interfaces.
+
+To start traffic shaping when Shorewall starts:
+
+ - Set TC_ENABLED=Yes and CLEAR_TC=Yes
+ - Supply an /etc/shorewall/tcstart script to configure your traffic
+shaping rules.
+ - Optionally supply an /etc/shorewall/tcclear script to stop
+traffic shaping. That is usually unnecessary.
+ - If your tcstart script uses the 'fwmark' classifier, you can mark
+packets using entries in /etc/shorewall/tcrules.
+
+To start traffic shaping when you bring up your network interfaces, you
+will have to arrange for your traffic shaping configuration script to
+be run at that time. How you do that is distribution dependent and will
+not be covered here. You then should:
+
+ - Set TC_ENABLED=Yes and CLEAR_TC=No
+ - Do not supply /etc/shorewall/tcstart or /etc/shorewall/tcclear
+scripts.
+ - If your tcstart script uses the 'fwmark' classifier,
+you can mark packets using entries in /etc/shorewall/tcrules.
+
+Kernel Configuration
+This screen shot show how I've configured QoS in my
+Kernel:
+
+/etc/shorewall/tcrules
+The fwmark classifier provides a convenient way to
+classify packets for traffic shaping. The /etc/shorewall/tcrules file
+provides a means for specifying these marks in a tabular fashion.
+
+Normally, packet marking occurs in the PREROUTING chain
+before any address rewriting takes place. This makes it impossible to
+mark inbound packets based on their destination address when SNAT or
+Masquerading
+are being used. Beginning with Shorewall 1.3.12, you can cause packet
+marking to occur in the FORWARD chain by using the
+MARK_IN_FORWARD_CHAIN
+option in shorewall.conf.
+
+Columns in the file are as follows:
+
+ - MARK - Specifies the mark value is to be assigned in case of a
+match. This is an integer in the range 1-255. Beginning with Shorewall
+version 1.3.14, this value may be optionally followed by
+":" and either 'F' or 'P' to designate that the marking will occur in
+the
+FORWARD or PREROUTING chains respectively. If this additional
+specification
+is omitted, the chain used to mark packets will be determined by the
+setting
+of the MARK_IN_FORWARD_CHAIN option in shorewall.conf.
+
+Example - 5
+
+ - SOURCE - The source of the packet. If the packet
+originates on the firewall, place "fw" in this column. Otherwise,
+this is a comma-separated list of interface names, IP addresses, MAC
+addresses in Shorewall Format
+and/or
+Subnets.
+
+Examples
+ eth0
+ 192.168.2.4,192.168.1.0/24
+
+ - DEST -- Destination of the packet. Comma-separated list of IP
+addresses and/or subnets.
+
+ - PROTO - Protocol - Must be the name of a protocol from
+/etc/protocol, a number or "all"
+
+ - PORT(S) - Destination Ports. A comma-separated list of Port names
+(from /etc/services), port numbers or port ranges (e.g., 21:22); if the
+protocol is "icmp", this column is interpreted as the destination icmp
+type(s).
+
+ - CLIENT PORT(S) - (Optional) Port(s) used by the client. If
+omitted, any source port is acceptable. Specified as a comma-separate
+list of port names, port numbers or port ranges.
+
+Example 1 - All packets arriving on eth1 should be
+marked with 1. All packets arriving on eth2 and eth3 should be marked
+with 2. All packets originating on the firewall itself should be marked
+with 3.
+
+
+
+ | MARK |
+ SOURCE |
+ DEST |
+ PROTO |
+ PORT(S) |
+ CLIENT PORT(S) |
+
+
+ | 1 |
+ eth1 |
+ 0.0.0.0/0 |
+ all |
+ |
+ |
+
+
+ | 2 |
+ eth2 |
+ 0.0.0.0/0 |
+ all |
+ |
+ |
+
+
+ 2
+ |
+ eth3
+ |
+ 0.0.0.0/0
+ |
+ all
+ |
+
+ |
+
+ |
+
+
+ | 3 |
+ fw |
+ 0.0.0.0/0 |
+ all |
+ |
+ |
+
+
+
+Example 2 - All GRE (protocol 47) packets not
+originating on the firewall and destined for 155.186.235.151 should be
+marked with 12.
+
+
+
+ | MARK |
+ SOURCE |
+ DEST |
+ PROTO |
+ PORT(S) |
+ CLIENT PORT(S) |
+
+
+ | 12 |
+ 0.0.0.0/0 |
+ 155.186.235.151 |
+ 47 |
+ |
+ |
+
+
+
+Example 3 - All SSH packets originating in
+192.168.1.0/24 and destined for 155.186.235.151 should be marked with
+22.
+
+
+
+ | MARK |
+ SOURCE |
+ DEST |
+ PROTO |
+ PORT(S) |
+ CLIENT PORT(S) |
+
+
+ | 22 |
+ 192.168.1.0/24 |
+ 155.186.235.151 |
+ tcp |
+ 22 |
+ |
+
+
+
+My Current Setup
+
+I am currently using the HTB version of The Wonder Shaper (I just
+copied wshaper.htb to /etc/shorewall/tcstart and modified it as
+shown in the Wondershaper README). WonderShaper
+DOES NOT USE THE
+/etc/shorewall/tcrules file. While I currently have entries in
+/etc/shorewall/tcrules, I do so for policy routing for Squid and not
+for Traffic Shaping.
+My Old Setup
+
+I have also run with the following set of hand-crafted rules in my /etc/shorewall/tcstart
+file.
+
+
+ run_tc qdisc add dev eth0 root handle 1: htb default 30
run_tc class add dev eth0 parent 1: classid 1:1 htb rate 384kbit burst 15k
echo " Added Top Level Class -- rate 384kbit"
+ run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 140kbit ceil 384kbit burst 15k prio 1
run_tc class add dev eth0 parent 1:1 classid 1:20 htb rate 224kbit ceil 384kbit burst 15k prio 0
run_tc class add dev eth0 parent 1:1 classid 1:30 htb rate 20kbit ceil 384kbit burst 15k quantum 1500 prio 1
+ echo " Added Second Level Classes -- rates 140kbit, 224kbit, 20kbit"
+ run_tc qdisc add dev eth0 parent 1:10 pfifo limit 5
run_tc qdisc add dev eth0 parent 1:20 pfifo limit 10
run_tc qdisc add dev eth0 parent 1:30 pfifo limit 5
+ echo " Enabled PFIFO on Second Level Classes"
+ run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:10
run_tc filter add dev eth0 protocol ip parent 1:0 prio 0 handle 2 fw classid 1:20
run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 3 fw classid 1:30
+ echo " Defined fwmark filters"
+
+My tcrules file that went with this tcstart file is shown in Example
+1 above. When I was using these rules:
+
+
+ - I wanted to allow up to 140kbits/second for traffic outbound from
+my DMZ (eth1 -- note that the ceiling is set to 384kbit so outbound DMZ
+traffic can use all available bandwidth if there is no traffic from the
+local systems or from my laptop or firewall).
+ - My laptop (which at that time connected via eth3) and local
+systems (eth2) could use up to 224kbits/second.
+ - My firewall could use up to 20kbits/second.
+
+Once www.shorewall.net was moved off-site, I no longer needed these
+shaping rules and The Wonder Shaper does all that I now require.
+Last Updated 10/21/2003 - Tom
+Eastep
+Copyright
+© 2001, 2002, 2003 Thomas M. Eastep.
+
+
+
+
+
+
+
diff --git a/Shorewall-docs/troubleshoot.htm b/Shorewall-docs/troubleshoot.htm
index 9669a7ab9..b7afdf2b4 100644
--- a/Shorewall-docs/troubleshoot.htm
+++ b/Shorewall-docs/troubleshoot.htm
@@ -8,19 +8,10 @@
-
-
-
-
- Shorewall Troubleshooting
- |
-
-
-
+Shorewall
+Troubleshooting
"If
you think you can you can; if you think you can't you're right.
If you don't believe that you can, why should someone else?" -- Gunnar
@@ -145,8 +136,8 @@ sending the packets or the destination host isn't in any zone (using an
/etc/shorewall/hosts file
are you?); or
- the source and destination hosts are both connected to the
-same interface and you don't have a policy or rule for the
-source zone to or from the destination zone.
+same interface and you haven't specified the 'routeback' option on that
+interface.
- Remember that Shorewall doesn't automatically allow ICMP type 8
@@ -199,7 +190,7 @@ in /etc/shorewall/shorewall.conf.
-Last updated 8/29/2003 - Tom Eastep
+Last updated 11/1/2003 - Tom Eastep
Copyright
© 2001, 2002 Thomas M. Eastep.
diff --git a/Shorewall-docs/two-interface.htm b/Shorewall-docs/two-interface.htm
index 2d849b165..e43e72d7b 100644
--- a/Shorewall-docs/two-interface.htm
+++ b/Shorewall-docs/two-interface.htm
@@ -10,18 +10,8 @@
-
-
-
-
- Basic Two-Interface
-Firewall
- |
-
-
-
+Basic Two-Interface Firewall
+
Setting up a Linux system as a firewall for a small
network is a fairly straight-forward task if you understand the basics
and follow the documentation.
@@ -30,7 +20,10 @@ of Shorewall. It rather focuses on what is required to configure
Shorewall in its most common configuration:
- Linux system used as a firewall/router for a small local network.
- - Single public IP address.
+ - Single public IP address. If you have
+more than one public IP address, this is not the guide you want -- see
+the Shorewall Setup Guide
+instead.
- Internet connection through cable modem, DSL, ISDN, Frame Relay,
dial-up ...
@@ -140,8 +133,8 @@ that file matches the connection request then the first policy
in /etc/shorewall/policy that matches the request is applied.
If that policy is REJECT or DROP the request is first checked
against
-the rules in /etc/shorewall/common (the samples provide that file
-for you).
+the rules in /etc/shorewall/common if that file exists; otherwise the
+rules in /etc/shorewall/common.def are checked.
The /etc/shorewall/policy file included with the two-interface
sample
has the following policies:
@@ -946,9 +939,15 @@ have added an entry for the IP address that you are connected from to alternate
configuration and test it using the "shorewall try" command.
+ href="starting_and_stopping_shorewall.htm">"shorewall try" command.
+
+Additional Recommended Reading
+I highly recommend that you review the Common Configuration File
+Features page -- it contains helpful tips about Shorewall features
+than make administering your firewall easier.
-Last updated 8/8/2003 - Last updated 11/15/2003 - Tom Eastep
Copyright 2002,
2003 Thomas M. Eastep
diff --git a/Shorewall-docs/two-interface_fr.html b/Shorewall-docs/two-interface_fr.html
index 5262afb6f..93f4ea84a 100755
--- a/Shorewall-docs/two-interface_fr.html
+++ b/Shorewall-docs/two-interface_fr.html
@@ -1,1381 +1,1339 @@
-
Two-Interface Firewall
-
-
-
-
-
-
-
-
-
-
-
-
- Basic Two-Interface Firewall
- |
-
-
-
-
-
-Version 2.0.1 Française
-
+
+Basic Two-Interface Firewall
- Notes du traducteur :
- Je ne prétends pas être un vrai traducteur dans le sens ou
-mon travail n’est pas des plus précis (loin de là...). Je ne
-me suis pas attaché à une traduction exacte du texte, mais plutôt
-à en faire une version française intelligible par tous (et
-par moi). Les termes techniques sont la plupart du temps conservés
- sous leur forme originale et mis entre parenthèses car vous pouvez
- les retrouver dans le reste des documentations ainsi que dans les fichiers
- de configuration. N’hésitez pas à me contacter afin d’améliorer
- ce document VETSEL Patrice
- (merci à JMM pour sa relecture et ses commentaires pertinents, ainsi
- qu'à Tom EASTEP pour son formidable outil et sa disponibilité).
-
-
-
-Mettre en place un système Linux en tant que firewall
- pour un petit réseau est une chose assez simple, si vous comprenez
- les bases et suivez la documentation.
-
-Ce guide ne veut pas vous apprendre tous les rouages de Shorewall. Il
-se focalise sur ce qui est nécessaire pour configurer Shorewall, dans
- son utilisation la plus courante :
-
+Notes du traducteur :
+Je ne prétends pas être un vrai traducteur dans le sens ou
+mon travail n’est pas des plus précis (loin de là...). Je
+ne me suis pas attaché à une traduction exacte du texte,
+mais plutôt
+à en faire une version française intelligible par tous
+(et
+par moi). Les termes techniques sont la plupart du temps
+conservés sous leur forme originale et mis entre
+parenthèses car vous pouvez les retrouver dans le reste des
+documentations ainsi que dans les fichiers de configuration.
+N’hésitez pas à me contacter afin d’améliorer ce
+document VETSEL Patrice
+(merci à JMM pour sa relecture et ses commentaires pertinents,
+ainsi qu'à Tom EASTEP pour son formidable outil et sa
+disponibilité).
+
+
+Mettre en place un système Linux en tant que
+firewall pour un petit réseau est une chose assez simple, si
+vous comprenez les bases et suivez la documentation.
+Ce guide ne veut pas vous apprendre tous les rouages de Shorewall.
+Il
+se focalise sur ce qui est nécessaire pour configurer Shorewall,
+dans son utilisation la plus courante :
- -
-
Un système Linux utilisé
- en tant que firewall/routeur pour un petit réseau local.
-
- -
-
Une seule adresse IP publique.
-
- -
-
Une connexion Internet par le biais d'un modem câble, ADSL,
- ISDN, "Frame Relay", RTC ...
-
-
+ -
+
Un système Linux
+utilisé en tant que firewall/routeur pour un petit réseau
+local.
+
+ -
+
Une seule adresse IP publique.
+
+ -
+
Une connexion Internet par le biais d'un modem câble,
+ADSL, ISDN, "Frame Relay", RTC ...
+
-
Voici un schéma d'une installation typique.
-
-
-
-Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus récent,
- vous pouvez facilement réaliser la configuration ci-dessus en utilisant
- l'applet Mandrake "Internet Connection Sharing". Depuis le "Mandrake Control
- Center", sélectionnez "Network & Internet" et "Connection Sharing".
- Vous ne devriez pas avoir besoin de vous référer à
-ce guide.
-
-Ce guide suppose que vous avez le paquet iproute/iproute2 d'installé.
- Vous pouvez voir si le paquet est installé en vérifiant
- la présence du programme ip sur votre système de firewall.
+ align="bottom" width="444" height="635" border="0">
+Si vous faites tourner Shorewall sous Mandrake 9.0 ou plus
+récent, vous pouvez facilement réaliser la configuration
+ci-dessus en utilisant l'applet Mandrake "Internet Connection Sharing".
+Depuis le "Mandrake Control Center", sélectionnez "Network &
+Internet" et "Connection Sharing". Vous ne devriez pas avoir besoin de
+vous référer à
+ce guide.
+Ce guide suppose que vous avez le paquet iproute/iproute2
+d'installé. Vous pouvez voir si le paquet est
+installé en vérifiant la présence du programme ip
+sur votre système de firewall.
Sous root, utilisez la commande 'which' pour rechercher le programme :
-
[root@gateway root]# which ip
/sbin/ip
[root@gateway root]#
-
-Je vous recommande dans un premier temps de parcourir tout le guide pour
- vous familiariser avec ce qui va se passer, et de revenir au début
- en effectuant le changements dans votre configuration. Les points où,
- les changements dans la configuration sont recommandées, sont signalés
- par une
- .
-
+Je vous recommande dans un premier temps de parcourir tout le guide
+pour vous familiariser avec ce qui va se passer, et de revenir au
+début en effectuant le changements dans votre configuration. Les
+points où, les changements dans la configuration sont
+recommandées, sont signalés par une .
- Si vous éditez vos fichiers de configuration
-sur un système Windows, vous devez les sauver comme des fichiers
-Unix si votre éditeur offre cette option sinon vous devez les faire
-passer par dos2unix avant d'essayer de les utiliser. De la même manière,
- si vous copiez un fichier de configuration depuis votre disque dur Windows
- vers une disquette, vous devez lancer dos2unix sur la copie avant de l'utiliser
- avec Shorewall.
-
+ width="60" height="60" border="0"> Si vous
+éditez vos fichiers de configuration
+sur un système Windows, vous devez les sauver comme des fichiers
+Unix si votre éditeur offre cette option sinon vous devez les
+faire
+passer par dos2unix avant d'essayer de les utiliser. De la même
+manière, si vous copiez un fichier de configuration depuis votre
+disque dur Windows vers une disquette, vous devez lancer dos2unix sur
+la copie avant de l'utiliser avec Shorewall.
-
Les Concepts de Shorewall
-
- Les fichiers de configuration pour Shorewall sont dans
- le répertoire /etc/shorewall -- pour de simples configurations, vous
- n'aurez seulement à faire qu'avec quelques fichiers comme décrit
- dans ce guide. Après avoir installé Shorewall,
+ width="13" height="13" border="0"> Les fichiers de
+configuration pour Shorewall sont dans le répertoire
+/etc/shorewall -- pour de simples configurations, vous n'aurez
+seulement à faire qu'avec quelques fichiers comme décrit
+dans ce guide. Après avoir installé
+Shorewall,
télé chargez le two-interface sample,
-un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les fichiers vers /etc/shorewall
-(ces fichiers remplaceront les fichiers de même nom).
-
-Parallèlement à la présentation de chacun des fichiers,
- je vous suggère de regarder le fichier qui se trouve réellement
- sur votre système -- tous les fichiers contiennent des instructions
- de configuration détaillées et des valeurs par défaut.
-
-Shorewall voit le réseau où il tourne, comme un ensemble
- de zones. Dans une configuration avec deux interfaces, les noms des
- zones suivantes sont utilisés:
-
+ href="http://www1.shorewall.net/pub/shorewall/Samples/">two-interface
+sample, un-tarez le (tar -zxvf two-interfaces.tgz) et copiez les
+fichiers vers /etc/shorewall (ces fichiers remplaceront les fichiers de
+même nom).
+Parallèlement à la présentation de chacun des
+fichiers, je vous suggère de regarder le fichier qui se trouve
+réellement sur votre système -- tous les fichiers
+contiennent des instructions de configuration détaillées
+et des valeurs par défaut.
+Shorewall voit le réseau où il tourne, comme un
+ensemble de zones. Dans une configuration avec deux interfaces,
+les noms des zones suivantes sont utilisés:
+
-
-
- |
+ |
+
+ |
Nom
- |
-
+ |
+
Description
- |
-
-
- |
+ |
+
+
+ |
net
- |
-
+ |
+
Internet
- |
-
-
- |
+ |
+
+
+ |
loc
- |
-
+ |
+
Votre réseau local
- |
-
-
-
+
+
+
-
Les zones sont définies dans le fichier/etc/shorewall/zones .
-
-Shorewall reconnaît aussi le système de firewall comme sa
- propre zone - par défaut, le firewall est connu comme fw.
-
-Les règles à propos de quel trafic autoriser, et de quel
- trafic interdire sont exprimées en terme de zones.
-
+Shorewall reconnaît aussi le système de firewall comme
+sa propre zone - par défaut, le firewall est connu comme fw.
+Les règles à propos de quel trafic autoriser, et de
+quel trafic interdire sont exprimées en terme de zones.
- -
-
Vous exprimez votre politique par défaut
- pour les connexions d'une zone vers une autre zone dans le fichier /etc/shorewall/policy .
-
- -
-
Vous définissez les exceptions à ces politiques pas
- défaut dans le fichier /etc/shorewall/rules
- .
-
-
+ -
+
Vous exprimez votre politique par
+défaut pour les connexions d'une zone vers une autre zone dans
+le fichier /etc/shorewall/policy .
+
+
+ -
+
Vous définissez les exceptions à ces politiques
+pas défaut dans le fichier /etc/shorewall/rules
+ .
+
-
-Pour chaque connexion demandant à entrer dans le firewall, la requête
- est en premier lieu comparée par rapport au fichier /etc/shorewall/rules.
- Si aucune règle dans ce fichier ne correspond à la demande
-de connexion alors la première politique dans le fichier /etc/shorewall/policy
- qui y correspond sera appliquée. Si cette politique est REJECT ou
-DROP la requête est dans un premier temps comparée par
+
Pour chaque connexion demandant à entrer dans le firewall, la
+requête est en premier lieu comparée par rapport au
+fichier /etc/shorewall/rules. Si aucune règle dans ce fichier ne
+correspond à la demande
+de connexion alors la première politique dans le fichier
+/etc/shorewall/policy qui y correspond sera appliquée. Si cette
+politique est REJECT ou
+DROP la requête est dans un premier temps comparée
+par
rapport aux règles contenues dans /etc/shorewall/common.
-
-Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple (two-interface)
- a les politiques suivantes:
-
+Le fichier /etc/shorewall/policy inclue dans l'archive d'exemple
+(two-interface) a les politiques suivantes:
+
- -
+
-
-
-
- |
+ |
+
+ |
Source Zone
- |
-
+ |
+
Destination Zone
- |
-
+ |
+
Policy
- |
-
+ |
+
Log Level
- |
-
+ |
+
Limit:Burst
- |
-
-
- |
+ |
+
+
+ |
loc
- |
-
+ |
+
net
- |
-
+ |
+
ACCEPT
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
- |
+ |
+
+
+ |
net
- |
-
+ |
+
all
- |
-
+ |
+
DROP
- |
-
+ |
+
info
- |
-
+ |
+
- |
-
-
- |
+ |
+
+
+ |
all
- |
-
+ |
+
all
- |
-
+ |
+
REJECT
- |
-
+ |
+
info
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
-Dans le fichier d'exemple (two-interface), la ligne suivante
-est inclue mais elle est commentée. Si vous voulez que votre firewall
-puisse avoir un accès complet aux serveurs sur Internet, décommentez
- la ligne.
-
+Dans le fichier d'exemple (two-interface), la ligne
+suivante
+est inclue mais elle est commentée. Si vous voulez que votre
+firewall
+puisse avoir un accès complet aux serveurs sur Internet,
+décommentez la ligne.
+
- -
+
-
-
-
- |
+ |
+
+ |
Source Zone
- |
-
+ |
+
Destination Zone
- |
-
+ |
+
Policy
- |
-
+ |
+
Log Level
- |
-
+ |
+
Limit:Burst
- |
-
-
- |
+ |
+
+
+ |
fw
- |
-
+ |
+
net
- |
-
+ |
+
ACCEPT
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
Ces politiques vont:
-
- -
-
permettre toutes les demandes de connexion
- depuis votre réseau local vers l'Internet
-
- -
-
drop (ou ignorer) toutes les demandes
- de connexion depuis l'Internet vers votre firewall ou votre réseau
- local.
-
- -
-
Facultativement accepter toutes les
- demandes de connexion de votre firewall vers l'Internet (si vous avez
-dé commenté la politique additionnelle)
-
- -
-
reject (rejeter) toutes les autres demandes de connexion.
-
-
+ -
+
permettre toutes les demandes de
+connexion depuis votre réseau local vers l'Internet
+
+ -
+
drop (ou ignorer) toutes les
+demandes de connexion depuis l'Internet vers votre firewall ou votre
+réseau local.
+
+ -
+
Facultativement accepter toutes
+les demandes de connexion de votre firewall vers l'Internet (si vous
+avez
+dé commenté la politique additionnelle)
+
+ -
+
reject (rejeter) toutes les autres demandes de connexion.
+
-
- A ce point, éditez votre fichier /etc/shorewall/policy
- et faite les changements que vous désirez.
-
+ width="13" height="13" border="0"> A ce point,
+éditez votre fichier /etc/shorewall/policy et faite les
+changements que vous désirez.
Network Interfaces
-
-
-
-Le firewall a deux interfaces de réseau. Lorsque la
- connexion Internet passe par le câble ou par un ROUTEUR (pas un simple
- modem) ADSL (non USB), l'interface vers l'extérieur (External
-Interface) sera l'adaptateur sur lequel est connecté le routeur
-(e.g., eth0) à moins que vous ne vous connectiez
-par Point-to-PointProtocol overEthernet
-(PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP),
- dans ce cas l'interface extérieure sera une interface de type ppp
- (e.g., ppp0). Si vous vous connectez par un simple modem (RTC), votre
- interface extérieure sera aussi ppp0. Si votre connexion passe
- par Numéris (ISDN), votre interface extérieure seraippp0.
-
+ align="bottom" width="444" height="635" border="0">
+Le firewall a deux interfaces de réseau. Lorsque
+la connexion Internet passe par le câble ou par un ROUTEUR (pas
+un simple modem) ADSL (non USB), l'interface vers l'extérieur (External
+Interface) sera l'adaptateur sur lequel est connecté le
+routeur
+(e.g., eth0) à moins que vous ne vous
+connectiez
+par Point-to-PointProtocol overEthernet
+(PPPoE) ou par Point-to-PointTunnelingProtocol(PPTP),
+dans ce cas l'interface extérieure sera une interface de type
+ppp (e.g., ppp0). Si vous vous connectez par un simple modem
+(RTC), votre interface extérieure sera aussi ppp0. Si
+votre connexion passe par Numéris (ISDN), votre interface
+extérieure seraippp0.
- Si votre interface vers l'extérieur estppp0
- ou ippp0 alors vous mettrez CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.
-
-Votre Internal Interface (interface vers votre réseau
- local -> LAN) sera un adaptateur Ethernet (eth1 ou eth0) et sera connectée
- à un hub ou switch (ou un PC avec un câble croisé).
-Vos autres ordinateurs seront connectés à ce même hub/switch
-
+ align="bottom" width="13" height="13" border="0">
+Si votre interface vers l'extérieur estppp0 ou ippp0
+alors vous mettrez CLAMPMSS=yes dans /etc/shorewall/shorewall.conf.
+Votre Internal Interface (interface vers votre
+réseau local -> LAN) sera un adaptateur Ethernet (eth1 ou
+eth0) et sera connectée à un hub ou switch (ou un PC avec
+un câble croisé).
+Vos autres ordinateurs seront connectés à ce même
+hub/switch
- Ne connectez pas l'interface interne et externe sur le même
- hub ou switch (même pour tester). Cela ne fonctionnera pas et ne croyez
- pas que ce soit shorewall qui ne marche pas.
-
+ align="bottom" width="60" height="60" border="0"> Ne
+connectez pas l'interface interne et externe sur le même hub ou
+switch (même pour tester). Cela ne fonctionnera pas et ne croyez
+pas que ce soit shorewall qui ne marche pas.
- Le fichier de configuration d'exemple pour deux interfaces
- suppose que votre interface externe est eth0et que l'interne est
-eth1. Si votre configuration est différente, vous devrez modifier
-le fichier /etc/shorewall/interfaces
-en conséquence. Tant que vous y êtes, vous pourriez parcourir
-la liste des options qui sont spécifiées pour les interfaces.
+ align="left" width="13" height="13" border="0"> Le
+fichier de configuration d'exemple pour deux interfaces suppose que
+votre interface externe est eth0et que l'interne est
+eth1. Si votre configuration est différente, vous devrez
+modifier
+le fichier /etc/shorewall/interfaces
+en conséquence. Tant que vous y êtes, vous pourriez
+parcourir
+la liste des options qui sont spécifiées pour les
+interfaces.
Quelques trucs:
-
- -
-
Si votre interface vers l'extérieur est ppp0
- ou ippp0, vous pouvez remplacer le "detect" dans la seconde colonne
- par un "-".
-
- -
-
Si votre interface vers l'extérieur est ppp0
- ou ippp0 ou si vous avez une adresse IP statique, vous pouvez enlever
- "dhcp" dans la liste des options.
-
-
+ -
+
Si votre interface vers l'extérieur est ppp0
+ou ippp0, vous pouvez remplacer le "detect" dans la seconde
+colonne par un "-".
+
+ -
+
Si votre interface vers l'extérieur est ppp0
+ou ippp0 ou si vous avez une adresse IP statique, vous pouvez
+enlever "dhcp" dans la liste des options.
+
-
Adresses IP
-
-Avant d'aller plus loin, nous devons dire quelques mots au
- sujet de Internet Protocol (IP) addresses. Normalement, votre fournisseur
- Internet (ISP) vous assignera une seule adresse IP (single PublicIP
- address). Cette adresse peut être assignée par le Dynamic
- Host Configuration Protocol(DHCP) ou lors de l'établissement de
-votre connexion lorsque vous vous connectez (modem standard) ou établissez
- votre connexion PPP. Dans de rares cas , votre provider peut vous assigner
- une adresse statique (staticIP address); cela signifie que vous devez
- configurer l'interface externe de votre firewall afin d'utiliser cette adresse
- de manière permanente. Votre adresse externe assignée, elle
- va être partagée par tous vos systèmes lors de l'accès
- à Internet. Vous devrez assigner vos propres adresses dans votre réseau
-local (votre interface interne sur le firewall ainsi que les autres
+
Avant d'aller plus loin, nous devons dire quelques mots
+au sujet de Internet Protocol (IP) addresses. Normalement,
+votre fournisseur Internet (ISP) vous assignera une seule adresse IP
+(single PublicIP address). Cette adresse peut être
+assignée par le Dynamic Host Configuration Protocol(DHCP)
+ou lors de l'établissement de
+votre connexion lorsque vous vous connectez (modem standard) ou
+établissez votre connexion PPP. Dans de rares cas , votre
+provider peut vous assigner une adresse statique (staticIP
+address); cela signifie que vous devez configurer l'interface externe
+de votre firewall afin d'utiliser cette adresse de manière
+permanente. Votre adresse externe assignée, elle va être
+partagée par tous vos systèmes lors de l'accès
+à Internet. Vous devrez assigner vos propres adresses dans votre
+réseau
+local (votre interface interne sur le firewall ainsi que les
+autres
ordinateurs). La RFC 1918 réserve plusieurs plages d'IP (PrivateIP
address ranges) à cette fin :
-
10.0.0.0 - 10.255.255.255an
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
-
- Avant de lancer Shorewall, vous devriez regarder l'adresse
- IP de votre interface externe, et si elle est dans les plages précédentes,
- vous devriez enlever l'option 'norfc1918' dans la ligne concernant l'interface
- externe dans le fichier /etc/shorewall/interfaces.
-
-Vous devrez assigner vos adresses depuis le même sous-réseau
- (sub-network/subnet). Pour ce faire, nous pouvons considérer
- un sous-réseau dans une plage d'adresses x.y.z.0 - x.y.z.255. Chaque
- sous-réseau aura un masque (Subnet Mask) de 255.255.255.0.
-L'adresse x.y.z.0 est réservée comme l'adresse de sous-réseau
-(Subnet Address) et x.y.z.255 est réservée en tant qu'adresse
-de broadcast (Subnet Broadcast Address). Dans Shorewall, un
+ align="bottom" width="13" height="13" border="0">
+Avant de lancer Shorewall, vous devriez regarder l'adresse IP de votre
+interface externe, et si elle est dans les plages
+précédentes, vous devriez enlever l'option 'norfc1918'
+dans la ligne concernant l'interface externe dans le fichier
+/etc/shorewall/interfaces.
+Vous devrez assigner vos adresses depuis le même
+sous-réseau (sub-network/subnet). Pour ce faire, nous
+pouvons considérer un sous-réseau dans une plage
+d'adresses x.y.z.0 - x.y.z.255. Chaque sous-réseau aura un
+masque (Subnet Mask) de 255.255.255.0.
+L'adresse x.y.z.0 est réservée comme l'adresse de
+sous-réseau
+(Subnet Address) et x.y.z.255 est réservée en
+tant qu'adresse
+de broadcast (Subnet Broadcast Address). Dans Shorewall,
+un
sous-réseau est décrit en utilisant la notation Classless InterDomain
- Routing (CIDR) qui consiste en l'adresse du sous-réseau suivie
- par "/24". Le "24" se réfère au nombre consécutif de
- bits marquant "1" dans la partie gauche du masque de sous-réseau.
-
+ href="shorewall_setup_guide.htm#Subnets">la notation Classless
+InterDomain Routing (CIDR) qui consiste en l'adresse du
+sous-réseau suivie par "/24". Le "24" se réfère au
+nombre consécutif de bits marquant "1" dans la partie gauche du
+masque de sous-réseau.
Un exemple de sous-réseau (sub-network) :
-
+
- -
+
-
-
-
- |
+ |
+
+ |
Plage:
- |
-
+ |
+
10.10.10.0 - 10.10.10.255
- |
-
-
- |
+ |
+
+
+ |
Subnet Address:
- |
-
+ |
+
10.10.10.0
- |
-
-
- |
+ |
+
+
+ |
Broadcast Address:
- |
-
+ |
+
10.10.10.255
- |
-
-
- |
+ |
+
+
+ |
CIDR Notation:
- |
-
+ |
+
10.10.10.0/24
- |
-
-
-
+
+
+
-
+
-
-Il est de mise d'assigner l'interface interne (LAN) à
- la première adresse utilisable du sous-réseau (10.10.10.1
-dans l'exemple précédent) ou la dernière adresse utilisable
- (10.10.10.254).
-
-L'un des buts d'un sous-réseau est de permettre à
- tous les ordinateurs dans le sous-réseau de savoir avec quels autres
- ordinateurs ils peuvent communiquer directement. Pour communiquer avec des
- systèmes en dehors du sous-réseau, les ordinateurs envoient
- des paquets à travers le gateway (routeur).
-
+Il est de mise d'assigner l'interface interne (LAN)
+à la première adresse utilisable du sous-réseau
+(10.10.10.1
+dans l'exemple précédent) ou la dernière adresse
+utilisable (10.10.10.254).
+L'un des buts d'un sous-réseau est de permettre
+à tous les ordinateurs dans le sous-réseau de savoir avec
+quels autres ordinateurs ils peuvent communiquer directement. Pour
+communiquer avec des systèmes en dehors du sous-réseau,
+les ordinateurs envoient des paquets à travers le gateway
+(routeur).
- Vos ordinateurs en local (ordinateur 1 et ordinateur
-2 dans le diagramme) devraient être configurés avec leur passerelle
- par défaut (default gateway) pointant sur l'adresse IP de l'interface
+ align="bottom" width="13" height="13" border="0">
+Vos ordinateurs en local (ordinateur 1 et ordinateur 2 dans le
+diagramme) devraient être configurés avec leur passerelle
+par défaut (default gateway) pointant sur l'adresse IP de
+l'interface
interne du firewall.
-
-The foregoing short discussion barely scratches the surface
- regarding subnetting and routing. If you are interested in learning more
-about IP addressing and routing, I highly recommend "IP Fundamentals:
-What Everyone Needs to Know about Addressing & Routing", Thomas A.
+
The foregoing short discussion barely scratches the
+surface regarding subnetting and routing. If you are interested in
+learning more
+about IP addressing and routing, I highly recommend "IP
+Fundamentals:
+What Everyone Needs to Know about Addressing & Routing", Thomas
+A.
Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
-
-Le reste de ce guide assumera que vous avez configuré
- votre réseau comme montré ci-dessous :
-
+Le reste de ce guide assumera que vous avez
+configuré votre réseau comme montré ci-dessous :
-
-
-La passerelle par défaut pour les ordinateurs 1 et
- 2 devrait être 10.10.10.254.
-
+ align="bottom" width="444" height="635" border="0">
+La passerelle par défaut pour les ordinateurs 1
+et 2 devrait être 10.10.10.254.
IP Masquerading (SNAT)
-
-Les adresses réservées par la RFC 1918 sont
- parfois désignées comme non-routables car les routeurs
- Internet (backbone) ne font pas circuler les paquets qui ont une adresse
-de destination appartenant à la RFC-1918. Lorsqu'un de vos systèmes
- en local (supposons l'ordinateur1) demande une connexion à un serveur
- par Internet, le firewall doit appliquer un NAT (Network Address Translation).
- Le firewall ré écrit l'adresse source dans le paquet, et l'a
- remplace par l'adresse de l'interface externe du firewall; en d'autres mots,
- le firewall fait croire que c'est lui même qui initie la connexion.
- Ceci est nécessaire afin que l'hôte de destination soit capable
- de renvoyer les paquets au firewall (souvenez vous que les paquets qui ont
- pour adresse de destination, une adresse réservée par la RFC
- 1918 ne pourront pas être routés à travers Internet,
-donc l'hôte Internet ne pourra adresser sa réponse à
-l'ordinateur 1). Lorsque le firewall reçoit le paquet de réponse,
-il remet l'adresse de destination à 10.10.10.1 et fait passer le paquet
+
Les adresses réservées par la RFC 1918
+sont parfois désignées comme non-routables car
+les routeurs Internet (backbone) ne font pas circuler les paquets qui
+ont une adresse
+de destination appartenant à la RFC-1918. Lorsqu'un de vos
+systèmes en local (supposons l'ordinateur1) demande une
+connexion à un serveur par Internet, le firewall doit appliquer
+un NAT (Network Address Translation). Le firewall ré
+écrit l'adresse source dans le paquet, et l'a remplace par
+l'adresse de l'interface externe du firewall; en d'autres mots, le
+firewall fait croire que c'est lui même qui initie la connexion.
+Ceci est nécessaire afin que l'hôte de destination soit
+capable de renvoyer les paquets au firewall (souvenez vous que les
+paquets qui ont pour adresse de destination, une adresse
+réservée par la RFC 1918 ne pourront pas être
+routés à travers Internet,
+donc l'hôte Internet ne pourra adresser sa réponse
+à
+l'ordinateur 1). Lorsque le firewall reçoit le paquet de
+réponse,
+il remet l'adresse de destination à 10.10.10.1 et fait passer le
+paquet
vers l'ordinateur 1.
-
-Sur les systèmes Linux, ce procédé est
- souvent appelé de l'IP Masquerading mais vous verrez aussi
-le terme de Source Network Address Translation (SNAT) utilisé.
- Shorewall suit la convention utilisée avec Netfilter:
-
+Sur les systèmes Linux, ce procédé
+est souvent appelé de l'IP Masquerading mais vous verrez
+aussi
+le terme de Source Network Address Translation (SNAT)
+utilisé. Shorewall suit la convention utilisée avec
+Netfilter:
- -
-
Masquerade désigne le cas ou vous laissez
- votre firewall détecter automatiquement l'adresse de l'interface
-externe.
-
- -
-
SNAT désigne le cas où vous spécifiez
- explicitement l'adresse source des paquets sortant de votre réseau
- local.
-
-
+ -
+
Masquerade désigne le cas ou vous
+laissez votre firewall détecter automatiquement l'adresse de
+l'interface
+externe.
+
+ -
+
SNAT désigne le cas où vous
+spécifiez explicitement l'adresse source des paquets sortant de
+votre réseau local.
+
-
-Sous Shorewall, autant le Masquerading que le SNAT sont configuré
- avec des entrés dans le fichier /etc/shorewall/masq. Vous utiliserez
- normalement le Masquerading si votre adresse IP externe est dynamique, et
- SNAT si elle est statique.
-
+Sous Shorewall, autant le Masquerading que le SNAT sont
+configuré avec des entrés dans le fichier
+/etc/shorewall/masq. Vous utiliserez normalement le Masquerading si
+votre adresse IP externe est dynamique, et SNAT si elle est statique.
- Si votre interface externe du firewall est eth0,
- vous n'avez pas besoin de modifier le fichier fourni avec l'exemple. Dans
- le cas contraire, éditez /etc/shorewall/masq et changez la première
- colonne par le nom de votre interface externe, et la seconde colonne par
+ align="bottom" width="13" height="13" border="0">
+Si votre interface externe du firewall est eth0, vous n'avez
+pas besoin de modifier le fichier fourni avec l'exemple. Dans le cas
+contraire, éditez /etc/shorewall/masq et changez la
+première colonne par le nom de votre interface externe, et la
+seconde colonne par
le nom de votre interface interne.
-
- Si votre IP externe est statique, vous pouvez la mettre
- dans la troisième colonne dans /etc/shorewall/masq si vous le désirez,
- de toutes façons votre firewall fonctionnera bien si vous laissez
-cette colonne vide. Le fait de mettre votre IP statique dans la troisième
- colonne permet un traitement des paquets sortant un peu plus efficace.
-
-
- Si vous utilisez les paquets Debian, vérifiez
-que votre fichier de configuration shorewall.conf contient bien les valeurs
-suivantes, si elles n'y sont pas faite les changements nécessaires:
-
+ align="bottom" width="13" height="13" border="0">
+Si votre IP externe est statique, vous pouvez la mettre dans la
+troisième colonne dans /etc/shorewall/masq si vous le
+désirez, de toutes façons votre firewall fonctionnera
+bien si vous laissez
+cette colonne vide. Le fait de mettre votre IP statique dans la
+troisième colonne permet un traitement des paquets sortant un
+peu plus efficace.
+
+ Si vous utilisez les
+paquets Debian, vérifiez que votre fichier de configuration
+shorewall.conf contient bien les valeurs suivantes, si elles n'y sont
+pas faite les changements nécessaires:
- -
-
NAT_ENABLED=Yes
-
- -
+
-
+
NAT_ENABLED=Yes
+
+ -
IP_FORWARDING=On
-
-
+
-
Port Forwarding (DNAT)
-
-Un de nos buts est de , peut être, faire tourner un
- ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces ordinateurs
- on une adresse RFC-1918, il n' est pas possible pour les clients sur Internet
- de se connecter directement à eux. Il est nécessaire à
- ces clients d'adresser leurs demandes de connexion au firewall qui ré
- écrit l'adresse de destination de votre serveur, et fait passer le
- paquet à celui-ci. Lorsque votre serveur répond, le firewall
- applique automatiquement un SNAT pour ré écrire l'adresse
-source dans la réponse.
-
-Ce procédé est appelé Port Forwarding
- ou Destination Network Address Translation(DNAT). Vous configurez
-le port forwarding en utilisant les règles DNAT dans le fichier /etc/shorewall/rules.
-
-La forme générale d'une simple règle de port forwarding
- dans /etc/shorewall/rules est:
-
+Un de nos buts est de , peut être, faire tourner
+un ou plusieurs serveurs sur nos ordinateurs locaux. Parce que ces
+ordinateurs on une adresse RFC-1918, il n' est pas possible pour les
+clients sur Internet de se connecter directement à eux. Il est
+nécessaire à ces clients d'adresser leurs demandes de
+connexion au firewall qui ré écrit l'adresse de
+destination de votre serveur, et fait passer le paquet à
+celui-ci. Lorsque votre serveur répond, le firewall applique
+automatiquement un SNAT pour ré écrire l'adresse
+source dans la réponse.
+Ce procédé est appelé Port
+Forwarding ou Destination Network Address Translation(DNAT).
+Vous configurez
+le port forwarding en utilisant les règles DNAT dans le fichier
+/etc/shorewall/rules.
+La forme générale d'une simple règle de port
+forwarding dans /etc/shorewall/rules est:
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
DNAT
- |
-
+ |
+
net
- |
-
- loc:<server local ip address> [:<server port>]
- |
-
+ |
+
+ loc:<server local ip address> [:<server
+port>]
+ |
+
<protocol>
- |
-
+ |
+
<port>
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
-Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et vous
- voulez faire passer les requêtes TCP sur le port 80 à ce système
- :
-
+Exemple - vous faites tourner un serveur Web sur l'ordinateur 2 et
+vous voulez faire passer les requêtes TCP sur le port 80 à
+ce système :
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
DNAT
- |
-
+ |
+
net
- |
-
+ |
+
loc:10.10.10.2
- |
-
+ |
+
tcp
- |
-
+ |
+
80
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
Deux points importants à garder en mémoire :
-
- -
-
Vous devez tester la règle précédente
- depuis un client à l'extérieur de votre réseau local
- (c.a.d., ne pas tester depuis un navigateur tournant sur l'ordinateur 1
-ou 2 ou sur le firewall). Si vous voulez avoir la possibilité d'accéder
- à votre serveur web en utilisant l'adresse IP externe de votre firewall,
- regardez Shorewall FAQ #2.
-
- -
-
Quelques fournisseurs Internet (Provider/ISP) bloquent les requêtes
- entrantes de connexion sur le port 80. Si vous avez des problèmes
- à vous connecter à votre serveur web, essayez la règle
- suivante et connectez vous sur le port 5000.
-
-
+ -
+
Vous devez tester la règle
+précédente depuis un client à l'extérieur
+de votre réseau local (c.a.d., ne pas tester depuis un
+navigateur tournant sur l'ordinateur 1
+ou 2 ou sur le firewall). Si vous voulez avoir la possibilité
+d'accéder à votre serveur web en utilisant l'adresse IP
+externe de votre firewall, regardez Shorewall
+FAQ #2.
+
+ -
+
Quelques fournisseurs Internet (Provider/ISP) bloquent les
+requêtes entrantes de connexion sur le port 80. Si vous avez des
+problèmes à vous connecter à votre serveur web,
+essayez la règle suivante et connectez vous sur le port 5000.
+
-
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
DNAT
- |
-
+ |
+
net
- |
-
+ |
+
loc:10.10.10.2:80
- |
-
+ |
+
tcp
- |
-
+ |
+
5000
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
- A ce point, modifiez /etc/shorewall/rules pour ajouter
- les règles DNAT dont vous avez besoin.
-
+ width="13" height="13" border="0"> A ce point,
+modifiez /etc/shorewall/rules pour ajouter les règles DNAT dont
+vous avez besoin.
Domain Name Server (DNS)
-
-Normalement, quand vous vous connectez à votre fournisseur
- (ISP), une partie consiste à obtenir votre adresse IP, votre DNS
-pour le firewall (Domain Name Service) est configuré automatiquement
- (c.a.d.,le fichier /etc/resolv.conf a été écrit). Il
- arrive que votre provider vous donne une paire d'adresse IP pour les DNS
- (name servers) afin que vous configuriez manuellement votre serveur
-de nom primaire et secondaire. La manière dont le DNS est configuré
- sur votre firewall est de votre responsabilité. Vous pouvez
- procéder d'une de ses deux façons :
-
+Normalement, quand vous vous connectez à votre
+fournisseur (ISP), une partie consiste à obtenir votre adresse
+IP, votre DNS
+pour le firewall (Domain Name Service) est configuré
+automatiquement (c.a.d.,le fichier /etc/resolv.conf a été
+écrit). Il arrive que votre provider vous donne une paire
+d'adresse IP pour les DNS (name servers) afin que vous
+configuriez manuellement votre serveur
+de nom primaire et secondaire. La manière dont le DNS est
+configuré sur votre firewall est de votre
+responsabilité. Vous pouvez procéder d'une de ses deux
+façons :
- -
-
Vous pouvez configurer votre système interne
-pour utiliser les noms de serveurs de votre provider. Si votre fournisseur
-vous donne les adresses de leurs serveurs ou si ces adresses sont disponibles
- sur leur site web, vous pouvez configurer votre système interne
-afin de les utiliser. Si cette information n' est pas disponible, regardez
-dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont
- donnés dans l'enregistrement "nameserver" dans ce fichier.
-
- -
+
-
+
Vous pouvez configurer votre système interne
+pour utiliser les noms de serveurs de votre provider. Si votre
+fournisseur
+vous donne les adresses de leurs serveurs ou si ces adresses sont
+disponibles sur leur site web, vous pouvez configurer votre
+système interne
+afin de les utiliser. Si cette information n' est pas disponible,
+regardez
+dans /etc/resolv.conf sur votre firewall -- les noms des serveurs sont
+donnés dans l'enregistrement "nameserver" dans ce fichier.
+
+ -
- Vous pouvez configurer un cache dns (Caching Name
- Server) sur votre firewall. Red Hat a un RPM pour mettre en
-cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les
-utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette approche,
-vous configurez votre système interne pour utiliser le firewall
-lui même comme étant le seul serveur de nom primaire. Vous
-pouvez utiliser l'adresse IP interne du firewall (10.10.10.254 dans l'exemple)
-pour l'adresse de serveur de nom. Pour permettre à vos systèmes
-locaux de discuter avec votre serveur cache de nom, vous devez ouvrir le
-port 53 (UDP ET TCP) sur le firewall vers le réseau local;
-vous ferez ceci en ajoutant les règles suivantes dans /etc/shorewall/rules.
-
-
-
+ align="bottom" width="13" height="13" border="0">
+Vous pouvez configurer un cache dns (Caching Name Server) sur
+votre firewall. Red Hat a un RPM pour mettre en
+cache un serveur de nom (le RPM requis aussi le RPM 'bind') et pour les
+utilisateurs de Bering, il y a dnscache.lrp. Si vous adoptez cette
+approche,
+vous configurez votre système interne pour utiliser le firewall
+lui même comme étant le seul serveur de nom primaire. Vous
+pouvez utiliser l'adresse IP interne du firewall (10.10.10.254 dans
+l'exemple)
+pour l'adresse de serveur de nom. Pour permettre à vos
+systèmes
+locaux de discuter avec votre serveur cache de nom, vous devez ouvrir
+le
+port 53 (UDP ET TCP) sur le firewall vers le réseau local;
+vous ferez ceci en ajoutant les règles suivantes dans
+/etc/shorewall/rules.
+
-
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
loc
- |
-
+ |
+
fw
- |
-
+ |
+
tcp
- |
-
+ |
+
53
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
loc
- |
-
+ |
+
fw
- |
-
+ |
+
udp
- |
-
+ |
+
53
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
Autres Connexions
-
-Les fichiers exemples inclus dans l'archive (two-interface)
- contiennent les règles suivantes :
-
+Les fichiers exemples inclus dans l'archive
+(two-interface) contiennent les règles suivantes :
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
fw
- |
-
+ |
+
net
- |
-
+ |
+
tcp
- |
-
+ |
+
53
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
fw
- |
-
+ |
+
net
- |
-
+ |
+
udp
- |
-
+ |
+
53
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
-Ces règles autorisent l'accès DNS à
-partir de votre firewall et peuvent être enlevées si vous avez
-dé commenté la ligne dans /etc/shorewall/policy autorisant
+
Ces règles autorisent l'accès DNS
+à
+partir de votre firewall et peuvent être enlevées si vous
+avez
+dé commenté la ligne dans /etc/shorewall/policy
+autorisant
toutes les connexions depuis le firewall vers Internet.
-
Les exemples contiennent aussi :
-
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
loc
- |
-
+ |
+
fw
- |
-
+ |
+
tcp
- |
-
+ |
+
22
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
-Cette règle vous autorise à faire tourner un
- serveur SSH sur votre firewall et à vous y connecter depuis votre
+
Cette règle vous autorise à faire tourner
+un serveur SSH sur votre firewall et à vous y connecter depuis
+votre
réseau local.
-
-Si vous voulez permettre d'autres connexions entre votre
-firewall et d'autres systèmes, la forme générale est
+
Si vous voulez permettre d'autres connexions entre
+votre
+firewall et d'autres systèmes, la forme générale
+est
:
-
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
<source zone>
- |
-
+ |
+
<destination zone>
- |
-
+ |
+
<protocol>
- |
-
+ |
+
<port>
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
-Exemple - Vous voulez faire tourner un serveur Web sur votre
- firewall :
-
+Exemple - Vous voulez faire tourner un serveur Web sur
+votre firewall :
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
net
- |
-
+ |
+
fw
- |
-
+ |
+
tcp
- |
-
+ |
+
80
- |
-
+ |
+
#Permet l'accès Web
- |
-
+ |
+
depuis Internet
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
loc
- |
-
+ |
+
fw
- |
-
+ |
+
tcp
- |
-
+ |
+
80
- |
-
+ |
+
#Permet l'accès Web
-
- |
-
+
+ |
+
depuis Internet
- |
-
-
-
+
+
+
-
+
-
-Ces deux règles bien sûr viennent s'ajouter
-aux règles décrites précédemment dans "Vous pouvez
- configurer un cache dns (Caching Name Server) sur votre firewall"
-
-Si vous ne savez pas quel port et quel protocole une application
- particulière utilise, regardez ici.
-
-Important: Je ne vous recommande pas de permettre
-le telnet depuis ou vers Internet car il utilise du texte en clair (même
- pour le login et le mot de passe!). Si vous voulez un accès au shell
- sur votre firewall depuis Internet, utilisez SSH :
-
+Ces deux règles bien sûr viennent
+s'ajouter
+aux règles décrites précédemment dans "Vous
+pouvez configurer un cache dns (Caching Name Server) sur votre
+firewall"
+Si vous ne savez pas quel port et quel protocole une
+application particulière utilise, regardez ici.
+Important: Je ne vous recommande pas de
+permettre
+le telnet depuis ou vers Internet car il utilise du texte en clair
+(même pour le login et le mot de passe!). Si vous voulez un
+accès au shell sur votre firewall depuis Internet, utilisez SSH :
+
- -
+
-
-
-
- |
+ |
+
+ |
ACTION
- |
-
+ |
+
SOURCE
- |
-
+ |
+
DESTINATION
- |
-
+ |
+
PROTOCOL
- |
-
+ |
+
PORT
- |
-
+ |
+
SOURCE PORT
- |
-
+ |
+
ORIGINAL ADDRESS
- |
-
-
- |
+ |
+
+
+ |
ACCEPT
- |
-
+ |
+
net
- |
-
+ |
+
fw
- |
-
+ |
+
tcp
- |
-
+ |
+
22
- |
-
+ |
+
- |
-
+ |
+
- |
-
-
-
+
+
+
-
+
-
- Maintenant éditez votre fichier /etc/shorewall/rules
- pour ajouter ou supprimer les connexions voulues.
-
+ align="bottom" width="13" height="13" border="0">
+Maintenant éditez votre fichier /etc/shorewall/rules pour
+ajouter ou supprimer les connexions voulues.
Lancer et Arrêter votre Firewall
-
- La procédure d'installation
- configure votre système pour lancer Shorewall au boot du système,
- mais pour les débutants sous Shorewall version 1.3.9, le lancement
- est désactivé tant que la configuration n' est pas finie.
-Une fois la configuration de votre firewall achevée, vous pouvez
-permettre le lancement de Shorewall en enlevant le fichier /etc/shorewall/startup_disabled.
-
-IMPORTANT: Les utilisateurs
-des paquets .deb doivent éditer /etc/default/shorewall et mettre 'startup=1'.
-
-Le firewall est lancé en utilisant la commande "shorewall
- start" et stoppé avec "shorewall stop". Lorsque le firewall est stoppé,
- le routage est permis sur les hôtes qui sont dans le fichier/etc/shorewall/routestopped. Un
- firewall fonctionnant peut être relancé en utilisant la commande
- "shorewall restart". Si vous voulez enlever toutes les traces de Shorewall
- dans votre configuration de Netfilter, utilisez "shorewall clear".
-
+ La procédure
+d'installation configure votre système pour lancer Shorewall
+au boot du système, mais pour les débutants sous
+Shorewall version 1.3.9, le lancement est désactivé tant
+que la configuration n' est pas finie.
+Une fois la configuration de votre firewall achevée, vous pouvez
+permettre le lancement de Shorewall en enlevant le fichier
+/etc/shorewall/startup_disabled.
+IMPORTANT: Les
+utilisateurs
+des paquets .deb doivent éditer /etc/default/shorewall et mettre
+'startup=1'.
+Le firewall est lancé en utilisant la commande
+"shorewall start" et stoppé avec "shorewall stop". Lorsque le
+firewall est stoppé, le routage est permis sur les hôtes
+qui sont dans le fichier/etc/shorewall/routestopped.
+Un firewall fonctionnant peut être relancé en utilisant la
+commande "shorewall restart". Si vous voulez enlever toutes les traces
+de Shorewall dans votre configuration de Netfilter, utilisez "shorewall
+clear".
- Les exemples (two-interface) supposent que vous voulez
- permettre le routage depuis ou vers eth1 (le réseau local)
-lorsque Shorewall est stoppé. Si votre réseau local n' est
-pas connecté à eth1 ou si vous voulez permettre l'accès
-depuis ou vers d'autres hôtes, changez /etc/shorewall/routestopped
+ align="bottom" width="13" height="13" border="0">
+Les exemples (two-interface) supposent que vous voulez permettre le
+routage depuis ou vers eth1 (le réseau local)
+lorsque Shorewall est stoppé. Si votre réseau local n'
+est
+pas connecté à eth1 ou si vous voulez permettre
+l'accès
+depuis ou vers d'autres hôtes, changez
+/etc/shorewall/routestopped
en conséquence.
-
-ATTENTION: Si vous êtes connecté à
- votre firewall depuis Internet, n'essayez pas la commande "shorewall stop"
- tant que vous n'avez pas ajouté une entrée pour votre adresse
- IP depuis laquelle vous êtes connecté dans/etc/shorewall/routestopped. De
- plus, je ne vous recommande pas d'utiliser "shorewall restart"; il est mieux
- de créer une configuration
- alternative et de l'essayer en utilisant la commandeATTENTION: Si vous êtes connecté
+à votre firewall depuis Internet, n'essayez pas la commande
+"shorewall stop" tant que vous n'avez pas ajouté une
+entrée pour votre adresse IP depuis laquelle vous êtes
+connecté dans/etc/shorewall/routestopped.
+De plus, je ne vous recommande pas d'utiliser "shorewall restart"; il
+est mieux de créer une configuration
+alternative et de l'essayer en utilisant la commande"shorewall try".
-
Last updated 12/20/2002 - Tom Eastep
-
-Copyright 2002 Thomas
- M. Eastep
-
-
-
-
-
-
-
-
-
-
+Copyright 2002
+Thomas M. Eastep
+
+
+
+
+
+
+
+
+
+
diff --git a/Shorewall-docs/upgrade_issues.htm b/Shorewall-docs/upgrade_issues.htm
index 3d7fe7683..32cf343ff 100755
--- a/Shorewall-docs/upgrade_issues.htm
+++ b/Shorewall-docs/upgrade_issues.htm
@@ -1,471 +1,378 @@
-
Upgrade Issues
-
-
-
-
-
-
-
-
-
-
- Upgrade Issues
- |
-
-
-
-
-
-For upgrade instructions see the Install/Upgrade page.
-
-
-It is important that you read all of the sections on this page where the
- version number mentioned in the section title is later than what you
- are currently running.
-
-
- In the descriptions that follows, the term group refers
- to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
- be a host address) accessed through a particular interface.
-
-
+
+Upgrade Issues
+
+For upgrade instructions see the Install/Upgrade
+page.
+
+It is important that you read all of the sections on this page where
+the version number mentioned in the section title is later than what
+you are currently running.
+
+ In the descriptions that follows, the term group refers
+to a particular network or subnetwork (which may be 0.0.0.0/0 or it may
+be a host address) accessed through a particular interface.
+
Examples:
-
- eth0:0.0.0.0/0
- eth2:192.168.1.0/24
- eth3:192.0.2.123
-
-
- You can use the "shorewall check" command to see the groups associated
- with each of your zones.
-
-
+
+ eth0:0.0.0.0/0
+ eth2:192.168.1.0/24
+ eth3:192.0.2.123
+
+ You can use the "shorewall check" command to see the groups
+associated with each of your zones.
+
-
+Version >= 1.4.8
+
+ - The meaning of ROUTE_FILTER=Yes has changed. Previously this
+setting was documented as causing route filtering to occur on all
+network interfaces; this didn't work. Beginning with this release,
+ROUTE_FILTER=Yes causes route filtering to occur on all interfaces
+brought up while Shorewall is running. This means that it may be
+appropriate to set ROUTE_FILTER=Yes and use the routefilter
+option in /etc/shorewall/interfaces
+entries.
+
+
Version >= 1.4.6
-
- - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been removed
-from shorewall.conf. These capabilities are now automatically detected by
-Shorewall.
- - An undocumented feature previously allowed entries in the host
-file as follows:
-
- zone eth1:192.168.1.0/24,eth2:192.168.2.0/24
-
- This capability was never documented and has been removed in 1.4.6 to allow
-entries of the following format:
-
- zone eth1:192.168.1.0/24,192.168.2.0/24
-
-
-
-
-Version >= 1.4.4
- If you are upgrading from 1.4.3 and have set the LOGMARKER variable
-in /etc/shorewall/shorewall.conf, then
-you must set the new LOGFORMAT variable appropriately and remove your setting
- of LOGMARKER
+ - The NAT_ENABLED, MANGLE_ENABLED and MULTIPORT options have been
+removed from shorewall.conf. These capabilities are now automatically
+detected by Shorewall.
+ - An undocumented feature previously allowed entries in the
+host file as follows:
-
+ zone eth1:192.168.1.0/24,eth2:192.168.2.0/24
+
+This capability was never documented and has been removed in 1.4.6 to
+allow entries of the following format:
+
+ zone eth1:192.168.1.0/24,192.168.2.0/24
+
+
+Version >= 1.4.4
+If you are upgrading from 1.4.3 and have set the LOGMARKER variable
+in /etc/shorewall/shorewall.conf,
+then you must set the new LOGFORMAT variable appropriately and remove
+your setting of LOGMARKER
+
Version 1.4.4
-
- If you have zone names that are 5 characters long, you may experience
-problems starting Shorewall because the --log-prefix in a logging rule
-is too long. Upgrade to Version 1.4.4a to fix this problem..
-
+
+If you have zone names that are 5 characters long, you may experience
+problems starting Shorewall because the --log-prefix in a logging rule
+is too long. Upgrade to Version 1.4.4a to fix this problem..
Version >= 1.4.2
- There are some cases where you may want to handle traffic from a particular
- group to itself. While I personally think that such a setups are ridiculous,
- there are two cases covered in this documentation where it can occur:
-
+There are some cases where you may want to handle traffic from a
+particular group to itself. While I personally think that such a setups
+are ridiculous, there are two cases covered in this documentation where
+it can occur:
- - In FAQ #2.
- - When running Squid as a
-transparent proxy in your local zone.
-
+ - In FAQ #2.
+ - When running Squid as a
+transparent proxy in your local zone.
- If you have either of these cases, you will want to review the current
- documentation and change your configuration accordingly.
-
+If you have either of these cases, you will want to review the current
+documentation and change your configuration accordingly.
Version >= 1.4.1
-
- - Beginning with Version 1.4.1, traffic between groups in
-the same zone is accepted by default. Previously, traffic from a zone
-to itself was treated just like any other traffic; any matching rules
-were applied followed by enforcement of the appropriate policy. With 1.4.1
-and later versions, unless you have explicit rules for traffic from Z
-to Z or you have an explicit Z to Z policy (where "Z" is some zone) then
-traffic between the groups in zone Z will be accepted. If you do have one
-or more explicit rules for Z to Z or if you have an explicit Z to Z policy
-then the behavior is as it was in prior versions.
-
+ - Beginning with Version 1.4.1, traffic between groups in
+the same zone is accepted by default. Previously, traffic from a zone
+to itself was treated just like any other traffic; any matching rules
+were applied followed by enforcement of the appropriate policy. With
+1.4.1
+and later versions, unless you have explicit rules for traffic from Z
+to Z or you have an explicit Z to Z policy (where "Z" is some zone)
+then
+traffic between the groups in zone Z will be accepted. If you do have
+one
+or more explicit rules for Z to Z or if you have an explicit Z to Z
+policy
+then the behavior is as it was in prior versions.
-
-
+
- - If you have a Z Z ACCEPT policy for a zone to allow traffic
- between two interfaces to the same zone, that policy can be removed
-and traffic between the interfaces will traverse fewer rules than previously.
- - If you have a Z Z DROP or Z Z REJECT policy or you have
- Z->Z rules then your configuration should not require any change.
- - If you are currently relying on a implicit policy (one
-that has "all" in either the SOURCE or DESTINATION column) to prevent
-traffic between two interfaces to a zone Z and you have no rules for
-Z->Z then you should add an explicit DROP or REJECT policy for Z to
+
- If you have a Z Z ACCEPT policy for a zone to allow traffic
+between two interfaces to the same zone, that policy can be removed
+and traffic between the interfaces will traverse fewer rules than
+previously.
+ - If you have a Z Z DROP or Z Z REJECT policy or you have Z->Z
+rules then your configuration should not require any change.
+ - If you are currently relying on a implicit policy (one
+that has "all" in either the SOURCE or DESTINATION column) to prevent
+traffic between two interfaces to a zone Z and you have no rules for
+Z->Z then you should add an explicit DROP or REJECT policy for Z to
Z.
-
-
+
-
-
+
- - Sometimes, you want two separate zones on one interface but
- you don't want Shorewall to set up any infrastructure to handle traffic
- between them.
-
+ - Sometimes, you want two separate zones on one interface but you
+don't want Shorewall to set up any infrastructure to handle traffic
+between them.
-
Example:
-
-
+
/etc/shorewall/zones
z1 Zone1 The first Zone
z2 Zone2 The secont Zone
/etc/shorewall/interfaces
z2 eth1 192.168.1.255
/etc/shorewall/hosts
z1 eth1:192.168.1.3
-
- Here, zone z1 is nested in zone z2 and the firewall is not going
- to be involved in any traffic between these two zones. Beginning with
-Shorewall 1.4.1, you can prevent Shorewall from setting up any infrastructure
-to handle traffic between z1 and z2 by using the new NONE policy:
-
-
+
+Here, zone z1 is nested in zone z2 and the firewall is not going to be
+involved in any traffic between these two zones. Beginning with
+Shorewall 1.4.1, you can prevent Shorewall from setting up any
+infrastructure
+to handle traffic between z1 and z2 by using the new NONE policy:
+
/etc/shorewall/policy
z1 z2 NONE
z2 z1 NONE
-
- Note that NONE policies are generally used in pairs unless there
- is asymetric routing where only the traffic on one direction flows through
- the firewall and you are using a NONE polciy in the other direction.
-
+
+Note that NONE policies are generally used in pairs unless there is
+asymetric routing where only the traffic on one direction flows through
+the firewall and you are using a NONE polciy in the other
+direction.
Version 1.4.1
-
-
+
- - In Version 1.4.1, Shorewall will never create rules to
- deal with traffic from a given group back to itself. The multi
- interface option is no longer available so if you want to route traffic
-between two subnetworks on the same interface then I recommend that you
-upgrade to Version 1.4.2 and use the 'routeback' interface or host option.
-
+ - In Version 1.4.1, Shorewall will never create rules to deal with
+traffic from a given group back to itself. The multi interface
+option is no longer available so if you want to route traffic between
+two subnetworks on the same interface then I recommend that you upgrade
+to Version 1.4.2 and use the 'routeback' interface or host option.
-
Version >= 1.4.0
- IMPORTANT: Shorewall >=1.4.0 requires the
- iproute package ('ip' utility).
-
- Note: Unfortunately, some distributions call this package
- iproute2 which will cause the upgrade of Shorewall to fail with the
+IMPORTANT: Shorewall >=1.4.0 requires the iproute
+package ('ip' utility).
+
+Note: Unfortunately, some distributions call this package
+iproute2 which will cause the upgrade of Shorewall to fail with the
diagnostic:
-
- error: failed dependencies:iproute is needed by shorewall-1.4.0-1
-
-
- This may be worked around by using the --nodeps option of rpm
- (rpm -Uvh --nodeps <shorewall rpm>).
-
- If you are upgrading from a version < 1.4.0, then:
-
+
+ error: failed dependencies:iproute is needed by
+shorewall-1.4.0-1
+
+This may be worked around by using the --nodeps option of rpm (rpm -Uvh
+--nodeps <shorewall rpm>).
+
+If you are upgrading from a version < 1.4.0, then:
- - The noping and forwardping interface
- options are no longer supported nor is the FORWARDPING option
- in shorewall.conf. ICMP echo-request (ping) packets are treated just
- like any other connection request and are subject to rules and policies.
- - Interface names of the form <device>:<integer>
- in /etc/shorewall/interfaces now generate a Shorewall error at startup
- (they always have produced warnings in iptables).
- - The MERGE_HOSTS variable has been removed from shorewall.conf.
- Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
- contents are determined by BOTH the interfaces and hosts files when
- there are entries for the zone in both files.
- - The routestopped option in the interfaces
-and hosts file has been eliminated; use entries in the routestopped
-file instead.
- - The Shorewall 1.2 syntax for DNAT and REDIRECT rules
- is no longer accepted; you must convert to using the new syntax.
- - The ALLOWRELATED variable in shorewall.conf
- is no longer supported. Shorewall 1.4 behavior is the same as 1.3
-with ALLOWRELATED=Yes.
- - Late-arriving DNS replies are now dropped
- by default; there is no need for your own /etc/shorewall/common file
- simply to avoid logging these packets.
- - The 'firewall', 'functions' and 'version'
- file have been moved to /usr/share/shorewall.
- - The icmp.def file has been removed. If you
- include it from /etc/shorewall/icmpdef, you will need to modify that
- file.
-
+ - The noping and forwardping interface options are
+no longer supported nor is the FORWARDPING option in
+shorewall.conf. ICMP echo-request (ping) packets are treated just like
+any other connection request and are subject to rules and policies.
+ - Interface names of the form <device>:<integer> in
+/etc/shorewall/interfaces now generate a Shorewall error at startup
+(they always have produced warnings in iptables).
+ - The MERGE_HOSTS variable has been removed from shorewall.conf.
+Shorewall 1.4 behaves like 1.3 did when MERGE_HOSTS=Yes; that is zone
+contents are determined by BOTH the interfaces and hosts files when
+there are entries for the zone in both files.
+ - The routestopped option in the interfaces
+and hosts file has been eliminated; use entries in the routestopped
+file instead.
+ - The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer
+accepted; you must convert to using the new syntax.
+ - The ALLOWRELATED variable in shorewall.conf is no
+longer supported. Shorewall 1.4 behavior is the same as 1.3 with
+ALLOWRELATED=Yes.
+ - Late-arriving DNS replies are now dropped by default;
+there is no need for your own /etc/shorewall/common file simply to
+avoid logging these packets.
+ - The 'firewall', 'functions' and 'version' file have
+been moved to /usr/share/shorewall.
+ - The icmp.def file has been removed. If you include it
+from /etc/shorewall/icmpdef, you will need to modify that file.
- - If you followed the advice in FAQ #2 and call find_interface_address
- in /etc/shorewall/params, that code should be moved to /etc/shorewall/init.
-
-
+ - If you followed the advice in FAQ #2 and call
+find_interface_address in /etc/shorewall/params, that code should be
+moved to /etc/shorewall/init.
+
-
-
Version 1.4.0
-
- - The 'multi' interface option is no longer supported.
- Shorewall will generate rules for sending packets back out the same
- interface that they arrived on in two cases:
-
+ - The 'multi' interface option is no longer supported.
+ Shorewall will generate rules for sending packets back out the
+same interface that they arrived on in two cases:
-
-
+
- - There is an explicit policy for the source zone
-to or from the destination zone. An explicit policy names both zones
-and does not use the 'all' reserved word.
-
+ - There is an explicit policy for the source zone to or
+from the destination zone. An explicit policy names both zones and does
+not use the 'all' reserved word.
-
- - There are one or more rules for traffic for the source
-zone to or from the destination zone including rules that use the 'all'
-reserved word. Exception: if the source zone and destination zone are
-the same then the rule must be explicit - it must name the zone in both
-the SOURCE and DESTINATION columns.
-
+ - There are one or more rules for traffic for the source zone to
+or from the destination zone including rules that use the 'all'
+reserved word. Exception: if the source zone and destination zone are
+the same then the rule must be explicit - it must name the zone in both
+the SOURCE and DESTINATION columns.
-
-
+
Version >= 1.3.14
-
- Beginning in version 1.3.14, Shorewall treats entries
- in /etc/shorewall/masq differently.
- The change involves entries with an interface name in the SUBNET
- (second) column:
-
+
+ Beginning in version 1.3.14, Shorewall treats
+entries in /etc/shorewall/masq differently.
+The change involves entries with an interface name in the SUBNET
+(second) column:
- - Prior to 1.3.14, Shorewall would detect the FIRST
- subnet on the interface (as shown by "ip addr show interface")
- and would masquerade traffic from that subnet. Any other subnets that
- routed through eth1 needed their own entry in /etc/shorewall/masq to
- be masqueraded or to have SNAT applied.
- - Beginning with Shorewall 1.3.14, Shorewall uses
-the firewall's routing table to determine ALL subnets routed through
-the named interface. Traffic originating in ANY of those subnets is
-masqueraded or has SNAT applied.
-
+ - Prior to 1.3.14, Shorewall would detect the FIRST subnet on the
+interface (as shown by "ip addr show interface") and would
+masquerade traffic from that subnet. Any other subnets that routed
+through eth1 needed their own entry in /etc/shorewall/masq to be
+masqueraded or to have SNAT applied.
+ - Beginning with Shorewall 1.3.14, Shorewall uses the firewall's
+routing table to determine ALL subnets routed through the named
+interface. Traffic originating in ANY of those subnets is
+masqueraded or has SNAT applied.
- You will need to make a change to your configuration
+You will need to make a change to your configuration
if:
-
- - You have one or more entries in /etc/shorewall/masq
- with an interface name in the SUBNET (second) column; and
- - That interface connects to more than one subnetwork.
-
+ - You have one or more entries in /etc/shorewall/masq with an
+interface name in the SUBNET (second) column; and
+ - That interface connects to more than one subnetwork.
- Two examples:
-
- Example 1 -- Suppose that your current config
-is as follows:
-
-
- [root@gateway test]# cat /etc/shorewall/masq
#INTERFACE SUBNET ADDRESS
eth0 eth2 206.124.146.176
eth0 192.168.10.0/24 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
[root@gateway test]# ip route show dev eth2
192.168.1.0/24 scope link
192.168.10.0/24 proto kernel scope link src 192.168.10.254
[root@gateway test]#
-
-In this case, the second entry in /etc/shorewall/masq is no longer
- required.
-
- Example 2-- What if your current configuration
-is like this?
-
- [root@gateway test]# cat /etc/shorewall/masq
#INTERFACE SUBNET ADDRESS
eth0 eth2 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
[root@gateway test]# ip route show dev eth2
192.168.1.0/24 scope link
192.168.10.0/24 proto kernel scope link src 192.168.10.254
[root@gateway test]#
-
-In this case, you would want to change the entry in /etc/shorewall/masq
- to:
-
-
- #INTERFACE SUBNET ADDRESS
eth0 192.168.1.0/24 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
-
- Version 1.3.14 also introduced simplified ICMP echo-request
- (ping) handling. The option OLD_PING_HANDLING=Yes in /etc/shorewall/shorewall.conf
- is used to specify that the old (pre-1.3.14) ping handling is to
-be used (If the option is not set in your /etc/shorewall/shorewall.conf
- then OLD_PING_HANDLING=Yes is assumed). I don't plan on supporting
-the old handling indefinitely so I urge current users to migrate to using
- the new handling as soon as possible. See the 'Ping'
- handling documentation for details.
-
+Two examples:
+
+ Example 1 -- Suppose that your current config is as
+follows:
+
+ [root@gateway test]# cat /etc/shorewall/masq
#INTERFACE SUBNET ADDRESS
eth0 eth2 206.124.146.176
eth0 192.168.10.0/24 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
[root@gateway test]# ip route show dev eth2
192.168.1.0/24 scope link
192.168.10.0/24 proto kernel scope link src 192.168.10.254
[root@gateway test]#
+In this case, the second entry in /etc/shorewall/masq is no
+longer required.
+
+Example 2-- What if your current configuration is like this?
+ [root@gateway test]# cat /etc/shorewall/masq
#INTERFACE SUBNET ADDRESS
eth0 eth2 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
[root@gateway test]# ip route show dev eth2
192.168.1.0/24 scope link
192.168.10.0/24 proto kernel scope link src 192.168.10.254
[root@gateway test]#
+In this case, you would want to change the entry in
+/etc/shorewall/masq to:
+
+ #INTERFACE SUBNET ADDRESS
eth0 192.168.1.0/24 206.124.146.176
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+ Version 1.3.14 also introduced simplified ICMP
+echo-request (ping) handling. The option OLD_PING_HANDLING=Yes in
+/etc/shorewall/shorewall.conf is used to specify that the old
+(pre-1.3.14) ping handling is to be used (If the option is not set in
+your /etc/shorewall/shorewall.conf then OLD_PING_HANDLING=Yes is
+assumed). I don't plan on supporting the old handling indefinitely so I
+urge current users to migrate to using the new handling as soon as
+possible. See the 'Ping' handling documentation
+for details.
Version 1.3.10
- If you have installed the 1.3.10 Beta 1 RPM and are
-now upgrading to version 1.3.10, you will need to use the '--force'
+If you have installed the 1.3.10 Beta 1 RPM and are
+now upgrading to version 1.3.10, you will need to use the '--force'
option:
-
-
-
- rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
-
-
+
+
+ rpm -Uvh --force shorewall-1.3.10-1.noarch.rpm
+
Version >= 1.3.9
- The 'functions' file has moved to /usr/lib/shorewall/functions.
- If you have an application that uses functions from that file, your
- application will need to be changed to reflect this change of location.
-
+The 'functions' file has moved to /usr/lib/shorewall/functions. If you
+have an application that uses functions from that file, your
+application will need to be changed to reflect this change of location.
Version >= 1.3.8
-
-If you have a pair of firewall systems configured for failover
- or if you have asymmetric routing, you will need to modify
- your firewall setup slightly under Shorewall
- versions >= 1.3.8. Beginning with version 1.3.8,
- you must set NEWNOTSYN=Yes in your
- /etc/shorewall/shorewall.conf file.
-
+If you have a pair of firewall systems configured for failover or if
+you have asymmetric routing, you will need to modify your firewall
+setup slightly under Shorewall versions >= 1.3.8. Beginning with
+version 1.3.8, you must set NEWNOTSYN=Yes in your
+/etc/shorewall/shorewall.conf file.
Version >= 1.3.7
-
-Users specifying ALLOWRELATED=No in /etc/shorewall.conf
- will need to include the following
- rules in their /etc/shorewall/icmpdef file (creating this
- file if necessary):
-
+Users specifying ALLOWRELATED=No in /etc/shorewall.conf will need to
+include the following rules in their /etc/shorewall/icmpdef file
+(creating this file if necessary):
run_iptables -A icmpdef -p ICMP --icmp-type echo-reply -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type source-quench -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type destination-unreachable -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type time-exceeded -j ACCEPT
run_iptables -A icmpdef -p ICMP --icmp-type parameter-problem -j ACCEPT
-
-Users having an /etc/shorewall/icmpdef file may remove the ". /etc/shorewall/icmp.def"
- command from that file since the icmp.def file is now empty.
-
-Upgrading Bering to Shorewall >= 1.3.3
-
-To properly upgrade with Shorewall version 1.3.3 and later:
-
+Users having an /etc/shorewall/icmpdef file may remove the ".
+/etc/shorewall/icmp.def" command from that file since the icmp.def file
+is now empty.
+Upgrading Bering to Shorewall >= 1.3.3
+To properly upgrade with Shorewall version 1.3.3 and later:
- - Be sure you
-have a backup -- you will need
-to transcribe any Shorewall configuration
- changes that you have made to the new
- configuration.
- - Replace the
-shorwall.lrp package provided on
- the Bering floppy with the later one. If you did
- not obtain the later version from Jacques's site,
- see additional instructions below.
- - Edit the /var/lib/lrpkg/root.exclude.list
- file and remove the /var/lib/shorewall
- entry if present. Then do not
-forget to backup root.lrp !
-
+ - Be sure you have a backup -- you will need to transcribe any
+Shorewall configuration changes that you have made to the new
+configuration.
+ - Replace the shorwall.lrp package provided on the Bering floppy
+with the later one. If you did not obtain the later version from
+Jacques's site, see additional instructions below.
+ - Edit the /var/lib/lrpkg/root.exclude.list file and remove the
+/var/lib/shorewall entry if present. Then do not forget to backup
+root.lrp !
-
-The .lrp that I release isn't set up for a two-interface firewall like
- Jacques's. You need to follow the instructions for setting up a two-interface
- firewall plus you also need to add the following two Bering-specific
- rules to /etc/shorewall/rules:
-
-
+The .lrp that I release isn't set up for a two-interface firewall
+like Jacques's. You need to follow the instructions
+for setting up a two-interface firewall plus you also need to add
+the following two Bering-specific rules to /etc/shorewall/rules:
+
# Bering specific rules:
# allow loc to fw udp/53 for dnscache to work
# allow loc to fw tcp/80 for weblet to work
#
ACCEPT loc fw udp 53
ACCEPT loc fw tcp 80
-
-
-Version 1.3.6 and 1.3.7
-
-If you have a pair of firewall systems configured for
- failover or if you have asymmetric routing, you will need to modify
- your firewall setup slightly under Shorewall versions
-1.3.6 and 1.3.7
-
+
+Version 1.3.6 and 1.3.7
+If you have a pair of firewall systems configured for
+failover or if you have asymmetric routing, you will need to modify
+your firewall setup slightly under Shorewall versions
+1.3.6 and 1.3.7
- -
-
-
Create the file /etc/shorewall/newnotsyn and in it add
- the following rule
-
- run_iptables -A
-newnotsyn -j RETURN # So that the connection tracking
-table can be rebuilt
-
-# from non-SYN packets after takeover.
-
-
- -
-
-
Create /etc/shorewall/common (if you don't already
- have that file) and include the following:
-
- run_iptables -A
-common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
-#Accept Acks to rebuild connection
-
- #tracking table.
- . /etc/shorewall/common.def
-
-
+ -
+
Create the file /etc/shorewall/newnotsyn and in it
+add the following rule
+
+ run_iptables -A
+newnotsyn -j RETURN # So that the connection tracking
+table can be rebuilt
+
+# from non-SYN packets after takeover.
+
+
+ -
+
Create /etc/shorewall/common (if you don't already
+have that file) and include the following:
+
+ run_iptables -A
+common -p tcp --tcp-flags ACK,FIN,RST ACK -j ACCEPT
+#Accept Acks to rebuild connection
+
+#tracking table.
+. /etc/shorewall/common.def
+
-
Versions >= 1.3.5
-
-Some forms of pre-1.3.0 rules file syntax are no longer
- supported.
-
+Some forms of pre-1.3.0 rules file syntax are no longer
+supported.
Example 1:
-
-
+
ACCEPT net loc:192.168.1.12:22 tcp 11111 - all
-
-
+
Must be replaced with:
-
-
+
DNAT net loc:192.168.1.12:22 tcp 11111
-
-
-
+
+
-
-
+
+
ACCEPT loc fw::3128 tcp 80 - all
-
-
-
+
+
-
-
+
+
REDIRECT loc 3128 tcp 80
-
-
+
Version >= 1.3.2
-
-The functions and versions files together with the 'firewall'
- symbolic link have moved from /etc/shorewall to /var/lib/shorewall.
- If you have applications that access these files, those
- applications should be modified accordingly.
-
- Last updated 6/29/2003 - Tom
+The functions and versions files together with the
+'firewall' symbolic link have moved from /etc/shorewall to
+/var/lib/shorewall. If you have applications that access these files,
+those applications should be modified accordingly.
+ Last updated 10/30/2003 - Tom
Eastep
-
-Copyright
- © 2001, 2002, 2003 Thomas M. Eastep.
-
-
-
-
+Copyright
+© 2001, 2002, 2003 Thomas M. Eastep
+
diff --git a/Shorewall-docs/useful_links.html b/Shorewall-docs/useful_links.html
index b55737d14..8a3357d3d 100644
--- a/Shorewall-docs/useful_links.html
+++ b/Shorewall-docs/useful_links.html
@@ -2,65 +2,39 @@
Useful Links
-
-
-
-
-
-
-
-
- Useful Links
-
-
- |
-
-
-
-
-
-
+
+Useful Links
-
+ height="33" hspace="4" align="middle" border="0">
Linux Advanced Routing and Traffic Control Howto: http://ds9a.nl/lartc
-
-
-
+ align="middle" hspace="4" border="0">
-
+ href="http://leaf.sourceforge.net/devel/jnilo">
+http://leaf.sourceforge.net/devel/jnilo
-
- Last updated 9/16/2002 - Tom Eastep
-
-Copyright
- © 2001, 2002 Thomas M. Eastep.
-
-
-
-
-
+ align="middle" hspace="4" border="0"> 
+
+
+Last updated 11/20/2003 - Tom
+Eastep
+Copyright
+© 2001, 2002, 2003 Thomas M. Eastep.
+
+
+
+
+
diff --git a/Shorewall-docs/whitelisting_under_shorewall.htm b/Shorewall-docs/whitelisting_under_shorewall.htm
index 5dd7f367e..b23f190a7 100644
--- a/Shorewall-docs/whitelisting_under_shorewall.htm
+++ b/Shorewall-docs/whitelisting_under_shorewall.htm
@@ -1,309 +1,267 @@
-
-
-
-
Whitelisting under Shorewall
-
-
-
-
-
-
- Whitelisting under Shorewall
- |
-
-
-
-
-
-For a brief time, the 1.2 version of Shorewall supported
-an /etc/shorewall/whitelist file. This file was intended to contain a list
-of IP addresses of hosts whose POLICY to all zones was ACCEPT. The whitelist
-file was implemented as a stop-gap measure until the facilities necessary
-for implementing white lists using zones was in place. As of Version 1.3
-RC1, those facilities were available.
-
-White lists are most often used to give special privileges
-to a set of hosts within an organization. Let us suppose that we have the
- following environment:
-
+
+Whitelisting under Shorewall
+
+For a brief time, the 1.2 version of Shorewall
+supported
+an /etc/shorewall/whitelist file. This file was intended to contain a
+list
+of IP addresses of hosts whose POLICY to all zones was ACCEPT. The
+whitelist file was implemented as a stop-gap measure until the
+facilities necessary for implementing white lists using zones was in
+place. As of Version 1.3 RC1, those facilities were available.
+White lists are most often used to give special
+privileges to a set of hosts within an organization. Let us
+suppose that we have the following environment:
- - A firewall with three interfaces -- one to the internet, one
-to a local network and one to a DMZ.
- - The local network uses SNAT to the internet and is comprised
-of the class B network 10.10.0.0/16 (Note: While this example uses an RFC
-1918 local network, the technique described here in no way depends on
-that or on SNAT. It may be used with Proxy ARP, Subnet Routing, Static
+
- A firewall with three interfaces -- one to the internet, one to a
+local network and one to a DMZ.
+ - The local network uses SNAT to the internet and is comprised of
+the class B network 10.10.0.0/16 (Note: While this example uses an RFC
+1918 local network, the technique described here in no way depends on
+that or on SNAT. It may be used with Proxy ARP, Subnet Routing, Static
NAT, etc.).
- - The network operations staff have workstations with IP addresses
+
- The network operations staff have workstations with IP addresses
in the class C network 10.10.10.0/24
- - We want the network operations staff to have full access to all
+
- We want the network operations staff to have full access to all
other hosts.
- - We want the network operations staff to bypass the transparent
+
- We want the network operations staff to bypass the transparent
HTTP proxy running on our firewall.
-
-
-The basic approach will be that we will place the operations
- staff's class C in its own zone called ops. Here are the appropriate
- configuration files:
-
+The basic approach will be that we will place the
+operations staff's class C in its own zone called ops. Here are
+the appropriate configuration files:
Zone File
-
-
+
-
-
- | ZONE |
- DISPLAY |
- COMMENTS |
-
-
- | net |
- Net |
- Internet |
-
-
- | ops |
- Operations |
- Operations Staff's Class C |
-
-
- | loc |
- Local |
- Local Class B |
-
-
- | dmz |
- DMZ |
- Demilitarized zone |
-
-
-
+
+
+ | ZONE |
+ DISPLAY |
+ COMMENTS |
+
+
+ | net |
+ Net |
+ Internet |
+
+
+ | ops |
+ Operations |
+ Operations Staff's Class C |
+
+
+ | loc |
+ Local |
+ Local Class B |
+
+
+ | dmz |
+ DMZ |
+ Demilitarized zone |
+
+
-
-
-The ops zone has been added to the standard 3-zone zones file --
-since ops is a sub-zone of loc, we list it BEFORE loc.
-
+
+The ops zone has been added to the standard 3-zone zones
+file -- since ops is a sub-zone of loc, we list it BEFORE
+loc.
Interfaces File
-
-
+
-
-
- | ZONE |
- INTERFACE |
- BROADCAST |
- OPTIONS |
-
-
- | net |
- eth0 |
- <whatever> |
- <options> |
-
-
- | dmz |
- eth1 |
- <whatever> |
-
- |
-
-
- | - |
- eth2 |
- 10.10.255.255 |
- |
-
-
-
+
+
+ | ZONE |
+ INTERFACE |
+ BROADCAST |
+ OPTIONS |
+
+
+ | net |
+ eth0 |
+ <whatever> |
+ <options> |
+
+
+ | dmz |
+ eth1 |
+ <whatever> |
+
+ |
+
+
+ | - |
+ eth2 |
+ 10.10.255.255 |
+ |
+
+
-
-
-Because eth2 interfaces to two zones (ops and loc),
-we don't specify a zone for it here.
-
+
+Because eth2 interfaces to two zones (ops and loc),
+we don't specify a zone for it here.
Hosts File
-
-
-
+
-
-
- | ZONE |
- HOST(S) |
- OPTIONS |
-
-
- | ops |
- eth2:10.10.10.0/24 |
-
- |
-
-
- | loc |
- eth2:0.0.0.0/0 |
- |
-
-
-
+
+
+ | ZONE |
+ HOST(S) |
+ OPTIONS |
+
+
+ | ops |
+ eth2:10.10.10.0/24 |
+
+ |
+
+
+ | loc |
+ eth2:0.0.0.0/0 |
+ |
+
+
-
-
-Here we define the ops and loc zones. When Shorewall is stopped,
-only the hosts in the ops zone will be allowed to access the firewall
-and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than 10.10.0.0/16
-so that the limited broadcast address (255.255.255.255) falls into that
-zone. If I used 10.10.0.0/16 then I would have to have a separate entry for
- that special address.
-
+
+Here we define the ops and loc zones. When Shorewall
+is stopped,
+only the hosts in the ops zone will be allowed to access the
+firewall
+and the DMZ. I use 0.0.0.0/0 to define the loc zone rather than
+10.10.0.0/16
+so that the limited broadcast address (255.255.255.255) falls into that
+zone. If I used 10.10.0.0/16 then I would have to have a separate entry
+for that special address.
Policy File
-
-
-
+
-
-
- | SOURCE |
- DEST |
- POLICY |
- LOG LEVEL |
- LIMIT:BURST |
-
-
- | ops |
- all |
- ACCEPT |
- |
- |
-
-
- | all |
- ops |
- CONTINUE |
- |
- |
-
-
- | loc |
- net |
- ACCEPT |
- |
- |
-
-
- | net |
- all |
- DROP |
- info |
- |
-
-
- | all |
- all |
- REJECT |
- info |
- |
-
-
-
+
+
+ | SOURCE |
+ DEST |
+ POLICY |
+ LOG LEVEL |
+ LIMIT:BURST |
+
+
+ | ops |
+ all |
+ ACCEPT |
+ |
+ |
+
+
+ | all |
+ ops |
+ CONTINUE |
+ |
+ |
+
+
+ | loc |
+ net |
+ ACCEPT |
+ |
+ |
+
+
+ | net |
+ all |
+ DROP |
+ info |
+ |
+
+
+ | all |
+ all |
+ REJECT |
+ info |
+ |
+
+
-
-
-Two entries for ops have been added to the standard 3-zone policy
-file.
-
+
+Two entries for ops have been added to the standard 3-zone
+policy file.
Rules File
-
-
-
+
-
-
- | ACTION |
- SOURCE |
- DEST |
- PROTO |
- DEST
- PORT(S) |
- SOURCE
- PORT(S) |
- ORIGINAL
- DEST |
-
-
- | REDIRECT |
- loc!ops |
- 3128 |
- tcp |
- http |
- |
- |
-
-
- | ... |
- |
- |
- |
- |
- |
- |
-
-
-
+
+
+ | ACTION |
+ SOURCE |
+ DEST |
+ PROTO |
+ DEST
+PORT(S) |
+ SOURCE
+PORT(S) |
+ ORIGINAL
+DEST |
+
+
+ | REDIRECT |
+ loc!ops |
+ 3128 |
+ tcp |
+ http |
+ |
+ |
+
+
+ | ... |
+ |
+ |
+ |
+ |
+ |
+ |
+
+
-
-
-This is the rule that transparently redirects web traffic to the transparent
- proxy running on the firewall. The SOURCE column explicitly excludes the
-ops zone from the rule.
-
+
+This is the rule that transparently redirects web traffic to the
+transparent proxy running on the firewall. The SOURCE column explicitly
+excludes the ops zone from the rule.
Routestopped File
-
-
+
-
-
- INTERFACE
- |
- HOST(S) |
-
-
- eth1
- |
-
- |
-
-
- eth2
- |
- 10.10.10.0/24 |
-
-
-
+
+
+ INTERFACE
+ |
+ HOST(S) |
+
+
+ eth1
+ |
+
+ |
+
+
+ eth2
+ |
+ 10.10.10.0/24 |
+
+
-
-
- Updated 2/18/2003 - Tom Eastep
-
-
-Copyright
- © 2002, 2003Thomas M. Eastep.
-
-
-
+
+ Updated 2/18/2003 - Tom Eastep
+
+Copyright
+© 2002, 2003Thomas M. Eastep.
+
+
+
- 
+ 
- 
- 
-