.
Shorewall 1.4 Reference |
Shorewall consists of the following components:
You may use the file /etc/shorewall/params file to set shell variables that you can then use in some of the other configuration files.
It is suggested that variable names begin with an upper case letter to distinguish them from variables used internally within the Shorewall programs
Example:
NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=blacklist,norfc1918
Example (/etc/shorewall/interfaces record):
net $NET_IF $NET_BCAST $NET_OPTIONS
The result will be the same as if the record had been written
net eth0 130.252.100.255 blacklist,norfc1918
Variables may be used anywhere in the other configuration files.
This file is used to define the network zones. There is one entry in /etc/shorewall/zones for each zone; Columns in an entry are:
The /etc/shorewall/zones file released with Shorewall is as follows:
| 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.
Warning 1: If you rename or delete a zone, you should perform "shorewall stop; shorewall start" to install the change rather than "shorewall restart".
Warning 2: The order of entries in the /etc/shorewall/zones file is 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:
tcpflags (added in version 1.3.11) - This option causes Shorewall
to make sanity checks on the header flags in TCP packets arriving on this
interface. Checks include Null flags, SYN+FIN, SYN+RST and FIN+URG+PSH; these
flag combinations are typically used for "silent" port scans. Packets failing
these checks are logged according to the TCP_FLAGS_LOG_LEVEL option in /etc/shorewall/shorewall.conf and are disposed of according
to the TCP_FLAGS_DISPOSITION option.
blacklist - This option causes incoming packets
on this interface to be checked against the blacklist.
dhcp - The interface is assigned an
IP address via DHCP or is used by a DHCP server running
on the firewall. The firewall will be configured to allow
DHCP traffic to and from the interface even when the firewall
is stopped. You may also wish to use this option if you have a
static IP but you are on a LAN segment that has a lot of Laptops
that use DHCP and you select the norfc1918 option
(see below).
norfc1918 - Packets arriving on this interface and that
have a source address that is reserved in RFC 1918 or in other
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 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.
dropunclean - Packets from this interface that
are selected by the 'unclean' match target in iptables will
be optionally logged and then dropped.
Warning: This feature
requires that UNCLEAN match support be configured in your
kernel, either in the kernel itself or as a module. UNCLEAN
support is broken in some versions of the kernel
but appears to work ok in 2.4.17-rc1.
Update 12/17/2001: The
unclean match patch from 2.4.17-rc1 is
available
for download. I am currently running
this patch applied to kernel 2.4.16.
Update 12/20/2001: I've seen a number of tcp connection requests with OPT (020405B40000080A...) being dropped in the badpkt chain. This appears to be a bug in the remote TCP stack whereby it is 8-byte aligning a timestamp (TCP option 8) but rather than padding with 0x01 it is padding with 0x00. It's a tough call whether to deny people access to your servers because of this rather minor bug in their networking software. If you wish to disable the check that causes these connections to be dropped, here's a kernel patch against 2.4.17-rc2.
logunclean - This option works like dropunclean with the exception that packets selected by the 'unclean' match target in iptables are logged but not dropped. The level at which the packets are logged is determined by the setting of LOGUNCLEAN and if LOGUNCLEAN has not been set, "info" is assumed.
proxyarp (Added in version 1.3.5) - This option
causes Shorewall to set /proc/sys/net/ipv4/conf/<interface>/proxy_arp
and is used when implementing Proxy
ARP Sub-netting as described at
http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/.
Do not set this option if you are implementing
Proxy ARP through entries in
/etc/shorewall/proxyarp.
maclist (Added in version 1.3.10)
- If this option is specified, all connection requests from this
interface are subject to MAC Verification.
May only be specified for ethernet interfaces.
My recommendations concerning options:
Example 1: You have a conventional firewall setup in which eth0 connects to a Cable or DSL modem and eth1 connects to your local network and eth0 gets its IP address via DHCP. You want to check all packets entering from the internet against the black list. Your /etc/shorewall/interfaces file would be as follows:
ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,norfc1918,blacklist loc eth1 detect
Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces file would be:
ZONE INTERFACE BROADCAST OPTIONS net ppp0
Example 3: You have local interface eth1 with two IP addresses - 192.168.1.1/24 and 192.168.12.1/24
ZONE INTERFACE BROADCAST OPTIONS loc eth1 192.168.1.255,192.168.12.255
For most applications, specifying zones entirely in terms of network interfaces is sufficient. There may be times though where you need to define a zone to be a more general collection of hosts. This is the purpose of the /etc/shorewall/hosts file.
WARNING: The only times that you need
entries in /etc/shorewall/hosts are:
Columns in this file are:
- 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.
maclist - Added in version 1.3.10. If specified, connection requests from the hosts specified in this entry are subject to MAC Verification. This option is only valid for ethernet interfaces.
If you don't define any hosts for a zone, the hosts in the zone default to i0:0.0.0.0/0 , i1:0.0.0.0/0, ... where i0, i1, ... are the interfaces to the zone.
Note: You probably DON'T want to specify any hosts for your internet zone since the hosts that you specify will be the only ones that you will be able to access without adding additional rules.
Example 1:
Your local interface is eth1 and you have two groups of local hosts that you want to make into separate zones:
Your /etc/shorewall/interfaces file might look like:
ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,norfc1918 - eth1 192.168.1.127,192.168.1.255
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
Example 2:
Your local interface is eth1 and you have two groups of local hosts that you want to consider as one zone and you want Shorewall to route between them:
Your /etc/shorewall/interfaces file might look like:
ZONE INTERFACE BROADCAST OPTIONS net eth0 detect dhcp,norfc1918 loc
eth1 192.168.1.127,192.168.1.255
Your /etc/shorewall/hosts file might look like:
ZONE HOST(S) OPTIONS loc eth1:192.168.1.0/25
loc eth1:192.168.1.128/25
The /etc/shorewall/interfaces and /etc/shorewall/hosts file allow you to define nested or overlapping zones. Such overlapping/nested zones are allowed and Shorewall processes zones in the order that they appear in the /etc/shorewall/zones file. So if you have nested zones, you want the sub-zone to appear before the super-zone and in the case of overlapping zones, the rules that will apply to hosts that belong to both zones is determined by which zone appears first in /etc/shorewall/zones.
Hosts that belong to more than one zone may be managed by the rules of all of those zones. This is done through use of the special CONTINUE policy described below.
This file is used to describe the firewall policy regarding establishment of connections. Connection establishment is described in terms of clients who initiate connections and servers who receive those connection requests. Policies defined in /etc/shorewall/policy describe which zones are allowed to establish connections with other zones.
Policies established in /etc/shorewall/policy can be viewed as default policies. If no rule in /etc/shorewall/rules applies to a particular connection request then the policy from /etc/shorewall/policy is applied.
Four policies are defined:
For each policy specified in /etc/shorewall/policy, you can indicate that you want a message sent to your system log each time that the policy is applied.
Entries in /etc/shorewall/policy have four columns as follows:
In the SOURCE and DEST columns, you can enter "all" to indicate all 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
This table may be interpreted as follows:
WARNING:
The firewall script processes the /etc/shorewall/policy file from top to bottom and uses the first applicable policy that it finds. For example, in the following policy file, the policy for (loc, loc) connections would be ACCEPT as specified in the first entry even though the third entry in the file specifies REJECT.
SOURCE DEST POLICY LOG LEVEL LIMIT:BURST loc all ACCEPT
net all DROP info
loc loc REJECT info
Any time that you have multiple interfaces associated with a single zone,
you should ask yourself if you really want traffic routed between those interfaces.
Cases where you might not want that behavior are:
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 DISPLAY COMMENTS sam Sam Sam's system at home net Internet The Internet loc Loc Local Network
/etc/shorewall/interfaces:
ZONE INTERFACE BROADCAST OPTIONS - eth0 detect dhcp,norfc1918 loc eth1 detect
/etc/shorewall/hosts:
ZONE HOST(S) OPTIONS net eth0:0.0.0.0/0
sam eth0:206.191.149.197
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:
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 net zone with the exception of those in the 'sam' zone should have their connection port forwarded to 192.168.1.3. If you need to exclude more than one zone in this way, you can list the zones separated by commas (e.g., net!sam,joe,fred). This technique also may be used when the ACTION is REDIRECT.
The /etc/shorewall/rules file defines exceptions to the policies established
in the /etc/shorewall/policy file. There is one entry in
/etc/shorewall/rules for each of these rules.
Shorewall automatically enables firewall->firewall traffic over the
loopback interface (lo) -- that traffic cannot be regulated using
rules and any rule that tries to regulate such traffic will generate
a warning and will be ignored.
Entries in the file have the following columns:
The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info).
This causes the packet to be logged at the specified level prior
to being processed according to the specified ACTION. Note: if the
ACTION is LOG then you MUST specify a syslog level.
The use of DNAT or REDIRECT requires
that you have NAT enabled.
Example 1. You wish to forward all ssh connection requests from the internet to local system 192.168.1.3.
ACTION SOURCE DEST PROTO DEST
PORT(S)SOURCE
PORT(S)ORIGINAL
DESTDNAT 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
DESTREDIRECT 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
DESTACCEPT 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
DESTDNAT 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:
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 important point here is to ensure that the port range used for FTP passive connections is unique and will not overlap with any usage on the firewall system.
Example 5. You wish to allow unlimited DMZ access to the host with MAC address 02:00:08:E3:FA:55.
Example 6. You wish to allow access to the SMTP server in your DMZ from all zones.
ACTION SOURCE DEST PROTO DEST
PORT(S)SOURCE
PORT(S)ORIGINAL
DESTACCEPT loc:~02-00-08-E3-FA-55 dmz all
Example 7 (For advanced users running Shorewall version 1.3.13 or later). From the internet, you with to forward tcp port 25 directed to 192.0.2.178 and 192.0.2.179 to host 192.0.2.177 in your DMZ. You also want to allow access from the internet directly to tcp port 25 on 192.0.2.177.
ACTION
SOURCE
DEST
PROTO
DEST
PORT(S)
SOURCE
PORT(S)
ORIGINAL
DEST
ACCEPT
all
dmz
tcp
25
Note: When 'all' is used as a source or destination, intra-zone traffic is not affected. In this example, if there were two DMZ interfaces then the above rule would NOT enable SMTP traffic between hosts on these interfaces.
Using "DNAT-" rather than "DNAT" avoids two extra copies of the third rule from being generated.
ACTION
SOURCE
DEST
PROTO
DEST
PORT(S)
SOURCE
PORT(S)
ORIGINAL
DEST
DNAT-
net
dmz:192.0.2.177
tcp
25
0
192.0.2.178
DNAT-
net
dmz:192.0.2.177
tcp
25
0
192.0.2.179
ACCEPT
net
dmz:192.0.2.177
tcp
25
Look here for information on other services.
Shorewall allows definition of rules that apply between all zones. By default, these rules are defined in the file /etc/shorewall/common.def but may be modified to suit individual requirements. Rather than modify /etc/shorewall/common.def, you should copy that file to /etc/shorewall/common and modify that file.
The /etc/shorewall/common file is expected to contain iptables commands; rather than running iptables directly, you should run it indirectly using the Shorewall function 'run_iptables'. That way, if iptables encounters an error, the firewall will be safely stopped.
The /etc/shorewall/masq file is used to define classical IP Masquerading and Source Network Address Translation (SNAT). There is one entry in the file for each subnet that you want to masquerade. 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:
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 eth1. You want all local->net connections to use source address 206.124.146.176.
INTERFACE SUBNET ADDRESS eth0 192.168.10.0/24 206.124.146.176
Example 4: Same as example 3 except that you wish to exclude 192.168.10.44 and 192.168.10.45 from the SNAT rule.
Example 5 (Shorewall version >= 1.3.14): You have a second IP address (206.124.146.177) assigned to you and wish to use it for SNAT of the subnet 192.168.12.0/24. You want to give that address the name eth0:0. You must have ADD_SNAT_ALIASES=Yes in /etc/shorewall/shorewall.conf.
INTERFACE SUBNET ADDRESS eth0 192.168.10.0/24!192.168.10.44,192.168.10.45 206.124.146.176
INTERFACE SUBNET ADDRESS eth0:0 192.168.12.0/24 206.124.146.177
If you want to use proxy ARP on an entire sub-network, I suggest that you look at http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/. If you decide to use the technique described in that HOWTO, you can set the proxy_arp flag for an interface (/proc/sys/net/ipv4/conf/<interface>/proxy_arp) by including the proxyarp option in the interface's record in /etc/shorewall/interfaces. When using Proxy ARP sub-netting, you do NOT include any entries in /etc/shorewall/proxyarp.
The /etc/shorewall/proxyarp file is used to define Proxy ARP. The file is typically used for enabling Proxy ARP on a small set of systems since you need one entry in this file for each system using proxy ARP. Columns are:
Note: After you have made a change to the /etc/shorewall/proxyarp file, you may need to flush the ARP cache of all routers on the LAN segment connected to the interface specified in the EXTERNAL column of the change/added entry(s). If you are having problems communicating between an individual host (A) on that segment and a system whose entry has changed, you may need to flush the ARP cache on host A as well.
ISPs typically have ARP configured with long TTL (hours!) so if your ISPs router has a stale cache entry (as seen using "tcpdump -nei <external interface> host <IP addr>"), it may take a long while to time out. I personally have had to contact my ISP and ask them to delete a stale entry in order to restore a system to working order after changing my proxy ARP settings.
Example: You have public IP addresses 155.182.235.0/28. You configure your firewall as follows:
In your DMZ, you want to install a Web/FTP server with public address 155.186.235.4. On the Web server, you subnet just like the firewall's eth0 and you configure 155.186.235.1 as the default gateway. In your /etc/shorewall/proxyarp file, you will have:
ADDRESS INTERFACE EXTERNAL HAVEROUTE 155.186.235.4 eth2 eth0 No
Note: You may want to configure the servers in your DMZ with a subnet that is smaller than the subnet of your internet interface. See the Proxy ARP Subnet Mini HOWTO (http://www.tldp.org/HOWTO/mini/Proxy-ARP-Subnet/) for details. In this case you will want to place "Yes" in the HAVEROUTE column.
Warning: Do not use Proxy ARP and FreeS/Wan on the same system unless you are prepared to suffer the consequences. If you start or restart Shorewall with an IPSEC tunnel active, the proxied IP addresses are mistakenly assigned to the IPSEC tunnel device (ipsecX) rather than to the interface that you specify in the INTERFACE column of /etc/shorewall/proxyarp. I haven't had the time to debug this problem so I can't say if it is a bug in the Kernel or in FreeS/Wan.
You might be able to work around this problem using the following (I haven't tried it):
In /etc/shorewall/init, include:
qt service ipsec stop
In /etc/shorewall/start, include:
qt service ipsec start
The /etc/shorewall/nat file is used to define static NAT. There is one entry in the file for each static NAT relationship that you wish to define. In order to make use of this feature, you must have NAT enabled .
IMPORTANT: If all you want to do is forward ports to servers behind your firewall, you do NOT want to use static NAT. Port forwarding can be accomplished with simple entries in the rules file. Also, in most cases Proxy ARP provides a superior solution to static NAT because the internal systems are accessed using the same IP address internally and externally.
Columns in an entry are:
Look here for additional information and an example.
The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, OpenVPN and PPTP tunnels with end-points on your firewall. To use ipsec, you must install version 1.9, 1.91 or the current FreeS/WAN development snapshot.
Note: For kernels 2.4.4 and above, you will need to use version 1.91 or a development snapshot as patching with version 1.9 results in kernel compilation errors.
Instructions for setting up IPSEC tunnels may be found here, instructions for IPIP and GRE tunnels are here, instructions for OpenVPN tunnels are here, and instructions for PPTP tunnels are here.
This file is used to set the following firewall parameters:
Rules not meeting those criteria will continue to generate an individual rule for each listed port or port range.
The file /etc/shorewall/modules contains commands for loading the kernel modules required by Shorewall-defined firewall rules. Shorewall will source this file during start/restart provided that it exists and that the directory specified by the MODULESDIR parameter exists (see /etc/shorewall/shorewall.conf above).
The file that is released with Shorewall calls the Shorewall function "loadmodule" for the set of modules that I load.
The loadmodule function is called as follows:
loadmodule <modulename> [ <module parameters> ]
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:
insmod moduledirectory/<modulename>.o <module parameters>
If the file doesn't exist, the function determines of the ".o.gz" file corresponding to the module exists in the moduledirectory. If it does, the function assumes that the running configuration supports compressed modules and execute the following command:
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 .
Entries in the file have the following columns:
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.
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.
Each line in /etc/shorewall/blacklist contains an IP address, a MAC address in Shorewall Format or subnet address. Example:
130.252.100.69
206.124.146.0/24
Packets
from
hosts
listed
in
the
blacklist
file
will
be
disposed
of
according
to
the
value
assigned
to
the BLACKLIST_DISPOSITION
and BLACKLIST_LOGLEVEL variables
in
/etc/shorewall/shorewall.conf.
Only
packets
arriving
on
interfaces
that
have
the
'blacklist'
option
in
/etc/shorewall/interfaces
are
checked
against
the
blacklist. The black list is designed to
prevent listed hosts/subnets from accessing services on your
network.
Beginning with Shorewall 1.3.8, the blacklist file has three columns:
Shorewall also has a dynamic blacklist capability.
IMPORTANT: The Shorewall blacklist file is NOT designed to police your users' web browsing -- to do that, I suggest that you install and configure Squid (http://www.squid-cache.org).
This file lists the subnets affected by the norfc1918 interface option. 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.
INTERFACE HOST(S) eth2 192.168.1.0/24 eth1 -
Updated 3/21/2003 - Tom Eastep
Copyright © 2001, 2002, 2003 Thomas M. Eastep.