diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index fd1bb25b3..839d5c6aa 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -2,3589 +2,3610 @@
- + - + - ++ |
-
+
Shorewall 1.4 Reference- |
-
Shorewall consists of the following components:
+You may use the file /etc/shorewall/params file to set shell variables - 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:
- - -NET_IF=eth0- -
NET_BCAST=130.252.100.255
NET_OPTIONS=blacklist,norfc1918
Example (/etc/shorewall/interfaces record):
- -net $NET_IF $NET_BCAST $NET_OPTIONS- -
The result will be the same as if the record had been written
- -net eth0 130.252.100.255 blacklist,norfc1918- -
Variables may be used anywhere in the other configuration - files.
- - -This file is used to define the network zones. There is one entry - in /etc/shorewall/zones for each zone; Columns in an entry - are:
- -The /etc/shorewall/zones file released with Shorewall is as follows:
+You may use the file /etc/shorewall/params file to set shell variables + 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:
+ + +NET_IF=eth0+ +
NET_BCAST=130.252.100.255
NET_OPTIONS=blacklist,norfc1918
Example (/etc/shorewall/interfaces record):
+ +net $NET_IF $NET_BCAST $NET_OPTIONS+ +
The result will be the same as if the record had been written
+ +net eth0 130.252.100.255 blacklist,norfc1918+ +
Variables may be used anywhere in the other configuration + files.
+ + +This file is used to define the network zones. There is one entry + in /etc/shorewall/zones for each zone; Columns in an entry + are:
+ + +The /etc/shorewall/zones file released with Shorewall is as follows:
+ +ZONE | -DISPLAY | -COMMENTS | -
net | -Net | -Internet | -
loc | -Local | -Local networks | -
dmz | -DMZ | -Demilitarized zone | -
ZONE | +DISPLAY | +COMMENTS | +
net | +Net | +Internet | +
loc | +Local | +Local networks | +
dmz | +DMZ | +Demilitarized zone | +
You may add, delete and modify entries in the /etc/shorewall/zones file + +
You may add, delete and modify entries in the /etc/shorewall/zones file as desired so long as you have at least one zone defined.
- +Warning 1: If you rename or delete a zone, you should perform "shorewall - stop; shorewall start" to install the change rather than + color="#ff0000"> If you rename or delete a zone, you should perform "shorewall + stop; shorewall start" to install the change rather than "shorewall restart".
- +Warning 2: The order of entries in the /etc/shorewall/zones file is + color="#ff0000">The order of entries in the /etc/shorewall/zones file is significant in some cases.
- +This file is used to tell the firewall which of your firewall's network - interfaces are connected to which zone. There will be one - entry in /etc/shorewall/interfaces for each of your interfaces. + +
This file is used to tell the firewall which of your firewall's network + interfaces are connected to which zone. There will be one + entry in /etc/shorewall/interfaces for each of your interfaces. Columns in an entry are:
- + tcpflags (added in version 1.3.11) - This option causes Shorewall
-to make sanity checks on the header flags in TCP packets arriving on this
-interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; these
-flag combinations are typically used for "silent" port scans. Packets failing
-these checks are logged according to the TCP_FLAGS_LOG_LEVEL option in /etc/shorewall/shorewall.conf and are disposed of according
- to the TCP_FLAGS_DISPOSITION option.
-
- blacklist - This option causes incoming packets
+
+
tcpflags (added in version 1.3.11) - This option causes
+Shorewall to make sanity checks on the header flags in TCP packets arriving
+on this interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH;
+these flag combinations are typically used for "silent" port scans. Packets
+ failing these checks are logged according to the TCP_FLAGS_LOG_LEVEL option
+ in /etc/shorewall/shorewall.conf and are disposed of
+according to the TCP_FLAGS_DISPOSITION option.
+
+ blacklist - This option causes incoming packets
on this interface to be checked against the blacklist.
-
- dhcp - The interface is assigned an IP
-address via DHCP or is used by a DHCP server running on the
-firewall. The firewall will be configured to allow DHCP traffic
-to and from the interface even when the firewall is stopped.
-You may also wish to use this option if you have a static IP but
- you are on a LAN segment that has a lot of Laptops that use DHCP
-and you select the norfc1918 option (see below).
norfc1918 - Packets arriving on this interface and that - have a source address that is reserved in RFC 1918 or in other + +
norfc1918 - Packets arriving on this interface and that
+ have a source address that is reserved in RFC 1918 or in other
RFCs will be dropped after being optionally logged. If packet mangling is enabled in /etc/shorewall/shorewall.conf
- , then packets arriving on this interface that have a destination
- address that is reserved by one of these RFCs will also be
- logged and dropped.
-
- Addresses blocked by the standard rfc1918 file include those
- addresses reserved by RFC1918 plus other ranges reserved by the
+ href="#Conf">packet mangling is enabled in /etc/shorewall/shorewall.conf
+ , then packets arriving on this interface that have a destination
+ address that is reserved by one of these RFCs will also be
+logged and dropped.
+
+ Addresses blocked by the standard rfc1918 file include those
+ addresses reserved by RFC1918 plus other ranges reserved by the
IANA or by other RFCs.
Beware that as IPv4 addresses become in increasingly short supply, - ISPs are beginning to use RFC 1918 addresses within their - own infrastructure. Also, many cable and DSL "modems" have -an RFC 1918 address that can be used through a web browser for -management and monitoring functions. If you want to specify norfc1918 - on your external interface but need to allow access to certain - addresses from the above list, see FAQ -14.
+ +Beware that as IPv4 addresses become in increasingly short supply, + ISPs are beginning to use RFC 1918 addresses within their + own infrastructure. Also, many cable and DSL "modems" have +an RFC 1918 address that can be used through a web browser for +management and monitoring functions. If you want to specify norfc1918 + on your external interface but need to allow access to certain + addresses from the above list, see FAQ 14.
-routefilter - Invoke the Kernel's route filtering - (anti-spoofing) facility on this interface. The kernel - will reject any packets incoming on this interface that have -a source address that would be routed outbound through another - interface on the firewall. Warning: - If you specify this option for an interface then the + +
routefilter - Invoke the Kernel's route filtering + (anti-spoofing) facility on this interface. The kernel + will reject any packets incoming on this interface that have +a source address that would be routed outbound through another + interface on the firewall. Warning: + If you specify this option for an interface then the interface must be up prior to starting the firewall.
- dropunclean - Packets from this interface that
- are selected by the 'unclean' match target in iptables will
- be optionally logged and then dropped.
- Warning: This feature
- requires that UNCLEAN match support be configured in your
- kernel, either in the kernel itself or as a module. UNCLEAN
- support is broken in some versions of the kernel
- but appears to work ok in 2.4.17-rc1.
-
- Update 12/17/2001: The
- unclean match patch from 2.4.17-rc1 is
- available
- for download. I am currently running
- this patch applied to kernel 2.4.16.
dropunclean - Packets from this interface that
+ are selected by the 'unclean' match target in iptables will
+ be optionally logged and then
+dropped. Warning: This feature
+ requires that UNCLEAN match support be configured in
+your kernel, either in the kernel itself or as a module.
+UNCLEAN support is broken in some versions of the
+kernel but appears to work ok in 2.4.17-rc1.
+
+ Update 12/17/2001: The
+ unclean match patch from 2.4.17-rc1 is
+ available
+ for download. I am currently running
+ this patch applied to kernel 2.4.16.
Update 12/20/2001: I've - seen a number of tcp connection requests - with OPT (020405B40000080A...) being - dropped in the badpkt chain. This appears to be - a bug in the remote TCP stack whereby it is 8-byte aligning - a timestamp (TCP option 8) but rather than padding with - 0x01 it is padding with 0x00. It's a tough call whether - to deny people access to your servers because of -this rather minor bug in their networking software. - If you wish to disable the check that causes these - connections to be dropped, here's - a kernel patch against 2.4.17-rc2.
+ +Update 12/20/2001: I've + seen a number of tcp connection requests + with OPT (020405B40000080A...) being + dropped in the badpkt chain. This appears to be + a bug in the remote TCP stack whereby it is 8-byte aligning + a timestamp (TCP option 8) but rather than padding + with 0x01 it is padding with 0x00. It's a tough +call whether to deny people access to your servers +because of this rather minor bug in their networking +software. If you wish to disable the check that +causes these connections to be dropped, here's + a kernel patch against 2.4.17-rc2.
- -logunclean - This option works like dropunclean - with the exception that packets selected - by the 'unclean' match target in iptables are - logged but not dropped. The level - at which the packets are logged is determined by - the setting of LOGUNCLEAN and if - LOGUNCLEAN has not been set, "info" is assumed.
+ +logunclean - This option works like dropunclean + with the exception that packets selected + by the 'unclean' match target in iptables +are logged but not dropped. The +level at which the packets are logged is determined by + the setting of LOGUNCLEAN + and if LOGUNCLEAN has not been set, "info" is assumed.
- -proxyarp (Added in version 1.3.5) - This option
- causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp
- and is used when implementing Proxy ARP
- Sub-netting as described at
-
- http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do
- not set this option if you are implementing Proxy
- ARP through entries in
- /etc/shorewall/proxyarp.
-
- maclist (Added in version 1.3.10) - If
-this option is specified, all connection requests from this interface
- are subject to MAC Verification.
+
+
proxyarp (Added in version 1.3.5) - This option
+ causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp
+ and is used when implementing Proxy ARP
+ Sub-netting as described at
+
+ http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. Do
+ not set this option if you are implementing Proxy
+ ARP through entries in
+ /etc/shorewall/proxyarp.
+
+ maclist (Added in version 1.3.10) - If
+ this option is specified, all connection requests from this interface
+ are subject to MAC Verification.
May only be specified for ethernet interfaces.
My recommendations concerning options:
-
- -
Example 1: You have a conventional firewall setup in which eth0 connects - to a Cable or DSL modem and eth1 connects to your local -network and eth0 gets its IP address via DHCP. You want to -check all packets entering from the internet - against the black list. Your /etc/shorewall/interfaces + +
Example 1: You have a conventional firewall setup in which eth0 connects + to a Cable or DSL modem and eth1 connects to your local network + and eth0 gets its IP address via DHCP. You want to check all + packets entering from the internet against +the black list. Your /etc/shorewall/interfaces file would be as follows:
- -- -- - -- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -net -eth0 -detect -dhcp,norfc1918,blacklist -- - - - - - - - -loc -eth1 -detect --
-
Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:
- - ++ - -- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- + +net -ppp0 - --
--
-+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +net +eth0 +detect +dhcp,norfc1918,blacklist ++ - + - +loc +eth1 +detect ++
+
Example 3: You have local interface eth1 with two IP - addresses - 192.168.1.1/24 and 192.168.12.1/24
+ +Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces + file would be:
- -- + +- -++- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- +loc -eth1 ++ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +net +ppp0 -192.168.1.255,192.168.12.255 --
-+
++ - - - + + + +
+
Example 3: You have local interface eth1 with two IP + addresses - 192.168.1.1/24 and 192.168.12.1/24
+ + ++ ++ + ++ +
++ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ + + + + + + +loc +eth1 + +192.168.1.255,192.168.12.255 ++
+
For most applications, specifying zones entirely in terms of network - interfaces is sufficient. There may be times though where you need to -define a zone to be a more general collection of hosts. This is the purpose -of the /etc/shorewall/hosts file.
+ +For most applications, specifying zones entirely in terms of network + interfaces is sufficient. There may be times though where you need to define +a zone to be a more general collection of hosts. This is the purpose of +the /etc/shorewall/hosts file.
- -WARNING: 90% of - Shorewall users don't need to put entries in this file and - 80% of those who try to add such entries do it wrong. - Unless you are ABSOLUTELY SURE that you need entries in - this file, don't touch it.
+ +WARNING: 90% of +Shorewall users don't need to put entries in this file and + 80% of those who try to add such entries do it wrong. + Unless you are ABSOLUTELY SURE that you need entries in + this file, don't touch it.
- +Columns in this file are:
- ++ ++ + +- ++-
- +- An IP address (example +
- An IP address (example - eth1:192.168.1.3)
-- A subnet in CIDR notation +
- A subnet in CIDR notation (example - eth2:192.168.2.0/24)
- +The interface name much match an entry in /etc/shorewall/interfaces.
-
++ + +maclist - Added in version 1.3.10. If specified, connection + requests from the hosts specified in this entry are subject to + MAC Verification. This option is only + valid for ethernet interfaces.
+
+
If you don't define any hosts for a zone, the hosts in the zone default + to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are + the interfaces to the zone.
+ + +Note: You probably DON'T + want to specify any hosts for your internet zone since the hosts that +you specify will be the only ones that you will be able to access without +adding additional rules.
+ + + + +Example:
+ + +Your local interface is eth1 and you have two groups of local hosts that + you want to make into separate zones:
+ +- - -- - -maclist - Added in version 1.3.10. If specified, connection - requests from the hosts specified in this entry are subject to - MAC Verification. This option is only - valid for ethernet interfaces.
-
-
If you don't define any hosts for a zone, the hosts in the zone default - to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are - the interfaces to the zone.
- - -Note: You probably DON'T -want to specify any hosts for your internet zone since the hosts that you -specify will be the only ones that you will be able to access without adding -additional rules.
- - - - -Example:
- - -Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:
- - -Your /etc/shorewall/interfaces file might look like:
- -- -- - - -- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -net -eth0 -detect -dhcp,norfc1918 -- - - - - - - - -- -eth1 -detect --
-
The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces - to multiple zones.
- - - -Your /etc/shorewall/hosts file might look like:
- - - -- - -- - - -- -
-- -ZONE -HOST(S) -OPTIONS -- -loc1 -eth1:192.168.1.0/25 --
-- - - -loc2 -eth1:192.168.1.128/25 --
-
Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.
- - - -The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow - you to define nested or overlapping zones. Such overlapping/nested zones - are allowed and Shorewall processes zones in the order that - they appear in the /etc/shorewall/zones file. So if you have -nested zones, you want the sub-zone to appear before the super-zone - and in the case of overlapping zones, the rules that will apply - to hosts that belong to both zones is determined by which zone appears - first in /etc/shorewall/zones.
- - - -Hosts that belong to more than one zone may be managed by the rules - of all of those zones. This is done through use of the special - CONTINUE policy described below.
- - - ---This file is used to describe the firewall policy regarding establishment - of connections. Connection establishment is described in terms - of clients who initiate connections and servers -who receive those connection requests. Policies defined -in /etc/shorewall/policy describe which zones are allowed -to establish connections with other zones.
++ +
++ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +net +eth0 +detect +dhcp,norfc1918 ++ - -- +eth1 +detect ++
+Policies established in /etc/shorewall/policy can be viewed as default - policies. If no rule in /etc/shorewall/rules applies to -a particular connection request then the policy from /etc/shorewall/policy - is applied.
- - - -Four policies are defined:
--
+ + + +- ACCEPT - The connection is -allowed.
-- DROP - The connection request - is ignored.
-- REJECT - The connection request - is rejected with an RST (TCP) or an ICMP destination-unreachable - packet being returned to the client.
-- CONTINUE - The connection -is neither ACCEPTed, DROPped nor REJECTed. CONTINUE may -be used when one or both of the zones named in the entry are - sub-zones of or intersect with another zone. For more information, -see below.
- -
For each policy specified in /etc/shorewall/policy, you can indicate - that you want a message sent to your system log each time +
The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.
+ + + +Your /etc/shorewall/hosts file might look like:
+ + + ++ + ++ + + ++ +
++ +ZONE +HOST(S) +OPTIONS ++ +loc1 +eth1:192.168.1.0/25 ++
++ + + +loc2 +eth1:192.168.1.128/25 ++
+
Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.
+ + + +The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow +you to define nested or overlapping zones. Such overlapping/nested zones + are allowed and Shorewall processes zones in the order that + they appear in the /etc/shorewall/zones file. So if you have +nested zones, you want the sub-zone to appear before the super-zone + and in the case of overlapping zones, the rules that will apply + to hosts that belong to both zones is determined by which zone appears + first in /etc/shorewall/zones.
+ + + +Hosts that belong to more than one zone may be managed by the rules + of all of those zones. This is done through use of the special + CONTINUE policy described below.
+ + + +This file is used to describe the firewall policy regarding establishment + of connections. Connection establishment is described in terms + of clients who initiate connections and servers who + receive those connection requests. Policies defined in /etc/shorewall/policy + describe which zones are allowed to establish connections +with other zones.
+ + + +Policies established in /etc/shorewall/policy can be viewed as default + policies. If no rule in /etc/shorewall/rules applies to a + particular connection request then the policy from /etc/shorewall/policy + is applied.
+ + + +Four policies are defined:
+ + +For each policy specified in /etc/shorewall/policy, you can indicate + that you want a message sent to your system log each time that the policy is applied.
- +Entries in /etc/shorewall/policy have four columns as follows:
- +In the SOURCE and DEST columns, you can enter "all" to indicate all + +
In the SOURCE and DEST columns, you can enter "all" to indicate all zones.
- +The policy file installed by default is as follows:
- +- - + face="Century Gothic, Arial, Helvetica"> + +- - - -- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- +loc -net -ACCEPT -+
-+ +SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST ++ -loc +net +ACCEPT +-
+-
-- -net -all -DROP -info --
-- - - - - - - - -all -all -REJECT -info --
-
This table may be interpreted as follows:
- - -WARNING:
- - -The firewall script processes the - /etc/shorewall/policy file from top to bottom and uses - the first applicable policy that it finds. For example, -in the following policy file, the policy for (loc, loc) connections - would be ACCEPT as specified in the first entry even though the -third entry in the file specifies REJECT.
- - -- -+ + + + +- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- - -loc -all -ACCEPT --
--
-- -net -all -DROP -info --
-- +loc -loc -REJECT -info --
-+ +
++ +net +all +DROP +info ++
++ - + - +all +all +REJECT +info ++
+
This table may be interpreted as follows:
+ + +WARNING:
-Where zones are nested or overlapping , the - CONTINUE policy allows hosts that are within multiple zones -to be managed under the rules of all of these zones. Let's look -at an example:
+The firewall script processes the + /etc/shorewall/policy file from top to bottom and uses + the first applicable policy that it finds. For example, +in the following policy file, the policy for (loc, loc) connections + would be ACCEPT as specified in the first entry even though the +third entry in the file specifies REJECT.
-/etc/shorewall/zones:
- - -- +-++- -
-- -ZONE -DISPLAY -COMMENTS -- -sam -Sam -Sam's system at home -- -net -Internet -The Internet -- + +loc -Loc -Local Network -+ +SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST ++ + +loc +all +ACCEPT ++
++
++ +net +all +DROP +info ++
++ - + - +loc +loc +REJECT +info ++
+
/etc/shorewall/interfaces:
+Where zones are nested or overlapping , the + CONTINUE policy allows hosts that are within multiple zones +to be managed under the rules of all of these zones. Let's look +at an example:
+ + +/etc/shorewall/zones:
+ -- - -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -- -eth0 -detect -dhcp,norfc1918 -- + +loc -eth1 -detect --
-+ +ZONE +DISPLAY +COMMENTS ++ +sam +Sam +Sam's system at home ++ +net +Internet +The Internet ++ - + - +loc +Loc +Local Network +
/etc/shorewall/hosts:
+/etc/shorewall/interfaces:
-- +-++- + -
-- -ZONE -HOST(S) -OPTIONS -- - -net -eth0:0.0.0.0/0 --
-- +sam -eth0:206.191.149.197 --
-+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +- +eth0 +detect +dhcp,norfc1918 ++ - - + +loc +eth1 +detect ++
+
Note that Sam's home system is a member of both the sam zone - and the net -zone and as described above , that means -that sam must be listed before net in /etc/shorewall/zones.
+/etc/shorewall/hosts:
-/etc/shorewall/policy:
- - -- +-++- + -
-- -SOURCE -DEST -POLICY -LOG LEVEL -- +loc -net -ACCEPT --
-+ +ZONE +HOST(S) +OPTIONS ++ -net +eth0:0.0.0.0/0 ++
+- - -sam -all -CONTINUE --
-- -net -all -DROP -info -- +all -all -REJECT -info -+ - + - +sam +eth0:206.191.149.197 ++
+
The second entry above says that when Sam is the client, connection - requests should first be process under rules where the source - zone is sam and if there is no match then the connection - request should be treated under rules where the source zone is -net. It is important that this policy be listed BEFORE -the next policy (net to all).
+Note that Sam's home system is a member of both the sam zone + and the net +zone and as described above , that means +that sam must be listed before net in /etc/shorewall/zones.
-Partial /etc/shorewall/rules:
+/etc/shorewall/policy:
-- + face="Century Gothic, Arial, Helvetica"> ++ -- + -
-- ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL +
- DEST+ +SOURCE +DEST +POLICY +LOG LEVEL ++ - -loc +net +ACCEPT ++
+- +... --
--
--
--
--
--
-+ -sam +all +CONTINUE ++
+- -DNAT -sam -loc:192.168.1.3 -tcp -ssh -- --
-- -DNAT -net -loc:192.168.1.5 -tcp -www -- --
-- +... --
--
--
--
--
--
-+ +net +all +DROP +info ++ - + - +all +all +REJECT +info +
Given these two rules, Sam can connect to the firewall's internet interface - with ssh and the connection request will be forwarded to -192.168.1.3. Like all hosts in the net zone, Sam can -connect to the firewall's internet interface on TCP port 80 -and the connection request will be forwarded to 192.168.1.5. The -order of the rules is not significant.
+The second entry above says that when Sam is the client, connection + requests should first be process under rules where the source + zone is sam and if there is no match then the connection + request should be treated under rules where the source zone is +net. It is important that this policy be listed BEFORE the +next policy (net to all).
- -Sometimes it is necessary to suppress port forwarding - for a sub-zone. For example, suppose that all hosts can -SSH to the firewall and be forwarded to 192.168.1.5 EXCEPT -Sam. When Sam connects to the firewall's external IP, he should -be connected to the firewall itself. Because of the way that Netfilter -is constructed, this requires two rules as follows:
+ +Partial /etc/shorewall/rules:
- -- -+ + +- - - + +
++ + - -- -
-- + -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- --
--
--
--
--
--
--
-- ... --
--
--
--
--
-+
-+ -ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL -
+ DEST- -DNAT -sam -fw -tcp -ssh -- --
-- -DNAT -net!sam -loc:192.168.1.3 -tcp -ssh -- --
-- + +... --
--
--
--
--
--
-+ + +... ++
++
++
++
++
++
++ +DNAT +sam +loc:192.168.1.3 +tcp +ssh +- ++
++ +DNAT +net +loc:192.168.1.5 +tcp +www +- ++
++ - - - -... ++
++
++
++
++
++
+The first rule allows Sam SSH - access to the firewall. The second - rule says that any clients from the - net zone with the exception of those - in the 'sam' zone should have their - connection port forwarded to - 192.168.1.3. If you need to exclude - more than one zone in this way, - you can list the - zones separated by - commas (e.g., net!sam,joe,fred). - This technique also may be used when - the ACTION is REDIRECT.
- - - -- /etc/shorewall/rules
- - - -The /etc/shorewall/rules file defines exceptions to the policies established - in the /etc/shorewall/policy file. There is one entry in - /etc/shorewall/rules for each of these rules.
- -
-Shorewall automatically enables firewall->firewall traffic over the - loopback interface (lo) -- that traffic cannot be regulated using - rules and any rule that tries to regulate such traffic will generate - a warning and will be ignored.
- - - -
-Entries in the file have the following columns:
- --
- ACTION - - -
--
- - - -- ACCEPT, DROP, REJECT, CONTINUE. These -have the same meaning here as in the policy file above.
-- DNAT -- Causes the connection request - to be forwarded to the system specified in the DEST column - (port forwarding). "DNAT" stands for "Destination - Network Address Translation"
-- DNAT- -- The above ACTION (DNAT) generates two -iptables rules: 1) and header-rewriting rule in the Netfilter 'nat' -table and; 2) an ACCEPT rule in the Netfilter 'filter' table. DNAT- -works like DNAT but only generates the header-rewriting rule.
-
-- REDIRECT -- Causes the connection request - to be redirected to a port on the local (firewall) system.
-- LOG - Log the packet -- requires a syslog level (see below).
- - - -The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info). -This causes the packet to be logged at the specified level prior -to being processed according to the specified ACTION. Note: if the -ACTION is LOG then you MUST specify a syslog level.
-
-
- The use of DNAT or REDIRECT requires that -you have NAT enabled.
-- SOURCE - Describes the source hosts - to which the rule applies.. The contents of this field must -begin with the name of a zone defined in /etc/shorewall/zones, -$FW or "all". If the ACTION is DNAT or REDIRECT, sub-zones may -be excluded from the rule by following the initial zone name with - "!' and a comma-separated list of those sub-zones to be excluded. - There is an example above.
-
- If the source is not 'all' then the source - may be further restricted by adding a colon (":") followed by - a comma-separated list of qualifiers. Qualifiers are may - include: + +
Given these two rules, Sam can connect to the firewall's internet interface + with ssh and the connection request will be forwarded to 192.168.1.3. + Like all hosts in the net zone, Sam can connect to the + firewall's internet interface on TCP port 80 and the connection + request will be forwarded to 192.168.1.5. The order of the rules + is not significant.
+ + +Sometimes it is necessary to suppress port forwarding + for a sub-zone. For example, suppose that all hosts can SSH + to the firewall and be forwarded to 192.168.1.5 EXCEPT Sam. +When Sam connects to the firewall's external IP, he should be +connected to the firewall itself. Because of the way that Netfilter +is constructed, this requires two rules as follows:
+ + ++ ++ + ++ + + +
+ +
++ + +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ ++
++
++
++
++
++
++
++ +... ++
++
++
++
++
++ +
++ +DNAT +sam +fw +tcp +ssh +- ++
++ +DNAT +net!sam +loc:192.168.1.3 +tcp +ssh +- ++
++ + + + + + + + +... ++
++
++
++
++
++
+
The first rule allows Sam SSH + access to the firewall. The second + rule says that any clients from the + net zone with the exception of those + in the 'sam' zone should have their + connection port forwarded to + 192.168.1.3. If you need to exclude + more than one zone in this way, + you can list the + zones separated by + commas (e.g., net!sam,joe,fred). + This technique also may be used when + the ACTION is REDIRECT.
+ + + +The /etc/shorewall/rules file defines exceptions to the policies established
+ in the /etc/shorewall/policy file. There is one entry in
+/etc/shorewall/rules for each of these rules.
+
Shorewall automatically enables firewall->firewall traffic over the
+ loopback interface (lo) -- that traffic cannot be regulated using
+ rules and any rule that tries to regulate such traffic will generate
+ a warning and will be ignored.
+
Entries in the file have the following columns:
+ +The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info). This
+causes the packet to be logged at the specified level prior to being
+processed according to the specified ACTION. Note: if the ACTION
+is LOG then you MUST specify a syslog level.
+
+ The use of DNAT or REDIRECT requires that
+ you have NAT enabled.
+
Example 1. You wish to forward all - ssh connection requests from the internet to local system + name="PortForward"> Example 1. You wish to forward all + ssh connection requests from the internet to local system 192.168.1.3.
- +- + face="Century Gothic, Arial, Helvetica"> +- - -- + -
-- ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL +
- DEST+ -ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL -
+ DEST- - - - - - - - - - -DNAT -net -loc:192.168.1.3 -tcp -ssh --
--
-
Example 2. 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 -and listening on port 3128. Squid will of course require access -to remote web servers. This example shows yet - another use for the ORIGINAL - DEST column; here, connection - requests that were NOT - -(notice the "!") originally - destined to 206.124.146.177 are - redirected to local port 3128.
- - -- -+ - -- - -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL - -
- DEST- -REDIRECT -loc -3128 -tcp -www -- -
-!206.124.146.177 -- + +ACCEPT -fw -net -tcp -www --
--
-+ - + - +DNAT +net +loc:192.168.1.3 +tcp +ssh ++
++
+
Example 3. You want to run a web server at 155.186.235.222 in -your DMZ and have it accessible remotely and locally. the DMZ is managed - by Proxy ARP or by classical sub-netting.
+ +Example 2. 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 and + listening on port 3128. Squid will of course require access to + remote web servers. This example shows yet + another use for the ORIGINAL + DEST column; here, connection + requests that were NOT + + (notice the "!") originally + destined to 206.124.146.177 + are redirected to +local port 3128.
- -- + +- -++- + -
-- ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL +
- DEST+ -ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL -
+ DEST- - -ACCEPT -net -dmz:155.186.235.222 -tcp -www -- --
-- + +ACCEPT -loc -dmz:155.186.235.222 -tcp -www --
--
-+ +REDIRECT +loc +3128 +tcp +www +- +
+!206.124.146.177 ++ - + - +ACCEPT +fw +net +tcp +www ++
++
+
Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded - DMZ. Your internet interface address is 155.186.235.151 -and you want the FTP server to be accessible from the internet -in addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24 - subnetworks. Note that since the server is in the 192.168.2.0/24 -subnetwork, we can assume that access to the server from that subnet -will not involve the firewall (but see FAQ -2). Note that unless you - have more than one external - IP address, you can leave - the ORIGINAL DEST column - blank in the first rule. You - cannot leave it blank -in the second rule though -because then all -ftp connections - originating in the local - subnet 192.168.1.0/24 would - be sent to 192.168.2.2 - regardless of the site that - the user was trying to - connect to. That is - clearly not what you -want - .
+ +Example 3. You want to run a web server at 155.186.235.222 in your + DMZ and have it accessible remotely and locally. the DMZ is managed + by Proxy ARP or by classical sub-netting.
- -- + face="Century Gothic, Arial, Helvetica"> ++ + + +- + -
-- ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL +
- DEST+ -ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL -
+ DEST- -DNAT -net -dmz:192.168.2.2 -tcp -ftp --
--
-- + +DNAT -loc:192.168.1.0/24 -dmz:192.168.2.2 -tcp -ftp -- -155.186.235.151 -+ + +ACCEPT +net +dmz:155.186.235.222 +tcp +www +- ++
++ - + - +ACCEPT +loc +dmz:155.186.235.222 +tcp +www ++
++
+
Example 4. You want to run wu-ftpd on 192.168.2.2 in your masqueraded + DMZ. Your internet interface address is 155.186.235.151 +and you want the FTP server to be accessible from the internet +in addition to the local 192.168.1.0/24 and dmz 192.168.2.0/24 + subnetworks. Note that since the server is in the 192.168.2.0/24 +subnetwork, we can assume that access to the server from that subnet +will not involve the firewall (but see FAQ +2). Note that unless you + have more than one external + IP address, you can leave + the ORIGINAL DEST column + blank in the first rule. You + cannot leave it blank in +the second rule though +because then all ftp +connections originating +in the local subnet +192.168.1.0/24 would + be sent to 192.168.2.2 + regardless of the site that + the user was trying to + connect to. That is + clearly not what you want + + .
+ + ++ +-+ + +
++ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL + +
+ DEST+ +DNAT +net +dmz:192.168.2.2 +tcp +ftp ++
++
++ - -DNAT +loc:192.168.1.0/24 +dmz:192.168.2.2 +tcp +ftp +- +155.186.235.151 +If you are running wu-ftpd, you should restrict the range of passive - in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions - so I use port range 65500-65535. In /etc/ftpaccess, this -entry is appropriate:
+ + + + + + +
+- -If you are running wu-ftpd, you should restrict the range of passive + in your /etc/ftpaccess file. I only need a few simultaneous FTP sessions + so I use port range 65500-65535. In /etc/ftpaccess, this +entry is appropriate:
- + + ++ + ++passive ports 0.0.0.0/0 65500 65534
-
If you are running pure-ftpd, you would include "-p 65500:65534" on + +
If you are running pure-ftpd, you would include "-p 65500:65534" on the pure-ftpd runline.
- -The important point here is to ensure that the port range used for FTP - passive connections is unique and will not overlap with any + +
The important point here is to ensure that the port range used for FTP + passive connections is unique and will not overlap with any usage on the firewall system.
- -Example 5. You - wish to allow unlimited - DMZ access to the host - with MAC address - 02:00:08:E3:FA:55.
+ +Example 5. You + wish to allow unlimited + DMZ access to the host + with MAC address + 02:00:08:E3:FA:55.
- +- + face="Century Gothic, Arial, Helvetica"> +- - - Example - 6. You wish to allow access to the SMTP server in your DMZ from - all zones.- -
-- +ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL +
- DEST+ -ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL -
+ DEST- + +ACCEPT -loc:~02-00-08-E3-FA-55 -dmz -all --
--
--
-+ - - - -ACCEPT +loc:~02-00-08-E3-FA-55 +dmz +all ++
++
++
+
- -- Example 7 (For advanced users running Shorewall version - 1.3.13 or later). From the internet, you with to forward tcp port - 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in -your DMZ. You also want to allow access from the internet directly to -tcp port 25 on 192.0.2.177.- -
-- -ACTION -
-SOURCE -
-DEST -
-PROTO -
-DEST -
- PORT(S)
-SOURCE -
- PORT(S)
-ORIGINAL -
- DEST
-- - - + - +ACCEPT -
-all -
-dmz -
-tcp -
-25 -
--
--
-
- Note: When 'all' is used as a source or destination, -intra-zone traffic is not affected. In this example, if there were -two DMZ interfaces then the above rule would NOT enable SMTP traffic -between hosts on these interfaces.
-
++ + + Example + 6. You wish to allow access to the SMTP server in your DMZ from + all zones.
+- Using "DNAT-" rather than "DNAT" avoids two extra copies +- -
-- -ACTION -
-SOURCE -
-DEST -
-PROTO -
-DEST -
- PORT(S)
-SOURCE -
- PORT(S)
-ORIGINAL -
- DEST
-- -DNAT- -
-net -
-dmz:192.0.2.177 -
-tcp -
-25 -
-0 -
-192.0.2.178 -
-- -DNAT- -
-net -
-dmz:192.0.2.177 -
-tcp -
-25 -
-0 -
-192.0.2.179 -
-- + +ACCEPT -
-net -
-dmz:192.0.2.177 -
-tcp -
-25 -
--
--
-+ +ACTION +
+SOURCE +
+DEST +
+PROTO +
+DEST +
+ PORT(S)
+SOURCE +
+ PORT(S)
+ORIGINAL +
+ DEST
++ - - + + +ACCEPT +
+all +
+dmz +
+tcp +
+25 +
++
++
+
++ Using "DNAT-" rather than "DNAT" avoids two extra copies of the third rule from being generated.+ +
++ +ACTION +
+SOURCE +
+DEST +
+PROTO +
+DEST +
+ PORT(S)
+SOURCE +
+ PORT(S)
+ORIGINAL +
+ DEST
++ +DNAT- +
+net +
+dmz:192.0.2.177 +
+tcp +
+25 +
+0 +
+192.0.2.178 +
++ +DNAT- +
+net +
+dmz:192.0.2.177 +
+tcp +
+25 +
+0 +
+192.0.2.179 +
++ + + + +ACCEPT +
+net +
+dmz:192.0.2.177 +
+tcp +
+25 +
++
++
+
Look here for information on other services. -
- - - - -Look here for information on other services. +
-Shorewall allows - definition of rules that - apply between all zones. - By default, these rules - are defined in the file - /etc/shorewall/common.def - but may be modified to - suit individual - requirements. Rather - than - modify /etc/shorewall/common.def, - you - should copy that - file to - /etc/shorewall/common - and modify that file.
+The /etc/shorewall/common - file - is expected to - contain iptables - commands; rather than - running iptables - directly, you should run - it indirectly using the - Shorewall function - 'run_iptables'. - That way, if iptables - encounters an error, the - firewall will be safely - stopped.
+ +Shorewall allows + definition of rules that + apply between all zones. + By default, these rules + are defined in the file + /etc/shorewall/common.def + but may be modified to + suit individual + requirements. Rather + than + modify /etc/shorewall/common.def, + you + should copy that + file to + /etc/shorewall/common + and modify that file.
- -The /etc/shorewall/common + file + is expected to + contain iptables + commands; rather than + running iptables + directly, you should run + it indirectly using the + Shorewall function + 'run_iptables'. + That way, if iptables + encounters an error, the + firewall will be safely + stopped.
- -The /etc/shorewall/masq file is used to define classical IP Masquerading - and Source Network Address Translation (SNAT). There is one - entry in the file for each subnet that you want to masquerade. + +
The /etc/shorewall/masq file is used to define classical IP Masquerading + and Source Network Address Translation (SNAT). There is one + entry in the file for each subnet that you want to masquerade. In order to make use of this feature, you must have NAT enabled .
- +Columns are:
- +Example 1: You have eth0 connected to a cable modem and eth1 - connected to your local subnetwork 192.168.9.0/24. Your -/etc/shorewall/masq file would look like:
+ +Example 1: You have eth0 connected to a cable modem and eth1 + connected to your local subnetwork 192.168.9.0/24. Your /etc/shorewall/masq + file would look like:
- -- - -- - -- - -
-- -INTERFACE -SUBNET -ADDRESS -- - - - - - - - - - -eth0 -192.168.9.0/24 --
-
Example 2: You have a number of IPSEC tunnels through ipsec0 - and you want to masquerade traffic from your 192.168.9.0/24 - subnet to the remote subnet 10.1.0.0/16 only.
- - +- ++ + +- + -
-- -INTERFACE -SUBNET -ADDRESS -- +ipsec0:10.1.0.0/16 -192.168.9.0/24 --
-+ +INTERFACE +SUBNET +ADDRESS ++ - + - +eth0 +192.168.9.0/24 ++
+
Example 2: You have a number of IPSEC tunnels through ipsec0 + and you want to masquerade traffic from your 192.168.9.0/24 + subnet to the remote subnet 10.1.0.0/16 only.
- -Example 3: You have a DSL line connected on eth0 and a local - network - (192.168.10.0/24) - connected to eth1. You - want all local->net - connections to use - source address - 206.124.146.176.
- - +- -- - - -- -
-- -INTERFACE -SUBNET -ADDRESS -- - - - - - - - -eth0 -192.168.10.0/24 -206.124.146.176 -
Example 4: - Same as example 3 - except that you wish - to exclude - 192.168.10.44 and - 192.168.10.45 from - the SNAT rule.
- - - - -- - -- - Example - 5 (Shorewall version >= 1.3.14): You have a second IP address (206.124.146.177) - assigned to you and wish to use it for SNAT of the subnet 192.168.12.0/24. - You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes - in /etc/shorewall/shorewall.conf.- - -
-- -INTERFACE -SUBNET -ADDRESS -- - - - - - - - -eth0 -192.168.10.0/24!192.168.10.44,192.168.10.45 -206.124.146.176 -
-- -+ - -
-- -INTERFACE -SUBNET -ADDRESS -- - - - - - - - -eth0:0 -192.168.12.0/24 -206.124.146.177 -
If you want to - use proxy ARP on an - entire sub-network, - I suggest that you - look at - - http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. - - If you decide to use - the technique - described in that - HOWTO, you can set - the proxy_arp flag - for an interface - (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) - by - including the - proxyarp option - in the interface's - record in - - /etc/shorewall/interfaces. - When using -Proxy ARP - sub-netting, you do - NOT include - any entries in - /etc/shorewall/proxyarp.
- - - - -The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is - typically used for - enabling Proxy ARP - on a small set of - systems since you - need one entry - in - this file for each - system using proxy - ARP. Columns are:
- -Note: After you have made a change to the /etc/shorewall/proxyarp - file, you may need to flush the ARP cache of all routers -on the LAN segment connected to the interface specified in the -EXTERNAL column of the change/added entry(s). If you are having -problems communicating between an individual host (A) on that -segment and a system whose entry has changed, you may need to -flush the ARP cache on host A as well.
- - - -ISPs typically have ARP configured with long -TTL (hours!) so if your ISPs router has a stale cache entry (as seen using -"tcpdump -nei <external interface> host <IP addr>"), it may -take a long while to time out. I personally have had to contact my ISP -and ask them to delete a stale entry in order to restore a system to working -order after changing my proxy ARP settings.
- - - - -Example: - You have public IP addresses 155.182.235.0/28. You configure your - firewall as follows:
- -In your DMZ, you want to install a Web/FTP server with public address - 155.186.235.4. On the Web server, you subnet just like the - firewall's eth0 and you configure 155.186.235.1 as the default - gateway. In your /etc/shorewall/proxyarp file, you will have:
- - - -- - -+ - -- - -
-- -ADDRESS -INTERFACE -EXTERNAL -HAVEROUTE -- +155.186.235.4 -eth2 -eth0 -No -+ +INTERFACE +SUBNET +ADDRESS ++ - + - +ipsec0:10.1.0.0/16 +192.168.9.0/24 ++
+
Note: You may want to configure the servers in your DMZ with a subnet - that is smaller than the subnet of your internet interface. - See the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) - for details. In this case you will want to place "Yes" in -the HAVEROUTE column.
+ + +Example 3: You have a DSL line connected on eth0 and a local + network + (192.168.10.0/24) + connected to eth1. You + want all local->net + connections to use + source address + 206.124.146.176.
+ + ++ ++ + + ++ + +
++ +INTERFACE +SUBNET +ADDRESS ++ + + + + + + + +eth0 +192.168.10.0/24 +206.124.146.176 +
Example 4: + Same as example 3 + except that you wish + to exclude + 192.168.10.44 and + 192.168.10.45 from + the SNAT rule.
+ + + + ++ + ++ + Example + 5 (Shorewall version >= 1.3.14): You have a second IP address (206.124.146.177) + assigned to you and wish to use it for SNAT of the subnet 192.168.12.0/24. + You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes + in /etc/shorewall/shorewall.conf.+ + +
++ +INTERFACE +SUBNET +ADDRESS ++ + + + + + + + +eth0 +192.168.10.0/24!192.168.10.44,192.168.10.45 +206.124.146.176 +
+ ++ ++ + +
++ +INTERFACE +SUBNET +ADDRESS ++ + + + + + + + +eth0:0 +192.168.12.0/24 +206.124.146.177 +
If you want to + use proxy ARP on an + entire sub-network, + I suggest that you + look at + + http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. + + If you decide to use + the technique + described in that + HOWTO, you can set + the proxy_arp flag + for an interface + (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) + by + including the + proxyarp option + in the interface's + record in + + /etc/shorewall/interfaces. + When using Proxy + ARP sub-netting, + you do NOT + include + any entries in + /etc/shorewall/proxyarp.
+ + + + +The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is + typically used for + enabling Proxy ARP + on a small set of + systems since you + need one entry + in + this file for each + system using proxy + ARP. Columns are:
+ +Note: After you have made a change to the /etc/shorewall/proxyarp + file, you may need to flush the ARP cache of all routers on + the LAN segment connected to the interface specified in the EXTERNAL + column of the change/added entry(s). If you are having problems +communicating between an individual host (A) on that segment +and a system whose entry has changed, you may need to flush the +ARP cache on host A as well.
-Warning: Do not use Proxy ARP and -FreeS/Wan on the same system unless you are prepared to suffer the consequences. - If you start or restart Shorewall with an IPSEC tunnel active, - the proxied IP addresses are mistakenly assigned to the IPSEC -tunnel device (ipsecX) rather than to the interface that you -specify in the INTERFACE column of /etc/shorewall/proxyarp. I haven't -had the time 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 +
ISPs typically have ARP configured with long TTL + (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump + -nei <external interface> host <IP addr>"), it may take a long +while to time out. I personally have had to contact my ISP and ask them +to delete a stale entry in order to restore a system to working order after +changing my proxy ARP settings.
+ + + + +Example: + You have public IP addresses 155.182.235.0/28. You configure your + firewall as follows:
+ +In your DMZ, you want to install a Web/FTP server with public address + 155.186.235.4. On the Web server, you subnet just like the + firewall's eth0 and you configure 155.186.235.1 as the default + gateway. In your /etc/shorewall/proxyarp file, you will have:
+ + + ++ + ++ + ++ + +
++ +ADDRESS +INTERFACE +EXTERNAL +HAVEROUTE ++ + + + + + + + + + + +155.186.235.4 +eth2 +eth0 +No +
Note: You may want to configure the servers in your DMZ with a subnet + that is smaller than the subnet of your internet interface. + See the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) + for details. In this case you will want to place "Yes" in +the HAVEROUTE column.
+ + + +Warning: Do not use Proxy ARP and + FreeS/Wan on the same system unless you are prepared to suffer the consequences. + If you start or restart Shorewall with an IPSEC tunnel active, + the proxied IP addresses are mistakenly assigned to the IPSEC +tunnel device (ipsecX) rather than to the interface that you specify +in the INTERFACE column of /etc/shorewall/proxyarp. I haven't had +the time 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
- -The /etc/shorewall/nat file is used to define static NAT. There is one - entry in the file for each static NAT relationship that -you wish to define. In order to make use of this feature, you -must have NAT enabled .
+ +The /etc/shorewall/nat file is used to define static NAT. There is one + entry in the file for each static NAT relationship that you + wish to define. In order to make use of this feature, you must + have NAT enabled .
+ + + +- 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. - Also, in most - cases - - Proxy ARP - provides a - superior solution - to static NAT - because the - internal systems - are accessed - using - the same IP - address internally - and externally.
+ color="#ff0000"> + 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. + Also, in most + cases + + Proxy ARP + provides a + superior solution + to static NAT + because the + internal systems + are accessed + using +the same IP + address internally + and externally. - +Columns in an entry are:
- +Look here for additional information and an example. - -
+ +Look here for additional information and an example. + +
- -The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, - OpenVPN and PPTP -tunnels with end-points on your firewall. To use ipsec, you must - install version 1.9, 1.91 or the current FreeS/WAN development -snapshot.
+ +The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, + OpenVPN and PPTP + tunnels with end-points on your firewall. To use ipsec, you must + install version 1.9, 1.91 or the current FreeS/WAN development snapshot. +
- -Note: For kernels 2.4.4 and above, you will need to use version 1.91 - or a development snapshot as patching with version 1.9 results + +
Note: For kernels 2.4.4 and above, you will need to use version 1.91 + or a development snapshot as patching with version 1.9 results in kernel compilation errors.
- - Instructions for setting up IPSEC tunnels may
- be found here, instructions
+
+ Instructions for setting up IPSEC tunnels may
+ be found here, instructions
for IPIP and GRE tunnels are here, instructions for OpenVPN tunnels are here, and
+ href="OPENVPN.html">instructions for OpenVPN tunnels are here
This file is used to set the following firewall parameters:
- +Rules not meeting those criteria will continue to generate an individual + +
Rules not meeting those criteria will continue to generate an individual rule for each listed port or port range.
-The file /etc/shorewall/modules contains commands for loading the kernel - modules required by Shorewall-defined firewall rules. Shorewall - will source this file during start/restart provided that it - exists and that the directory specified by the MODULESDIR parameter - exists (see /etc/shorewall/shorewall.conf - above).
+ +The file /etc/shorewall/modules contains commands for loading the kernel + modules required by Shorewall-defined firewall rules. Shorewall + will source this file during start/restart provided that it + exists and that the directory specified by the MODULESDIR parameter + exists (see /etc/shorewall/shorewall.conf +above).
- -The file that is released with Shorewall calls the Shorewall function + +
The file that is released with Shorewall calls the Shorewall function "loadmodule" for the set of modules that I load.
- +The loadmodule function is called as follows:
- -+ +- +- -+ +loadmodule - <modulename> - [ <module parameters> ]
-loadmodule + <modulename> + [ <module parameters> ]
+
where
- -+ +- -- ++<modulename>
- -+ +- +- -+ +is the name of the modules without the trailing ".o" (example - ip_conntrack).
-is the name of the modules without the trailing ".o" (example + ip_conntrack).
+<module parameters>
- -+ ++- +-Optional parameters to the insmod utility.
-
The function determines if the module named by <modulename> - is already loaded and if not then the function determines - if the ".o" file corresponding to the module exists in the -moduledirectory; if so, then the following command -is executed:
+ +The function determines if the module named by <modulename> + is already loaded and if not then the function determines + if the ".o" file corresponding to the module exists in the +moduledirectory; if so, then the following command is +executed:
- -+ +- -- -+insmod moduledirectory/<modulename>.o <module + +
insmod moduledirectory/<modulename>.o <module parameters>
-
If the file doesn't exist, the function determines of the ".o.gz" - file corresponding to the module exists in the moduledirectory. -If it does, the function assumes that the running configuration supports -compressed modules and execute the following command:
+ +If the file doesn't exist, the function determines of the ".o.gz" +file corresponding to the module exists in the moduledirectory. If +it does, the function assumes that the running configuration supports compressed + modules and execute the following command:
- -+ +-- -- - - - -insmod moduledirectory/<modulename>.o.gz <module + +
insmod moduledirectory/<modulename>.o.gz <module parameters>
-- /etc/shorewall/tos Configuration
+
The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet destination, - protocol, source port and destination port. In order for +
The /etc/shorewall/tos file allows you to set the Type of Service field + in packet headers based on packet source, packet destination, + protocol, source port and destination port. In order for this file to be processed by Shorewall, you must have mangle support enabled .
- +Entries in the file have the following columns:
- ++ ++- -- -+ +-- +Minimize-Delay (16)
+ Maximize-Throughput (8)
- Maximize-Throughput (8)
- Maximize-Reliability (4)
- Minimize-Cost (2)
- Normal-Service (0)
+ Maximize-Reliability (4)
+ Minimize-Cost (2)
+ Normal-Service (0) +The /etc/shorewall/tos file that is included with Shorewall contains + +
The /etc/shorewall/tos file that is included with Shorewall contains the following entries.
- -- + ++ + + ++- - -- + -
-- -SOURCE -DEST -PROTOCOL -SOURCE -
- PORT(S)DEST PORT(S) -TOS -- -all -all -tcp -- -ssh -16 -- -all -all -tcp -ssh -- -16 -- -all -all -tcp -- -ftp -16 -- -all -all -tcp -ftp -- -16 -- -all -all -tcp -- -ftp-data -8 -- +all -all -tcp -ftp-data -- -8 -+ +SOURCE +DEST +PROTOCOL +SOURCE +
+ PORT(S)DEST PORT(S) +TOS ++ +all +all +tcp +- +ssh +16 ++ +all +all +tcp +ssh +- +16 ++ +all +all +tcp +- +ftp +16 ++ +all +all +tcp +ftp +- +16 ++ +all +all +tcp +- +ftp-data +8 ++ - - - - - - -all +all +tcp +ftp-data +- +8 +WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos file. + + + + + + +
WARNING: Users have reported that odd routing problems result from + adding the ESP and AH protocols to the /etc/shorewall/tos file.
- +/etc/shorewall/blacklist
- -Each - line - in - /etc/shorewall/blacklist - contains - - an - IP - address, a MAC address in Shorewall Format - or - subnet - address. - - Example:
+ +Each + line + in + /etc/shorewall/blacklist + contains - + an + IP + address, a MAC address in Shorewall Format + or + subnet + address. + + Example:
+ +130.252.100.69- -
206.124.146.0/24Packets - from - hosts - listed - in - - the - blacklist - file - will - be + +
Packets + from + hosts + listed + in - disposed - of - according - to - the + the + blacklist + file + will - value - assigned - to - the BLACKLIST_DISPOSITION - - and BLACKLIST_LOGLEVEL variables + be + disposed + of + according + to + the - in - /etc/shorewall/shorewall.conf. - Only - packets - - arriving - on - interfaces - that - have + value + assigned + to + the BLACKLIST_DISPOSITION + and BLACKLIST_LOGLEVEL variables + in + /etc/shorewall/shorewall.conf. - the - 'blacklist' - option - - in - /etc/shorewall/interfaces - are - checked + Only + packets + arriving + on + interfaces - against - the - blacklist. The black list is designed to prevent - listed hosts/subnets from accessing services on your - network.
- + that + have + the + 'blacklist' + + option + in + /etc/shorewall/interfaces + are + + checked + against + the + blacklist. The black list +is designed to prevent listed hosts/subnets from accessing services +on your network.
-
+ +Beginning with Shorewall 1.3.8, the blacklist file has three columns:
- + +
--
- -- ADDRESS/SUBNET - As described above.
-- PROTOCOL - Optional. If specified, +
- ADDRESS/SUBNET - As described above.
+- PROTOCOL - Optional. If specified, only packets specifying this protocol will be blocked.
-- PORTS - Optional; may only be given - if PROTOCOL is tcp, udp or icmp. Expressed as a comma-separated - list of port numbers or service names (from /etc/services). If present, - only packets destined for the specified protocol and one of the - listed ports are blocked. When the PROTOCOL is icmp, the PORTS column - contains a comma-separated list of ICMP type numbers or names (see - "iptables -h icmp").
- +
-- PORTS - Optional; may only be given + if PROTOCOL is tcp, udp or icmp. Expressed as a comma-separated + list of port numbers or service names (from /etc/services). If +present, only packets destined for the specified protocol and +one of the listed ports are blocked. When the PROTOCOL is icmp, the +PORTS column contains a comma-separated list of ICMP type numbers + or names (see "iptables -h icmp").
+
+Shorewall also has a dynamic blacklist + +
Shorewall also has a dynamic blacklist capability.
- -IMPORTANT: The Shorewall blacklist file is NOT - designed to police your users' web browsing -- to do that, -I suggest that you install and configure Squid (IMPORTANT: The Shorewall blacklist file is NOT + designed to police your users' web browsing -- to do that, I + suggest that you install and configure Squid (http://www.squid-cache.org).
- +/etc/shorewall/rfc1918 (Added in Version 1.3.1)
- -This file lists the subnets affected by the norfc1918 + +
This file lists the subnets affected by the norfc1918 interface option. Columns in the file are:
- +-
- -- SUBNET - The subnet using +
- SUBNET - The subnet using VLSM notation (e.g., 192.168.0.0/16).
-- TARGET - What to -do with packets to/from the SUBNET: +
- TARGET - What to +do with packets to/from the SUBNET: - +
- + +-
-- RETURN - Process the packet - normally thru the rules and policies.
+- RETURN - Process the +packet normally thru the rules and policies.
-- DROP - Silently drop the - packet.
+- DROP - Silently drop +the packet.
-- logdrop - Log then drop - the packet -- see the RFC1918_LOG_LEVEL parameter +
- logdrop - Log then drop + the packet -- see the RFC1918_LOG_LEVEL parameter above.
- +/etc/shorewall/routestopped (Added in Version - 1.3.4)
- - - - - -This file defines the hosts that are accessible from the firewall when - the firewall is stopped. Columns in the file are:
- - - - - -- -
- - - - - -- INTERFACE - The firewall -interface through which the host(s) comminicate with the firewall.
- -- HOST(S) - (Optional) - A -comma-separated list of IP/Subnet addresses. If not supplied or -supplied as "-" then 0.0.0.0/0 is assumed.
- -Example: When your firewall is stopped, you want firewall accessibility - from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ -interfaces through eth1 and your local hosts through eth2.
- - - - - -- - -- - - - +- - -
-- - - -INTERFACE - -HOST(S) - -- - - -eth2 - -192.168.1.0/24 - -- - - - - - - - -eth1 - -- - -/etc/shorewall/routestopped (Added in Version + 1.3.4)
+ + + + + +This file defines the hosts that are accessible from the firewall when + the firewall is stopped. Columns in the file are:
+ + + + + ++ +
+ + + + + +- INTERFACE - The firewall + interface through which the host(s) comminicate with the firewall.
+ +- HOST(S) - (Optional) - +A comma-separated list of IP/Subnet addresses. If not supplied +or supplied as "-" then 0.0.0.0/0 is assumed.
+ +Example: When your firewall is stopped, you want firewall accessibility + from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ +interfaces through eth1 and your local hosts through eth2.
+ + + + + ++ + ++ + + + ++ + +
++ + + +INTERFACE + +HOST(S) + ++ + + +eth2 + +192.168.1.0/24 + ++ + + + + + + + +eth1 + +- + +/etc/shorewall/maclist (Added in Version 1.3.10)
- This file is described in the MAC Validation Documentation.
-
- -Updated 2/18/2003 - Tom Eastep -
+/etc/shorewall/ecn (Added in Version 1.4.0)
+ This file is described in the ECN Control Documentation.
+
+ +Updated 2/24/2003 - Tom Eastep +
- +Copyright © 2001, 2002, 2003 Thomas M. Eastep.
+ +
-
diff --git a/Shorewall-docs/Install.htm b/Shorewall-docs/Install.htm index 9438668ed..da5e76434 100644 --- a/Shorewall-docs/Install.htm +++ b/Shorewall-docs/Install.htm @@ -1,220 +1,188 @@ - +Shorewall Installation - + - + - +- -
- +- + +- +Shorewall Installation and + +
+ - - ++ -Shorewall Installation and Upgrade
-Before upgrading, be sure to review the Upgrade Issues
- +Install using RPM
- + Install using tarball
- Install using tarball
-Install the .lrp
- Upgrade using RPM
- Upgrade using tarball
-Upgrade the .lrp
- Configuring Shorewall
- Uninstall/Fallback
+ 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 + +
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 + href="http://www.redhat.com/support/errata/RHSA-2001-144.html">RedHat update + site or from the Shorewall Errata page before attempting to start Shorewall.
- +-
- -- Install the RPM (rpm -ivh <shorewall rpm>).
-
-
- Note: 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>).- 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>).
+
+
+ Note: 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>).- 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 + +
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, 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 +
- 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 +
- For other distributions, determine where your distribution + installs init scripts and type "./install.sh <init script directory>
-- Edit the configuration files to match +
- 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 +
- 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 + +
+ +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 + +
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.3 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.3 (you must use the -new 1.3 syntax). See the upgrade issues for -details. You can check your rules and host file for 1.3 compatibility using -the "shorewall check" command after installing the latest version of 1.3.
- + +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"). -
Note: 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 +
- 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"). + +
-Note: 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>).
-
-- 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).
- +See if there are any incompatibilities between your configuration + and the new Shorewall version and correct as necessary. +Restart the firewall (shorewall restart). + - -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.3 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.3 (you must use the -new 1.3 syntax). See the upgrade issues -for details. You can check your rules and host file for 1.3 compatibility -using the "shorewall check" command after installing the latest version -of 1.3.
- + +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 for +details.
-
- If you already have a running Bering installation -and wish to upgrade to a later version of Shorewall:- 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, 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 +
- 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 +
- 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"
- +- Check your configuration for incompatibility with 1.4 as described +above.
+
+- Restart the firewall by typing "shorewall restart"
+
-
- 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 these 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.
+-
- -- /etc/shorewall/shorewall.conf - used to set several firewall - parameters.
-- /etc/shorewall/params - use this file to set shell variables that - you will expand in other files.
-- /etc/shorewall/zones - partition the firewall's view of the world - into zones.
-- /etc/shorewall/policy - establishes firewall high-level policy.
-- /etc/shorewall/interfaces - describes the interfaces on the - firewall system.
-- /etc/shorewall/hosts - allows defining zones in terms of individual - hosts and subnetworks.
-- /etc/shorewall/maclist - verification of the MAC addresses of devices.
-
-- /etc/shorewall/masq - directs the firewall where to use many-to-one - (dynamic) NAT a.k.a. Masquerading.
-- /etc/shorewall/modules - directs the firewall to load kernel modules.
-- /etc/shorewall/rules - defines rules that are exceptions to the - overall policies established in /etc/shorewall/policy.
-- /etc/shorewall/nat - defines static NAT rules.
-- /etc/shorewall/proxyarp - defines use of Proxy ARP.
-- /etc/shorewall/routestopped (Shorewall 1.3.4 and later) - defines - hosts accessible when Shorewall is stopped.
-- /etc/shorewall/tcrules - defines marking of packets for later use - by traffic control/shaping.
-- /etc/shorewall/tos - defines rules for setting the TOS field in -packet headers.
-- /etc/shorewall/tunnels - defines IPSEC tunnels with end-points on - the firewall system.
-- /etc/shorewall/blacklist - lists blacklisted IP/subnet/MAC addresses.
- +Updated 1/30/2003 - Tom Eastep +
+Updated 1/24/2003 - Tom Eastep
- +Copyright © 2001, 2002, 2003 Thomas M. Eastep.
-
+
+
diff --git a/Shorewall-docs/News.htm b/Shorewall-docs/News.htm index 891e46fa6..f5d18a42e 100644 --- a/Shorewall-docs/News.htm +++ b/Shorewall-docs/News.htm @@ -3,7 +3,7 @@ - +Shorewall News @@ -11,612 +11,592 @@ - + - + - +- -
- +- ++ + + + - - + +- + -Shorewall News Archive
-3/14/2003 - Shorewall 1.4.0
- Shorewall 1.4 represents the -next step in the evolution of Shorewall. The main thrust of the initial -release is simply to remove the cruft that has accumulated in Shorewall -over time.
+ Shorewall 1.4 represents the +next step in the evolution of Shorewall. The main thrust of the initial release + is simply to remove the cruft that has accumulated in Shorewall over time.
-IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package +
+ IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package ('ip' utility).
-
- Function from 1.3 that has been omitted from this version include:
- +
+ Function from 1.3 that has been omitted from this version include:
+-
- Changes for 1.4 include:- The MERGE_HOSTS variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
-
-
-- Interface names of the form <device>:<integer> in /etc/shorewall/interfaces - now generate an error.
-
-
-- Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. - OLD_PING_HANDLING=Yes will generate an error at startup as will specification - of the 'noping' or 'filterping' interface options.
-
-
-- The 'routestopped' option in the /etc/shorewall/interfaces and /etc/shorewall/hosts - files is no longer supported and will generate an error at startup if specified.
-
-
-- The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer - accepted.
-
-
-- The ALLOWRELATED variable in shorewall.conf is no longer supported. - Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
-
-
-- The icmp.def file has been removed.
- -
-
- --
- -- The /etc/shorewall/shorewall.conf file has been completely reorganized - into logical sections.
-
-
-- LOG is now a valid action for a rule (/etc/shorewall/rules).
-
-
-- The firewall script and version file are now installed in /usr/share/shorewall.
-
-
-- Late arriving DNS replies are now silently dropped in the common -chain by default.
-
-
-- In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 -no longer unconditionally accepts outbound ICMP packets. So if you want to -'ping' from the firewall, you will need the appropriate rule or policy. -
- -2/8/2003 - Shoreawall 1.3.14
- -New features include
- --
- -- An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been (see - http://www.shorewall.net/ping.html).
-
-
- When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules - and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options -in /etc/shorewall/interfaces will all generate an error.
-
-- It is now possible to direct Shorewall to create a "label" such - as "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
-
-
- a) In the INTERFACE column of /etc/shorewall/masq
- b) In the INTERFACE column of /etc/shorewall/nat
-- Support for OpenVPN Tunnels.
-
-
-- Support for VLAN devices with names of the form $DEV.$VID (e.g., - eth0.0)
+- The "check" command is no longer supported.
+
+
+- The MERGE_HOSTS variable in shorewall.conf is no longer supported. +Shorewall 1.4 behavior is the same as 1.3 with MERGE_HOSTS=Yes.
-
- In /etc/shorewall/tcrules, the MARK 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.
-
-
-- When an interface name is entered in the SUBNET column of the - /etc/shorewall/masq file, Shorewall previously masqueraded traffic -from only the first subnet defined on that interface. It did not masquerade - traffic from:
- +
-
- a) The subnets associated with other addresses on the interface.
- b) Subnets accessed through local routers.
-
- Beginning with Shorewall 1.3.14, if you enter an interface name - in the SUBNET column, shorewall will use the firewall's routing table - to construct the masquerading/SNAT rules.
-
- Example 1 -- This is how it works in 1.3.14.
-
- -[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]# shorewall start-
...
Masqueraded Subnets and Hosts:
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
Processing /etc/shorewall/tos...
- When upgrading to Shorewall 1.3.14, if you have multiple local - subnets connected to an interface that is specified in the SUBNET column - of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will -need changing. In most cases, you will simply be able to remove redundant -entries. In some cases though, you might want to change from using the -interface name to listing specific subnetworks if the change described -above will cause masquerading to occur on subnetworks that you don't wish -to masquerade.
-
- Example 2 -- 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 3 -- 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- Interface names of the form <device>:<integer> in /etc/shorewall/interfaces + now generate an error.
+
+
+- Shorewall 1.4 implements behavior consistent with OLD_PING_HANDLING=No. + OLD_PING_HANDLING=Yes will generate an error at startup as will specification + of the 'noping' or 'filterping' interface options.
+
+
+- The 'routestopped' option in the /etc/shorewall/interfaces and +/etc/shorewall/hosts files is no longer supported and will generate an +error at startup if specified.
+
+
+- The Shorewall 1.2 syntax for DNAT and REDIRECT rules is no longer + accepted.
+
+
+- The ALLOWRELATED variable in shorewall.conf is no longer supported. + Shorewall 1.4 behavior is the same as 1.3 with ALLOWRELATED=Yes.
+
+
+- The icmp.def file has been removed.
+
+- -
- 2/5/2003 - Shorewall Support included in Webmin 1.060Webmin version 1.060 now has Shorewall support included as standard. See - http://www.webmin.com.
- -
-
- 2/4/2003 - Shorewall 1.3.14-RC1Includes the Beta 2 content plus support for OpenVPN tunnels.
- -1/28/2003 - Shorewall 1.3.14-Beta2
- -Includes the Beta 1 content plus restores VLAN device names of the form - $dev.$vid (e.g., eth0.1)
- -1/25/2003 - Shorewall 1.3.14-Beta1
- -
-The Beta includes the following changes:
- + Changes for 1.4 include:
-
+-
+ +- An OLD_PING_HANDLING option has been added to shorewall.conf. - When set to Yes, Shorewall ping handling is as it has always been (see - http://www.shorewall.net/ping.html).
-
-
- When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules - and policies just like any other connection request. The FORWARDPING=Yes - option in shorewall.conf and the 'noping' and 'filterping' options -in /etc/shorewall/interfaces will all generate an error.
-
-- It is now possible to direct Shorewall to create a "label" - such as "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes - and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead - of just the interface name:
-
-
- a) In the INTERFACE column of /etc/shorewall/masq
- b) In the INTERFACE column of /etc/shorewall/nat
-- When an interface name is entered in the SUBNET column -of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic - from only the first subnet defined on that interface. It did not masquerade - traffic from:
- +
-
- a) The subnets associated with other addresses on the interface.
- b) Subnets accessed through local routers.
-
- Beginning with Shorewall 1.3.14, if you enter an interface name - in the SUBNET column, shorewall will use the firewall's routing table - to construct the masquerading/SNAT rules.
-
- Example 1 -- This is how it works in 1.3.14.
-
- -[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]# shorewall start-
...
Masqueraded Subnets and Hosts:
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
Processing /etc/shorewall/tos...
- When upgrading to Shorewall 1.3.14, if you have multiple local - subnets connected to an interface that is specified in the SUBNET column - of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will -need changing. In most cases, you will simply be able to remove redundant -entries. In some cases though, you might want to change from using the -interface name to listing specific subnetworks if the change described -above will cause masquerading to occur on subnetworks that you don't wish -to masquerade.
-
- Example 2 -- 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 3 -- 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- The /etc/shorewall/shorewall.conf file has been completely reorganized + into logical sections.
+
+
+- LOG is now a valid action for a rule (/etc/shorewall/rules).
+
+
+- The firewall script and version file are now installed in /usr/share/shorewall.
+
+
+- Late arriving DNS replies are now silently dropped in the common + chain by default.
+
+
+- In addition to behaving like OLD_PING_HANDLING=No, Shorewall 1.4 + no longer unconditionally accepts outbound ICMP packets. So if you want +to 'ping' from the firewall, you will need the appropriate rule or policy. +
+2/8/2003 - Shoreawall 1.3.14
+ +New features include
+ ++
+ +- An OLD_PING_HANDLING option has been added to shorewall.conf. + When set to Yes, Shorewall ping handling is as it has always been (see + http://www.shorewall.net/ping.html).
+
+
+ When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules + and policies just like any other connection request. The FORWARDPING=Yes + option in shorewall.conf and the 'noping' and 'filterping' options in + /etc/shorewall/interfaces will all generate an error.
+
+- It is now possible to direct Shorewall to create a "label" +such as "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes + and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead + of just the interface name:
+
+
+ a) In the INTERFACE column of /etc/shorewall/masq
+ b) In the INTERFACE column of /etc/shorewall/nat
+- Support for OpenVPN Tunnels.
+
+
+- Support for VLAN devices with names of the form $DEV.$VID (e.g., + eth0.0)
+
+
+- In /etc/shorewall/tcrules, the MARK 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.
+
+
+- When an interface name is entered in the SUBNET column of the + /etc/shorewall/masq file, Shorewall previously masqueraded traffic from + only the first subnet defined on that interface. It did not masquerade + traffic from:
+ +
+
+ a) The subnets associated with other addresses on the interface.
+ b) Subnets accessed through local routers.
+
+ Beginning with Shorewall 1.3.14, if you enter an interface name + in the SUBNET column, shorewall will use the firewall's routing table + to construct the masquerading/SNAT rules.
+
+ Example 1 -- This is how it works in 1.3.14.
+
+ + +[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]# shorewall start+
...
Masqueraded Subnets and Hosts:
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
Processing /etc/shorewall/tos...
+ When upgrading to Shorewall 1.3.14, if you have multiple local + subnets connected to an interface that is specified in the SUBNET column + of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will need + changing. In most cases, you will simply be able to remove redundant entries. + In some cases though, you might want to change from using the interface + name to listing specific subnetworks if the change described above will +cause masquerading to occur on subnetworks that you don't wish to masquerade.
+
+ Example 2 -- 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 3 -- 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+ +
+ 2/5/2003 - Shorewall Support included in Webmin 1.060Webmin version 1.060 now has Shorewall support included as standard. See + http://www.webmin.com.
+ +
+
+ 2/4/2003 - Shorewall 1.3.14-RC1Includes the Beta 2 content plus support for OpenVPN tunnels.
+ +1/28/2003 - Shorewall 1.3.14-Beta2
+Includes the Beta 1 content plus restores VLAN device names of the form + $dev.$vid (e.g., eth0.1)
+ +1/25/2003 - Shorewall 1.3.14-Beta1
+ +
+The Beta includes the following changes:
+ +
++
+- An OLD_PING_HANDLING option has been added to shorewall.conf. + When set to Yes, Shorewall ping handling is as it has always been (see + http://www.shorewall.net/ping.html).
+
+
+ When OLD_PING_HANDLING=No, icmp echo (ping) is handled via rules + and policies just like any other connection request. The FORWARDPING=Yes + option in shorewall.conf and the 'noping' and 'filterping' options in + /etc/shorewall/interfaces will all generate an error.
+
+- It is now possible to direct Shorewall to create a "label" + such as "eth0:0" for IP addresses that it creates under ADD_IP_ALIASES=Yes + and ADD_SNAT_ALIASES=Yes. This is done by specifying the label instead + of just the interface name:
+
+
+ a) In the INTERFACE column of /etc/shorewall/masq
+ b) In the INTERFACE column of /etc/shorewall/nat
+- When an interface name is entered in the SUBNET column +of the /etc/shorewall/masq file, Shorewall previously masqueraded traffic + from only the first subnet defined on that interface. It did not masquerade + traffic from:
+ +
+
+ a) The subnets associated with other addresses on the interface.
+ b) Subnets accessed through local routers.
+
+ Beginning with Shorewall 1.3.14, if you enter an interface name + in the SUBNET column, shorewall will use the firewall's routing table + to construct the masquerading/SNAT rules.
+
+ Example 1 -- This is how it works in 1.3.14.
+
+ + +[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]# shorewall start+
...
Masqueraded Subnets and Hosts:
To 0.0.0.0/0 from 192.168.1.0/24 through eth0 using 206.124.146.176
To 0.0.0.0/0 from 192.168.10.0/24 through eth0 using 206.124.146.176
Processing /etc/shorewall/tos...
+ When upgrading to Shorewall 1.3.14, if you have multiple local + subnets connected to an interface that is specified in the SUBNET column + of an /etc/shorewall/masq entry, your /etc/shorewall/masq file will need + changing. In most cases, you will simply be able to remove redundant entries. + In some cases though, you might want to change from using the interface + name to listing specific subnetworks if the change described above will +cause masquerading to occur on subnetworks that you don't wish to masquerade.
+
+ Example 2 -- 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 3 -- 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 REMOVE1/18/2003 - Shorewall 1.3.13 Documentation in PDF Format
- -Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation. + +
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.13 documenation. the PDF may be downloaded from
- ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
- http://slovakia.shorewall.net/pub/shorewall/pdf/ - + http://slovakia.shorewall.net/pub/shorewall/pdf/ +1/17/2003 - shorewall.net has MOVED
- +Thanks to the generosity of Alex Martin and Rett Consulting, www.shorewall.net and ftp.shorewall.net -are now hosted on a system in Bellevue, Washington. A big thanks to Alex -for making this happen.
- + href="http://www.rettc.com">Rett Consulting, www.shorewall.net and +ftp.shorewall.net are now hosted on a system in Bellevue, Washington. A +big thanks to Alex for making this happen.
-
+1/13/2003 - Shorewall 1.3.13
- + +
-Just includes a few things that I had on the burner:
- + +
--
- -- A new 'DNAT-' action has been added for entries in -the /etc/shorewall/rules file. DNAT- is intended for advanced users -who wish to minimize the number of rules that connection requests -must traverse.
-
- A Shorewall DNAT rule actually generates two iptables rules: - a header rewriting rule in the 'nat' table and an ACCEPT rule in the - 'filter' table. A DNAT- rule only generates the first of these rules. - This is handy when you have several DNAT rules that would generate -the same ACCEPT rule.
-
- Here are three rules from my previous rules file:
-
- DNAT net dmz:206.124.146.177 tcp smtp - 206.124.146.178
- DNAT net dmz:206.124.146.177 tcp smtp - 206.124.146.179
- ACCEPT net dmz:206.124.146.177 tcp www,smtp,ftp,...
-
- These three rules ended up generating _three_ copies of
-
- ACCEPT net dmz:206.124.146.177 tcp smtp
-
- By writing the rules this way, I end up with only one +- A new 'DNAT-' action has been added for entries in +the /etc/shorewall/rules file. DNAT- is intended for advanced users +who wish to minimize the number of rules that connection requests must +traverse.
-
+
+ A Shorewall DNAT rule actually generates two iptables rules: + a header rewriting rule in the 'nat' table and an ACCEPT rule in the + 'filter' table. A DNAT- rule only generates the first of these rules. + This is handy when you have several DNAT rules that would generate the + same ACCEPT rule.
+
+ Here are three rules from my previous rules file:
+
+ DNAT net dmz:206.124.146.177 tcp smtp - 206.124.146.178
+ DNAT net dmz:206.124.146.177 tcp smtp - 206.124.146.179
+ ACCEPT net dmz:206.124.146.177 tcp www,smtp,ftp,...
+
+ These three rules ended up generating _three_ copies +of
+
+ ACCEPT net dmz:206.124.146.177 tcp smtp
+
+ By writing the rules this way, I end up with only one copy of the ACCEPT rule.
-
- DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.178
- DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.179
- ACCEPT net dmz:206.124.146.177 tcp www,smtp,ftp,....
-
-- The 'shorewall check' command now prints out the applicable - policy between each pair of zones.
-
-
-- A new CLEAR_TC option has been added to shorewall.conf. - If this option is set to 'No' then Shorewall won't clear the current - traffic control rules during [re]start. This setting is intended for -use by people that prefer to configure traffic shaping when the network -interfaces come up rather than when the firewall is started. If that is -what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not supply -an /etc/shorewall/tcstart file. That way, your traffic shaping rules can -still use the 'fwmark' classifier based on packet marking defined in /etc/shorewall/tcrules.
-
-
-- A new SHARED_DIR variable has been added that allows - distribution packagers to easily move the shared directory (default - /usr/lib/shorewall). Users should never have a need to change the -value of this shorewall.conf setting.
- +
-
+ DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.178
+ DNAT- net dmz:206.124.146.177 tcp smtp - 206.124.146.179
+ ACCEPT net dmz:206.124.146.177 tcp www,smtp,ftp,....
+
+ +- The 'shorewall check' command now prints out the applicable + policy between each pair of zones.
+
+
+- A new CLEAR_TC option has been added to shorewall.conf. + If this option is set to 'No' then Shorewall won't clear the current + traffic control rules during [re]start. This setting is intended for + use by people that prefer to configure traffic shaping when the network + interfaces come up rather than when the firewall is started. If that +is what you want to do, set TC_ENABLED=Yes and CLEAR_TC=No and do not +supply an /etc/shorewall/tcstart file. That way, your traffic shaping +rules can still use the 'fwmark' classifier based on packet marking defined +in /etc/shorewall/tcrules.
+
+
+- A new SHARED_DIR variable has been added that allows + distribution packagers to easily move the shared directory (default + /usr/lib/shorewall). Users should never have a need to change the value + of this shorewall.conf setting.
+
+1/6/2003 - BURNOUT -
- -Until further notice, I will not be involved in either Shorewall Development - or Shorewall Support
- + +1/6/2003 - BURNOUT +
+ +Until further notice, I will not be involved in either Shorewall Development + or Shorewall Support
+-Tom Eastep
- + +
-12/30/2002 - Shorewall Documentation in PDF Format
- -Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. + +
Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.12 documenation. the PDF may be downloaded from
- +ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
- + +
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-12/27/2002 - Shorewall 1.3.12 Released
- +Features include:
- + +
--
- +- "shorewall refresh" now reloads the traffic shaping +
- "shorewall refresh" now reloads the traffic shaping rules (tcrules and tcstart).
-- "shorewall debug [re]start" now turns off debugging - after an error occurs. This places the point of the failure near +
- "shorewall debug [re]start" now turns off debugging + after an error occurs. This places the point of the failure near the end of the trace rather than up in the middle of it.
-- "shorewall [re]start" has been speeded up by more +
- "shorewall [re]start" has been speeded up by more than 40% with my configuration. Your milage may vary.
-- A "shorewall show classifiers" command has been -added which shows the current packet classification filters. The -output from this command is also added as a separate page in "shorewall +
- A "shorewall show classifiers" command has been +added which shows the current packet classification filters. The +output from this command is also added as a separate page in "shorewall monitor"
-- ULOG (must be all caps) is now accepted as a valid - syslog level and causes the subject packets to be logged using the - ULOG target rather than the LOG target. This allows you to run ulogd - (available from http://www.gnumonks.org/projects/ulogd) +
- ULOG (must be all caps) is now accepted as a valid + syslog level and causes the subject packets to be logged using +the ULOG target rather than the LOG target. This allows you to run +ulogd (available from http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file.
-- If you are running a kernel that has a FORWARD chain - in the mangle table ("shorewall show mangle" will show you the chains - in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes in - shorewall.conf. This allows for - marking input packets based on their destination even when you +
- If you are running a kernel that has a FORWARD +chain in the mangle table ("shorewall show mangle" will show you +the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes +in shorewall.conf. This allows for + marking input packets based on their destination even when you are using Masquerading or SNAT.
-- I have cluttered up the /etc/shorewall directory -with empty 'init', 'start', 'stop' and 'stopped' files. If you -already have a file with one of these names, don't worry -- the upgrade -process won't overwrite your file.
-- I have added a new RFC1918_LOG_LEVEL variable to - shorewall.conf. This variable specifies - the syslog level at which packets are logged as a result of entries - in the /etc/shorewall/rfc1918 file. Previously, these packets were -always logged at the 'info' level.
- +
-- I have cluttered up the /etc/shorewall directory + with empty 'init', 'start', 'stop' and 'stopped' files. If you + already have a file with one of these names, don't worry -- the upgrade + process won't overwrite your file.
+- I have added a new RFC1918_LOG_LEVEL variable to + shorewall.conf. This variable specifies + the syslog level at which packets are logged as a result of entries + in the /etc/shorewall/rfc1918 file. Previously, these packets were + always logged at the 'info' level.
+
+12/20/2002 - Shorewall 1.3.12 Beta 3
- This version corrects a problem with Blacklist logging. - In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the - firewall would fail to start and "shorewall refresh" would also fail.
-
- + + This version corrects a problem with Blacklist logging. + In Beta 2, if BLACKLIST_LOG_LEVEL was set to anything but ULOG, the + firewall would fail to start and "shorewall refresh" would also fail.
+12/20/2002 - Shorewall 1.3.12 Beta 2
- -The first public Beta version of Shorewall 1.3.12 is now available (Beta - 1 was made available only to a limited audience).
- Features include:
-
- + +The first public Beta version of Shorewall 1.3.12 is now available (Beta + 1 was made available only to a limited audience).
+ Features include:
+
+-
- You may download the Beta from:- "shorewall refresh" now reloads the traffic -shaping rules (tcrules and tcstart).
-- "shorewall debug [re]start" now turns off debugging - after an error occurs. This places the point of the failure near - the end of the trace rather than up in the middle of it.
-- "shorewall [re]start" has been speeded up by - more than 40% with my configuration. Your milage may vary.
-- A "shorewall show classifiers" command has -been added which shows the current packet classification filters. -The output from this command is also added as a separate page in -"shorewall monitor"
-- ULOG (must be all caps) is now accepted as -a valid syslog level and causes the subject packets to be logged -using the ULOG target rather than the LOG target. This allows you +
- "shorewall refresh" now reloads the traffic + shaping rules (tcrules and tcstart).
+- "shorewall debug [re]start" now turns off +debugging after an error occurs. This places the point of the +failure near the end of the trace rather than up in the middle of +it.
+- "shorewall [re]start" has been speeded up +by more than 40% with my configuration. Your milage may vary.
+- A "shorewall show classifiers" command has +been added which shows the current packet classification filters. +The output from this command is also added as a separate page in "shorewall + monitor"
+- ULOG (must be all caps) is now accepted as +a valid syslog level and causes the subject packets to be logged +using the ULOG target rather than the LOG target. This allows you to run ulogd (available from http://www.gnumonks.org/projects/ulogd) + href="http://www.gnumonks.org/projects/ulogd">http://www.gnumonks.org/projects/ulogd) and log all Shorewall messages to a separate log file.
-- If you are running a kernel that has a FORWARD - chain in the mangle table ("shorewall show mangle" will show you - the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes - in shorewall.conf. This allows for marking input packets based on +
- If you are running a kernel that has a FORWARD + chain in the mangle table ("shorewall show mangle" will show you + the chains in the mangle table), you can set MARK_IN_FORWARD_CHAIN=Yes + in shorewall.conf. This allows for marking input packets based on their destination even when you are using Masquerading or SNAT.
-- I have cluttered up the /etc/shorewall directory - with empty 'init', 'start', 'stop' and 'stopped' files. If you -already have a file with one of these names, don't worry -- the upgrade +
- I have cluttered up the /etc/shorewall directory + with empty 'init', 'start', 'stop' and 'stopped' files. If you +already have a file with one of these names, don't worry -- the upgrade process won't overwrite your file.
- +
- + You may download the Beta from:
+http://www.shorewall.net/pub/shorewall/Beta- +
- ftp://ftp.shorewall.net/pub/shorewall/Beta
-
12/12/2002 - Mandrake Multi Network Firewall -
- Shorewall is at the center of MandrakeSoft's recently-announced - Multi - Network Firewall (MNF) product. Here is the press + + Shorewall is at the center of MandrakeSoft's +recently-announced Multi + Network Firewall (MNF) product. Here is the press release.12/7/2002 - Shorewall Support for Mandrake 9.0
- -Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. - I have installed 9.0 on one of my systems and I am now in a + +
Two months and 3 days after I ordered Mandrake 9.0, it was finally delivered. + I have installed 9.0 on one of my systems and I am now in a position to support Shorewall users who run Mandrake 9.0.
- +12/6/2002 - Debian 1.3.11a Packages Available
-
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
- -12/3/2002 - Shorewall 1.3.11a
- -This is a bug-fix roll up which includes Roger Aich's fix for DNAT with - excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 - users who don't need rules of this type need not upgrade to 1.3.11.
- -11/24/2002 - Shorewall 1.3.11
- -In this version:
- -11/14/2002 - Shorewall Documentation in PDF Format
- -Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. - the PDF may be downloaded from
- - ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
- http://slovakia.shorewall.net/pub/shorewall/pdf/
-
11/09/2002 - Shorewall is Back at SourceForge -
- - -The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
-
11/09/2002 - Shorewall 1.3.10
- -In this version:
- -10/24/2002 - Shorewall is now in Gentoo Linux
-
10/23/2002 - Shorewall 1.3.10 Beta 1
- In this version:Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
+ +12/3/2002 - Shorewall 1.3.11a
+ +This is a bug-fix roll up which includes Roger Aich's fix for DNAT with + excluded subnets (e.g., "DNAT foo!bar ..."). Current 1.3.11 + users who don't need rules of this type need not upgrade to 1.3.11.
+ +11/24/2002 - Shorewall 1.3.11
+ +In this version:
+ +11/14/2002 - Shorewall Documentation in PDF Format
+ +Juraj Ontkanin has produced a PDF containing the Shorewall 1.3.10 documenation. + the PDF may be downloaded from
+ + ftp://slovakia.shorewall.net/mirror/shorewall/pdf/
+ http://slovakia.shorewall.net/pub/shorewall/pdf/
+
11/09/2002 - Shorewall is Back at SourceForge +
+ + +The main Shorewall 1.3 web site is now back at SourceForge at http://shorewall.sf.net.
+
11/09/2002 - Shorewall 1.3.10
+ +In this version:
+10/10/2002 - Debian 1.3.9b Packages Available
-
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
- -10/9/2002 - Shorewall 1.3.9b
- This release rolls up fixes to the installer - and to the firewall script.10/6/2002 - Shorewall.net now running on RH8.0
-
- The firewall and server here at shorewall.net
- are now running RedHat release 8.0.
-
- 9/30/2002 - Shorewall 1.3.9a
9/30/2002 - TUNNELS Broken in 1.3.9!!!
- There is an updated firewall script - at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall - -- copy that file to /usr/lib/shorewall/firewall.10/24/2002 - Shorewall is now in Gentoo Linux
+
9/28/2002 - Shorewall 1.3.9
+10/23/2002 - Shorewall 1.3.10 Beta 1
+ In this version:In this version:
-
10/10/2002 - Debian 1.3.9b Packages Available
+
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
+ +10/9/2002 - Shorewall 1.3.9b
+ This release rolls up fixes to the +installer and to the firewall script.10/6/2002 - Shorewall.net now running on RH8.0
+
+ The firewall and server here at shorewall.net
+ are now running RedHat release 8.0.
+
+ 9/30/2002 - Shorewall 1.3.9a
9/30/2002 - TUNNELS Broken in 1.3.9!!!
+ There is an updated firewall script + at ftp://www.shorewall.net/pub/shorewall/errata/1.3.9/firewall + -- copy that file to /usr/lib/shorewall/firewall.9/28/2002 - Shorewall 1.3.9
+ + +In this version:
+
9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored
-
+ +- Hopefully these problems -are now corrected. -- ++ Hopefully these problems +are now corrected. ++
+- Mailing List Archive +Search was not available.
+- The Site Search index + was incomplete
+- Only one page of matches + was presented.
+ + + +9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability + Restored
+ A couple of recent configuration + changes at www.shorewall.net had the negative effect + of breaking the Search facility:
+
+ + +-
- Mailing List Archive Search was not available.
- The Site Search index @@ -722,1812 +768,1791 @@ was incomplete
- Only one page of matches was presented.
- - -
9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored
-
9/18/2002 - Debian 1.3.8 Packages Available
-
9/18/2002 - Debian 1.3.8 Packages Available
+
Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
- +9/16/2002 - Shorewall 1.3.8
- +In this version:
-
9/11/2002 - Debian 1.3.7c Packages Available
- +Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html.
- +9/2/2002 - Shorewall 1.3.7c
- -This is a role up of a fix for "DNAT" rules where the source zone is $FW + +
This is a role up of a fix for "DNAT" rules where the source zone is $FW (fw).
- +8/31/2002 - I'm not available
- -I'm currently on vacation -- please respect my need for a couple of -weeks free of Shorewall problem reports.
+ +I'm currently on vacation -- please respect my need for a couple of + weeks free of Shorewall problem reports.
- +-Tom
- +8/26/2002 - Shorewall 1.3.7b
- -This is a role up of the "shorewall refresh" bug fix and the change which + +
This is a role up of the "shorewall refresh" bug fix and the change which reverses the order of "dhcp" and "norfc1918" checking.
- +8/26/2002 - French FTP Mirror is Operational
- +ftp://france.shorewall.net/pub/mirrors/shorewall + href="ftp://france.shorewall.net/pub/mirrors/shorewall">ftp://france.shorewall.net/pub/mirrors/shorewall is now available.
- +8/25/2002 - Shorewall Mirror in France
- -Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored + +
Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored at http://france.shorewall.net.
- +8/25/2002 - Shorewall 1.3.7a Debian Packages Available
- -Lorenzo Martignoni reports that the packages for version 1.3.7a are available + +
Lorenzo Martignoni reports that the packages for version 1.3.7a are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
- -8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author + +
8/22/2002 - Shorewall 1.3.7 Wins a Brown Paper Bag Award for its Author -- Shorewall 1.3.7a released -
+ - -1.3.7a corrects problems occurring in rules file processing when starting + +
1.3.7a corrects problems occurring in rules file processing when starting Shorewall 1.3.7.
- +8/22/2002 - Shorewall 1.3.7 Released 8/13/2002
- +Features in this release include:
- +I would like to thank John Distler for his valuable input regarding TCP - SYN and ICMP treatment in Shorewall. That input -has led to marked improvement in Shorewall in the last + +
I would like to thank John Distler for his valuable input regarding TCP + SYN and ICMP treatment in Shorewall. That input +has led to marked improvement in Shorewall in the last two releases.
- +8/13/2002 - Documentation in the CVS Repository
- -The Shorewall-docs project now contains just the HTML and image files -- the Frontpage files have been removed.
+ +The Shorewall-docs project now contains just the HTML and image files - +the Frontpage files have been removed.
- +8/7/2002 - STABLE branch added to CVS Repository
- -This branch will only be updated after I release a new version of Shorewall - so you can always update from this branch to get + +
This branch will only be updated after I release a new version of Shorewall + so you can always update from this branch to get the latest stable tree.
- -8/7/2002 - Upgrade Issues section -added to the Errata Page
+ +8/7/2002 - Upgrade Issues section added + to the Errata Page
- -Now there is one place to go to look for issues involved with upgrading + +
Now there is one place to go to look for issues involved with upgrading to recent versions of Shorewall.
- +8/7/2002 - Shorewall 1.3.6
- +This is primarily a bug-fix rollup with a couple of new features:
- +7/30/2002 - Shorewall 1.3.5b Released
- +This interim release:
- +7/29/2002 - New Shorewall Setup Guide Available
- +The first draft of this guide is available at http://www.shorewall.net/shorewall_setup_guide.htm. - The guide is intended for use by people who are -setting up Shorewall to manage multiple public IP addresses - and by people who want to learn more about Shorewall than - is described in the single-address guides. Feedback on -the new guide is welcome.
+ href="http://www.shorewall.net/shorewall_setup_guide.htm"> http://www.shorewall.net/shorewall_setup_guide.htm. + The guide is intended for use by people who are +setting up Shorewall to manage multiple public IP addresses + and by people who want to learn more about Shorewall than + is described in the single-address guides. Feedback on the + new guide is welcome. - +7/28/2002 - Shorewall 1.3.5 Debian Package Available
- -Lorenzo Martignoni reports that the packages are version 1.3.5a and are + +
Lorenzo Martignoni reports that the packages are version 1.3.5a and are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
- +7/27/2002 - Shorewall 1.3.5a Released
- +This interim release restores correct handling of REDIRECT rules.
- +7/26/2002 - Shorewall 1.3.5 Released
- -This will be the last Shorewall release for a while. I'm going to be -focusing on rewriting a lot of the documentation.
+ +This will be the last Shorewall release for a while. I'm going to be + focusing on rewriting a lot of the documentation.
- +In this version:
- +7/16/2002 - New Mirror in Argentina
- -Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in + +
Thanks to Arturo "Buanzo" Busleiman, there is now a Shorewall mirror in Argentina. Thanks Buanzo!!!
- +7/16/2002 - Shorewall 1.3.4 Released
- +In this version:
- +7/8/2002 - Shorewall 1.3.3 Debian Package Available
- +Lorenzo Marignoni reports that the packages are available at http://security.dsi.unimi.it/~lorenzo/debian.html.
- +7/6/2002 - Shorewall 1.3.3 Released
- +In this version:
- +6/25/2002 - Samples Updated for 1.3.2
- -The comments in the sample configuration files have been updated to reflect + +
The comments in the sample configuration files have been updated to reflect new features introduced in Shorewall 1.3.2.
- +6/25/2002 - Shorewall 1.3.1 Debian Package Available
- +Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.
- +6/19/2002 - Documentation Available in PDF Format
- -Thanks to Mike Martinez, the Shorewall Documentation is now available -for download in Adobe PDF format.
+ +Thanks to Mike Martinez, the Shorewall Documentation is now available for + download in Adobe + PDF format.
- +6/16/2002 - Shorewall 1.3.2 Released
- +In this version:
- +6/6/2002 - Why CVS Web access is Password Protected
- -Last weekend, I installed the CVS Web package to provide brower-based -access to the Shorewall CVS repository. Since then, I have had several -instances where my server was almost unusable due to the high load generated -by website copying tools like HTTrack and WebStripper. These mindless tools:
+ +Last weekend, I installed the CVS Web package to provide brower-based access + to the Shorewall CVS repository. Since then, I have had several instances +where my server was almost unusable due to the high load generated by website +copying tools like HTTrack and WebStripper. These mindless tools:
- +These tools/weapons are particularly damaging when combined with CVS Web - because they doggedly follow every link in the -cgi-generated HTML resulting in 1000s of executions -of the cvsweb.cgi script. Yesterday, I spend several -hours implementing measures to block these tools but unfortunately, - these measures resulted in my server OOM-ing under even - moderate load.
+ +These tools/weapons are particularly damaging when combined with CVS Web + because they doggedly follow every link in the cgi-generated + HTML resulting in 1000s of executions of the cvsweb.cgi + script. Yesterday, I spend several hours implementing + measures to block these tools but unfortunately, these measures + resulted in my server OOM-ing under even moderate load.
- -Until I have the time to understand the cause of the OOM (or until I buy - more RAM if that is what is required), CVS Web -access will remain Password Protected.
+ +Until I have the time to understand the cause of the OOM (or until I buy + more RAM if that is what is required), CVS Web access + will remain Password Protected.
- +6/5/2002 - Shorewall 1.3.1 Debian Package Available
- +Lorenzo Marignoni reports that the package is available at http://security.dsi.unimi.it/~lorenzo/debian.html.
- +6/2/2002 - Samples Corrected
- -The 1.3.0 samples configurations had several serious problems that prevented - DNS and SSH from working properly. These problems + +
The 1.3.0 samples configurations had several serious problems that prevented + DNS and SSH from working properly. These problems have been corrected in the 1.3.1 samples.
- +6/1/2002 - Shorewall 1.3.1 Released
- +Hot on the heels of 1.3.0, this release:
- +5/29/2002 - Shorewall 1.3.0 Released
- -In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 - includes:
+ +In addition to the changes in Beta 1, Beta 2 and RC1, Shorewall 1.3.0 + includes:
- +5/23/2002 - Shorewall 1.3 RC1 Available
- -In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) - incorporates the following:
+ +In addition to the changes in Beta 1 and Beta 2, RC1 (Version 1.2.92) + incorporates the following:
- +5/19/2002 - Shorewall 1.3 Beta 2 Available
- -In addition to the changes in Beta 1, this release which carries the -designation 1.2.91 adds:
+ +In addition to the changes in Beta 1, this release which carries the + designation 1.2.91 adds:
- +5/17/2002 - Shorewall 1.3 Beta 1 Available
- -Beta 1 carries the version designation 1.2.90 and implements the following + +
Beta 1 carries the version designation 1.2.90 and implements the following features:
- +5/4/2002 - Shorewall 1.2.13 is Available
- +In this version:
- +4/30/2002 - Shorewall Debian News
- -Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the -Debian - Testing Branch and the Debian - Unstable Branch.
+ +Lorenzo Marignoni reports that Shorewall 1.2.12 is now in both the Debian +Testing Branch and the Debian +Unstable Branch.
- +4/20/2002 - Shorewall 1.2.12 is Available
- +4/17/2002 - Shorewall Debian News
- +Lorenzo Marignoni reports that:
- +Thanks, Lorenzo!
- +4/16/2002 - Shorewall 1.2.11 RPM Available for SuSE
- -Thanks to Stefan Mohr, there + +
Thanks to Stefan Mohr, there is now a Shorewall 1.2.11 - SuSE RPM available.
+ href="http://www.shorewall.net/pub/shorewall/shorewall-1.2-11.i686.suse73.rpm"> + SuSE RPM available. - +4/13/2002 - Shorewall 1.2.11 Available
- +In this version:
- +4/13/2002 - Hamburg Mirror now has FTP
- +Stefan now has an FTP mirror at ftp://germany.shorewall.net/pub/shorewall. + href="ftp://germany.shorewall.net/pub/shorewall"> ftp://germany.shorewall.net/pub/shorewall. Thanks Stefan!
- +4/12/2002 - New Mirror in Hamburg
- -Thanks to Stefan Mohr, there + +
Thanks to Stefan Mohr, there is now a mirror of the Shorewall website at http://germany.shorewall.net. + target="_top" href="http://germany.shorewall.net"> http://germany.shorewall.net.
- +4/10/2002 - Shorewall QuickStart Guide Version 1.1 Available
- -Version 1.1 of the QuickStart - Guide is now available. Thanks to those who -have read version 1.0 and offered their suggestions. + +
Version 1.1 of the QuickStart + Guide is now available. Thanks to those who +have read version 1.0 and offered their suggestions. Corrections have also been made to the sample scripts.
- +4/9/2002 - Shorewall QuickStart Guide Version 1.0 Available
- -Version 1.0 of the QuickStart - Guide is now available. This Guide and its -accompanying sample configurations are expected to -provide a replacement for the recently withdrawn parameterized - samples.
+ +Version 1.0 of the QuickStart + Guide is now available. This Guide and its accompanying + sample configurations are expected to provide a replacement + for the recently withdrawn parameterized samples. +
- +4/8/2002 - Parameterized Samples Withdrawn
- +Although the parameterized - samples have allowed people to get a firewall - up and running quickly, they have unfortunately set -the wrong level of expectation among those who have used - them. I am therefore withdrawing support for the samples - and I am recommending that they not be used in new Shorewall -installations.
+ href="http://www.shorewall.net/pub/shorewall/samples-1.2.1/">parameterized + samples have allowed people to get a firewall + up and running quickly, they have unfortunately set +the wrong level of expectation among those who have used + them. I am therefore withdrawing support for the samples + and I am recommending that they not be used in new Shorewall installations. - +4/2/2002 - Updated Log Parser
- -John Lodge has provided an updated + +
John Lodge has provided an updated version of his CGI-based log parser - with corrected date handling.
+ href="pub/shorewall/parsefw/">CGI-based log parser + with corrected date handling. - +3/30/2002 - Shorewall Website Search Improvements
- -The quick search on the home page now excludes the mailing list archives. - The Extended Search - allows excluding the archives or restricting the search - to just the archives. An archive search form is also -available on the mailing list information - page.
+ +The quick search on the home page now excludes the mailing list archives. + The Extended Search + allows excluding the archives or restricting the search + to just the archives. An archive search form is also available + on the mailing + list information page.
- +3/28/2002 - Debian Shorewall News (From Lorenzo Martignoni)
- +3/25/2002 - Log Parser Available
- +John Lodge has provided a CGI-based log parser for Shorewall. Thanks + href="pub/shorewall/parsefw/">CGI-based log parser for Shorewall. Thanks John.
- +3/20/2002 - Shorewall 1.2.10 Released
- +In this version:
- +3/11/2002 - Shorewall 1.2.9 Released
- +In this version:
- +3/1/2002 - 1.2.8 Debian Package is Available
- - -See http://security.dsi.unimi.it/~lorenzo/debian.html
- - -2/25/2002 - New Two-interface Sample
- - -I've enhanced the two interface sample to allow access from the firewall - to servers in the local zone - - http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz
- -2/23/2002 - Shorewall 1.2.8 Released
- - -Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects - problems associated with the lock file used to prevent multiple state-changing - operations from occuring simultaneously. My apologies - for any inconvenience my carelessness may have caused.
- - -2/22/2002 - Shorewall 1.2.7 Released
- - -In this version:
- - -2/18/2002 - 1.2.6 Debian Package is Available
- - -See http://security.dsi.unimi.it/~lorenzo/debian.html
- - -2/8/2002 - Shorewall 1.2.6 Released
- - -In this version:
- - -2/4/2002 - Shorewall 1.2.5 Debian Package Available
- - -see http://security.dsi.unimi.it/~lorenzo/debian.html
- - -2/1/2002 - Shorewall 1.2.5 Released
- - -Due to installation problems with Shorewall 1.2.4, I have released Shorewall - 1.2.5. Sorry for the rapid-fire development.
- - -In version 1.2.5:
- - -1/28/2002 - Shorewall 1.2.4 Released
- - -1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html
- - -1/20/2002 - Corrected firewall script available
- - -Corrects a problem with BLACKLIST_LOGLEVEL. See the - errata for details.
- - -1/19/2002 - Shorewall 1.2.3 Released
- - -This is a minor feature and bugfix release. The single new feature is:
- - -The following problems were corrected:
- - -1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release
- - -Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution - that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo - for details.
- - -1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2 - Shorewall Debian package is now available. There -is a link to Lorenzo's site from the Shorewall download page.
- - -1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores - the "shorewall status" command to health.
- - -1/8/2002 - Shorewall 1.2.2 Released
- - -In version 1.2.2
- - -1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates - to the previously-released samples. There are two -new rules added:
- - -See the README file for upgrade instructions.
- - -1/1/2002 - Shorewall Mailing List Moving
- - -The Shorewall mailing list hosted at - Sourceforge is moving to Shorewall.net. If you - are a current subscriber to the list at Sourceforge, -please see these instructions. - If you would like to subscribe to the new list, visit - http://www.shorewall.net/mailman/listinfo/shorewall-users.
- - -12/31/2001 - Shorewall 1.2.1 Released
- - -In version 1.2.1:
- - -12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist -releasing 1.2 on 12/21/2001
- - -Version 1.2 contains the following new features:
- - -For the next month or so, I will continue to provide corrections to version - 1.1.18 as necessary so that current version 1.1.x - users will not be forced into a quick upgrade to 1.2.0 -just to have access to bug fixes.
- - -For those of you who have installed one of the Beta RPMS, you will need - to use the "--oldpackage" option when upgrading -to 1.2.0:
- - -- - -- - -rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
-
12/19/2001 - Thanks to Steve - Cowles, there is now a Shorewall mirror in Texas. - This web site is mirrored at http://www.infohiiway.com/shorewall - and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall.
- - -11/30/2001 - A new set of the parameterized Sample - Configurations has been released. In this version:
- - -11/20/2001 - The current version of Shorewall is 1.1.18.
- - -In this version:
- - -11/19/2001 - Thanks to Juraj - Ontkanin, there is now a Shorewall mirror - in the Slovak Republic. The website is now mirrored - at http://www.nrg.sk/mirror/shorewall - and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.
- - -11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. - There are three sample configurations:
- - -3/1/2002 - 1.2.8 Debian Package is Available
+ + +See http://security.dsi.unimi.it/~lorenzo/debian.html
+ + +2/25/2002 - New Two-interface Sample
+ + +I've enhanced the two interface sample to allow access from the firewall + to servers in the local zone - + http://www.shorewall.net/pub/shorewall/LATEST.samples/two-interfaces.tgz
+ + +2/23/2002 - Shorewall 1.2.8 Released
+ + +Do to a serious problem with 1.2.7, I am releasing 1.2.8. It corrects + problems associated with the lock file used to prevent multiple state-changing + operations from occuring simultaneously. My apologies + for any inconvenience my carelessness may have caused.
+ + +2/22/2002 - Shorewall 1.2.7 Released
+ + +In this version:
+ + +2/18/2002 - 1.2.6 Debian Package is Available
+ + +See http://security.dsi.unimi.it/~lorenzo/debian.html
+ + +2/8/2002 - Shorewall 1.2.6 Released
+ + +In this version:
+ + +2/4/2002 - Shorewall 1.2.5 Debian Package Available
+ + +see http://security.dsi.unimi.it/~lorenzo/debian.html
+ + +2/1/2002 - Shorewall 1.2.5 Released
+ + +Due to installation problems with Shorewall 1.2.4, I have released Shorewall + 1.2.5. Sorry for the rapid-fire development.
+ + +In version 1.2.5:
+ + +1/28/2002 - Shorewall 1.2.4 Released
+ + +1/27/2002 - Shorewall 1.2.3 Debian Package Available -- see http://security.dsi.unimi.it/~lorenzo/debian.html
+ + +1/20/2002 - Corrected firewall script available
+ + +Corrects a problem with BLACKLIST_LOGLEVEL. See the + errata for details.
+ + +1/19/2002 - Shorewall 1.2.3 Released
+ + +This is a minor feature and bugfix release. The single new feature is:
+ + +The following problems were corrected:
+ + +1/18/2002 - Shorewall 1.2.2 packaged with new LEAF release
+ + +Jacques Nilo and Eric Wolzak have released a kernel 2.4.16 LEAF distribution + that includes Shorewall 1.2.2. See http://leaf.sourceforge.net/devel/jnilo + for details.
+ + +1/11/2002 - Debian Package (.deb) Now Available - Thanks to Lorenzo Martignoni, a 1.2.2 + Shorewall Debian package is now available. There is + a link to Lorenzo's site from the Shorewall download page.
+ + +1/9/2002 - Updated 1.2.2 /sbin/shorewall available - This corrected version restores + the "shorewall status" command to health.
+ + +1/8/2002 - Shorewall 1.2.2 Released
+ + +In version 1.2.2
+ + +1/5/2002 - New Parameterized Samples (version 1.2.0) released. These are minor updates + to the previously-released samples. There are two +new rules added:
+ + +See the README file for upgrade instructions.
+ + +1/1/2002 - Shorewall Mailing List Moving
+ + +The Shorewall mailing list hosted at + Sourceforge is moving to Shorewall.net. If you + are a current subscriber to the list at Sourceforge, please + see these instructions. + If you would like to subscribe to the new list, visit + http://www.shorewall.net/mailman/listinfo/shorewall-users.
+ + +12/31/2001 - Shorewall 1.2.1 Released
+ + +In version 1.2.1:
+ + +12/21/2001 - Shorewall 1.2.0 Released! - I couldn't resist releasing +1.2 on 12/21/2001
+ + +Version 1.2 contains the following new features:
+ + +For the next month or so, I will continue to provide corrections to version + 1.1.18 as necessary so that current version 1.1.x + users will not be forced into a quick upgrade to 1.2.0 + just to have access to bug fixes.
+ + +For those of you who have installed one of the Beta RPMS, you will need + to use the "--oldpackage" option when upgrading to + 1.2.0:
+ + ++ + ++ + +rpm -Uvh --oldpackage shorewall-1.2-0.noarch.rpm
+
12/19/2001 - Thanks to Steve + Cowles, there is now a Shorewall mirror in Texas. + This web site is mirrored at http://www.infohiiway.com/shorewall + and the ftp site is at ftp://ftp.infohiiway.com/pub/mirrors/shorewall.
+ + +11/30/2001 - A new set of the parameterized Sample +Configurations has been released. In this version:
+ + +11/20/2001 - The current version of Shorewall is 1.1.18.
+ + +In this version:
+ + +11/19/2001 - Thanks to Juraj + Ontkanin, there is now a Shorewall mirror + in the Slovak Republic. The website is now mirrored + at http://www.nrg.sk/mirror/shorewall + and the FTP site is mirrored at ftp://ftp.nrg.sk/mirror/shorewall.
+ + +11/2/2001 - Announcing Shorewall Parameter-driven Sample Configurations. + There are three sample configurations:
+ + +Samples may be downloaded from ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 - . See the README file for instructions.
+ href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17"> ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.17 + . See the README file for instructions. - -11/1/2001 - The current version of Shorewall is 1.1.17. I intend - this to be the last of the 1.1 Shorewall releases.
+ +11/1/2001 - The current version of Shorewall is 1.1.17. I intend + this to be the last of the 1.1 Shorewall +releases.
- +In this version:
- +10/22/2001 - The current version of Shorewall is 1.1.16. In this - version:
+ +10/22/2001 - The current version of Shorewall is 1.1.16. In this + version:
- +10/15/2001 - The current version of Shorewall is 1.1.15. In this - version:
+ +10/15/2001 - The current version of Shorewall is 1.1.15. In this + version:
+ + +10/4/2001 - The current version of Shorewall is 1.1.14. In this + version
10/4/2001 - The current version of Shorewall is 1.1.14. In this - version
- - -9/12/2001 - The current version of Shorewall is 1.1.13. In this + +
9/12/2001 - The current version of Shorewall is 1.1.13. In this version
- +8/28/2001 - The current version of Shorewall is 1.1.12. In this + +
8/28/2001 - The current version of Shorewall is 1.1.12. In this version
- +7/28/2001 - The current version of Shorewall is 1.1.11. In this + +
7/28/2001 - The current version of Shorewall is 1.1.11. In this version
- +7/6/2001 - The current version of Shorewall is 1.1.10. In this -version
+ +7/6/2001 - The current version of Shorewall is 1.1.10. In this version
- +6/23/2001 - The current version of Shorewall is 1.1.9. In this -version
+ +6/23/2001 - The current version of Shorewall is 1.1.9. In this version
- +6/18/2001 - The current version of Shorewall is 1.1.8. In this -version
+ +6/18/2001 - The current version of Shorewall is 1.1.8. In this version
- +6/2/2001 - The current version of Shorewall is 1.1.7. In this version
- +5/25/2001 - The current version of Shorewall is 1.1.6. In this -version
+ +5/25/2001 - The current version of Shorewall is 1.1.6. In this version
- +5/20/2001 - The current version of Shorewall is 1.1.5. In this -version
+ +5/20/2001 - The current version of Shorewall is 1.1.5. In this version
- +5/10/2001 - The current version of Shorewall is 1.1.4. In this -version
+ +5/10/2001 - The current version of Shorewall is 1.1.4. In this version
- +4/28/2001 - The current version of Shorewall is 1.1.3. In this -version
+ +4/28/2001 - The current version of Shorewall is 1.1.3. In this version
- +4/12/2001 - The current version of Shorewall is 1.1.2. In this -version
+ +4/12/2001 - The current version of Shorewall is 1.1.2. In this version
- +4/8/2001 - Shorewall is now affiliated with the Leaf Project -
+ - +4/5/2001 - The current version of Shorewall is 1.1.1. In this version:
- +3/25/2001 - The current version of Shorewall is 1.1.0. In this version:
- +3/19/2001 - The current version of Shorewall is 1.0.4. This version:
- +3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix - release with no new features.
+ - + +3/13/2001 - The current version of Shorewall is 1.0.3. This is a bug-fix + release with no new features.
+ +3/8/2001 - The current version of Shorewall is 1.0.2. It supports 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.
+ +3/8/2001 - The current version of Shorewall is 1.0.2. It supports 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 2/13/2003 - Tom Eastep
+
+ Updated 2/13/2003 - Tom Eastep
+ |
-
+
Configuration Files- |
-
Warning: If you copy or edit your - configuration files on a system running Microsoft Windows, you must + +
Warning: If you copy or edit your + configuration files on a system running Microsoft Windows, you must run them through dos2unix + href="http://www.megaloman.com/%7Ehany/software/hd2u/"> dos2unix before you use them with Shorewall.
- +Shorewall's configuration files are in the directory /etc/shorewall.
- +You may place comments in configuration files by making the first non-whitespace - character a pound sign ("#"). You may also place comments at - the end of any line, again by delimiting the comment from the rest - of the line with a pound sign.
- + +You may place comments in configuration files by making the first non-whitespace + character a pound sign ("#"). You may also place comments +at the end of any line, again by delimiting the comment from +the rest of the line with a pound sign.
+Examples:
- +# This is a comment- +
ACCEPT net fw tcp www #This is an end-of-line comment- +
You may continue lines in the configuration files using the usual backslash + +
You may continue lines in the configuration files using the usual backslash ("\") followed immediately by a new line character.
- +Example:
- +ACCEPT net fw tcp \- +
smtp,www,pop3,imap #Services running on the firewall
- -
WARNING: I personally recommend strongly against
- using DNS names in Shorewall configuration files. If you use DNS names
- and you are called out of bed at 2:00AM because Shorewall won't start
- as a result of DNS problems then don't say that you were not forewarned.
-
-
-Tom
-
Beginning with Shorwall 1.3.9, Host addresses in Shorewall
- configuration files may be specified as either IP addresses or DNS
- Names.
-
- DNS names in iptables rules aren't nearly as useful as they
- first appear. When a DNS name appears in a rule, the iptables utility
- resolves the name to one or more IP addresses and inserts those
-addresses into the rule. So changes in the DNS->IP address relationship
- that occur after the firewall has started have absolutely no effect
-on the firewall's ruleset.
If your firewall rules include DNS names then:
++ +
WARNING: I personally recommend strongly against
+ using DNS names in Shorewall configuration files. If you use DNS
+names and you are called out of bed at 2:00AM because Shorewall won't
+start as a result of DNS problems then don't say that you were not forewarned.
+
+
-Tom
+
Beginning with Shorwall 1.3.9, Host addresses in Shorewall
+ configuration files may be specified as either IP addresses or DNS
+ Names.
+
+ DNS names in iptables rules aren't nearly as useful as
+they first appear. When a DNS name appears in a rule, the iptables
+utility resolves the name to one or more IP addresses and inserts
+ those addresses into the rule. So changes in the DNS->IP address
+relationship that occur after the firewall has started have absolutely
+no effect on the firewall's ruleset.
If your firewall rules include DNS names then:
+Each DNS name much be fully qualified and include a minumum - of two periods (although one may be trailing). This restriction is - imposed by Shorewall to insure backward compatibility with existing + + +
Each DNS name much be fully qualified and include a minumum
+ of two periods (although one may be trailing). This restriction is
+ imposed by Shorewall to insure backward compatibility with existing
configuration files.
-
- Examples of valid DNS names:
-
Where specifying an IP address, a subnet or an interface, you can - precede the item with "!" to specify the complement of the item. For - example, !192.168.1.4 means "any host but 192.168.1.4". There must -be no white space following the "!".
- + +Where specifying an IP address, a subnet or an interface, you can + precede the item with "!" to specify the complement of the item. For + example, !192.168.1.4 means "any host but 192.168.1.4". There must be +no white space following the "!".
+Comma-separated lists are allowed in a number of contexts within the - configuration files. A comma separated list:
- + +Comma-separated lists are allowed in a number of contexts within the + configuration files. A comma separated list:
+Unless otherwise specified, when giving a port number you can use - either an integer or a service name from /etc/services.
- + +Unless otherwise specified, when giving a port number you can use + either an integer or a service name from /etc/services.
+If you need to specify a range of ports, the proper syntax is <low - port number>:<high port number>. For example, - if you want to forward the range of tcp ports 4000 through 4100 to + +
If you need to specify a range of ports, the proper syntax is <low
+ port number>:<high port number>. For example,
+ if you want to forward the range of tcp ports 4000 through 4100 to
local host 192.168.1.3, the entry in /etc/shorewall/rules is:
-
DNAT net loc:192.168.1.3 tcp 4000:4100- If you omit the low port number, a value of zero is assumed; if you omit -the high port number, a value of 65535 is assumed.
You may use the /etc/shorewall/params file to set shell variables - that you can then use in some of the other configuration files.
- + +You may use the /etc/shorewall/params file to set shell variables + 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 + size="1"> to distinguish them from variables used internally within the Shorewall programs
- +Example:
- -- + +++- +NET_IF=eth0-
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918
- Example (/etc/shorewall/interfaces record):
- +- + + ++-net $NET_IF $NET_BCAST $NET_OPTIONS-
The result will be the same as if the record had been written
- + -- ++ + - -+-net eth0 130.252.100.255 routefilter,norfc1918-
Variables may be used anywhere in the other configuration + +
Variables may be used anywhere in the other configuration files.
- +Media Access Control (MAC) addresses can be used to specify packet - source in several of the configuration files. To use this -feature, your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) + +
Media Access Control (MAC) addresses can be used to specify packet + source in several of the configuration files. To use this feature, + your kernel must have MAC Address Match support (CONFIG_IP_NF_MATCH_MAC) included.
- -MAC addresses are 48 bits wide and each Ethernet Controller has a
- unique MAC address.
-
- In GNU/Linux, MAC addresses are usually written as
-a series of 6 hex numbers separated by colons. Example:
-
- [root@gateway root]# ifconfig eth0
- eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
- inet addr:206.124.146.176 Bcast:206.124.146.255
- Mask:255.255.255.0
- UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
- RX packets:2398102 errors:0 dropped:0 overruns:0
- frame:0
- TX packets:3044698 errors:0 dropped:0 overruns:0
- carrier:0
- collisions:30394 txqueuelen:100
- RX bytes:419871805 (400.4 Mb) TX bytes:1659782221
- (1582.8 Mb)
- Interrupt:11 Base address:0x1800
-
- Because Shorewall uses colons as a separator for address
- fields, Shorewall requires MAC addresses to be written in another
- way. In Shorewall, MAC addresses begin with a tilde ("~") and
-consist of 6 hex numbers separated by hyphens. In Shorewall, the
-MAC address in the example above would be written "~02-00-08-E3-FA-55".
-
Note: It is not necessary to use the special Shorewall notation + +
MAC addresses are 48 bits wide and each Ethernet Controller has a
+ unique MAC address.
+
+ In GNU/Linux, MAC addresses are usually written as
+ a series of 6 hex numbers separated by colons. Example:
+
+ [root@gateway root]# ifconfig eth0
+ eth0 Link encap:Ethernet HWaddr 02:00:08:E3:FA:55
+ inet addr:206.124.146.176 Bcast:206.124.146.255
+ Mask:255.255.255.0
+ UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
+ RX packets:2398102 errors:0 dropped:0 overruns:0
+ frame:0
+ TX packets:3044698 errors:0 dropped:0 overruns:0
+ carrier:0
+ collisions:30394 txqueuelen:100
+ RX bytes:419871805 (400.4 Mb) TX bytes:1659782221
+ (1582.8 Mb)
+ Interrupt:11 Base address:0x1800
+
+ Because Shorewall uses colons as a separator for
+address fields, Shorewall requires MAC addresses to be written
+in another way. In Shorewall, MAC addresses begin with a tilde
+("~") and consist of 6 hex numbers separated by hyphens. In Shorewall,
+the MAC address in the example above would be written "~02-00-08-E3-FA-55".
+
Note: It is not necessary to use the special Shorewall notation
in the /etc/shorewall/maclist file.
-
Shorewall allows you to have configuration directories other than /etc/shorewall. - The shorewall start -and restart commands allow you to specify an alternate configuration - directory and Shorewall will use the files in the alternate directory - rather than the corresponding files in /etc/shorewall. The alternate -directory need not contain a complete configuration; those files not -in the alternate directory will be read from /etc/shorewall.
- -This facility permits you to easily create a test or temporary configuration + +
Shorewall allows you to have configuration directories other than /etc/shorewall. + The shorewall start +and restart commands allow you to specify an alternate configuration + directory and Shorewall will use the files in the alternate directory + rather than the corresponding files in /etc/shorewall. The alternate +directory need not contain a complete configuration; those files not in +the alternate directory will be read from /etc/shorewall.
+ +This facility permits you to easily create a test or temporary configuration by:
- +Updated 2/7/2003 - Tom Eastep -
+ +Updated 2/24/2003 - Tom Eastep +
- - ++ | ||||
-
+
-+ - - - + +- |
- - + | +
+
Shorewall Mailing Lists- |
- + |
- - + + - - + + + - - Powered by Postfix - |
-
If you experience problems with any of these lists, please + + + + +
If you experience problems with any of these lists, please let me know
- +You can report such problems by sending mail to tom dot eastep - at hp dot com.
- + +You can report such problems by sending mail to tom dot eastep + at hp dot com.
+Before subscribing please read my policy
- about list traffic that bounces. Also please note that the mail server
- at shorewall.net checks incoming mail:
-
Before subscribing please read my policy
+ about list traffic that bounces. Also please note that the mail server
+ at shorewall.net checks incoming mail:
+
Note: The list server limits posts to 120kb.
-
The Shorewall Users Mailing list provides a way for users - to get answers to questions and to report problems. Information -of general interest to the Shorewall user community is also posted -to this list.
- -Before posting a problem report to this list, please see - the problem reporting - guidelines.
- -To subscribe to the mailing list:
-
To post to the list, post to shorewall-users@lists.shorewall.net.
- -The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.
- -Note that prior to 1/1/2002, the mailing list was hosted at -Sourceforge. The archives from that list -may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.
- -This list is for announcements of general interest to the
- Shorewall community. To subscribe:
-
- The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.
The Shorewall Development Mailing list provides a forum for - the exchange of ideas about the future of Shorewall and for coordinating - ongoing Shorewall Development.
- + +The Shorewall Users Mailing list provides a way for users + to get answers to questions and to report problems. Information + of general interest to the Shorewall user community is also posted + to this list.
+ +Before posting a problem report to this list, please see + the problem reporting + guidelines.
+To subscribe to the mailing list:
To post to the list, post to shorewall-users@lists.shorewall.net.
+ +The list archives are at http://lists.shorewall.net/pipermail/shorewall-users.
+ +Note that prior to 1/1/2002, the mailing list was hosted +at Sourceforge. The archives from that +list may be found at www.geocrawler.com/lists/3/Sourceforge/9327/0/.
+ +This list is for announcements of general interest to the
+ Shorewall community. To subscribe:
+
+ The list archives are at http://lists.shorewall.net/pipermail/shorewall-announce.
The Shorewall Development Mailing list provides a forum for + the exchange of ideas about the future of Shorewall and for coordinating + ongoing Shorewall Development.
+ +To subscribe to the mailing list:
+
To post to the list, post to shorewall-devel@lists.shorewall.net.
- +The list archives are at http://lists.shorewall.net/pipermail/shorewall-devel.
- -There seems to be near-universal confusion about unsubscribing - from Mailman-managed lists although Mailman 2.1 has attempted to - make this less confusing. To unsubscribe:
- + +There seems to be near-universal confusion about unsubscribing + from Mailman-managed lists although Mailman 2.1 has attempted +to make this less confusing. To unsubscribe:
+Follow the same link above that you used to subscribe - to the list.
-Down at the bottom of that page is the following text: - " To unsubscribe from <list name>, get a password - reminder, or change your subscription options enter your subscription - email address:". Enter your email address in the box and -click on the "Unsubscribe or edit options" button.
-There will now be a box where you can enter your password - and click on "Unsubscribe"; if you have forgotten your password, - there is another button that will cause your password to be emailed - to you.
-Follow the same link above that you used to subscribe + to the list.
+Down at the bottom of that page is the following text: + " To unsubscribe from <list name>, get a +password reminder, or change your subscription options enter +your subscription email address:". Enter your email address + in the box and click on the "Unsubscribe or edit options" button.
+There will now be a box where you can enter your password + and click on "Unsubscribe"; if you have forgotten your password, + there is another button that will cause your password to be emailed + to you.
+Last updated 2/18/2003 - Last updated 2/24/2003 - Tom Eastep
- - Copyright
-© 2001, 2002, 2003 Thomas M. Eastep.
-
Copyright ©
+2001, 2002, 2003 Thomas M. Eastep.
+
+ |
@@ -42,15 +42,15 @@
-
+
- Shorewall - 1.4 - "iptables made - easy"+ Shorewall 1.4 - "iptables + made easy" @@ -60,43 +60,44 @@ - + + + -+ - |
+
-
+ |
@@ -106,7 +107,7 @@
-
+
What is it?@@ -119,7 +120,7 @@ - +The Shoreline Firewall, more commonly known as "Shorewall", is a Netfilter (iptables) based firewall that can be used on a dedicated firewall system, a multi-function @@ -135,27 +136,27 @@ - + 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. Copyright 2001, 2002, 2003 Thomas M. Eastep @@ -182,21 +183,21 @@ Ave, Cambridge, MA 02139, USA - +
- Jacques Nilo and
- Eric Wolzak have a LEAF (router/firewall/gateway
+ Jacques Nilo and
+ Eric Wolzak have a LEAF (router/firewall/gateway
on a floppy, CD or compact flash) distribution called
- Bering that features Shorewall-1.3.14
- and Kernel-2.4.20. You can find their work at:
- http://leaf.sourceforge.net/devel/jnilo + + Congratulations to Jacques and Eric on the recent release of Bering
1.1!!! This is a mirror of the main Shorewall web site at SourceForge (http://shorewall.sf.net)@@ -222,7 +223,7 @@ Ave, Cambridge, MA 02139, USA - +News@@ -235,7 +236,7 @@ Ave, Cambridge, MA 02139, USA - + @@ -245,108 +246,114 @@ Ave, Cambridge, MA 02139, USA - +3/14/2003 - Shorewall 1.4.0 - + + - Shorewall 1.4 represents the next step in the evolution of Shorewall. -The main thrust of the initial release is simply to remove the cruft that -has accumulated in Shorewall over time.- IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package -('ip' utility). - -Function from 1.3 that has been omitted from this version include: - + Shorewall 1.4 represents the next step in the evolution of Shorewall. + The main thrust of the initial release is simply to remove the cruft that + has accumulated in Shorewall over time. + IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute +package ('ip' utility). + + Function from 1.3 that has been omitted from this version include: +
- + Changes for 1.4 include: +
- + @@ -367,43 +374,43 @@ now support the 'maclist' option. - + Donations- |
+
- M | -
@@ -413,12 +420,12 @@ now support the 'maclist' option. - + + @@ -429,33 +436,35 @@ now support the 'maclist' option. - + Shorewall is free but if you try it and find it useful, please consider making a donation - to Starlight Children's Foundation. Thanks! - |
+
-
Updated 2/18/2003 - Tom Eastep
-
-
- + |
+
Tom Eastep- |
-
-
- + +Tarry & Tom -- August 2002
-
-
I am currently a member of the design team for the next-generation - operating system from the NonStop Enterprise Division of HP.
- -I became interested in Internet Security when I established a home office - in 1999 and had DSL service installed in our home. I investigated - ipchains and developed the scripts which are now collectively known -as Seattle Firewall. -Expanding on what I learned from Seattle Firewall, I then designed -and wrote Shorewall.
- -I telework from our home in Shoreline, - Washington where I live with my wife Tarry.
- -Our current home network consists of:
+I am currently a member of the design team for the next-generation + operating system from the NonStop Enterprise Division of HP.
+ +I became interested in Internet Security when I established a home office + in 1999 and had DSL service installed in our home. I investigated + ipchains and developed the scripts which are now collectively known as + Seattle Firewall. Expanding + on what I learned from Seattle Firewall, I then designed and +wrote Shorewall.
+ +I telework from our home in Shoreline, + Washington where I live with my wife Tarry.
+ +Our current home network consists of:
+All of our other systems are made by Compaq (part of the new HP).. All of our Tulip NICs are Netgear FA310TXs.
- + - - + +Last updated 2/23/2003 - Tom Eastep
- Copyright © 2001, 2002, 2003 Thomas + Copyright © 2001, 2002, 2003 Thomas M. Eastep.+ |
@@ -43,14 +43,14 @@
-
+
- Shorewall 1.4 - "iptables + Shorewall 1.4 - "iptables made easy"@@ -63,35 +63,35 @@ - + - |
-
+ |
@@ -102,7 +102,7 @@
-
+
What is it?@@ -115,12 +115,13 @@ - -The Shoreline Firewall, more commonly known as "Shorewall", is - a Netfilter (iptables) - based firewall that can be used on a dedicated firewall system, - a multi-function gateway/router/server or on a standalone GNU/Linux - system. + + +The Shoreline Firewall, more commonly known as "Shorewall", is + a Netfilter (iptables) + based firewall that can be used on a dedicated firewall system, + a multi-function gateway/router/server or on a standalone +GNU/Linux system. @@ -132,29 +133,30 @@ - -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. 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. Copyright 2001, 2002, 2003 Thomas M. Eastep @@ -180,25 +181,25 @@ Mass Ave, Cambridge, MA 02139, USA - +- Jacques Nilo - and Eric Wolzak have a LEAF (router/firewall/gateway - on a floppy, CD or compact flash) distribution - called Bering that features - Shorewall-1.3.14 and Kernel-2.4.20. You can find - their work at: Jacques Nilo + and Eric Wolzak have a LEAF (router/firewall/gateway + on a floppy, CD or compact flash) distribution + called Bering that features + Shorewall-1.3.14 and Kernel-2.4.20. You can find + their work at: http://leaf.sourceforge.net/devel/jnilo - - + + - Congratulations to Jacques and Eric -on the recent release of Bering 1.1!!!- + Congratulations to Jacques and Eric + on the recent release of Bering 1.1!!! + News@@ -214,102 +215,105 @@ on the recent release of Bering 1.1!!!- + 3/14/2003 - Shorewall 1.4.0 - - Shorewall 1.4 represents the -next step in the evolution of Shorewall. The main thrust of the initial release - is simply to remove the cruft that has accumulated in Shorewall over time. -- IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package + + Shorewall 1.4 represents the + next step in the evolution of Shorewall. The main thrust of the initial +release is simply to remove the cruft that has accumulated in Shorewall +over time. + IMPORTANT: Shorewall 1.4.0 REQUIRES the iproute package ('ip' utility). - - Function from 1.3 that has been omitted from this version include: - + + Function from 1.3 that has been omitted from this version include: +
- + Changes for 1.4 include: +
+ + - +
- - - + - +-+ - +- +This site is hosted by the generous folks at SourceForge.net@@ -382,97 +386,97 @@ now support the 'maclist' option.- + + 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 2/18/2003 - Tom Eastep
-
- + + Updated 2/24/2003 - Tom Eastep
+
+
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 2-5 and stop it in run levels 1 and 6. If you want to configure - your firewall differently from this default, you can use the "--level" - option in chkconfig (see "man chkconfig") or using your favorite - graphical run-level editor. + 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 2-5 and stop it in run levels 1 and 6. If you want +to configure your firewall differently from this default, you can +use the "--level" option in chkconfig (see "man chkconfig") or using +your favorite graphical run-level editor. @@ -55,275 +55,273 @@ - + Important Notes:
- + You can manually start and stop Shoreline Firewall using the "shorewall" - shell program: + shell program: - +
- + If you include the keyword debug as the first argument, then +a shell trace of the command is produced as in: + shorewall debug start 2> /tmp/trace- + The above command would trace the 'start' command and place the trace
information in the file /tmp/trace The Shorewall State Diagram is shown at the
- bottom of this page. + + The "shorewall" program may also be used to monitor the firewall. - +
- + Finally, the "shorewall" program may be used to dynamically alter +the contents of a zone. +
Examples:- - - The shorewall start, shorewall restart, shorewall check and - shorewall try commands allow you to specify which The shorewall start, shorewall restart, and shorewall +try commands allow you to specify which Shorewall configuration - to use: + to use: - +- -+ + shorewall [ -c configuration-directory ] {start|restart} If a configuration-directory is specified, each time that Shorewall - is going to use a file in /etc/shorewall it will first look in the configuration-directory - . If the file is present in the configuration-directory, that - file will be used; otherwise, the file in /etc/shorewall will be used. + is going to use a file in /etc/shorewall it will first look in the configuration-directory + . If the file is present in the configuration-directory, that + file will be used; otherwise, the file in /etc/shorewall will be used. - +When changing the configuration of a production firewall, I recommend - the following: + the following: - +
If the configuration starts but doesn't work, just "shorewall restart" - to restore the old configuration. If the new configuration fails to -start, the "try" command will automatically start the old one for you. + to restore the old configuration. If the new configuration fails to + start, the "try" command will automatically start the old one for you. - +When the new configuration works then just - +
The Shorewall State Diargram is depicted below.
-
-
+ - + + - - + + You will note that the commands that result in state transitions use + the word "firewall" rather than "shorewall". That is because the actual +transitions are done by /usr/lib/shorewall/firewall (/usr/share/shorewall/firewall +on Debian); /sbin/shorewall runs 'firewall" according to the following table: + +
- + + Updated 2/10/2003 - Tom Eastep - + - +Copyright - © 2001, 2002, 2003 Thomas M. Eastep. + © 2001, 2002, 2003 Thomas M. Eastep. -+ + + |