From a6c7cf06ee7d247b81f94843ab631b10d3f9e27a Mon Sep 17 00:00:00 2001
From: teastep Shorewall consists of the following components: 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.
-
-
-
-
-
+
+
+
-
-
-
- Shorewall 1.3 Reference
- This documentation is intended primarily for reference.
- Step-by-step instructions for configuring Shorewall in common setups
- may be found in the QuickStart
- Guides.
-
-Components
-
-This documentation is intended primarily for reference.
+ Step-by-step instructions for configuring Shorewall in common setups
+ may be found in the QuickStart
+ Guides.
+
+Components
+
+
-
-
+
+ /etc/shorewall/params
-
+
It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally - within the Shorewall programs
- + within the Shorewall programs +Example:
- +NET_IF=eth0- +
NET_BCAST=130.252.100.255
NET_OPTIONS=noping,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 noping,norfc1918- +
Variables may be used anywhere in the other configuration - files.
- + 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:
- + 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 - as desired so long as you have at least one zone defined.
- + 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 "shorewall restart".
- + stop; shorewall start" to install the change rather than "shorewall restart". +Warning 2: The order of entries in the /etc/shorewall/zones file is - significant in some cases.
- + 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. Columns in an entry are:
- + 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: + 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).
noping - ICMP echo-request (ping) packets addressed to
- the firewall will be ignored by this interface.
-
- filterping - ICMP echo-request (ping) packets addressed to the
- firewall will be handled according to the /etc/shorewall/rules and
-/etc/shorewall/policy file. If the applicable policy is DROP or REJECT and
-you have supplied your own /etc/shorewall/icmpdef file then these 'ping'
-requests will be passed through the rules in that file before being dropped
-or rejected. If neither noping nor filterping is specified
-then the firewall will automatically ACCEPT these 'ping' requests. If both
- noping and filterping are specified, filterping
-takes precedence.
routestopped - Beginning with Shorewall 1.3.4, this option - is deprecated in favor of the /etc/shorewall/routestopped - file. When the firewall is stopped, traffic to and from this interface - will be accepted and routing will occur between this interface and - other routestopped interfaces.
- + is deprecated in favor of the /etc/shorewall/routestopped + file. When the firewall is stopped, traffic to and from this interface + will be accepted and routing will occur between this interface and + other routestopped interfaces. + + 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 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 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 interface must be up prior to starting the - firewall.
- + (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. + +multi - The interface has multiple addresses and - you want to be able to route between them. Example: you have two addresses - on your single local interface eth1, one each in subnets 192.168.1.0/24 - and 192.168.2.0/24 and you want to route between these subnets. Because - you only have one interface in the local zone, Shorewall won't normally - create a rule to forward packets from eth1 to eth1. Adding "multi" -to the entry for eth1 will cause Shorewall to create the loc2loc chain - and the appropriate forwarding rule.
- + you want to be able to route between them. Example: you have two +addresses on your single local interface eth1, one each in subnets +192.168.1.0/24 and 192.168.2.0/24 and you want to route between these +subnets. Because you only have one interface in the local zone, Shorewall +won't normally create a rule to forward packets from eth1 to eth1. +Adding "multi" to the entry for eth1 will cause Shorewall to create +the loc2loc chain and the appropriate forwarding rule. +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 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 + 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.
- + 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.
-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 ignore ping requests from the - internet and 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,noping,norfc1918,blacklist -- - - - - -loc -eth1 -detect --
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 ignore ping requests from the + internet and you want to check all packets entering from + the internet against the black list. + Your /etc/shorewall/interfaces file would be as follows:
-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,noping,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 -192.168.1.255,192.168.12.255 -- + +ZONE +INTERFACE +BROADCAST +OPTIONS ++ - - + + +net +ppp0 ++ + 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 ++ /etc/shorewall/hosts - Configuration
- + Configuration +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.
- +Columns in this file are:
- +-
- -- ZONE - A zone defined in the /etc/shorewall/zones - file.
-- HOST(S) - The name of a network interface followed by - a colon (":") followed by either:
- +- ZONE - A zone defined in the /etc/shorewall/zones + file.
+- HOST(S) - The name of a network interface followed +by a colon (":") followed by either:
+- -- -- -
- - -- An IP address (example - eth1:192.168.1.3)
- -- A subnet in the form <subnet address>/<width> - (example - eth2:192.168.2.0/2)
- - -The interface name much match an entry in /etc/shorewall/interfaces.
--
- - +- OPTIONS - A comma-separated list of options. Currently - only a single option is defined:
- -++ ++ +
+ + +- An IP address (example - eth1:192.168.1.3)
+ +- A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
+ + +The interface name much match an entry in /etc/shorewall/interfaces.
++
+ + +- OPTIONS - A comma-separated list of options.
+ +++ this host (these hosts) will be accepted and routing will occur between + this host and other routestopped interfaces and hosts.routestopped - Beginning with Shorewall 1.3.4, this option is deprecated in favor of the /etc/shorewall/routestopped file. When the firewall is stopped, traffic to and from - this host (these hosts) will be accepted and routing will occur between - this host and other routestopped interfaces and hosts.
-
+
+ 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.
+ to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces + to the zone. - +Note 1: 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.
- +Note 2: The setting of the MERGE_HOSTS variable - in /etc/shorewall/shorewall.conf - has an important effect on how the host file is - processed. Please read the description of that + in /etc/shorewall/shorewall.conf + has an important effect on how the host file +is processed. Please read the description of that variable carefully.
- +Example:
- +Your local interface is eth1 and you have two groups of local hosts that - you want to make into separate zones:
- + you want to make into separate zones: +Your /etc/shorewall/interfaces file might look like:
- -+ +- -- - -- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -net -eth0 -detect -dhcp,noping,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 -routestopped -Hosts in 'loc2' can communicate with the firewall while Shorewall is - stopped -- those in 'loc1' cannot.
- - -Nested and Overlapping Zones
- - -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.
- - -- /etc/shorewall/policy Configuration.
- - -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:
- - --
- - -- 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 that the policy - is applied.
- - -Entries in /etc/shorewall/policy have four columns as follows:
- - -- -
- - -- SOURCE - The name of a client - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
- -- DEST - The name of a destination - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall zone or "all").
- -- POLICY - The default policy - for connection requests from the SOURCE zone to the DESTINATION zone.
- -- LOG LEVEL - Optional. If -left empty, no log message is generated when the policy is applied. -Otherwise, this column should contain an integer or name indicating -a syslog level. See the syslog.conf man page for a description of -each log level.
- -- LIMIT:BURST - Optional. If left - empty, TCP connection requests from the SOURCE zone to the DEST - zone will not be rate-limited. Otherwise, this column specifies the maximum - rate at which TCP connection requests will be accepted followed by a colon - (":") followed by the maximum burst size that will be tolerated. Example: - 10/sec:40 specifies that the maximum rate of TCP connection - requests allowed will be 10 per second and a burst of 40 connections will - be tolerated. Connection requests in excess of these limits will be dropped.
- - -In the SOURCE and DEST columns, you can enter "all" to indicate all - zones.
- - -The policy file installed by default is as follows:
- - -- -+- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- -loc -net -ACCEPT -- - - - -net -all -DROP -info -- - +all -all -REJECT -info -- ZONE +INTERFACE +BROADCAST +OPTIONS + ++ +net +eth0 +detect +dhcp,noping,norfc1918 ++ - +- +eth1 +detect ++
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.
- -+ ++ + +The '-' in the ZONE column for eth1 tells Shorewall that eth1 interfaces + to multiple zones.
+ + +Your /etc/shorewall/hosts file might look like:
+ + ++- -- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -LIMIT:BURST -- -loc -all -ACCEPT -- - - -net -all -DROP -info -- - + +loc -loc -REJECT -info -- + +ZONE +HOST(S) +OPTIONS ++ +loc1 +eth1:192.168.1.0/25 ++ + - +loc2 +eth1:192.168.1.128/25 +routestopped +- The CONTINUE policy
- -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:
- -++ + +Hosts in 'loc2' can communicate with the firewall while Shorewall is + stopped -- those in 'loc1' cannot.
+ + +Nested and Overlapping Zones
+ + +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.
+ + ++ /etc/shorewall/policy Configuration.
+ + +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:
+ + ++
+ + +- 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 that the policy + is applied.
+ + +Entries in /etc/shorewall/policy have four columns as follows:
+ + ++ +
+ + +- SOURCE - The name of a +client zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all").
+ +- DEST - The name of a destination + zone (a zone defined in the /etc/shorewall/zones + file , the name of the firewall zone or "all").
+ +- POLICY - The default policy + for connection requests from the SOURCE zone to the DESTINATION zone.
+ +- LOG LEVEL - Optional. If + left empty, no log message is generated when the policy is applied. + Otherwise, this column should contain an integer or name indicating + a syslog level. See the syslog.conf man page for a description of +each log level.
+ +- LIMIT:BURST - Optional. If +left empty, TCP connection requests from the SOURCE zone to the + DEST zone will not be rate-limited. Otherwise, this column +specifies the maximum rate at which TCP connection requests will be accepted +followed by a colon (":") followed by the maximum burst size that will +be tolerated. Example: 10/sec:40 specifies that the maximum +rate of TCP connection requests allowed will be 10 per second and a burst +of 40 connections will be tolerated. Connection requests in excess of +these limits will be dropped.
+ + +In the SOURCE and DEST columns, you can enter "all" to indicate all + zones.
+ + +The policy file installed by default is as follows:
+ + +++- -
-- -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 +net +ACCEPT ++ + + + +net +all +DROP +info ++ + - +all +all +REJECT +info ++
This table may be interpreted as follows:
+ +/etc/shorewall/interfaces:
+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.
+ ++- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- -- -eth0 -detect -dhcp,noping,norfc1918 -- + +loc -eth1 -detect -routestopped -+ +SOURCE +DEST +POLICY +LOG LEVEL +LIMIT:BURST ++ +loc +all +ACCEPT ++ + + +net +all +DROP +info ++ + - +loc +loc +REJECT +info ++
/etc/shorewall/hosts:
++-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 -HOST(S) -OPTIONS -- -net -eth0:0.0.0.0/0 -- - + +sam -eth0:206.191.149.197 -routestopped -+ +ZONE +DISPLAY +COMMENTS ++ +sam +Sam +Sam's system at home ++ +net +Internet +The Internet ++ - +loc +Loc +Local Network +
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/interfaces:
-/etc/shorewall/policy:
- -+-+- -
-- -SOURCE -DEST -POLICY -LOG LEVEL -- -loc -net -ACCEPT -- - -sam -all -CONTINUE -- - -net -all -DROP -info -- + +all -all -REJECT -info -+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ +- +eth0 +detect +dhcp,noping,norfc1918 ++ - - +loc +eth1 +detect +routestopped +
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).
+/etc/shorewall/hosts:
-Partial /etc/shorewall/rules:
- -+-+- -
-- -ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- -... -- - - - - - - -DNAT -sam -loc:192.168.1.3 -tcp -ssh -- -- - -DNAT -net -loc:192.168.1.5 -tcp -www -- -- - + +... -- - - - - - + +ZONE +HOST(S) +OPTIONS ++ +net +eth0:0.0.0.0/0 ++ + - +sam +eth0:206.191.149.197 +routestopped +
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:
- --+- 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/policy:
+ ++ face="Century Gothic, Arial, Helvetica">- -
- +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 -- -- - +... -- - - - - - SOURCE +DEST +POLICY +LOG LEVEL + ++ +loc +net +ACCEPT ++ + +sam +all +CONTINUE ++ + +net +all +DROP +info ++ - - + + + +all +all +REJECT +info +
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).
+ +Partial /etc/shorewall/rules:
+ +++ ++ +
++ +ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL +
+ DEST+ +... ++ + + + + + + +DNAT +sam +loc:192.168.1.3 +tcp +ssh +- ++ + +DNAT +net +loc:192.168.1.5 +tcp +www +- ++ + + + + + + + +... ++ + + + + +
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 @@ -1106,387 +1135,392 @@ be listed before net 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.
+ 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.
+ in the /etc/shorewall/policy file. There is one entry in /etc/shorewall/rules + for each of these rules. - +Entries in the file have the following columns:
- +The ACTION may optionally be followed by ":" and a syslogd log
- level (example: REJECT:info). This causes the packet to be logged at
-the specified level prior to being processed according to the specified
-ACTION.
-
- The use of DNAT or REDIRECT requires that you have
+
+ 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 192.168.1.3.
- + 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- - - - - - - -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 +
- DESTACTION +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 -- -
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.
- --- - -- -
-- -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 -- - + - +DNAT +net +loc:192.168.1.3 +tcp +ssh ++ +
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 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- -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 -+ +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 ++ +
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.
+ + +++ + + ++ +
-+ +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 ++ +
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:
+ 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 - the pure-ftpd runline.
+ 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 usage on the - firewall system.
+ 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 @@ -1494,51 +1528,51 @@ though because then 02:00:08:E3:FA:55.
- ++ face="Century Gothic, Arial, Helvetica">+ - +- -
-- +ACTION -SOURCE -DEST -PROTO -DEST -
- PORT(S)SOURCE -
- PORT(S)ORIGINAL -
- DEST- +ACCEPT -loc:~02-00-08-E3-FA-55 -dmz -all -- - - ACTION +SOURCE +DEST +PROTO +DEST +
+ PORT(S)SOURCE +
+ PORT(S)ORIGINAL + +
+ DEST+ - - + +ACCEPT +loc:~02-00-08-E3-FA-55 +dmz +all ++ + +
Look here for information on other services. -
+ - +Shorewall allows definition of rules that apply between all zones. @@ -1548,157 +1582,160 @@ though because then 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.
+ 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.
+ 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. In order to make use -of this feature, you must have NAT enabled .
+ 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:
+ 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.
+ + ++ ++ ++ +
++ +INTERFACE +SUBNET +ADDRESS ++ + + + + + + + +ipsec0:10.1.0.0/16 +192.168.9.0/24 ++
Example 3: You have a DSL line connected on eth0 and a local - network (192.168.10.0/24) - connected to + 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 -INTERFACE +SUBNET +ADDRESS + ++ - - + +eth0 +192.168.10.0/24 +206.124.146.176 +
Example 4: Same as example 3 except that you wish @@ -1708,34 +1745,34 @@ all local->net the SNAT rule.
- +- ++ - +- -
-- +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 +192.168.10.0/24!192.168.10.44,192.168.10.45 +206.124.146.176 +
If you want to use proxy ARP on an entire sub-network, @@ -1744,30 +1781,30 @@ all local->net 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 + 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. -
+ 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 @@ -1775,47 +1812,47 @@ record in - + 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.
+ 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 @@ -1824,92 +1861,94 @@ 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:
- + 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:
+ 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 -+ +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.
- + for details. In this case you will want to place "Yes" in the HAVEROUTE + column. +To learn how I use Proxy ARP in my DMZ, see my configuration files.
- +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.
- + 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):
- + (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 .
- +IMPORTANT: If @@ -1921,9 +1960,9 @@ I can't say if it is a bug in the Kernel or in FreeS/Wan. static NAT. Port forwarding can be accomplished - with simple - entries in - the rules file. Also, in most @@ -1938,387 +1977,397 @@ be accomplished are accessed using the same IP address internally - and externally.
+ and externally. - +Columns in an entry are:
- +Look here for additional information and an example. -
+ - +The /etc/shorewall/tunnels file allows you to define IPSec, GRE and - IPIP tunnels with end-points on your firewall. To use ipsec, you must -install version 1.9, 1.91 or the current The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP +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 in kernel - compilation errors.
+ 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 and instructions for IPIP - tunnels are here . Look here for information - about setting up PPTP - tunnels under - Shorewall.
+ be found here, instructions for IPIP and +GRE tunnels are here and instructions for +PPTP tunnels are here. + +This file is used to set the following firewall parameters:
- +ZONE | +HOSTS | +BROADCAST | +OPTIONS | +
ZONE | -HOSTS | -BROADCAST | -OPTIONS | -
loc | -eth1 | -- | -dhcp | -
- | -ppp+ | -- | - | loc | +eth1 | +- | +dhcp | + +
- | +ppp+ | ++ | + |
- Hosts File:
-
ZONE | +HOSTS | +
ZONE | -HOSTS | -
loc | -ppp+:192.168.12.0/24 | -loc | +ppp+:192.168.12.0/24 | + + +
- With MERGE_HOSTS=No, the loc zone consists of only ppp+:192.168.12.0/24;
- with MERGE_HOSTS=Yes, it includes eth1:0.0.0.0/0 and ppp+:192.168.12.0/24.
-
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).
+ 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 - "loadmodule" for the set of modules that I load.
+ "loadmodule" for the set of modules that I load. - +The loadmodule function is called as follows:
- +- - + ++ - +loadmodule <modulename> [ <module parameters> ]
-
where
- +- +- +<modulename>
- +- ++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:
+ 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: - +- ++ parameters> + - +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 @@ -2504,391 +2553,399 @@ it does, the function assumes that the running configuration supports compress - +
- ++ parameters> + - +insmod moduledirectory/<modulename>.o.gz <module - parameters>
-
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 + 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:
- +- ++ Maximize-Throughput (8)- +-Minimize-Delay (16)
-
- Maximize-Throughput (8)
- Maximize-Reliability (4)
- Minimize-Cost (2)
- Normal-Service (0)
The /etc/shorewall/tos file that is included with Shorewall contains - the following entries.
+ 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.
+ adding the ESP and AH protocols to the /etc/shorewall/tos file. - +Each line in /etc/shorewall/blacklist contains - an - IP - address, a MAC address in Shorewall - Format - or - subnet - address. - Example:
+ an + IP + address, a MAC address in Shorewall + Format + or + subnet + address. + Example: - +130.252.100.69- +
206.124.146.0/24
Packets
from
hosts
listed
in
- the
- blacklist
- file
- will
- be
- disposed
+ the
+ blacklist
+ file
+ will
+ be
+ disposed
- of
- according
- to
- the
- value
- assigned
+ of
+ according
+ to
+ the
+ value
+ assigned
- to
- the BLACKLIST_DISPOSITION
- and
- BLACKLIST_LOGLEVEL variables
- in
- /etc/shorewall/shorewall.conf.
+ to
+ the BLACKLIST_DISPOSITION
- Only
- packets
- arriving
- on
- interfaces
+and BLACKLIST_LOGLEVEL variables
+ in
+ /etc/shorewall/shorewall.conf.
+
+ Only
+ packets
+ arriving
+ on
+ interfaces
that
have
the
'blacklist'
- option
- in
- /etc/shorewall/interfaces
- are
+ option
+ in
+ /etc/shorewall/interfaces
+ are
- checked
- against
- the
- blacklist. The black list is
+ 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:
-
Shorewall also has a dynamic blacklist - capability.
+ 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 (http://www.squid-cache.org). -
+ designed to police your users' web browsing -- to do that, I suggest that + you install and configure Squid (http://www.squid-cache.org). + - +This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:
+ interface option. Columns in the file are: - +This fine defines the hosts that are accessible from the firewall when - the firewall is stopped. Columns in the file are:
+ +This file defines the hosts that are accessible from the firewall when + the firewall is stopped. Columns in the file are:
- +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.
+ from local hosts 192.168.1.0/24 and from your DMZ. Your DMZ interfaces through + eth1 and your local hosts through eth2. - +- ++ - -- -
-+ +- + -INTERFACE +INTERFACE -HOST(S) +HOST(S) -+ - + -eth2 +eth2 -192.168.1.0/24 +192.168.1.0/24 -+ - + - - + +eth1 +eth1 -- +- -
Updated 9/28/2002 - Tom Eastep -
+ +Updated 10/28/2002 - Tom Eastep +
- +Copyright - © 2001, 2002 Thomas M. Eastep.
+ © 2001, 2002 Thomas M. Eastep. -+ |
+
Shorewall FAQs- |
-
1a. Ok -- I followed those instructions - but it doesn't work.
- - - - - -3. I want to use Netmeeting/MSN - Messenger with Shorewall. What do I do?
- - - -4a. I just ran an nmap UDP scan - of my firewall and it showed 100s of ports as open!!!!
- -5. I've installed Shorewall and now - I can't ping through the firewall
- -6. Where are the log messages - written and how do I change the destination?
- -6a. Are there any log parsers - that work with Shorewall?
- - - -8. When I try to start Shorewall - on RedHat 7.x, I get messages about insmod failing -- what's wrong?
- -9. Why can't Shorewall detect - my interfaces properly?
- -10. What distributions does - it work with?
- -11. What features does it -support?
- + + + +1a. Ok -- I followed those instructions
+ but it doesn't work.
+
1b. I'm still having problems with +port forwarding
+ + + + + +3. I want to use Netmeeting/MSN + Messenger with Shorewall. What do I do?
+ + + +4a. I just ran an nmap UDP scan + of my firewall and it showed 100s of ports as open!!!!
+ +5. I've installed Shorewall and now + I can't ping through the firewall
+ +6. Where are the log messages + written and how do I change the destination?
+ +6a. Are there any log parsers + that work with Shorewall?
+ + + +8. When I try to start Shorewall + on RedHat 7.x, I get messages about insmod failing -- what's wrong?
+ +9. Why can't Shorewall detect + my interfaces properly?
+ +10. What distributions does + it work with?
+ +11. What features does it + support?
+ - +13. Why do you call it "Shorewall"?
- - - - - -15. My local systems can't see - out to the net
- -16. Shorewall is writing log messages - all over my console making it unusable!
- -15. My local systems can't see + out to the net
+ +16. Shorewall is writing log messages
+ all over my console making it unusable!
+
Answer: The first example in the rules file documentation shows how to - do port forwarding under Shorewall. Assuming that you have a dynamic external - IP address, the format of a port-forwarding rule to a local system is as -follows:
- -+ href="Documentation.htm#Rules">rules file documentation shows how to + do port forwarding under Shorewall. The format of a port-forwarding +rule to a local system is as follows: + ++ +- -- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -net -loc:<local IP address>[:<local port>] -<protocol> -<port #> --
--
-+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +net +loc:<local IP address>[:<local port>] +<protocol> +<port #> ++
++
+So to forward UDP port 7777 to internal system 192.168.1.5, - the rule is:
- -++ +So to forward UDP port 7777 to internal system 192.168.1.5, + the rule is:
+ +- -- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -net -loc:192.168.1.5 -udp -7777 --
--
-+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +net +loc:192.168.1.5 +udp +7777 ++
++
++ + ++ +- -DNAT net loc:192.168.1.5 udp 7777-If you want to forward requests directed to a particular -address ( <external IP> ) on your firewall to an internal system:
- -+If you want to forward requests directed to a particular address +( <external IP> ) on your firewall to an internal system:
+ +- -- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -net -loc:<local IP address>[:<local port>] -<protocol> -<port #> -- -<external IP> -+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +net +loc:<local IP address>[:<local port>] +<protocol> +<port #> +- +<external IP> +1a. Ok -- I followed those instructions - but it doesn't work
- +
Answer: That is usually the result of one of two things:
- +Answer: I have two objections to this setup.
- +If you insist on an IP solution to the accessibility problem - rather than a DNS solution, then assuming that your external interface is - eth0 and your internal interface is eth1 and that eth1 has IP address 192.168.1.254 - with subnet 192.168.1.0/24, do the following:
- -a) In /etc/shorewall/interfaces, specify "multi" as an option - for eth1.
- -If you insist on an IP solution to the accessibility problem + rather than a DNS solution, then assuming that your external interface + is eth0 and your internal interface is eth1 and that eth1 has IP address + 192.168.1.254 with subnet 192.168.1.0/24, do the following:
+ +a) In /etc/shorewall/interfaces, specify "multi" as an option + for eth1 (No longer required as of Shorewall version 1.3.9).
+ +b) In /etc/shorewall/rules, add:
-+
-- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -loc:192.168.1.0/24 -loc:192.168.1.5 -tcp -www -- -130.151.100.69:192.168.1.254 -+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +loc:192.168.1.0/24 +loc:192.168.1.5 +tcp +www +- +130.151.100.69:192.168.1.254 +
DNAT loc:192.168.1.0/24 loc:192.168.1.5 tcp www - 130.151.100.69:192.168.1.254-
That rule only works of course if you have a static external - IP address. If you have a dynamic IP address and are running Shorewall -1.3.4 or later then include this in /etc/shorewall/params:
-That rule only works of course if you have a static external + IP address. If you have a dynamic IP address and are running Shorewall + 1.3.4 or later then include this in /etc/shorewall/params:
+ETH0_IP=`find_interface_address eth0`-
and make your DNAT rule:
-+
-- -
-- -ACTION -SOURCE -DESTINATION -PROTOCOL -PORT -SOURCE PORT -ORIG. DEST. -- - - + +DNAT -loc:192.168.1.0/24 -loc:192.168.1.5 -tcp -www -- -$ETH0_IP:192.168.1.254 -+ +ACTION +SOURCE +DESTINATION +PROTOCOL +PORT +SOURCE PORT +ORIG. DEST. ++ + +DNAT +loc:192.168.1.0/24 +loc:192.168.1.5 +tcp +www +- +$ETH0_IP:192.168.1.254 +
Using this technique, you will want to configure your DHCP/PPPoE - client to automatically restart Shorewall each time that you get a new IP - address.
-Answer: This is another problem that is best solved - using Bind Version 9 "views". It allows both external and internal clients - to access a NATed host using the host's DNS name.
- -Another good way to approach this problem is to switch from - static NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918 addresses - and can be accessed externally and internally using the same address.
- -If you don't like those solutions and prefer routing all Z->Z -traffic through your firewall then:
- -a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces.
- b) Set the Z->Z policy to ACCEPT.
- c) Masquerade Z to itself.
-
- Example:
Using this technique, you will want to configure your DHCP/PPPoE + client to automatically restart Shorewall each time that you get a +new IP address.
+Answer: This is another problem that is best solved + using Bind Version 9 "views". It allows both external and internal clients + to access a NATed host using the host's DNS name.
+ +Another good way to approach this problem is to switch from + static NAT to Proxy ARP. That way, the hosts in Z have non-RFC1918 addresses + and can be accessed externally and internally using the same address. +
+ +If you don't like those solutions and prefer routing all +Z->Z traffic through your firewall then:
+ +a) Specify "multi" on the entry for Z's interface in /etc/shorewall/interfaces
+(If you are running a Shorewall version earlier than 1.3.9).
+ b) Set the Z->Z policy to ACCEPT.
+ c) Masquerade Z to itself.
+
+ Example:
Zone: dmz
- Interface: eth2
- Subnet: 192.168.2.0/24
In /etc/shorewall/interfaces:
- -+ ++- +- -
-- -ZONE -INTERFACE -BROADCAST -OPTIONS -- - - + +dmz -eth2 -192.168.2.255 -multi -+ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ + +dmz +eth2 +192.168.2.255 +multi +
In /etc/shorewall/policy:
- -+ ++ +- -- -
-- -SOURCE -DESTINATION -POLICY -LIMIT:BURST -- - - + +dmz -dmz -ACCEPT --
-+ +SOURCE +DESTINATION +POLICY +LIMIT:BURST ++ + +dmz +dmz +ACCEPT ++
++ + ++- +dmz dmz ACCEPT-In /etc/shorewall/masq:
- -+ ++ +- -- -
-- -INTERFACE -SUBNET -ADDRESS -- - - + +eth2 -192.168.2.0/24 --
-+ +INTERFACE +SUBNET +ADDRESS ++ + +eth2 +192.168.2.0/24 ++
+3. I want to use Netmeeting/MSN Messenger - with Shorewall. What do I do?
- +3. I want to use Netmeeting/MSN Messenger + with Shorewall. What do I do?
+Answer: There is an H.323 connection - tracking/NAT module that may help. Also check the Netfilter mailing list - archives at http://netfilter.samba.org. -
- -4. I just used an online port scanner - to check my firewall and it shows some ports as 'closed' rather than 'blocked'. - Why?
- -Answer: The common.def included with version 1.3.x - always rejects connection requests on TCP port 113 rather than dropping - them. This is necessary to prevent outgoing connection problems to services - that use the 'Auth' mechanism for identifying requesting users. Shorewall - also rejects TCP ports 135, 137 and 139 as well as UDP ports 137-139. -These are ports that are used by Windows (Windows can be configured -to use the DCE cell locator on port 135). Rejecting these connection requests - rather than dropping them cuts down slightly on the amount of Windows -chatter on LAN segments connected to the Firewall.
- -If you are seeing port 80 being 'closed', that's probably - your ISP preventing you from running a web server in violation of your - Service Agreement.
- -4a. I just ran an nmap UDP scan of my - firewall and it showed 100s of ports as open!!!!
- -Answer: Take a deep breath and read the nmap man page - section about UDP scans. If nmap gets nothing back from your firewall - then it reports the port as open. If you want to see which UDP ports are - really open, temporarily change your net->all policy to REJECT, restart - Shorewall and do the nmap UDP scan again.
- -5. I've installed Shorewall and now I - can't ping through the firewall
- -Answer: If you want your firewall to be totally open - for "ping":
- + href="http://www.kfki.hu/%7Ekadlec/sw/netfilter/newnat-suite/"> H.323 connection + tracking/NAT module that may help. Also check the Netfilter mailing + list archives at http://netfilter.samba.org. + + +4. I just used an online port scanner + to check my firewall and it shows some ports as 'closed' rather than + 'blocked'. Why?
+ +Answer: The common.def included with version 1.3.x + always rejects connection requests on TCP port 113 rather than dropping + them. This is necessary to prevent outgoing connection problems to + services that use the 'Auth' mechanism for identifying requesting +users. Shorewall also rejects TCP ports 135, 137 and 139 as well as +UDP ports 137-139. These are ports that are used by Windows (Windows +can be configured to use the DCE cell locator on port 135). +Rejecting these connection requests rather than dropping them cuts +down slightly on the amount of Windows chatter on LAN segments connected + to the Firewall.
+ +If you are seeing port 80 being 'closed', that's probably + your ISP preventing you from running a web server in violation of +your Service Agreement.
+ +4a. I just ran an nmap UDP scan of my + firewall and it showed 100s of ports as open!!!!
+ +Answer: Take a deep breath and read the nmap man page + section about UDP scans. If nmap gets nothing back from your + firewall then it reports the port as open. If you want to see which + UDP ports are really open, temporarily change your net->all policy + to REJECT, restart Shorewall and do the nmap UDP scan again.
+ +5. I've installed Shorewall and now I + can't ping through the firewall
+ +Answer: If you want your firewall to be totally open + for "ping":
+a) Do NOT specify 'noping' on any interface in /etc/shorewall/interfaces.
- -
- b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef
- c) Add the following to /etc/shorewall/icmpdef:-- -run_iptables -A icmpdef -p ICMP --icmp-type echo-request - -j ACCEPT
-6. Where are the log messages written - and how do I change the destination?
- -Answer: NetFilter uses the kernel's equivalent of syslog -(see "man syslog") to log messages. It always uses the LOG_KERN (kern) facility -(see "man openlog") and you get to choose the log level (again, see "man -syslog") in your policies and rules. The destination for messaged -logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). -When you have changed /etc/syslog.conf, be sure to restart syslogd (on a RedHat -system, "service syslog restart").
- -By default, older versions of Shorewall ratelimited log messages - through settings in /etc/shorewall/shorewall.conf - -- If you want to log all messages, set:
- -+ b) Copy /etc/shorewall/icmp.def to /etc/shorewall/icmpdef+ +
+ c) Add the following to /etc/shorewall/icmpdef: + +++ +run_iptables -A icmpdef -p ICMP --icmp-type echo-request + -j ACCEPT
+6. Where are the log messages written + and how do I change the destination?
+ +Answer: NetFilter uses the kernel's equivalent of +syslog (see "man syslog") to log messages. It always uses the LOG_KERN (kern) +facility (see "man openlog") and you get to choose the log level (again, +see "man syslog") in your policies + and rules. The destination for messaged + logged by syslog is controlled by /etc/syslog.conf (see "man syslog.conf"). + When you have changed /etc/syslog.conf, be sure to restart syslogd (on + a RedHat system, "service syslog restart").
+ +By default, older versions of Shorewall ratelimited log messages + through settings in /etc/shorewall/shorewall.conf + -- If you want to log all messages, set:
+ +- -LOGLIMIT=""-
LOGBURST=""6a. Are there any log parsers that work - with Shorewall?
- -Answer: Here are several links that may be helpful: -
- -+6a. Are there any log parsers that work + with Shorewall?
+ +Answer: Here are several links that may be helpful: +
+ +- -http://www.shorewall.net/pub/shorewall/parsefw/
-
- http://www.fireparse.com
- http://cert.uni-stuttgart.de/projects/fwlogwatch7. When I stop Shorewall using 'shorewall - stop', I can't connect to anything. Why doesn't that command work?
- -The 'stop' command is intended to place your firewall into - a safe state whereby only those interfaces/hosts having the 'routestopped' - option in /etc/shorewall/interfaces and /etc/shorewall/hosts are activated. - If you want to totally open up your firewall, you must use the 'shorewall - clear' command.
- -8. When I try to start Shorewall on RedHat - 7.x, I get messages about insmod failing -- what's wrong?
- -Answer: The output you will see looks something like - this:
- + http://www.fireparse.com
+ http://cert.uni-stuttgart.de/projects/fwlogwatch
+http://www.logwatch.org
+ +
The 'stop' command is intended to place your firewall into + a safe state whereby only those interfaces/hosts having the 'routestopped' + option in /etc/shorewall/interfaces and /etc/shorewall/hosts are activated. + If you want to totally open up your firewall, you must use the 'shorewall + clear' command.
+ +Answer: The output you will see looks something like + this:
+/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy- -
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
This is usually cured by the following sequence of commands: -
- -This is usually cured by the following sequence of commands: +
+ +service ipchains stop-
chkconfig --delete ipchains
rmmod ipchains
Also, be sure to check the errata - for problems concerning the version of iptables (v1.2.3) shipped with RH7.2.
-Also, be sure to check the errata + for problems concerning the version of iptables (v1.2.3) shipped with + RH7.2.
+I just installed Shorewall and when I issue the start command, - I see the following:
- -I just installed Shorewall and when I issue the start command, + I see the following:
+ +Processing /etc/shorewall/shorewall.conf ...-
Processing /etc/shorewall/params ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
Local Zone: eth1:0.0.0.0/0
Deleting user chains...
Creating input Chains...
...
Why can't Shorewall detect my interfaces properly?
-Answer: The above output is perfectly normal. The Net - zone is defined as all hosts that are connected through eth0 and the local - zone is defined as all hosts connected through eth1
-Shorewall works with any GNU/Linux distribution that includes - the proper prerequisites.
- +Answer: The above output is perfectly normal. The +Net zone is defined as all hosts that are connected through eth0 and the +local zone is defined as all hosts connected through eth1
+Shorewall works with any GNU/Linux distribution that includes + the proper prerequisites.
+Answer: See the Shorewall - Feature List.
- + +Answer: See the Shorewall + Feature List.
+Answer: Every time I've started to work on one, I find -myself doing other things. I guess I just don't care enough if Shorewall -has a GUI to invest the effort to create one myself. There are several -Shorewall GUI projects underway however and I will publish links to -them when the authors feel that they are ready.
- + +Answer: Every time I've started to work on one, I +find myself doing other things. I guess I just don't care enough if +Shorewall has a GUI to invest the effort to create one myself. There +are several Shorewall GUI projects underway however and I will publish +links to them when the authors feel that they are ready.
+Answer: Shorewall is a concatenation of "Shoreline" - (the city where I live) - and "Firewall".
- -Is there any way it can add a rule before the rfc1918 blocking - that will let all traffic to and from the 192.168.100.1 address of the modem - in/out but still block all other rfc1918 addresses.
- -Answer: If you are running a version of Shorewall earlier -than 1.3.1, create /etc/shorewall/start and in it, place the following:
- -Answer: Shorewall is a concatenation of "Shoreline" + (the city where I live) + and "Firewall".
+ +Is there any way it can add a rule before the rfc1918 blocking + that will let all traffic to and from the 192.168.100.1 address of +the modem in/out but still block all other rfc1918 addresses.
+ +Answer: If you are running a version of Shorewall +earlier than 1.3.1, create /etc/shorewall/start and in it, place the +following:
+ +run_iptables -I rfc1918 -s 192.168.100.1 -j ACCEPT-
If you are running version 1.3.1 or later, simply add the - following to /etc/shorewall/rfc1918:
-+
If you are running version 1.3.1 or later, simply add the + following to /etc/shorewall/rfc1918:
++- -
+- -SUBNET -TARGET -- + +192.168.100.1 -RETURN -+ +SUBNET +TARGET ++ + + +192.168.100.1 +RETURN +
Be sure that you add the entry ABOVE the entry for 192.168.0.0/16.
-
Note: If you add a second IP address to your external firewall
-interface to correspond to the modem address, you must also make an entry
-in /etc/shorewall/rfc1918 for that address. For example, if you configure
-the address 192.168.100.2 on your firewall, then you would add two entries
-to /etc/shorewall/rfc1918:
-
+ + +Note: If you add a second IP address to your external firewall + interface to correspond to the modem address, you must also make an entry + in /etc/shorewall/rfc1918 for that address. For example, if you configure + the address 192.168.100.2 on your firewall, then you would add two entries + to /etc/shorewall/rfc1918:
+ +
+-- -
-- -SUBNET -
-TARGET -
-- -192.168.100.1 -
-RETURN -
-- - - + +192.168.100.2 -
-RETURN -
-+ +SUBNET +
+TARGET +
++ +192.168.100.1 +
+RETURN +
++ + +192.168.100.2 +
+RETURN +
+
The solution is the same as FAQ 14 above. Simply substitute - the IP address of your ISPs DHCP server.
-Answer: Every time I read "systems can't see out to - the net", I wonder where the poster bought computers with eyes and what -those computers will "see" when things are working properly. That aside, -the most common causes of this problem are:
- + +The solution is the same as FAQ 14 above. Simply substitute + the IP address of your ISPs DHCP server.
+Answer: Every time I read "systems can't see out to + the net", I wonder where the poster bought computers with eyes and +what those computers will "see" when things are working properly. That +aside, the most common causes of this problem are:
+The default gateway on each local system isn't set to - the IP address of the local firewall interface.
-The entry for the local network in the /etc/shorewall/masq - file is wrong or missing.
-The DNS settings on the local systems are wrong or the - user is running a DNS server on the firewall and hasn't enabled UDP and - TCP port 53 from the firewall to the internet.
-The default gateway on each local system isn't set to + the IP address of the local firewall interface.
+The entry for the local network in the /etc/shorewall/masq + file is wrong or missing.
+The DNS settings on the local systems are wrong or the + user is running a DNS server on the firewall and hasn't enabled UDP + and TCP port 53 from the firewall to the internet.
+Answer: "man dmesg" -- add a suitable 'dmesg' command - to your startup scripts or place it in /etc/shorewall/start. Under RedHat, - the max log level that is sent to the console is specified in /etc/sysconfig/init - in the LOGLEVEL variable.
- + +Answer: "man dmesg" -- add a suitable 'dmesg' command
+ to your startup scripts or place it in /etc/shorewall/start. Under
+ RedHat, the max log level that is sent to the console is specified
+in /etc/sysconfig/init in the LOGLEVEL variable.
+
# Accept AUTH but only on address 192.0.2.125+ Example 2 (NAT):
ACCEPT net fw:192.0.2.125 tcp auth
192.0.2.126 eth0 10.1.1.126+ /etc/shorewall/rules +
# Accept HTTP on 192.0.2.126 (a.k.a. 10.1.1.126)+
ACCEPT net loc:10.1.1.126 tcp www
Last updated 10/8/2002 - Last updated 11/09/2002 - Tom Eastep
- -Copyright
- © 2001, 2002 Thomas M. Eastep.
+
+
Copyright
+ © 2001, 2002 Thomas M. Eastep.
+
- IPSEC Tunnels- |
-
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
-Suppose that we have the following sutuation:
- - - -- -
- - - -We want systems -in the 192.168.1.0/24 sub-network to be able to communicate with systems -in the 10.0.0.0/8 network.
- -To make this work, we need to do two things:
- -a) Open the firewall so that the IPSEC tunnel can be established -(allow the ESP and AH protocols and UDP Port 500).
- -b) Allow traffic through the tunnel.
- -Opening the firewall for the IPSEC tunnel is accomplished by -adding an entry to the /etc/shorewall/tunnels file.
- -In /etc/shorewall/tunnels -on system A, we need the following
- --- -- -
- -- TYPE -- ZONE -- GATEWAY -- GATEWAY ZONE -- - - -ipsec -net -134.28.54.2 --
In /etc/shorewall/tunnels -on system B, we would have:
- --- -- -
- -- TYPE -- ZONE -- GATEWAY -- GATEWAY ZONE -- - - -ipsec -net -206.161.148.9 --
You need to define a zone for the remote subnet or include - it in your local zone. In this example, we'll assume that you have created a - zone called "vpn" to represent the remote subnet.
- --- --
-- -ZONE -DISPLAY -COMMENTS -- - -vpn -VPN -Remote Subnet -
At both -systems, ipsec0 would be included in /etc/shorewall/interfaces as a "vpn" -interface:
- --- -- -
- -- ZONE -- INTERFACE -- BROADCAST -- OPTIONS -- - - -vpn -ipsec0 -- -
You will need to allow traffic between the "vpn" zone and - the "loc" zone -- if you simply want to admit all traffic in both - directions, you can use the policy file:
- - --- --
-- -SOURCE -DEST -POLICY -LOG LEVEL -- - -loc -vpn -ACCEPT -- - - -vpn -loc -ACCEPT --
Once -you have these entries in place, restart Shorewall (type shorewall restart); -you are now ready to configure the tunnel in - FreeS/WAN - .
- - -Suppose that you have -a laptop system (B) that you take with you when you travel and you want to -be able to establish a secure connection back to your local network.
- -- -
- -You need to define a zone for the laptop or include it in - your local zone. In this example, we'll assume that you have created a zone - called "vpn" to represent the remote host.
- --- --
-- -ZONE -DISPLAY -COMMENTS -- - -vpn -VPN -Remote Subnet -
In this -instance, the mobile system (B) has IP address 134.28.54.2 but that cannot -be determined in advance. In the /etc/shorewall/tunnels file on system A, -the following entry should be made:
- --+ + + + + + +- -
- -- TYPE -- ZONE -- GATEWAY -- GATEWAY ZONE -- - -ipsec -net -0.0.0.0/0 -vpn -
+ IPSEC Tunnels+ |
+
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
+ +Suppose that we have the following sutuation:
+ ++
+ +We want systems in the 192.168.1.0/24 sub-network to be able +to communicate with systems in the 10.0.0.0/8 network.
+ +To make this work, we need to do two things:
+ +a) Open the firewall so that the IPSEC tunnel can be established + (allow the ESP and AH protocols and UDP Port 500).
+ +b) Allow traffic through the tunnel.
+ +Opening the firewall for the IPSEC tunnel is accomplished +by adding an entry to the /etc/shorewall/tunnels file.
+ +In /etc/shorewall/tunnels on system A, we need the following
+ ++-+ +
++ +TYPE +ZONE +GATEWAY +GATEWAY ZONE ++ + + +ipsec +net +134.28.54.2 ++
Note that the GATEWAY -ZONE column contains the name of the zone corresponding to peer subnetworks. This indicates that the -gateway system itself comprises the peer subnetwork; in other words, the -remote gateway is a standalone system.
- - -You will need to configure /etc/shorewall/interfaces and establish - your "through the tunnel" policy as shown under the first example above.
- - -Last -updated 8/20/2002 - - Tom Eastep +
In /etc/shorewall/tunnels on system B, we would have:
+ +++ ++ +
++ +TYPE +ZONE +GATEWAY +GATEWAY ZONE ++ + + +ipsec +net +206.161.148.9 ++
Note: If either of the endpoints is behind a NAT gateway
+then the tunnels file entry on the other endpoint should specify
+a tunnel type of ipsecnat rather than ipsec and the GATEWAY
+address should specify the external address of the NAT gateway.
+
You need to define a zone for the remote subnet or include + it in your local zone. In this example, we'll assume that you have created +a zone called "vpn" to represent the remote subnet.
+ +++ ++ +
++ +ZONE +DISPLAY +COMMENTS ++ + + +vpn +VPN +Remote Subnet +
At both systems, ipsec0 would be included in /etc/shorewall/interfaces +as a "vpn" interface:
+ +++ ++ +
++ +ZONE +INTERFACE +BROADCAST +OPTIONS ++ + + +vpn +ipsec0 ++ +
You will need to allow traffic between the "vpn" zone and + the "loc" zone -- if you simply want to admit all traffic in both + directions, you can use the policy file:
+ +++ ++ +
++ +SOURCE +DEST +POLICY +LOG LEVEL ++ +loc +vpn +ACCEPT ++ + + + +vpn +loc +ACCEPT ++
Once you have these entries in place, restart Shorewall (type +shorewall restart); you are now ready to configure the tunnel in FreeS/WAN .
+ +Suppose that you have a laptop system (B) that you take with you when you +travel and you want to be able to establish a secure connection back to your +local network.
+ ++ +
+ +You need to define a zone for the laptop or include it in + your local zone. In this example, we'll assume that you have created +a zone called "vpn" to represent the remote host.
+ +++ ++ +
++ +ZONE +DISPLAY +COMMENTS ++ + + +vpn +VPN +Remote Subnet +
In this instance, the mobile system (B) has IP address 134.28.54.2 +but that cannot be determined in advance. In the /etc/shorewall/tunnels file +on system A, the following entry should be made:
+ +++ ++ +
++ +TYPE +ZONE +GATEWAY +GATEWAY ZONE ++ + + +ipsec +net +0.0.0.0/0 +vpn +
Note that the GATEWAY ZONE column contains the name of the zone corresponding +to peer subnetworks. This indicates that the gateway system itself comprises +the peer subnetwork; in other words, the remote gateway is a standalone system.
+ +You will need to configure /etc/shorewall/interfaces and establish
+ your "through the tunnel" policy as shown under the first example above.
- Copyright © 2001, 2002 Thomas M. Eastep.
- + +++ In /etc/shorewall/tunnels:+ +
++ +ZONE +
+DISPLAY +
+COMMENTS +
++ +vpn1 +
+VPN-1 +
+First VPN Zone +
++ +vpn2 +
+VPN-2 +
+Second VPN Zone +
++ + + +vpn3 +
+VPN-3 +
+Third VPN Zone +
+
+
++ When Shorewall is started, the zones vpn[1-3] will all be empty and Shorewall +will issue warnings to that effect. These warnings may be safely ignored. +FreeS/Wan may now be configured to have three different Road Warrior connections +with the choice of connection being based on X-509 certificates or some other +means. Each of these connectioins will utilize a different updown script that +adds the remote station to the appropriate zone when the connection comes +up and that deletes the remote station when the connection comes down. For +example, when 134.28.54.2 connects for the vpn2 zone the 'up' part of the +script will issue the command":+ +
++ +TYPE +
+ZONE +
+GATEWAY +
+GATEWAY ZONE +
++ + + +ipsec +
+net +
+0.0.0.0/0 +
+vpn1,vpn2,vpn3 +
+
+
/sbin/shorewall add ipsec0:134.28.54.2 vpn2+ and the 'down' part will:
+
/sbin/shorewall delete ipsec0:134.28.54.2 vpn+ +
Last updated 10/23/2002 - + Tom Eastep
+ ++ Copyright © 2001, 2002 Thomas M. Eastep.
+
- Shorewall Installation and
+
+
+ |
- Shorewall Installation and Upgrade- |
+
Before upgrading, be sure to review the Upgrade Issues
- +Install using RPM
- Install using tarball
- Upgrade using RPM
- Upgrade using tarball
- 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.
- +To install Shorewall using the tarball + +
To install Shorewall using the tarball and install script:
- +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.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.
+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 +
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>).
-
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.
- -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.
- + +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.
+Updated 10/9/2002 - Tom Eastep
+
+ 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. Updated 10/28/2002 - Tom Eastep
Copyright
+
+ Copyright
© 2001, 2002 Thomas M. Eastep. Updated 10/23/2002 - Tom Eastep
+ Copyright
+ © 2001, 2002 Thomas M. Eastep. 10/9/2002 - Shorewall 1.3.9b 10/6/2002 - Shorewall.net now running on RH8.0 9/30/2002 - TUNNELS Broken in 1.3.9!!! 9/28/2002 - Shorewall 1.3.9 In this version: 11/09/2002 - Shorewall 1.3.10 In this version: 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
- Restored 9/18/2002 - Debian 1.3.8 Packages Available 10/24/2002 - Shorewall is now in Gentoo Linux 10/23/2002 - Shorewall 1.3.10 Beta 1 10/10/2002 - Debian 1.3.9b Packages Available Apt-get sources listed at http://security.dsi.unimi.it/~lorenzo/debian.html. 9/16/2002 - Shorewall 1.3.8 10/9/2002 - Shorewall 1.3.9b 10/6/2002 - Shorewall.net now running on RH8.0 9/30/2002 - TUNNELS Broken in 1.3.9!!! 9/28/2002 - Shorewall 1.3.9 In this version: 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
+ Restored 9/23/2002 - Full Shorewall Site/Mailing List Archive Search Capability
+ Restored 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 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
- (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
- reverses the order of "dhcp" and "norfc1918" checking. 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
- is now available.Configuring Shorewall
+
+
+
+
+
+
+
+
diff --git a/STABLE/documentation/MAC_Validation.html b/STABLE/documentation/MAC_Validation.html
new file mode 100644
index 000000000..427184e89
--- /dev/null
+++ b/STABLE/documentation/MAC_Validation.html
@@ -0,0 +1,107 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+ MAC Verification
+
+
+
+ Beginning with Shorewall version 1.3.10, all traffic from an interface
+or from a subnet on an interface can be verified to originate from a defined
+ set of MAC addresses. Furthermore, each MAC address may be optionally associated
+ with one or more IP addresses. There are four components to this facility.
+
+
+
+ The columns in /etc/shorewall/maclist are:
+
+
+
+
+
+Example 1: Here are my files:
+ /etc/shorewall/shorewall.conf:
+
+ MACLIST_DISPOSITION=REJECT
+ /etc/shorewall/interfaces:
MACLIST_LOG_LEVEL=info
+
+ #ZONE INTERFACE BROADCAST OPTIONS
+ /etc/shorewall/maclist:
net eth0 206.124.146.255 norfc1918,filterping,dhcp,blacklist
loc eth2 192.168.1.255 dhcp,filterping,maclist
dmz eth1 192.168.2.255 filterping
net eth3 206.124.146.255 filterping,blacklist
- texas 192.168.9.255 filterping
loc ppp+ - filterping
+
+ #INTERFACE MAC IP ADDRESSES (Optional)
+ As shown above, I use MAC Verification on my local
+ zone.
eth2 00:A0:CC:63:66:89 192.168.1.3 #Wookie
eth2 00:10:B5:EC:FD:0B 192.168.1.4 #Tarry
eth2 00:A0:CC:DB:31:C4 192.168.1.5 #Ursa
eth2 00:06:25:aa:a8:0f 192.168.1.7 #Eastept1 (Wireless)
eth2 00:04:5A:0E:85:B9 192.168.1.250 #Wap
+
+Example 2: Router in Local Zone
+ Suppose now that I add a second ethernet segment to my local zone and gateway
+ that segment via a router with MAC address 00:06:43:45:C6:15 and IP address
+ 192.168.1.253. Hosts in the second segment have IP addresses in the subnet
+ 192.168.2.0/24. I would add the following entry to my /etc/shorewall/maclist
+ file:
+
+ eth2 00:06:43:45:C6:15 192.168.1.253,192.168.2.0/24
+ This entry accomodates traffic from the router itself (192.168.1.253) and
+ from the second LAN segment (192.168.2.0/24). Remember that all traffic
+being sent to my firewall from the 192.168.2.0/24 segment will be forwarded
+by the router so that traffic's MAC address will be that of the router (00:06:43:45:C6:15)
+ and not that of the host sending the traffic.
+
+
+
+
+
+
diff --git a/STABLE/documentation/News.htm b/STABLE/documentation/News.htm
index 46a69385d..6016710da 100644
--- a/STABLE/documentation/News.htm
+++ b/STABLE/documentation/News.htm
@@ -1,1357 +1,1455 @@
-
+
-
-
-
-
-
+
-
+
+
-
-
+
+
+
+
+
- Shorewall News Archive
-
-
-
- The firewall and server here at shorewall.net are now running RedHat release
-8.0.
-
- 9/30/2002 - Shorewall 1.3.9a
-
-
-
-
-
-
-
-
-
-
-
-
-
- Hopefully these problems are now corrected.
-
-
-
-
-
-
-
- Hopefully these problems are now corrected.
-
-
-
+
+
+
+
+
+
+ You may download the Beta from:
+
+
+
+
+
+
+
+ The firewall and server here at shorewall.net are now running RedHat
+release 8.0.
+
+ 9/30/2002 - Shorewall 1.3.9a
+
+
+
+
-
-
+
+
+ Hopefully these problems are now corrected.
+
-
+
+
+
+
+
+
+
+
+
-
-
+
+
+ Hopefully these problems are now corrected.
+
+
+
+
-
-
-
-
+
+
+
+
+
+
+
+
+
8/25/2002 - Shorewall Mirror in France
- -Thanks to a Shorewall user in Paris, the Shorewall web site is now mirrored - at http://france.shorewall.net.
- + +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 - 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 - -- Shorewall 1.3.7a releasedLorenzo 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 + -- Shorewall 1.3.7a released -
- -1.3.7a corrects problems occurring in rules file processing when starting - Shorewall 1.3.7.
- + + +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 two releases.
- + +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 the latest stable -tree.
- -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 - to recent versions of Shorewall.
- + +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
+ +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 - available at 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 - Argentina. Thanks Buanzo!!!
- + +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 - new features introduced in Shorewall 1.3.2.
- + +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.
- -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.
- + +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.
+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 have been corrected - in the 1.3.1 samples.
- + +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 - features:
- + +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 - is now a Shorewall 1.2.11 - SuSE RPM available.
- + +Thanks to Stefan Mohr, there + is now a Shorewall 1.2.11 + 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. - Thanks Stefan!
- + 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 - is now a mirror of the Shorewall website at http://germany.shorewall.net.
- + +Thanks to Stefan Mohr, there + is now a mirror of the Shorewall website at 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. Corrections have also been made to the - sample scripts.
- + +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 - version of his CGI-based log parser - with corrected date handling.
- + +John Lodge has provided an updated + version of his 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 - John.
- + 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
- + +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.
- + +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.
- + +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.
- + +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.
- + +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.
- + href="mailto:lorenzo.martignoni@milug.org">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.
- + href="/pub/shorewall/errata/1.2.2/shorewall">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:
- + target="_blank">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 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
- + +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:
- -+ ++ +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 +
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.
- + target="_top">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:
- + href="ftp://ftp.shorewall.net/pub/shorewall/samples-1.1.18">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:
-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.
- -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.
- + 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.
+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 + version
+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 + version
+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 + version
+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.
- -Updated 10/9/2002 - Tom Eastep -
- -Copyright -© 2001, 2002 Thomas M. Eastep.
+ +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 11/09/2002 - Tom Eastep +
+ ++Copyright © 2001, 2002 Thomas M. Eastep.
+