From cbc3ac56b12202a89e3400440f2d9979a8f2125f Mon Sep 17 00:00:00 2001 From: teastep Date: Wed, 16 Jul 2003 18:59:33 +0000 Subject: [PATCH] Add Corporate Network Example git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@664 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb --- Shorewall-docs/6to4.htm | 207 +- Shorewall-docs/CorpNetwork.htm | 293 + Shorewall-docs/Documentation.htm | 6724 +++++++++-------- Shorewall-docs/ECN.html | 138 +- Shorewall-docs/FAQ.htm | 2479 +++--- Shorewall-docs/Forum.html | 43 +- Shorewall-docs/GnuCopyright.htm | 571 +- Shorewall-docs/IPIP.htm | 385 +- Shorewall-docs/IPSEC.htm | 1382 ++-- Shorewall-docs/Install.htm | 323 +- Shorewall-docs/MAC_Validation.html | 205 +- Shorewall-docs/NAT.htm | 186 +- Shorewall-docs/News.htm | 5189 ++++++------- Shorewall-docs/OPENVPN.html | 457 +- Shorewall-docs/PPTP.htm | 1754 ++--- Shorewall-docs/ProxyARP.htm | 278 +- Shorewall-docs/SeattleInTheSpring.html | 57 +- Shorewall-docs/Shorewall_CA_html.html | 122 +- Shorewall-docs/Shorewall_CVS_Access.html | 63 +- Shorewall-docs/Shorewall_Doesnt.html | 58 +- Shorewall-docs/Shorewall_Squid_Usage.html | 956 +-- .../Shorewall_and_Aliased_Interfaces.html | 1051 +-- Shorewall-docs/Shorewall_index_frame.htm | 178 +- Shorewall-docs/Shorewall_sfindex_frame.htm | 159 +- Shorewall-docs/VPN.htm | 152 +- Shorewall-docs/blacklisting_support.htm | 104 +- Shorewall-docs/configuration_file_basics.htm | 778 +- Shorewall-docs/copyright.htm | 51 +- Shorewall-docs/dhcp.htm | 105 +- Shorewall-docs/download.htm | 302 +- Shorewall-docs/errata.htm | 537 +- Shorewall-docs/errata_1.htm | 381 +- Shorewall-docs/errata_2.htm | 842 +-- Shorewall-docs/errata_3.html | 995 ++- Shorewall-docs/fallback.htm | 129 +- Shorewall-docs/gnu_mailman.htm | 99 +- Shorewall-docs/images/CorpNetwork.gif | Bin 0 -> 49496 bytes Shorewall-docs/kernel.htm | 291 +- Shorewall-docs/mailing_list.htm | 415 +- Shorewall-docs/myfiles.htm | 343 +- Shorewall-docs/ping.html | 263 +- Shorewall-docs/ports.htm | 346 +- Shorewall-docs/quotes.htm | 188 +- Shorewall-docs/samba.htm | 200 +- Shorewall-docs/seattlefirewall_index.htm | 750 +- Shorewall-docs/shoreline.htm | 155 +- .../shorewall_extension_scripts.htm | 178 +- Shorewall-docs/shorewall_features.htm | 147 +- .../shorewall_firewall_structure.htm | 601 +- Shorewall-docs/shorewall_logging.html | 226 +- Shorewall-docs/shorewall_mirrors.htm | 119 +- Shorewall-docs/shorewall_prerequisites.htm | 101 +- Shorewall-docs/shorewall_quickstart_guide.htm | 483 +- Shorewall-docs/shorewall_setup_guide.htm | 4617 +++++------ Shorewall-docs/sourceforge_index.htm | 780 +- Shorewall-docs/standalone.htm | 650 +- Shorewall-docs/standalone_fr.html | 786 +- .../starting_and_stopping_shorewall.htm | 498 +- Shorewall-docs/support.htm | 456 +- Shorewall-docs/three-interface.htm | 1991 ++--- Shorewall-docs/three-interface_fr.html | 2087 ++--- Shorewall-docs/traffic_shaping.htm | 534 +- Shorewall-docs/troubleshoot.htm | 338 +- Shorewall-docs/two-interface.htm | 1647 ++-- Shorewall-docs/two-interface_fr.html | 2055 ++--- Shorewall-docs/upgrade_issues.htm | 767 +- Shorewall-docs/useful_links.html | 59 +- .../whitelisting_under_shorewall.htm | 573 +- 68 files changed, 25528 insertions(+), 24849 deletions(-) create mode 100644 Shorewall-docs/CorpNetwork.htm create mode 100644 Shorewall-docs/images/CorpNetwork.gif diff --git a/Shorewall-docs/6to4.htm b/Shorewall-docs/6to4.htm index 13c232288..c7410c168 100755 --- a/Shorewall-docs/6to4.htm +++ b/Shorewall-docs/6to4.htm @@ -1,142 +1,143 @@ - + 6to4 Tunnels - + - + - + - - - + + - - - + + + +
+ id="AutoNumber1" bgcolor="#3366ff" height="90"> +

6to4 Tunnels

-
- +

The 6to4 tunnel documentation is provided by Eric de Thouars.
-

- -

Warning: The 6to4 tunnel feature of Shorewall -only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 security -measures.

- -

6to4 tunneling with Shorewall can be used to connect your IPv6 network -to another IPv6 network over an IPv4 infrastructure

- + + +

Warning: The 6to4 tunnel feature of Shorewall + only facilitates IPv6 over IPv4 tunneling. It does not provide any IPv6 +security measures.

+ +

6to4 tunneling with Shorewall can be used to connect your IPv6 network + to another IPv6 network over an IPv4 infrastructure

+

More information on Linux and IPv6 can be found in the Linux IPv6 HOWTO. Details -on how to setup a 6to4 tunnels are described in the section Setup - of 6to4 tunnels.

- + href="http://www.tldp.org/HOWTO/Linux+IPv6-HOWTO">Linux IPv6 HOWTO. +Details on how to setup a 6to4 tunnels are described in the section Setup + of 6to4 tunnels.

+

Connecting two IPv6 Networks

- +

Suppose that we have the following situation:

- +

-

- -

We want systems in the 2002:100:333::/64 subnetwork to be -able to communicate with the systems in the 2002:488:999::/64 network. This -is accomplished through use of the /etc/shorewall/tunnels file and the "ip" -utility for network interface and routing configuration.

- -

Unlike GRE and IPIP tunneling, the /etc/shorewall/policy, -/etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There -is no need to declare a zone to represent the remote IPv6 network. This remote -network is not visible on IPv4 interfaces and to iptables. All that is visible -on the IPv4 level is an IPv4 stream which contains IPv6 traffic. Separate -IPv6 interfaces and ip6tables rules need to be defined to handle this traffic. -

- +

+ +

We want systems in the 2002:100:333::/64 subnetwork to be + able to communicate with the systems in the 2002:488:999::/64 network. This + is accomplished through use of the /etc/shorewall/tunnels file and the "ip" + utility for network interface and routing configuration.

+ +

Unlike GRE and IPIP tunneling, the /etc/shorewall/policy, + /etc/shorewall/interfaces and /etc/shorewall/zones files are not used. There + is no need to declare a zone to represent the remote IPv6 network. This +remote network is not visible on IPv4 interfaces and to iptables. All that +is visible on the IPv4 level is an IPv4 stream which contains IPv6 traffic. + Separate IPv6 interfaces and ip6tables rules need to be defined to handle +this traffic.

+

In /etc/shorewall/tunnels on system A, we need the following:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
TYPEZONEGATEWAYGATEWAY ZONE
6to4net134.28.54.2 
6to4net134.28.54.2 
-
- -

This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6 +

+ +

This entry in /etc/shorewall/tunnels, opens the firewall so that the IPv6 encapsulation protocol (41) will be accepted to/from the remote gateway.

- +

Use the following commands to setup system A:

- -
+ +

>ip tunnel add tun6to4 mode sit ttl 254 remote 134.28.54.2
- >ip link set dev tun6to4 up
- >ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4
- >ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2

-
- + >ip link set dev tun6to4 up
+ >ip addr add 3ffe:8280:0:2001::1/64 dev tun6to4
+ >ip route add 2002:488:999::/64 via 3ffe:8280:0:2001::2

+
+

Similarly, in /etc/shorewall/tunnels on system B we have:

- -
+ +
- + + + + + + + - - - - - - - - - - - - - + + + + + + +
TYPEZONEGATEWAYGATEWAY ZONE
TYPEZONEGATEWAYGATEWAY ZONE
6to4net206.191.148.9 
6to4net206.191.148.9 
-
- +
+

And use the following commands to setup system B:

- -
+ +

>ip tunnel add tun6to4 mode sit ttl 254 remote 206.191.148.9
- >ip link set dev tun6to4 up
- >ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4
- >ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1

-
- -

On both systems, restart Shorewall and issue the configuration commands -as listed above. The systems in both IPv6 subnetworks can now talk to each -other using IPv6.

- -

Updated 5/18/2003 - Tom Eastep + >ip link set dev tun6to4 up
+ >ip addr add 3ffe:8280:0:2001::2/64 dev tun6to4
+ >ip route add 2002:100:333::/64 via 3ffe:8280:0:2001::1

+
+ +

On both systems, restart Shorewall and issue the configuration commands + as listed above. The systems in both IPv6 subnetworks can now talk to each + other using IPv6.

+ +

Updated 5/18/2003 - Tom Eastep

- +

Copyright © 2001, 2002, 2003Thomas M. Eastep and Eric de Thouars.

-
+
+


diff --git a/Shorewall-docs/CorpNetwork.htm b/Shorewall-docs/CorpNetwork.htm new file mode 100644 index 000000000..bc3e07e75 --- /dev/null +++ b/Shorewall-docs/CorpNetwork.htm @@ -0,0 +1,293 @@ + + + + + + Corporate Shorewall Configuration + + + + + + + + + + + + + + + + + + + + +
+ +

Multiple IPs with DMZ and + Internal Servers

+
+ +
+ +

Corporate Network

+ +

Notes:

+ +
+
    +
  • This configuration is used on a corporate network that + has a Linux (RedHat 8.0) server with three interfaces, running Shorewall + 1.4.5 release,
    • +
  • Make sure you know what public IP addresses are currently +being used and verify these before starting.
    • +
  • Verify you DNS settings before starting any +Shorewall configuration especially if you have split DNS.
    • +
  • System names and Internet IP addresses have been changed +to protect the innocent.
    • + +
+ +

Warning: This configuration +uses a combination of Static NAT and Proxy ARP. This is generally not + relevant to a simple configuration with a single public IP address. + If you have just a single public IP address, most of what you see +here won't apply to your setup so beware of copying parts of this +configuration and expecting them to work for you. What you copy may +or may not work in your configuration.
+
+

+ +

I have a T1 with 64 static IP addresses (63.123.106.65-127/26). The + internet is connected to eth0. The local network is connected via eth1 + (10.10.0.0/22) and the DMZ is connected to eth2 (192.168.21.0/24). I +have an IPSec tunnel connecting our offices in Germany to our offices +in the US. I host two Microsoft Exchange servers for two different companies +behind the firewall hence, the two Exchange servers in the diagram below.

+ +

Summary:
+

+ +
    +
  • SNAT for all systems connected to the LAN +- Internal addresses 10.10.x.x to external address 63.123.106.127.
    • +
  • Static NAT for Polaris (Exchange Server + #2). Internal address 10.10.1.8 and external address 63.123.106.70.
    • +
  • Static NAT for Sims (Inventory Management server). + Internal address 10.10.1.56 and external address 63.123.106.75.
    +
    • +
  • Static NAT for Project (Project Web + Server). Internal address 10.10.1.55 and external + address 63.123.106.84.
    • +
  • Static NAT for Fortress (Exchange +Server). Internal address 10.10.1.252 and external +address 63.123.106.93.
    • +
  • Static NAT for BBSRV (Blackberry Server). + Internal address 10.10.1.230 and external address + 63.123.106.97.
    • +
  • Static NAT for Intweb (Intranet Web + Server). Internal address 10.10.1.60 and external + address 63.123.106.115.
    • + +
+ +

The firewall runs on a 2Gb, Dual PIV/2.8GHz, Intel motherboard with + RH8.0.

+ +

The Firewall is also a proxy server running Privoxy 3.0.

+ +

The single system in the DMZ (address 63.123.106.80) runs sendmail, + imap, pop3, DNS, a Web server (Apache) and an FTP server (vsFTPd 1.1.0). + That server is managed through Proxy ARP.

+ +

All administration and publishing is done using ssh/scp. I have X installed + on the firewall and the system in the DMZ. X applications tunnel + through SSH to Hummingbird Exceed running on a PC located in the LAN. + Access to the firewall using SSH is restricted to systems in the LAN, DMZ +or the system Kaos which is on the Internet and managed by me.

+ +

(Corporate Network Diagram) +

+ +

+ +

The Ethernet 0 interface in the Server is configured with IP + address 63.123.106.68, netmask 255.255.255.192. The server's default + gateway is 63.123.106.65, the Router connected to my network and +the ISP. This is the same default gateway used by the firewall + itself. On the firewall, Shorewall automatically + adds a host route to 63.123.106.80 through Ethernet + 2 (192.168.21.1) because of the entry in +/etc/shorewall/proxyarp (see below). I modified the start, stop and +init scripts to include the fixes suggested when having an IPSec tunnel.

+ +

Some Mistakes I Made:

+ +

Yes, believe it or not, I made some really basic mistakes when building + this firewall. Firstly, I had the new firewall setup in parallel with +the old firewall so that there was no interruption of service to my users. + During my out-bound testing, I set up systems on the LAN to utilize the + firewall which worked fine. When testing my NAT connections, from the +outside, these would fail and I could not understand why. Eventually, +I changed the default route on the internal system I was trying to access, +to point to the new firewall and "bingo", everything worked as expected. +This oversight delayed my deployment by a couple of days not to mention +level of frustration it produced.

+ +

Another problem that I encountered was in setting up the Proxyarp system + in the DMZ. Initially I forgot to remove the entry for the eth2 from +the /etc/shorewall/masq file. Once my file settings were correct, I started + verifying that the ARP caches on the firewall, as well as the outside +system "kaos", were showing the correct Ethernet MAC address. However, +in testing remote access, I could access the system in the DMZ only from +the firewall and LAN but not from the Internet. The message I received +was "connection denied" on all protocols. What I did not realize was that +a "helpful" administrator that had turned on an old system and assigned +the same address as the one I was using for Proxyarp without notifying +me. How did I work this out. I shutdown the system in the DMZ, rebooted +the router and flushed the ARP cache on the firewall and kaos. Then, from +kaos, I started pinging that IP address and checked the updated ARP cache +and lo-and-behold a different MAC address showed up. High levels of frustration +etc., etc. The administrator will not be doing that again! :-)

+ +

Lessons Learned:

+ +
    +
  • Read the documentation.
    • +
  • Draw your network topology before starting.
    • +
  • Understand what services you are going to allow in and out of + the firewall, whether they are TCP or UDP packets and make a note +of these port numbers.
    • +
  • Try to get quiet time to build the firewall - you need to focus + on the job at hand.
    • +
  • When asking for assistance, be honest and include as much detail + as requested. Don't try and hide IP addresses etc., you will probably + screw up the logs and make receiving assistance harder.
    • +
  • Read the documentation.
    • + +
+ +

Futures:

+ +

This is by no means the final configuration. In the near future, I will + be moving more systems from the LAN to the DMZ. I will also be watching + the logs for port scan programs etc. but, this should be standard security + maintenance.

+ +

Here are copies of my files. I have removed most of the internal +documentation for the purpose of this space however, my system still has +the original files with all the comments and I highly recommend you do +the same.

+ +
+ +

Shorewall.conf

+ +
+ 
##############################################################################
# /etc/shorewall/shorewall.conf V1.4 - Change the following variables to
# match your setup
#
# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm]
#
# This file should be placed in /etc/shorewall
#
# (c) 1999,2000,2001,2002,2003 - Tom Eastep (teastep@shorewall.net)
##############################################################################
# L O G G I N G
##############################################################################
LOGFILE=/var/log/messages
LOGFORMAT="Shorewall:%s:%s:"
LOGRATE=
LOGBURST=
LOGUNCLEAN=info
BLACKLIST_LOGLEVEL=
LOGNEWNOTSYN=
MACLIST_LOG_LEVEL=info
TCP_FLAGS_LOG_LEVEL=debug
RFC1918_LOG_LEVEL=debug
PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
SUBSYSLOCK=/var/lock/subsys/shorewall
STATEDIR=/var/lib/shorewall
MODULESDIR=
FW=fw
NAT_ENABLED=Yes
MANGLE_ENABLED=Yes
IP_FORWARDING=On
ADD_IP_ALIASES=Yes
ADD_SNAT_ALIASES=Yes
TC_ENABLED=Yes
CLEAR_TC=No
MARK_IN_FORWARD_CHAIN=No
CLAMPMSS=No
ROUTE_FILTER=Yes
NAT_BEFORE_RULES=No
MULTIPORT=Yes
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
NEWNOTSYN=Yes
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=REJECT
TCP_FLAGS_DISPOSITION=DROP
#LAST LINE -- DO NOT REMOVE

+
+ +

Zones File

+ +
+ 
#
# Shorewall 1.4 -- Sample Zone File For Two Interfaces
# /etc/shorewall/zones
#
# This file determines your network zones. Columns are:
#
# ZONE Short name of the zone
# DISPLAY Display name of the zone
# COMMENTS Comments about the zone
#
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local Networks
dmz DMZ Demilitarized Zone
vpn1 VPN1 VPN to Germany
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+ +

Interfaces File:

+ +
+

##############################################################################
+ #ZONE INTERFACE BROADCAST OPTIONS
+ net eth0 62.123.106.127 routefilter,norfc1918,blacklist,tcpflags
+ loc eth1 detect dhcp,routefilter
+ dmz eth2 detect
+ vpn1 ipsec0
+ #LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE +

+
+ +

Routestopped File:

+ +
+ 
#INTERFACE HOST(S)
eth1 -
eth2 -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+ +

Policy File:

+ +
+ 
###############################################################################
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
loc fw ACCEPT
loc dmz ACCEPT
# If you want open access to the Internet from your Firewall 
# remove the comment from the following line.
fw net ACCEPT
fw loc ACCEPT
fw dmz ACCEPT
dmz fw ACCEPT
dmz loc ACCEPT
dmz net ACCEPT
# 
# Adding VPN Access
loc vpn1 ACCEPT
dmz vpn1 ACCEPT
fw vpn1 ACCEPT
vpn1 loc ACCEPT
vpn1 dmz ACCEPT
vpn1 fw ACCEPT
#
net all DROP info
all all REJECT info
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+ +

Masq File:

+ +
+ 
#INTERFACE SUBNET ADDRESS
eth0 eth1 163.123.106.126
#
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+ +

NAT File:

+ +
+ 
#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
#
# Intranet Web Server
63.123.106.115 eth0:0 10.10.1.60 No No
#
# Project Web Server
63.123.106.84 eth0:1 10.10.1.55 No No
#
# Blackberry Server
63.123.106.97 eth0:2 10.10.1.55 No No
#
# Corporate Mail Server
63.123.106.93 eth0:3 10.10.1.252 No No
#
# Second Corp Mail Server
63.123.106.70 eth0:4 10.10.1.8 No No
#
# Sims Server
63.123.106.75 eth0:5 10.10.1.56 No No
#
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
+
+ +

Proxy ARP File:

+ +
+ 
#ADDRESS INTERFACE EXTERNAL HAVEROUTE
#
# The Corporate email server in the DMZ
63.123.106.80 eth2 eth0 No
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+ +

Tunnels File:

+ +
+ 
# TYPE ZONE GATEWAY GATEWAY ZONE PORT
ipsec net 134.147.129.82
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+ +

Rules File (The shell variables are set in /etc/shorewall/params):

+ +
+ 
##############################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
#
# Accept DNS connections from the firewall to the network
#
ACCEPT fw net tcp 53
ACCEPT fw net udp 53
#
# Accept SSH from internet interface from kaos only
#
ACCEPT net:63.123.106.98 fw tcp 22
#
# Accept connections from the local network for administration 
#
ACCEPT loc fw tcp 20:22
ACCEPT loc net tcp 22
ACCEPT loc fw tcp 53
ACCEPT loc fw udp 53
ACCEPT loc net tcp 53
ACCEPT loc net udp 53
#
# Allow Ping To And From Firewall
#
ACCEPT loc fw icmp 8
ACCEPT loc dmz icmp 8
ACCEPT loc net icmp 8
ACCEPT dmz fw icmp 8
ACCEPT dmz loc icmp 8
ACCEPT dmz net icmp 8
DROP net fw icmp 8
DROP net loc icmp 8
DROP net dmz icmp 8
ACCEPT fw loc icmp 8
ACCEPT fw dmz icmp 8
DROP fw net icmp 8
#
# Accept proxy web connections from the inside
#
ACCEPT loc fw tcp 8118
#
# Forward PcAnywhere, Oracle and Web traffic from outside to the Demo systems
# From a specific IP Address on the Internet.
# 
# ACCEPT net:207.65.110.10 loc:10.10.3.151 tcp 1521,http
# ACCEPT net:207.65.110.10 loc:10.10.2.32 tcp 5631:5632
#
# Intranet web server
ACCEPT net loc:10.10.1.60 tcp 443
ACCEPT dmz loc:10.10.1.60 tcp 443
#
# Projects web server
ACCEPT net loc:10.10.1.55 tcp 80
ACCEPT dmz loc:10.10.1.55 tcp 80
# 
# Blackberry Server
ACCEPT net loc:10.10.1.230 tcp 3101
#
# Corporate Email Server
ACCEPT net loc:10.10.1.252 tcp 25,53,110,143,443
#
# Corporate #2 Email Server
ACCEPT net loc:10.10.1.8 tcp 25,80,110,443
#
# Sims Server
ACCEPT net loc:10.10.1.56 tcp 80,443
ACCEPT net loc:10.10.1.56 tcp 7001:7002
ACCEPT net:63.83.198.0/24 loc:10.10.1.56 tcp 5631:5632
#
# Access to DMZ
ACCEPT loc dmz udp 53,177
ACCEPT loc dmz tcp 80,25,53,22,143,443,993,20,110 -
ACCEPT net dmz udp 53
ACCEPT net dmz tcp 25,53,22,21,123
ACCEPT dmz net tcp 25,53,80,123,443,21,22
ACCEPT dmz net udp 53
#
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
+
+ +

Start File:

+ +
+ 
############################################################################
# Shorewall 1.4 -- /etc/shorewall/start
#
# Add commands below that you want to be executed after shorewall has
# been started or restarted.
#
qt service ipsec start
+
+ +

Stop File:

+ +
+ 
############################################################################
# Shorewall 1.4 -- /etc/shorewall/stop
#
# Add commands below that you want to be executed at the beginning of a
# "shorewall stop" command.
#
qt service ipsec stop
+
+ +

Init File:

+ +
+ 
############################################################################
# Shorewall 1.4 -- /etc/shorewall/init
#
# Add commands below that you want to be executed at the beginning of
# a "shorewall start" or "shorewall restart" command.
#
qt service ipsec stop
+
+ +

Last updated 7/16/2003 +
+

+ +

Copyright 2003 Thomas M. Eastep and +Graeme Boyle
+

+
+ + + diff --git a/Shorewall-docs/Documentation.htm b/Shorewall-docs/Documentation.htm index c0f8ce32a..737efb0d7 100644 --- a/Shorewall-docs/Documentation.htm +++ b/Shorewall-docs/Documentation.htm @@ -2,3462 +2,3480 @@ - + - + - + Shorewall 1.4 Documentation - - + + - + - + - + - - - + + - + + - - -
+ bgcolor="#3366ff" height="90"> +
- +

Shorewall 1.4 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

- -

Shorewall consists of the following components:

- - - -

/etc/shorewall/params

- -

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.

- -

/etc/shorewall/zones

- -

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
netNetInternet
locLocalLocal - networks
dmzDMZDemilitarized - 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.

- -

/etc/shorewall/interfaces

- -

This file is used to tell the firewall which of your firewall's network - interfaces are connected to which zone. There - will be one entry in /etc/shorewall/interfaces for each - of your interfaces. Columns in an entry are:

- + +

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

+ +

Shorewall consists of the following components:

+ + +

/etc/shorewall/params

+ +

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.

+ +

/etc/shorewall/zones

+ +

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
netNetInternet
locLocalLocal + networks
dmzDMZDemilitarized + 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.

+ +

/etc/shorewall/interfaces

+ +

This file is used to tell the firewall which of your firewall's network + interfaces are connected to which zone. There + will be one entry in /etc/shorewall/interfaces for +each of your interfaces. Columns in an entry are:

+ + - +

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:

- -
- + +

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
neteth0detectdhcp,norfc1918,blacklist
loceth1detect
-
+ ZONE + INTERFACE + BROADCAST + OPTIONS
neteth0detectdhcp,norfc1918,blacklist
loceth1detect
+
-
- -

Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces - file would be:

- -
- +
+ +

Example 2: You have a standalone dialup GNU/Linux System. Your /etc/shorewall/interfaces + file would be:

+ +
+ - + - - - - - - - - - - - - + + + + + + + + + + + + - - - + + +
-ZONE -INTERFACE -BROADCAST -OPTIONS
netppp0
-
-
+ ZONE + INTERFACE + BROADCAST + OPTIONS
netppp0
+
+
-
- -

Example 3: You have local interface eth1 with two IP addresses - +

+ +

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
loceth1192.168.1.255,192.168.12.255
-
+ ZONE + INTERFACE + BROADCAST + OPTIONS
loceth1192.168.1.255,192.168.12.255
+
-
+
+ +

/etc/shorewall/hosts + 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: The only times that you need +entries in /etc/shorewall/hosts are:
+

-

/etc/shorewall/hosts - 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: The only times that you need entries -in /etc/shorewall/hosts are:
-

-
    -
  1. You have more than one zone connecting through +
  2. You have more than one zone connecting through a single interface; or
    3. -
  3. You have a zone that has multiple subnetworks - that connect through a single interface and you want the Shorewall - box to route traffic between those subnetworks.
    -
    4. - +
  4. You have a zone that has multiple subnetworks + that connect through a single interface and you want the Shorewall + box to route traffic between those subnetworks.
    +
    5. +
- IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN -DON'T TOUCH THIS FILE!! + IF YOU DON'T HAVE EITHER OF THOSE SITUATIONS THEN + DON'T TOUCH THIS FILE!!

Columns in this file are:

- +
    -
  • ZONE - - A zone defined in the /etc/shorewall/zones +
  • ZONE + - A zone defined in the /etc/shorewall/zones file.
    • -
  • HOST(S) - - The name of a network interface followed by a colon +
  • HOST(S) + - The name of a network interface followed by a colon (":") followed by a comma-separated list either:
    • - +
- -
- + +
+
    -
  1. An - IP address (example - eth1:192.168.1.3)
    2. -
  2. A - subnet in CIDR notation (example - - eth2:192.168.2.0/24)
    3. - +
  3. An IP address (example - eth1:192.168.1.3)
    4. + +
  4. A subnet in CIDR notation + (example - eth2:192.168.2.0/24)
    5. + +
- -

The interface name much match an entry in /etc/shorewall/interfaces.
-

-

Warning: If you are running a -version of Shorewall earlier than 1.4.6, only a single host/subnet address -may be specified in an entry in /etc/shorewall/hosts.
-

-
- -
    -
  • OPTIONS - - A comma-separated list of option
    • - -
- -
- -

routeback (Added in version 1.4.2) - This option causes Shorewall - to set up handling for routing packets sent by this host group -back back to the same group.
-
- 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:

- -
    -
  • 192.168.1.0/25 -
    • -
  • 192.168.1.128/
    • - -
- -

Your /etc/shorewall/interfaces file might look like:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
-ZONE -INTERFACE -BROADCAST -OPTIONS
neteth0detectdhcp,norfc1918
-eth1192.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
loc1eth1:192.168.1.0/25
-
loc2eth1: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:

- -
    -
  • 192.168.1.0/25
    • -
  • 192.168.1.128/25
    • - -
- -

Your /etc/shorewall/interfaces file might look like:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - -
-ZONE -INTERFACE -BROADCAST -OPTIONS
neteth0detectdhcp,norfc1918
loc
- 		eth1192.168.1.127,192.168.1.255
-
-
-
- -

Your /etc/shorewall/hosts file might look like:

- -
- - - - - - - - - - - - - - - - - - - - - - - - -
-ZONE -HOST(S) -OPTIONS
loceth1:192.168.1.0/25
-
loceth1:192.168.1.128/25
-
-
- If you are running Shorewall -1.4.6 or later, your hosts file may look like:
-
- - - - - - - - - - - - - - - - - - -
-ZONE -HOST(S) -OPTIONS
loceth1:192.168.1.0/25,192.168.1.128/25
-
-
-
-

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.
    • -
  • NONE - (Added in version 1.4.1) - Shorewall - should not set up any infrastructure for handling traffic from the - SOURCE zone to the DEST zone. When this policy is specified, the LOG - LEVEL and BURST:LIMIT columns must be left - blank.
    -
    • - -
- -

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:

- -
    - -
  1. SOURCE - The name of a client - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall - zone or "all").
    2. - -
  2. DEST - The name of a destination - zone (a zone defined in the /etc/shorewall/zones - file , the name of the firewall - zone or "all"). Shorewall automatically allows all traffic - from the firewall to itself so the name of the -firewall zone cannot appear in both the SOURCE and DEST columns.
    3. - -
  3. POLICY - The default policy - for connection requests from the SOURCE zone to the DESTINATION - zone.
    4. - -
  4. 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.
    5. - -
  5. 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.
    6. - -
- -

In the SOURCE and DEST columns, you can enter "all" to indicate all - zones.

- -

The policy file installed by default is as follows:

- -
- +

The interface name much match an entry in /etc/shorewall/interfaces.
+

+ +

Warning: If you are running a +version of Shorewall earlier than 1.4.6, only a single host/subnet address +may be specified in an entry in /etc/shorewall/hosts.
+

+
+ +
    +
  • OPTIONS + - A comma-separated list of option
    • + +
+ +
+ +

routeback (Added in version 1.4.2) - This option causes Shorewall + to set up handling for routing packets sent by this host group back + back to the same group.
+
+ 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:

+ +
    +
  • 192.168.1.0/25 +
    • +
  • 192.168.1.128/
    • + +
+ +

Your /etc/shorewall/interfaces file might look like:

+ +
+ - + - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
SOURCEDEST -POLICY -LOG LEVELLIMIT:BURST
locnetACCEPT
-
-
+ ZONE + INTERFACE + BROADCAST + OPTIONS
neteth0detectdhcp,norfc1918
-eth1192.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
loc1eth1:192.168.1.0/25
+
netallDROPinfo
-
allallREJECTinfo
-
-
- -

This table may be interpreted as follows:

- -
    -
  • All connection - requests from the local network to hosts on the - internet are accepted.
    • -
  • All connection - requests originating from the internet are ignored -and logged at level KERNEL.INFO.
    • -
  • All other connection - requests are rejected and logged.
    • - -
- -

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.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
SOURCEDESTPOLICYLOG -LEVELLIMIT:BURST
locallACCEPT
-
-
netallDROPinfo
-
loclocREJECTinfo
-
-
- -

IntraZone Traffic

- Shorewall allows a zone to be associated with more than - one interface or with multiple networks that interface through -a single interface. Beginning with Shorewall 1.4.1, Shorewall will -ACCEPT all traffic from a zone to itself provided that there is no -explicit policy governing traffic from that zone to itself (an explicit -policy does not specify "all" in either the SOURCE or DEST column) -and that there are no rules concerning connections from that zone to -itself. If there is an explicit policy or if there are one or more rules, -then traffic within the zone is handled just like traffic between zones -is.
- -

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:
-

- -
    -
  1. Multiple 'net' interfaces to different ISPs. You - don't want to route traffic from one ISP to the other through your - firewall.
    2. -
  2. Multiple VPN clients. You don't necessarily want - them to all be able to communicate between themselves using your gateway/router.
    -
    3. - -
- -

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:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
-ZONE -DISPLAY -COMMENTS
samSamSam's - system at home
netInternetThe Internet
locLocLocal - Network
-
- -

/etc/shorewall/interfaces:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
-ZONE -INTERFACE -BROADCAST -OPTIONS
-eth0detectdhcp,norfc1918
loceth1detect
-
-
- -

/etc/shorewall/hosts:

- -
- - - - - - - - - - - - - - - - - - - - - - -
-ZONE -HOST(S) -OPTIONS
neteth0:0.0.0.0/0
-
sameth0: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
locnetACCEPT
-
samallCONTINUE
-
netallDROPinfo
allallREJECTinfo
-
- -

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:

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
...
-
-
-
-
-
-
DNATsamloc:192.168.1.3tcpssh-
-
DNATnetloc:192.168.1.5tcpwww-
-
...
-
-
-
-
-
-
-
- -

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:

- -
- -

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST

-
-
-
-
-
-
-
...
-
-
-
-
-
-
DNATsamfwtcpssh-
-
DNATnet!samloc:192.168.1.3tcpssh-
-
...
-
-
-
-
-
-
-
- -

The first rule allows Sam SSH access to the firewall. The second - rule says that any clients from the net zone - with the exception of those in the -'sam' zone should have their - connection port forwarded to - 192.168.1.3. If you need to exclude - more than one zone in this way, you - can list the zones separated - by commas (e.g., net!sam,joe,fred). - This technique also may be used when - the ACTION is REDIRECT.

- -

/etc/shorewall/rules

- -

The /etc/shorewall/rules file defines exceptions to the policies established - in the /etc/shorewall/policy file. There is one - entry in /etc/shorewall/rules for each of these rules. -
-

- -

Shorewall automatically enables firewall->firewall traffic over the - loopback interface (lo) -- that traffic cannot be regulated - using rules and any rule that tries to regulate such traffic - will generate a warning and will be ignored.
-

- -

Entries in the file have the following columns:

- -
    -
  • ACTION - - -
      -
    • ACCEPT, DROP, - REJECT, CONTINUE. These have the same meaning here as - in the policy file above.
      • -
    • DNAT -- Causes - the connection request to be forwarded to the system - specified in the DEST column (port forwarding). "DNAT" - stands for "Destination Network - Address Translation"
      • -
    • DNAT- -- The above ACTION - (DNAT) generates two iptables rules: 1) and header-rewriting - rule in the Netfilter 'nat' table and; 2) an ACCEPT rule -in the Netfilter 'filter' table. DNAT- works like DNAT but only -generates the header-rewriting rule.
      -
      • -
    • REDIRECT -- - Causes the connection request to be redirected to -a port on the local (firewall) system.
      • -
    • REDIRECT- -- The above ACTION (REDIRECT) generates - two iptables rules: 1) and header-rewriting rule in the Netfilter - 'nat' table and; 2) an ACCEPT rule in the Netfilter 'filter' - table. REDIRECT- works like REDIRECT but only generates the header-rewriting - rule.
      -
      • -
    • LOG - Log the packet -- requires a syslog - level (see below).
      • - - -
    - - -

    The ACTION may optionally be followed by ":" and a syslog level (example: REJECT:info). This -causes the packet to be logged at the specified level prior to being -processed according to the specified ACTION. Note: if the ACTION -is LOG then you MUST specify a syslog level.
    -
    - The use of DNAT -or REDIRECT requires that you have NAT enabled.
    -

    -
    • -
  • SOURCE -- Describes the source hosts to which the rule applies.. - The contents of this field must begin with the -name of a zone defined in /etc/shorewall/zones, $FW or "all". - If the ACTION is DNAT or REDIRECT, sub-zones may be excluded - from the rule by following the initial zone name with "!' - and a comma-separated list of those sub-zones to be excluded. - There is an example above.
    -
    - If the source is -not 'all' then the source may be further restricted by -adding a colon (":") followed by a comma-separated list -of qualifiers. Qualifiers are may include: - - -
      -
    • An interface - name - refers to any connection requests arriving on - the specified interface (example loc:eth4). Beginning - with Shorwall 1.3.9, the interface name may optionally be followed - by a colon (":") and an IP address or subnet (examples: loc:eth4:192.168.4.22, - net:eth0:192.0.2.0/24).
      • -
    • An IP address - - refers to a connection request from the host with - the specified address (example net:155.186.235.151). - If the ACTION is DNAT, this must not be a DNS name.
      • -
    • A MAC Address - in Shorewall -format.
      • -
    • A subnet - -refers to a connection request from any host in the - specified subnet (example net:155.186.235.0/24).
      • - - -
    -
    • -
  • DEST -- Describes the destination host(s) to which the rule - applies. May take most of the forms described above for - SOURCE plus the following two additional forms: - - -
      -
    • An IP address - followed by a colon and the port number - that the server is listening on (service names from -/etc/services are not allowed - example loc:192.168.1.3:80). -
      -
      • -
    • A single port - number (again, service names are not allowed) -- - this form is only allowed if the ACTION is REDIRECT and refers - to a server running on the firewall itself and listening - on the specified port.
      • - - -
    - Restrictions:
    - - -
      -
    • MAC addresses may not be specified.
      • -
    • In DNAT rules, only IP addresses may be -given -- DNS names are not permitted.
      • -
    • You may not specify both an IP address and - an interface name in the DEST column.
      • - - -
    - Unlike in the SOURCE column, a range of IP addresses may be specified - in the DEST column as <first address>-<last address>. - When the ACTION is DNAT or DNAT-, connections will be assigned -to the addresses in the range in a round-robin fashion (load-balancing).
    -
    • -
  • PROTO - - Protocol. Must be a protocol name from /etc/protocols, - a number or "all". Specifies the protocol of the connection - request.
    • -
  • DEST - PORT(S) - Port or port range (<low port>:<high - port>) being connected to. May only be specified - if the protocol is tcp, udp or icmp. For icmp, this -column's contents are interpreted as an icmp type. If you - don't want to specify DEST PORT(S) but need to include information - in one of the columns to the right, enter "-" in this column. - You may give a list of ports and/or port ranges separated by -commas. Port numbers may be either integers or service names from -/etc/services.
    • -
  • SOURCE - PORTS(S) - May be used to restrict the - rule to a particular client port or port range (a port -range is specified as <low port number>:<high - port number>). If you don't want to restrict client ports but - want to specify something in the next column, enter "-" in -this column. If you wish to specify a list of port number - or ranges, separate the list elements with commas (with -no embedded white space). Port numbers may be either integers - or service names from /etc/services.
    • -
  • ORIGINAL -DEST - This column may only be non-empty if the - ACTION is DNAT or REDIRECT.
    -
    - If DNAT or REDIRECT - is the ACTION and the ORIGINAL DEST column is left -empty, any connection request arriving at the firewall - from the SOURCE that matches the rule will be forwarded - or redirected. This works fine for connection requests -arriving from the internet where the firewall has only a -single external IP address. When the firewall has multiple - external IP addresses or when the SOURCE is other than the -internet, there will usually be a desire for the rule to only -apply to those connection requests directed to particular - IP addresses (see Example 2 below for another usage). Those IP -addresses are specified in the ORIGINAL DEST column as a comma-separated -list.
    -
    - The IP address(es) - may be optionally followed by ":" and a second IP - address. This latter address, if present, is used as the - source address for packets forwarded to the server (This -is called "Source NAT" or SNAT.
    -
    - If this list begins with "!" then the rule will only apply if the - original destination address matches none of the addresses listed.
    -
    - Note: - When using SNAT, it is a good idea to qualify the source with - an IP address or subnet. Otherwise, it is likely that SNAT will - occur on connections other than those described in the rule. - The reason for this is that SNAT occurs in the Netfilter POSTROUTING - hook where it is not possible to restrict the scope of a rule - by incoming interface.
    -
    -     Example: - DNAT loc:192.168.1.0/24 loc:192.168.1.3 - tcp www - 206.124.146.179:192.168.1.3
    -
    -     If SNAT - is not used (no ":" and second IP address), the - original source address is used. If you want any destination - address to match the rule but want to specify SNAT, - simply use a colon followed by the SNAT address.
    • - -
- -

Example 1. You wish to forward all - ssh connection requests from the internet to -local system 192.168.1.3.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
DNATnetloc:192.168.1.3tcpssh
-
-
-
- -

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.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
REDIRECTloc3128tcpwww -
- 		!206.124.146.177
ACCEPTfwnettcpwww
-
-
-
- -

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.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTnetdmz:155.186.235.222tcpwww-
-
ACCEPTlocdmz:155.186.235.222tcpwww
-
-
-
- -

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 - .

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
DNATnetdmz:192.168.2.2tcpftp
-
-
DNATloc:192.168.1.0/24dmz:192.168.2.2tcpftp-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.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTIONSOURCEDEST -PROTODEST
- PORT(S)		SOURCE
- PORT(S)		ORIGINAL
- DEST
ACCEPTloc:~02-00-08-E3-FA-55dmzall
-
-
-
-
- - Example 6. You wish to allow access -to the SMTP server in your DMZ from all zones.
- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		all
- 		dmz
- 		tcp
- 		25
-
-
-
-
- Note: When 'all' is used as -a source or destination, intra-zone traffic is not affected. - In this example, if there were two DMZ interfaces then the - above rule would NOT enable SMTP traffic between hosts on these - interfaces.
-
- Example 7. Your firewall's - external interface has several IP addresses but you only want to accept - SSH connections on address 206.124.146.176.
- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
ACCEPT
- 		net
- 		fw:206.124.146.176
- 		tcp
- 		22
-
-
-
-
- Example 8 (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
-
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
-
-
-
-
- Using "DNAT-" rather than "DNAT" -avoids two extra copies of the third rule from being generated.
-
- Example 9 (Shorewall version 1.4.6 or later). You have 9 http -servers behind a Shorewall firewall and you want connection requests to -be distributed among your servers. The servers are 192.168.1.101-192.168.1.109.
-
- -
- - - - - - - - - - - - - - - - - - - - - - - - - -
ACTION
- 		SOURCE
- 		DEST
- 		PROTO
- 		DEST
- PORT(S)
- 		SOURCE
- PORT(S)
- 		ORIGINAL
- DEST
-
DNAT
- 		net
- 		loc:192.168.1.101-192.168.1.109
- 		tcp
- 		80
-
-
-
-
- -

Look here for information on other services. -

- -

/etc/shorewall/common

- -

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.

- -

/etc/shorewall/masq

- -

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:

- -
    -
  • INTERFACE - - The interface that will masquerade the subnet; -this is normally your internet interface. This interface - name can be optionally qualified by adding ":" and a subnet -or host IP. When this qualification is added, only packets -addressed to that host or subnet will be masqueraded. Beginning -with Shorewall version 1.3.14, if you have set ADD_SNAT_ALIASES=Yes - in /etc/shorewall/shorewall.conf, you can -cause Shorewall to create an alias label of the form interfacename:digit - (e.g., eth0:0) by placing that label in this column. -See example 5 below. Alias labels created in this way allow the -alias to be visible to the ipconfig utility. THAT IS THE ONLY -THING THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE -IN YOUR SHOREWALL CONFIGURATION.
    • -
  • SUBNET - - The subnet that you want to have masqueraded through - the INTERFACE. This may be expressed as a single IP address, - a subnet or an interface name. In the latter instance, - the interface must be configured and started before Shorewall - is started as Shorewall will determine the subnet based on - information obtained from the 'ip' utility. When using Shorewall 1.3.13 or earlier, when an interface - name is specified, Shorewall will only masquerade traffic from -the first subnetwork on the named interface; if the interface interfaces - to more that one subnetwork, you will need to add additional entries - to this file for each of those other subnetworks. Beginning with Shorewall - 1.3.14, shorewall will masquerade/SNAT traffic from any host that -is routed through the named interface.
    -
    - The subnet may be - optionally followed by "!' and a comma-separated - list of addresses and/or subnets that are to be excluded - from masquerading.
    • -
  • ADDRESS - - The source address to be used for outgoing packets. - This column is optional and if left blank, the current -primary IP address of the interface in the first column is -used. If you have a static IP on that interface, listing it here - makes processing of output packets a little less expensive - for the firewall. If you specify an address in this column, it must -be an IP address configured on the INTERFACE or you must have ADD_SNAT_ALIASES - enabled in /etc/shorewall/shorewall.conf.
    • - -
- -

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 -SUBNETADDRESS
eth0192.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 -SUBNETADDRESS
ipsec0:10.1.0.0/16192.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 -SUBNETADDRESS
eth0192.168.10.0/24206.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.

- -
- - - - - - - - - - - - - - - - - -
-INTERFACE -SUBNETADDRESS
eth0192.168.10.0/24!192.168.10.44,192.168.10.45206.124.146.176
-
- 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 -SUBNETADDRESS
eth0:0192.168.12.0/24206.124.146.177
-
- -

- /etc/shorewall/proxyarp

- -

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:

- -
    -
  • ADDRESS - - address of the system.
    • -
  • INTERFACE - - the interface that connects to the system. If the - interface is obvious from the subnetting, you may - enter "-" in this column.
    • -
  • EXTERNAL - - the external interface that you want to honor ARP - requests for the ADDRESS specified in the first column.
    • -
  • HAVEROUTE - - If you already -have a route -through - INTERFACE to - ADDRESS, this column should contain - "Yes" or "yes". If you want -Shorewall to add the route, the - column should - contain - "No" or - "no".
    • - -
- -

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:

- -
    -
  • eth0 - 155.186.235.1 - (internet connection)
    • -
  • eth1 - 192.168.9.0/24 - (masqueraded local systems)
    • -
  • eth2 - 192.168.10.1 - (interface to your DMZ)
    • - -
- -

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 -EXTERNALHAVEROUTE
155.186.235.4eth2eth0No
-
- -

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

- -

- /etc/shorewall/nat

- -

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:

- -
    -
  • EXTERNAL - - External IP address - This should NOT be -the primary IP address of the interface named in the next -column.
    • -
  • INTERFACE - - Interface that you want the EXTERNAL IP address - to appear on. Beginning with Shorewall version 1.3.14, -if you have set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf, -  you can specify an alias label of the form interfacename:digit - (e.g., eth0:0) and Shorewall will create the alias with - that label. Alias labels created in this way allow the alias -to be visible to the ipconfig utility. THAT IS THE ONLY THING - THAT THIS LABEL IS GOOD FOR AND IT MAY NOT APPEAR ANYWHERE ELSE IN -YOUR SHOREWALL CONFIGURATION. 
    • -
  • INTERNAL - - Internal IP address.
    • -
  • ALL - INTERFACES - - If Yes - or yes (or - left - empty), - NAT will -be effective from all - hosts. If - No or no -then NAT will -be effective - only - -through the interface named in - the INTERFACE - column.
    • -
  • LOCAL -- If Yes or yes and the ALL INTERFACES column contains - Yes or yes, NAT will be effective from the firewall system. - Note: For this to work, you must be running - kernel 2.4.19 or later and iptables 1.2.6a or later and -you must have enabled CONFIG_IP_NF_NAT_LOCAL - in your kernel.
    • - -
- -

Look here for additional information and an example. -

- -

- /etc/shorewall/tunnels

- -

The /etc/shorewall/tunnels file allows you to define IPSec, GRE, IPIP, - OpenVPN, PPTP - and 6to4.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, - instructions for PPTP tunnels are here - and instructions for 6to4 tunnels are here.

- -

/etc/shorewall/shorewall.conf

- -

This file is used to set the following firewall parameters:

- -
    -
  • SHOREWALL_SHELL - - Added at version 1.4.6
    - This parameter is used to specify the shell program to be used to interpret - the firewall script (/usr/share/shorewall/firewall). If not specified or -specified as a null value, /bin/sh is assumed.
    -
    • -
  • LOGFORMAT - Added at version 1.4.4.
    - The value of this variable generate the --log-prefix setting -for Shorewall logging rules. It contains a 'printf' formatting template -which accepts three arguments (the chain name, logging rule number (optional) - and the disposition). To use LOGFORMAT with fireparse (http://www.fireparse.com), set it -as:
    -  
    -        LOGFORMAT="fp=%s:%d a=%s "
    -  
    - If the LOGFORMAT value contains the substring '%d' then the logging - rule number is calculated and formatted in that position; if that substring - is not included then the rule number is not included. If not supplied - or supplied as empty (LOGFORMAT="") then "Shorewall:%s:%s:" is assumed.
    -
    - CAUTION: /sbin/shorewall uses the leading part -of the LOGFORMAT string (up to but not including the first '%') to -find log messages in the 'show log', 'status' and 'hits' commands. This -part should not be omitted (the LOGFORMAT should not begin with "%") -and the leading part should be sufficiently unique for /sbin/shorewall -to identify Shorewall messages.
    -
    • -
  • CLEAR_TC - Added at version 1.3.13
    - If this option is set to 'No' then Shorewall - won't clear the current traffic control rules during [re]start. - This setting is intended for use by people that prefer to configure - traffic shaping when the network interfaces come up rather than - when the firewall is started. If that is what you want to do, set -TC_ENABLED=Yes and CLEAR_TC=No and do not supply an /etc/shorewall/tcstart - file. That way, your traffic shaping rules can still use the 'fwmark' -classifier based on packet marking defined in /etc/shorewall/tcrules. -If not specified, CLEAR_TC=Yes is assumed.
    -
    • -
  • MARK_IN_FORWARD_CHAIN - Added - at version 1.3.12
    - If your kernel has a FORWARD chain - in the mangle table, you may set MARK_IN_FORWARD_CHAIN=Yes - to cause the marking specified in the tcrules file to occur in that - chain rather than in the PREROUTING chain. This permits you - to mark inbound traffic based on its destination address when SNAT - or Masquerading are in use. To determine if your kernel has a FORWARD - chain in the mangle table, use the "/sbin/shorewall show mangle" - command; if a FORWARD chain is displayed then your kernel will - support this option. If this option is not specified or if it is -given the empty value (e.g., MARK_IN_FORWARD_CHAIN="") then MARK_IN_FORWARD_CHAIN=No - is assumed.
    -
    • -
  • RFC1918_LOG_LEVEL - Added - at version 1.3.12
    - This parameter determines the -level at which packets logged under the 'norfc1918' mechanism - are logged. The value must be a valid syslog level and if no level is given, - then info is assumed. Prior to Shorewall version 1.3.12, - these packets are always logged at the info level.
    • -
  • TCP_FLAGS_DISPOSITION -- Added in Version 1.3.11
    - Determines the disposition of TCP - packets that fail the checks enabled by the tcpflags interface option and must - have a value of ACCEPT (accept the packet), REJECT (send an RST - response) or DROP (ignore the packet). If not set or if set - to the empty value (e.g., TCP_FLAGS_DISPOSITION="") then TCP_FLAGS_DISPOSITION=DROP - is assumed.
    • -
  • TCP_FLAGS_LOG_LEVEL - - Added in Version 1.3.11
    - Determines the syslog level for logging packets - that fail the checks enabled by the tcpflags interface option.The value must - be a valid syslogd log level. If you don't want to log -these packets, set to the empty value (e.g., TCP_FLAGS_LOG_LEVEL="").
    -
    • -
  • MACLIST_DISPOSITION - - Added in Version 1.3.10
    - Determines the disposition - of connections requests that fail MAC Verification and must have - the value ACCEPT (accept the connection request anyway), REJECT - (reject the connection request) or DROP (ignore the connection request). - If not set or if set to the empty value (e.g., MACLIST_DISPOSITION="") - then MACLIST_DISPOSITION=REJECT is assumed.
    • -
  • MACLIST_LOG_LEVEL - - Added in Version 1.3.10
    - Determines the syslog level for logging connection - requests that fail MAC Verification. - The value must be a valid syslogd log level. If you - don't want to log these connection requests, set to the -empty value (e.g., MACLIST_LOG_LEVEL="").
    -
    • -
  • NEWNOTSYN - -Added in Version 1.3.8
    - When set to "Yes" or -"yes", Shorewall will filter TCP packets that are -not part of an established connention and that are not SYN - packets (SYN flag on - ACK flag off). If set to "No", Shorewall - will silently drop such packets. If not set or set to the -empty value (e.g., "NEWNOTSYN="), NEWNOTSYN=No is assumed.
    -
    - If you have a HA setup - with failover to another firewall, you should have - NEWNOTSYN=Yes on both firewalls. You should also select NEWNOTSYN=Yes - if you have asymmetric routing.
    -
    • -
  • LOGNEWNOTSYN - - Added in Version 1.3.6
    - Beginning with version - 1.3.6, Shorewall drops non-SYN TCP packets that are - not part of an existing connection. If you would like -to log these packets, set LOGNEWNOTSYN to the syslog level at which you want -the packets logged. Example: LOGNEWNOTSYN=ULOG|
    -
    - Note: Packets - logged under this option are usually the result of - broken remote IP stacks rather than the result of any sort - of attempt to breach your firewall.
    • - -
  • DETECT_DNAT_ADDRS - Added in Version 1.3.4
    - If set to "Yes" or "yes", Shorewall will detect - the first IP address of the interface to the source zone and will - include this address in DNAT rules as the original destination - IP address. If set to "No" or "no", Shorewall will not detect -this address and any destination IP address will match the DNAT -rule. If not specified or empty, "DETECT_DNAT_ADDRS=Yes" is -assumed.
    -
    • -
  • MULTIPORT - - (Removed in version 1.4.6 -- the value of this parameter is now automatically - detected by Shorewall)
    - If set to "Yes" -or "yes", Shorewall will use the Netfilter multiport - facility. In order to use this facility, your kernel - must have multiport support (CONFIG_IP_NF_MATCH_MULTIPORT). - When this support is used, Shorewall will generate a -single rule from each record in the /etc/shorewall/rules - file that meets these criteria:
    - - -
      -
    • No port range(s) - specified
      • -
    • Specifies -15 or fewer ports
      • - - -
    - - -

    Rules not meeting those criteria will continue to generate an individual - rule for each listed port or port range. -

    -
    • -
  • NAT_BEFORE_RULES
    - If set to "No" or - "no", port forwarding rules can override the contents - of the /etc/shorewall/nat file. - If set to "Yes" or "yes", port forwarding rules cannot -override static NAT. If not set or set to an empty value, "Yes" - is assumed.
    • -
  • FW
    -     This - parameter - specifies the - name of the - firewall zone. - If not set or - if set to an empty string, - the value "fw" - is assumed.
    • -
  • SUBSYSLOCK
    - This parameter - should be set to the name of a file that the firewall - should create if it starts successfully and remove - when it stops. Creating and removing this file allows Shorewall - to work with your distribution's initscripts. For RedHat, - this should be set to /var/lock/subsys/shorewall. For - Debian, the value is /var/state/shorewall and in LEAF it is /var/run/shorwall. - Example: SUBSYSLOCK=/var/lock/subsys/shorewall.
    • -
  • STATEDIR
    - This parameter - specifies the name of a directory where Shorewall - stores state information. If the directory doesn't -exist when Shorewall starts, it will create the directory. - Example: STATEDIR=/tmp/shorewall.
    -
    - NOTE: If -you change the STATEDIR variable while the firewall - is running, create the new directory if necessary then -copy the contents of the old directory to the new directory. -
    • -
  • MODULESDIR
    - This parameter - specifies the directory where your kernel netfilter - modules may be found. If you leave the variable empty, - Shorewall will supply the value "/lib/modules/`uname -r`/kernel/net/ipv4/netfilter.
    • -
  • LOGRATE - and LOGBURST
    - These parameters - set the match rate and initial burst size for logged - packets. Please see the iptables man page for a description - of the behavior of these parameters (the iptables option - --limit is set by LOGRATE and --limit-burst is set by LOGBURST). - If both parameters are set empty, no rate-limiting - will occur.
    -
    - Example:
    - LOGRATE=10/minute
    - LOGBURST=5
    -
    • -
  • LOGFILE
    - This parameter - tells the - /sbin/shorewall - program where - to look for - Shorewall - messages when processing the "show - log", "monitor", "status" - and "hits" - commands. If - not assigned - or if assigned - an empty - value, - /var/log/messages - is assumed.
    • -
  • NAT_ENABLED - (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically - detected by Shorewall)
    - This parameter - determines whether Shorewall supports NAT operations. - NAT operations include:
    -
    - Static -NAT
    - Port Forwarding
    - Port Redirection
    - Masquerading
    -
    - If the parameter - has no value or has a value of "Yes" or "yes" -then NAT is enabled. If the parameter has a value of "no" - or "No" then NAT is disabled.
    -
    • -
  • MANGLE_ENABLED - (Removed in Shorewall 1.4.6 -- the value of this parameter is now automatically - detected by Shorewall)
    - This parameter - determines if packet mangling is enabled. If the parameter - has no value or has a value of "Yes" or "yes" than - packet mangling is enabled. If the parameter has a value - of "no" or "No" then packet mangling is disabled. If packet - mangling is disabled, the /etc/shorewall/tos file is - ignored.
    -
    • -
  • IP_FORWARDING
    - This parameter - determines whether Shorewall enables or disables IPV4 - Packet Forwarding (/proc/sys/net/ipv4/ip_forward). - Possible values are:
    -
    - On or -on - packet forwarding will be enabled.
    - Off or -off - packet forwarding will be disabled.
    - Keep or - keep - Shorewall will neither enable nor disable - packet forwarding.
    -
    - If this variable - is not set or is given an empty value (IP_FORWARD="") - then IP_FORWARD=On is assumed.
    -
    • -
  • ADD_IP_ALIASES
    - This parameter - determines whether Shorewall automatically adds -the external - address(es) in /etc/shorewall/nat - . If the variable is set to "Yes" or "yes" then Shorewall -automatically adds these aliases. If it is set to "No" or "no", -you must add these aliases yourself using your distribution's -network configuration tools. RESTRICTION: Shorewall -versions before 1.4.6 can only add addresses to the first subnetwork -configured on an interface.
    -
    - If this variable - is not set or is given an empty value (ADD_IP_ALIASES="") - then ADD_IP_ALIASES=Yes is assumed.
    • -
  • ADD_SNAT_ALIASES
    - This parameter determines - whether Shorewall automatically adds the SNAT - ADDRESS in /etc/shorewall/masq. - If the variable is set to "Yes" or "yes" then Shorewall - automatically adds these addresses. If it is set to - "No" or "no", you must add these addresses yourself using -your distribution's network configuration tools. RESTRICTION: - Shorewall versions before 1.4.6 can only add addresses to -the first subnetwork configured on an interface.
    -
    - If this variable - is not set or is given an empty value (ADD_SNAT_ALIASES="") - then ADD_SNAT_ALIASES=No is assumed.
    -
    • -
  • LOGUNCLEAN
    - This parameter - determines the - logging level - of mangled/invalid - packets - controlled by - the 'dropunclean and logunclean' - interface - options. If - LOGUNCLEAN is empty - (LOGUNCLEAN=) then packets -selected by 'dropclean' are - dropped - silently ('logunclean' - packets are - logged - under the 'info' log level). Otherwise, - these packets are logged at - the specified - level (Example: - LOGUNCLEAN=debug).
    • -
  • BLACKLIST_DISPOSITION
    - This parameter - determines the - disposition of - packets from - blacklisted - hosts. It may have the value DROP - if the packets are to - be dropped or - REJECT if the - packets are to - be replied - with an ICMP - port - unreachable - reply or a TCP RST (tcp - only). If you do not assign - a value or if you assign an - empty value - then DROP is - assumed.
    • -
  • BLACKLIST_LOGLEVEL
    - This paremter - determines if - packets from - blacklisted - hosts are logged - and it - determines the syslog level that they are - to be logged -at. Its value is a syslog level - (Example: - BLACKLIST_LOGLEVEL=debug). If you do not - assign a value or if you - assign an empty value - then packets from - blacklisted - hosts are not - logged.
    • -
  • CLAMPMSS
    - This parameter - enables the - TCP Clamp MSS - to PMTU feature -of Netfilter and - is usually - required when - your internet - connection is through PPPoE - or PPTP. If - set to - "Yes" or - "yes", the - feature is enabled. - If left - blank or - set to - "No" - or - "no", the -feature is - not enabled. Note: This option - requires CONFIG_IP_NF_TARGET_TCPMSS - in your kernel.
    • -
  • ROUTE_FILTER
    - If this parameter - is given the value "Yes" or "yes" then route filtering - (anti-spoofing) is enabled on all network interfaces. - The default value is "no".
    • - -
- -

/etc/shorewall/modules Configuration

- -

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>

-
- -

/etc/shorewall/tos Configuration

- -

The /etc/shorewall/tos file allows you to set the Type of Service field - in packet headers based on packet source, packet - destination, protocol, source port and destination - port. In order for this file to be processed by Shorewall, - you must have mangle support enabled - .

- -

Entries in the file have the following columns:

- -
    -
  • SOURCE - -- The source zone. May be qualified by following -the zone name with a colon (":") and either an IP address, - an IP subnet, a MAC address in Shorewall Format or the - name of an interface. This column may also contain the - name of - the firewall - zone to indicate packets originating - on the firewall itself or "all" to indicate any source.
    • -
  • DEST - -- The destination zone. May be qualified by following - the zone name with a colon (":") and either an IP address - or an IP subnet. Because packets are marked prior to routing, - you may not specify the name of an interface. This -column may also contain "all" to indicate any destination.
    • -
  • PROTOCOL - -- The name of a protocol in /etc/protocols or the -protocol's number.
    • -
  • SOURCE -PORT(S) -- The source port or a port range. For - all ports, place a hyphen ("-") in this column.
    • -
  • DEST PORT(S) - -- The destination port or a port range. To indicate - all ports, place a hyphen ("-") in this column.
    • -
  • TOS - -- The type of service. Must be one of the following:
    • - -
- -
- -
- -

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.

- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + +
SOURCEDESTPROTOCOLSOURCE
- PORT(S)		DEST - PORT(S)TOS
allalltcp-ssh16
allalltcpssh-16
allalltcp-ftp16
allalltcpftp-16
allalltcp-ftp-data8
allalltcpftp-data-8
loc2eth1:192.168.1.128/25
+
-
- -

WARNING: Users have reported that odd routing problems result from - adding the ESP and AH protocols to the /etc/shorewall/tos - file.

- -

/etc/shorewall/blacklist

- -

Each line in - /etc/shorewall/blacklist - contains - an IP - address, a MAC address in Shorewall Format - or - subnet - address. Example:

- -
      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:
-

- -
    -
  • ADDRESS/SUBNET - - As described above.
    • -
  • PROTOCOL -- Optional. If specified, only packets specifying this - protocol will be blocked.
    • -
  • PORTS - Optional; - may only be given if PROTOCOL is tcp, udp or icmp. -Expressed as a comma-separated list of port numbers or service - names (from /etc/services). If present, only packets destined - for the specified protocol and one of the listed ports are -blocked. When the PROTOCOL is icmp, the PORTS column contains - a comma-separated list of ICMP type numbers or names (see "iptables - -h icmp").
    -
    • - -
- -

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). -

+
+ +

Example 2:

-

/etc/shorewall/rfc1918 (Added in Version 1.3.1)

- -

This file lists the subnets affected by the norfc1918 - interface option. Columns in the file are:

- -