.GNU Free Documentation License
shorwall.lrpfile on the image with the file that you downloaded. See the
--oldpackage- option to rpm.
loczone are configured with their default gateway set to - the Shorewall router's RFC1918 address.
Local Processmeans a process running on the Shorewall system itself.
Copyright © 2003-2004 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software Foundation; with - no Invariant Sections, with no Front-Cover, and with no Back-Cover - Texts. A copy of the license is included in the section entitled - “GNU Free Documentation License”.
2004-02-04
Table of Contents
This page covers Shorewall configuration to use with Squid running as a Transparent - Proxy or as a Manual Proxy.
If you are running Shorewall 1.3, please see this documentation.
Caution
Please observe the following general requirements:
In all cases, Squid should be configured to run as a transrent - proxy as described at - http://tldp.org/HOWTO/mini/TransparentProxy.html.
The following instructions mention the files - /etc/shorewall/start and /etc/shorewall/init -- if you don't - have those files, siimply create them.
When the Squid server is in the DMZ zone or in the local zone, - that zone must be defined ONLY by its interface -- no - /etc/shorewall/hosts file entries. That is because the packets being - routed to the Squid server still have their original destination IP - addresses.
You must have iptables installed on your Squid server.
If you run a Shorewall version earlier than 1.4.6, you must - have NAT and MANGLE enabled in your /etc/shorewall/conf file
NAT_ENABLED=Yes -MANGLE_ENABLED=Yes
Three different configurations are covered:
| Squid (transparent) Running on the Firewall |
| Squid (transparent) Running in the local Network |
| Squid (transparent) Running in a DMZ |
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.
In /etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL -# PORT(S) DEST -REDIRECT loc 3228 tcp www - !206.124.146.177 -ACCEPT fw net tcp www |
There may be a requirement to exclude additional destination hosts - or networks from being redirected. For example, you might also want - requests destined for 130.252.100.0/24 to not be routed to Squid.
If you are running Shorewall version 1.4.5 or later, you may just - add the additional hosts/networks to the ORIGINAL DEST column in your - REDIRECT rule.
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL -# PORT(S) DEST -REDIRECT loc 3228 tcp www - !206.124.146.177,130.252.100.0/24 |
If you are running a Shorewall version earlier than 1.4.5, you - must add a manual rule in /etc/shorewall/start:
run_iptables -t nat -I loc_dnat -p tcp --dport www -d 130.252.100.0/24 -j RETURN |
To exclude additional hosts or networks, just add additional - similar rules.
You want to redirect all local www connection requests to a Squid - transparent proxy running in your local zone at 192.168.1.3 and - listening on port 3128. Your local interface is eth1. There may also be - a web server running on 192.168.1.3. It is assumed that web access is - already enabled from the local zone to the internet..
* On your firewall system, issue the following command
echo 202 www.out >> /etc/iproute2/rt_tablesIn /etc/shorewall/init, put:
if [ -z "`ip rule list | grep www.out`" ] ; then - ip rule add fwmark 202 table www.out - ip route add default via 192.168.1.3 dev eth1 table www.out - ip route flush cache - echo 0 > /proc/sys/net/ipv4/conf/eth1/send_redirects -fiImportant
If you are running Shorewall 1.4.1 or Shorewall 1.4.1a, - please upgrade to Shorewall 1.4.2 or later.
If you are running Shorewall 1.4.2 or later, then in - /etc/shorewall/interfaces:
#ZONE INTERFACE BROADCAST OPTIONS -loc eth1 detect routebackIn /etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST PORT(S) -ACCEPT loc loc tcp www
Alternativfely, if you are running Shorewall 1.4.0 you can - have the following policy in place of the above rule.
/etc/shorewall/policy
#SOURCE DESTINATION POLICY -loc loc ACCEPT
In /etc/shorewall/start add:
iptables -t mangle -A PREROUTING -i eth1 -s ! 192.168.1.3 -p tcp --dport 80 -j MARK --set-mark 202On 192.168.1.3, arrange for the following command to be - executed after networking has come up
iptables -t nat -A PREROUTING -i eth0 -d ! 192.168.1.3 -p tcp --dport 80 -j REDIRECT --to-ports 3128If you are running RedHat on the server, you can simply - execute the following commands after you have typed the iptables - command above:
iptables-save > /etc/sysconfig/iptables -chkconfig --level 35 iptables on
You have a single Linux system in your DMZ with IP address - 192.0.2.177. You want to run both a web server and Squid on that system. - Your DMZ interface is eth1 and your local interface is eth2.
On your firewall system, issue the following command
echo 202 www.out >> /etc/iproute2/rt_tablesIn /etc/shorewall/init, put:
if [ -z "`ip rule list | grep www.out`" ] ; then - ip rule add fwmark 202 table www.out - ip route add default via 192.0.2.177 dev eth1 table www.out - ip route flush cache -fiDo one of the following:
In /etc/shorewall/start add
iptables -t mangle -A PREROUTING -i eth2 -p tcp --dport 80 -j MARK --set-mark 202Set MARK_IN_FORWARD_CHAIN=No in /etc/shorewall/shorewall.conf - and add the following entry in /etc/shorewall/tcrules:
#MARK SOURCE DESTINATION PROTOCOL PORT -202 eth2 0.0.0.0 tcp 80
Run Shorewall 1.3.14 or later and add the following entry - in /etc/shorewall/tcrules:
#MARK SOURCE DESTINATION PROTOCOL PORT -202:P eth2 0.0.0.0 tcp 80
In /etc/shorewall/rules, you will need:
#ACTION SOURCE DEST PROTO DEST PORT(S) -ACCEPT loc dmz tcp 80 -ACCEPT dmz net tcp 80
On 192.0.2.177 (your Web/Squid server), arrange for the - following command to be executed after networking has come up
iptables -t nat -A PREROUTING -i eth0 -d ! 192.0.2.177 -p tcp --dport 80 -j REDIRECT --to-ports 3128If you are running RedHat on the server, you can simply - execute the following commands after you have typed the iptables - command above:
iptables-save > /etc/sysconfig/iptables -chkconfig --level 35 iptables on
Assume that Squid is running in zone SZ and listening on port SP; - all web sites that are to be accessed through Squid are in the - “net” zone. Then for each zone Z that needs access to the - Squid server.
/etc/shorewall/rules:
#ACTION SOURCE DEST PROTO DEST PORT(S) -ACCEPT Z SZ tcp SP -ACCEPT SZ net tcp 80 |
:) and ACCEPT, DROP or - REJECT. When this is done, the named action will become the -
:) and ACCEPT, DROP + or REJECT. When this is done, the named action will become the +
Foothen copy -
Foothen copy +
:) and a syslog - log level (e.g, REJECT:info or ACCEPT:debugging). This causes the packet - to be logged at the specified level. You may also specify ULOG (must be - in upper case) as a log level.This will log to the ULOG target for - routing to a separate log through use of ulogd (
~and must use -
-as a separator.
:) and a syslog log level (e.g, REJECT:info or + ACCEPT:debugging). This causes the packet to be logged at the + specified level. You may also specify ULOG (must be in upper case) as + a log level.This will log to the ULOG target for routing to a separate + log through use of ulogd (
:) - and an IP/MAC/subnet address as described above (e.g., - eth1:192.168.1.5).
~+ and must use
-as a separator.
:) and an IP/MAC/subnet address as described above + (e.g., eth1:192.168.1.5).
tcp,
udp, -
icmp, a number, or
all.
icmp, this column is - interpreted as the destination icmp-type(s).
tcp,
udp, +
icmp, a number, or
all.
icmp, this column is + interpreted as the destination icmp-type(s).
-.
-.
secor -
min) and <
secor +
min) and <
Dropfor DROP policies and -
Rejectfor REJECT policies.
Dropor -
Reject, simply copy
Dropfor DROP policies and +
Rejectfor REJECT policies.
Drop+ or
Reject, simply copy
~) and consist of 6 hex numbers separated by hyphens. In Shorewall, the MAC address in - the example above would be written
~02-00-08-E3-FA-55. + the example above would be written
Copyright © 2001-2004 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software Foundation; with - no Invariant Sections, with no Front-Cover, and with no Back-Cover - Texts. A copy of the license is included in the section entitled - “GNU Free Documentation License”.
2004-02-13
Table of Contents
- My Current Network
- Shorewall.conf
- Params File (Edited)
- Zones File
- Interfaces File
- Hosts File
- Routestopped File
- RFC1918 File
- Blacklist File (Partial)
- Policy File
- Masq File
- NAT File
- Proxy ARP File
- Tunnels File (Shell variable TEXAS set in /etc/shorewall/params)
- Actions File
- action.Mirrors File
- action.MyDrop
- action.MyReject
- Rules File (The shell variables are set in /etc/shorewall/params)
- /etc/network/interfaces
- /etc/dhcpd.conf (MAC Addresses Omitted)
Caution
I use a combination of One-to-one NAT and Proxy ARP, neither of - which are 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.
Caution
The configuration shown here corresponds to Shorewall version - 2.0.0-Beta1. It may use features not available in earlier Shorewall - releases.
I have DSL service and have 5 static IP addresses - (206.124.146.176-180). My DSL “modem” (Fujitsu Speedport) is - connected to eth0. I have a local network connected to eth2 (subnet - 192.168.1.0/24), a DMZ connected to eth1 (206.124.146.176/32) and a - Wireless network connected to eth3 (192.168.3.0/24). Note that the IP - address of eth1 is a duplicate of one on eth0.
I use:
One-to-one NAT for Ursa (my personal system that dual-boots - Mandrake 9.2 and Windows XP) - Internal address 192.168.1.5 and - external address 206.124.146.178.
One-to-one NAT for EastepLaptop (My work system -- Windows XP - SP2). Internal address 192.168.1.7 and external address - 206.124.146.180.
SNAT through 206.124.146.179 for my SuSE 9.0 Linux - system (Wookie), my Wife's Windows XP system (Tarry), and - our Windows XP laptop (Tipper) which connects through the - Wireless Access Point (wap) via a Wireless Bridge (bridge).
Note
While - the distance between the WAP and where I usually use the laptop - isn't very far (25 feet or so), using a WAC11 (CardBus wireless - card) has proved very unsatisfactory (lots of lost connections). By - replacing the WAC11 with the WET11 wireless bridge, I have virtually - eliminated these problems (Being an old radio tinkerer (K7JPV), I was - also able to eliminate the disconnects by hanging a piece of aluminum - foil on the family room wall. Needless to say, my wife Tarry rejected - that as a permanent solution :-).
The firewall runs on a 256MB PII/233 with Debian Sarge (Testing).
Wookie, Ursa and the Firewall all run Samba and the Firewall acts as - a WINS server.
The wireless network connects to eth3 via a LinkSys WAP11. - In additional to using the rather weak WEP 40-bit encryption (64-bit with - the 24-bit preamble), I use MAC - verification. This is still a weak combination and if I lived near - a wireless “hot spot”, I would probably add IPSEC or - something similar to my WiFi->local connections.
The single system in the DMZ (address 206.124.146.177) runs postfix, - Courier IMAP (imaps and pop3), DNS, a Web server (Apache) and an FTP - server (Pure-ftpd) under RedHat 9.0. The system also runs fetchmail to - fetch our email from our old and current ISPs. That server is managed - through Proxy ARP.
The firewall system itself runs a DHCP server that serves the local - network.
All administration and publishing is done using ssh/scp. I have a - desktop environment installed on the firewall but I am not usually logged - in to it. X applications tunnel through SSH to Ursa. The server also has a - desktop environment installed and that desktop environment is available - via XDMCP from the local zone. For the most part though, X tunneled - through SSH is used for server administration and the server runs at run - level 3 (multi-user console mode on RedHat).
I run an SNMP server on my firewall to serve MRTG running - in the DMZ.
The - ethernet interface in the Server is configured with IP address - 206.124.146.177, netmask 255.255.255.0. The server's default gateway - is 206.124.146.254 (Router at my ISP. This is the same default gateway - used by the firewall itself). On the firewall, an entry in my - /etc/network/interfaces file (see below) adds a host route to - 206.124.146.177 through eth1 when that interface is brought up.
Ursa (192.168.1.5 A.K.A. 206.124.146.178) runs a PPTP server for - Road Warrior access.
This is set up so that I can start the firewall before bringing - up my Ethernet interfaces.
I use a stripped-down file which doesn't have to be updated - when the IANA allocates a block of IP addresses.
Although most of our internal systems use one-to-one NAT, my - wife's system (192.168.1.4) uses IP Masquerading (actually SNAT) - as does my SuSE system (192.168.1.3), our laptop (192.168.3.8) and - visitors with laptops.
The $MIRRORS variable expands to a list of approximately 10 IP - addresses. So moving these checks into a separate chain reduces the - number of rules that most net->dmz traffic needs to traverse.
This is my common action for the DROP policy. It is like the - standard Reject action except that it - allows “Ping”.
This is my common action for the REJECT policy. It is like the - standard Drop action except that it - allows “Ping”.
This file is Debian specific. My additional entry (which is - displayed in bold type) adds a route - to my DMZ server when eth1 is brought up. It allows me to enter - “Yes” in the HAVEROUTE column of my - Proxy ARP file.
... -auto eth1 -iface eth1 inet static - address 206.124.146.176 - netmask 255.255.255.255 - broadcast 0.0.0.0 - up ip route add 206.124.146.177 dev eth1 -...
While this is a little off-topic, I've included it to show - how to set up DHCP on two interfaces.
default-lease-time 67200; max-lease-time 67200; -get-lease-hostnames on; - -group { - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.1.255; - option routers 192.168.1.254; - option ntp-servers 192.168.1.254; - option domain-name-servers 192.168.1.193; - option netbios-name-servers 192.168.1.254; - option domain-name "shorewall.net"; - option netbios-dd-server 192.168.1.254; - option netbios-node-type 8; - option netbios-scope ""; - - subnet 192.168.1.0 netmask 255.255.255.0 { - range 192.168.1.11 192.168.1.20; - } - - host ursa.shorewall.net { - hardware ethernet …; - fixed-address 192.168.1.5; - } - - host eastept1 { - hardware ethernet …; - fixed-address 192.168.1.7; - } - - host tarry { - hardware ethernet …; - fixed-address 192.168.1.4; - } - - host wookie.shorewall.net { - hardware ethernet …; - fixed-address 192.168.1.3; - } - - host testws.shorewall.net { - hardware ethernet …; - fixed-address 192.168.1.6; - } - - host printer.shorewall.net { - hardware ethernet …; - fixed-address 192.168.1.10; - } - -} - -group { - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.3.255; - option routers 192.168.3.254; - option ntp-servers 192.168.3.254; - option domain-name-servers 206.124.146.177; - option netbios-name-servers 192.168.3.254; - option domain-name "shorewall.net"; - option netbios-dd-server 192.168.3.254; - option netbios-node-type 8; - option netbios-scope ""; - - subnet 192.168.3.0 netmask 255.255.255.0 { - range 192.168.3.11 192.168.3.20; - } - - host easteplaptop { - hardware ethernet …; - fixed-address 192.168.3.7; - } - - host tipper.shorewall.net { - hardware ethernet …; - fixed-address 192.168.3.8; - }
modem(Fujitsu Speedport) is connected to eth0. I have a local network connected to eth2 (subnet - 192.168.1.0/24), a DMZ connected to eth1 (206.124.146.176/32) and a - Wireless network connected to eth3 (192.168.3.0/24). Note that the IP - address of eth1 is a duplicate of one on eth0.
hot spot, I would probably add IPSEC or - something similar to my WiFi->local connections.
hot spot, I + would probably add IPSEC or something similar to my WiFi->local + connections.
@@ -229,7 +238,6 @@ tx#ZONE DISPLAY COMMENTS net Internet Internet -WiFi Wireless Wireless Network on eth3 dmz DMZ Demilitarized zone loc Local Local networks tx Texas Peer Network in Dallas @@ -206,7 +216,6 @@ tx Texas Peer Network in Dallas net eth0 206.124.146.255 dhcp,norfc1918,routefilter,blacklist,tcpflags,nosmurfs loc eth2 192.168.1.255 dhcp,detectnets dmz eth1 - -WiFi eth3 192.168.3.255 dhcp,maclist,detectnets - texas 192.168.9.255 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
@@ -428,23 +435,17 @@ REJECT:$LOG loc net tcp REJECT loc net tcp 137,445 REJECT loc net udp 137:139 # -DROP loc:!192.168.1.0/24 net - QUEUE loc net udp QUEUE loc fw udp QUEUE loc net tcp ############################################################################################################################################################################### # Local Network to Firewall # -DROP loc:!192.168.1.0/24 fw -ACCEPT loc fw tcp ssh,time,10000,swat,137,139,445 -ACCEPT loc fw udp snmp,ntp,445 -ACCEPT loc fw udp 137:139 -ACCEPT loc fw udp 1024: 137 +ACCEPT loc fw tcp ssh,time +ACCEPT loc fw udp snmp,ntp ############################################################################################################################################################################### # Local Network to DMZ # -DROP loc:!192.168.1.0/24 dmz REJECT loc dmz tcp 465 ACCEPT loc dmz udp domain,xdmcp ACCEPT loc dmz tcp www,smtp,domain,ssh,imap,https,imaps,cvspserver,ftp,10000,8080,10027,pop3 - @@ -500,72 +501,17 @@ ACCEPT dmz fw tcp ACCEPT dmz fw udp snmp REJECT dmz fw tcp auth ############################################################################################################################################################################### -# DMZ to Internet -# -ACCEPT dmz net tcp smtp,domain,www,https,whois,echo,2702,21,2703,ssh,8080 -ACCEPT dmz net udp domain -ACCEPT dmz net:$POPSERVERS tcp pop3 -#ACCEPT dmz net:206.191.151.2 tcp pop3 -#ACCEPT dmz net:66.216.26.115 tcp pop3 -# -# Something is wrong with the FTP connection tracking code or there is some client out there -# that is sending a PORT command which that code doesn't understand. Either way, -# the following works around the problem. -# -ACCEPT:$LOG dmz net tcp 1024: 20 -############################################################################################################################################################################### -# DMZ to Firewall -- ntp & snmp, Silently reject Auth -# -ACCEPT dmz fw udp ntp ntp -ACCEPT dmz fw tcp snmp,ssh -ACCEPT dmz fw udp snmp -REJECT dmz fw tcp auth -############################################################################################################################################################################### -# # DMZ to Local Network # ACCEPT dmz loc tcp smtp,6001:6010 -ACCEPT dmz loc tcp 111 -ACCEPT dmz loc udp +ACCEPT dmz:206.124.146.177 loc:192.168.1.3 tcp 111 +ACCEPT dmz:206.124.146.177 loc:192.168.1.3 udp ############################################################################################################################################################################### # Internet to Firewall # REJECT net fw tcp www ACCEPT net dmz udp 33434:33435 -############################################################################################################################################################################### -# WIFI to Firewall -# -ACCEPT WiFi fw tcp ssh,137,139,445 -ACCEPT WiFi fw udp 137:139,445 -ACCEPT WiFi fw udp 1024: 137 -ACCEPT WiFi fw udp ntp ntp -############################################################################################################################################################################### -# Firewall to WIFI -# -ACCEPT fw WiFi tcp 137,139,445 -ACCEPT fw WiFi udp 137:139,445 -ACCEPT fw WiFi udp 1024: 137 -ACCEPT fw WiFi udp ntp ntp -############################################################################################################################################################################## -# WIFI to DMZ -# -DNAT- WiFi dmz:206.124.146.177 all - - 192.168.1.193 -ACCEPT WiFi dmz tcp smtp,www,ftp,imaps,domain,https,ssh,8080 - -ACCEPT WiFi dmz udp domain -############################################################################################################################################################################## -# WIFI to loc -# -ACCEPT WiFi loc udp 137:139 -ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389 -ACCEPT WiFi loc udp 1024: 137 -ACCEPT WiFi loc udp 177 -############################################################################################################################################################################## -# loc to WiFi -# -ACCEPT loc WiFi udp 137:139 -ACCEPT loc WiFi tcp 137,139,445 -ACCEPT loc WiFi udp 1024: 137 -ACCEPT loc WiFi tcp 6000:6010 + ############################################################################################################################################################################### # Firewall to Internet # @@ -694,4 +640,241 @@ group { + +Although most of our internal systems use one-to-one NAT, my wife's system (192.168.1.4) uses IP Masquerading (actually SNAT) - as does my SuSE system (192.168.1.3), our laptop (192.168.3.8) and + as do my SuSE system (192.168.1.3), our laptop (192.168.3.8) and visitors with laptops. #INTERFACE SUBNET ADDRESS eth0:2 eth2 206.124.146.179 -eth0 eth3 206.124.146.179 #LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE
++Only the changes from the defaults are shown. + +BRIDGING=Yes +
++#ZONE DISPLAY COMMENTS +net Net Internet +loc Local Local networks +WiFi WireLess Wireless Network +#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE + +
++#SOURCE DEST POLICY LOG LIMIT:BURST +fw fw ACCEPT +loc net ACCEPT +net loc ACCEPT +net fw ACCEPT +loc fw ACCEPT +loc WiFi ACCEPT +fw WiFi ACCEPT +fw net ACCEPT +fw loc ACCEPT +# +# THE FOLLOWING POLICY MUST BE LAST +# +all all REJECT info +#LAST LINE -- DO NOT REMOVE +
++#ZONE INTERFACE BROADCAST OPTIONS +- br0 192.168.1.255 +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE +
++#ZONE HOST(S) OPTIONS +net br0:eth1 +loc br0:eth0 +WiFi br0:eth2 maclist +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS LINE -- DO NOT REMOVE +
++The first rule allows a transparent WWW proxy (Squid) to run on + my bridge/firewall. Squid listens on port 3128. + +The remaining rules protect the local systems and bridge from + the WiFi network. Note that we don't restrict WiFi→net traffic + since the only directly-accessible system in the net zone is the + firewall (Wookie and the Firewall are connected by a cross-over + cable). + +#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL +# PORT PORT(S) DEST +REDIRECT loc 3128 tcp www - !192.168.1.0/24 + +ACCEPT WiFi loc udp 137:139 +ACCEPT WiFi loc tcp 22,80,137,139,445,901,3389 +ACCEPT WiFi loc udp 1024: 137 +ACCEPT WiFi loc udp 177 + +ACCEPT loc WiFi udp 137:139 +ACCEPT loc WiFi tcp 137,139,445 +ACCEPT loc WiFi udp 1024: 137 +ACCEPT loc WiFi tcp 6000:6010 + +ACCEPT WiFi fw tcp ssh,137,139,445 +ACCEPT WiFi fw udp 137:139,445 +ACCEPT WiFi fw udp 1024: 137 +ACCEPT WiFi fw udp ntp + +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE +
++#INTERFACE HOST(S) OPTIONS +br0 0.0.0.0/0 routeback +#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE +
++#INTERFACE MAC IP ADDRESSES (Optional) +br0:eth2 00:A0:1C:DB:0C:A0 192.168.1.7 #Work Laptop +br0:eth2 00:04:59:0e:85:b9 #WAP11 +br0:eth2 00:06:D5:45:33:3c #WET11 +br0:eth2 00:0b:c1:53:cc:97 192.168.1.8 #TIPPER +#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE +
++This file is SuSE-specific and creates the bridge device + + +br0 . A script for other + disbributions would be similar.#!/bin/sh +################################################################################ +# Script to create a bridge between eth0, eth1 and eth2 +# +# This program is under GPL [http://www.gnu.org/copyleft/gpl.htm] +# +# (c) 2004 - Tom Eastep (teastep@shorewall.net) +# +# Modify the following variables to match your configuration +# +# chkconfig: 2345 05 89 +# description: Layer 2 Bridge +# +################################################################################ + +PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin + +do_stop() { + echo "Stopping Bridge" + brctl delbr br0 + ip link set eth0 down + ip link set eth1 down + ip link set eth2 down +} + +do_start() { + + echo "Starting Bridge" + ip link set eth0 up + ip link set eth1 up + ip link set eth2 up + brctl addbr br0 + brctl addif br0 eth0 + brctl addif br0 eth1 + brctl addif br0 eth2 +} + +case "$1" in + start) + do_start + ;; + stop) + do_stop + ;; + restart) + do_stop + sleep 1 + do_start + ;; + *) + echo "Usage: $0 {start|stop|restart}" + exit 1 +esac +exit 0 +
++This file is SuSE-specific + +BOOTPROTO='static' +BROADCAST='192.168.1.255' +IPADDR='192.168.1.3' +NETWORK='192.168.1.0' +NETMASK='255.255.255.0' +REMOTE_IPADDR='' +STARTMODE='onboot' +UNIQUE='3hqH.MjuOqWfSZ+C' +WIRELESS='no' +MTU='' +
++This file is SuSE-specific + +192.168.1.0 - 255.255.255.0 br0 +default 192.168.1.254 - - +
Copyright © 2001-2002, 2004 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software Foundation; with - no Invariant Sections, with no Front-Cover, and with no Back-Cover - Texts. A copy of the license is included in the section entitled - “GNU Free Documentation License”.
2004-02-12
Abstract
In addition to those applications described in the - /etc/shorewall/rules documentation, here are some other - services/applications that you may need to configure your firewall to - accommodate.
Table of Contents
Note
Beginning with Shorewall 2.0.0, the Shorewall distribution contains - a library of user-defined actions that allow for easily allowing or - blocking a particular application. Check your /etc/shorewall/actions.std - file for a list of the actions in your distribution. If you find what you - need, you simply use the action in a rule. For example, to allow DNS - queries from the dmz zone to the - net zone:
#ACTION SOURCE DESTINATION -AllowPing dmz net |
Note
In the rules that are shown in this document, the ACTION is shown as - ACCEPT. You may need to use DNAT (see FAQ 30) - or you may want DROP or REJECT if you are trying to block the application.
Example: You want to port forward FTP from the net to your server at - 192.168.1.4 in your DMZ. The FTP section below gives you:
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 21 |
You would code your rule as follows:
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -DNAT net dmz:192.168.1.4 tcp 21 |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> udp 53 -ACCEPT <source> <destination> tcp 53 |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 21 |
Look here for much more information.
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> udp 4000 -ACCEPT <source> <destination> tcp 4000:4100 |
UDP Port 4000. You will also need to open a range of TCP ports which - you can specify to your ICQ client. By default, clients use 4000-4100.
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 143 #Unsecure IMAP -ACCEPT <source> <destination> tcp 993 #Secure IMAP |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> 50 -ACCEPT <source> <destination> 51 -ACCEPT <source> <destination> udp 500 -ACCEPT <destination> <source> 50 -ACCEPT <destination> <source> 51 -ACCEPT <destination> <source> udp 500 |
I personally use the following rules for opening access from zone z1 - to a server with IP address a.b.c.d in zone z2. I have found though that - different distributions behave differently so your milage may vary.
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <z1> <z2>:a.b.c.d tcp 111 -ACCEPT <z1> <z2>:a.b.c.d udp 111 -ACCEPT <z1> <z2>:a.b.c.d udp 2049 -ACCEPT <z1> <z2>:a.b.c.d udp 32700: |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> udp 123 |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> udp 5632 -ACCEPT <source> <destination> tcp 5631 |
TCP Port 110 (Secure Pop3 is TCP Port 995)
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 110 #Unsecure Pop3 -ACCEPT <source> <destination> tcp 995 #Secure Pop3 |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> 47 -ACCEPT <source> <destination> tcp 1723 |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 137,139,445 -ACCEPT <source> <destination> udp 137:139 -ACCEPT <destination> <source> tcp 137,139,445 -ACCEPT <destination> <source> udp 137:139 |
Also, see this page.
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> udp 33434:33443 #Good for 10 hops -ACCEPT <source> <destination> icmp 8 |
UDP traceroute uses ports 33434 through 33434+<max number of - hops>-1
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 119 |
TCP Port 119
Vncviewer to Vncserver -- TCP port 5900 + <display number>.
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 5901 #Display Number 1 -ACCEPT <source> <destination> tcp 5902 #Display Number 2 -... |
Vncserver to Vncviewer in listen mode -- TCP port 5500.
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 5500 |
#ACTION SOURCE DESTINATION PROTO DEST PORT(S) -ACCEPT <source> <destination> tcp 80 #Insecure HTTP -ACCEPT <source> <destination> tcp 443 #Secure HTTP |
Didn't find what you are looking for -- have you looked in your - own /etc/services file?
Still looking? Try http://www.networkice.com/advice/Exploits/Ports
A. Revision History
| Revision History | ||
|---|---|---|
| Revision 1.6 | 2004-01-26 | TE |
| Add - PCAnywhere. | ||
| Revision 1.5 | 2004-02-05 | TE |
| Added - information about VNC viewers in listen mode. | ||
| Revision 1.4 | 2004-01-26 | TE |
| Correct - ICQ. | ||
| Revision 1.3 | 2004-01-04 | TE |
| Alphabetize | ||
| Revision 1.2 | 2004-01-03 | TE |
| Add - rules file entries. | ||
| Revision 1.1 | 2002-07-30 | TE |
| Initial - version converted to Docbook XML | ||
Allow. -
Allow.
Allowaction in @@ -406,7 +407,8 @@ AllowSSH net fw
Copyright © 2002-2004 Thomas M. Eastep
Permission is granted to copy, distribute and/or modify this - document under the terms of the GNU Free Documentation License, Version - 1.2 or any later version published by the Free Software Foundation; with - no Invariant Sections, with no Front-Cover, and with no Back-Cover - Texts. A copy of the license is included in the section entitled - “GNU Free Documentation License”.
2004-02-12
Table of Contents
Setting up a Linux system as a firewall for a small network with DMZ - is a fairly straight-forward task if you understand the basics and follow - the documentation.
This guide doesn't attempt to acquaint you with all of the - features of Shorewall. It rather focuses on what is required to configure - Shorewall in one of its more popular configurations:
Linux system used as a firewall/router for a small local - network.
Single public IP address.
Note
If you have more than one public IP address, this is not the - guide you want -- see the Shorewall - Setup Guide instead.
DMZ connected to a separate ethernet interface.
Connection through DSL, Cable Modem, ISDN, Frame Relay, dial-up, - ...
Here is a schematic of a typical installation.
Shorewall requires that you have the iproute/iproute2 - package installed (on RedHat™, the package is - called iproute). You can tell if this package is - installed by the presence of an ip program on your - firewall system. As root, you - can use the which command to check for this program:
[root@gateway root]# which ip
-/sbin/ip
-[root@gateway root]# |
I recommend that you first read through the guide to familiarize - yourself with what's involved then go back through it again making - your configuration changes.
Caution
If you edit your configuration files on a - Windows™ system, you must save them as - Unix™ files if your editor supports that option - or you must run them through dos2unix before trying - to use them. Similarly, if you copy a configuration file from your - Windows™ hard drive to a floppy disk, you must - run dos2unix against the copy before using it with - Shorewall.
If you have an ADSL Modem and you use PPTP to communicate with a - server in that modem, you must make the changes - recommended here in addition to those detailed below. ADSL with - PPTP is most commonly found in Europe, notably in Austria.
The configuration files for Shorewall are contained in the directory - /etc/shorewall -- for simple setups, you will only - need to deal with a few of these as described in this guide. After you - have installed Shorewall, download the three-interface sample, un-tar it (tar - -zxvf three-interfaces.tgz) - and and copy the files to /etc/shorewall (the files - will replace files with the same names that were placed in - /etc/shorewall when Shorewall was installed).
As each file is introduced, I suggest that you look through the - actual file on your system -- each file contains detailed configuration - instructions and default entries.
Shorewall views the network where it is running as being composed of - a set of zones. In the three-interface sample configuration, the following - zone names are used:
| Name | Description |
|---|---|
| net | The Internet |
| loc | Your Local Network |
| dmz | Demilitarized Zone |
Zone names are defined in /etc/shorewall/zones.
Shorewall also recognizes the firewall system as its own zone - by - default, the firewall itself is known as fw.
Rules about what traffic to allow and what traffic to deny are - expressed in terms of zones.
You express your default policy for connections from one zone to - another zone in the /etc/shorewall/policy file.
You define exceptions to those default policies in the - /etc/shorewall/rules file.
For each connection request entering the firewall, the request is - first checked against the /etc/shorewall/rules file. - If no rule in that file matches the connection request then the first - policy in /etc/shorewall/policy that matches the - request is applied. If that policy is REJECT or DROP the request is first - checked against the rules in /etc/shorewall/common if - that file exists; otherwise the file /etc/shorewall/common.def - is checked
The /etc/shorewall/policy file included with - the three-interface sample has the following policies:
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST -loc net ACCEPT -net all DROP info -all all REJECT info |
Important
In the three-interface sample, the line below is included but - commented out. If you want your firewall system to have full access to - servers on the internet, uncomment that line.
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST -fw net ACCEPT |
The above policy will:
allow all connection requests from your local network to the - internet
drop (ignore) all connection requests from the internet to your - firewall or local network
optionally accept all connection requests from the firewall to - the internet (if you uncomment the additional policy)
reject all other connection requests.
At this point, edit your /etc/shorewall/policy - file and make any changes that you wish.
The firewall has three network interfaces. Where Internet - connectivity is through a cable or DSL “Modem”, the External - Interface will be the ethernet adapter that is connected to that - “Modem” (e.g., eth0) - unless you connect via Point-to-Point Protocol over - Ethernet (PPPoE) or Point-to-Point Tunneling Protocol - (PPTP) in which case the External Interface will be a ppp - interface (e.g., ppp0). If you - connect via a regular modem, your External Interface will also be - ppp0. If you connect using ISDN, - you external interface will be ippp0.
If your external interface is ppp0 - or ippp0 then you will want to set - CLAMPMSS=yes in /etc/shorewall/shorewall.conf.
Your Local Interface will be an ethernet adapter (eth0, eth1 - or eth2) and will be connected to - a hub or switch. Your local computers will be connected to the same switch - (note: If you have only a single local system, you can connect the - firewall directly to the computer using a cross-over cable).
Your DMZ Interface will also be an ethernet adapter (eth0, eth1 - or eth2) and will be connected to - a hub or switch. Your DMZ computers will be connected to the same switch - (note: If you have only a single DMZ system, you can connect the firewall - directly to the computer using a cross-over cable).
Caution
Do not connect the internal and external interface to the same hub - or switch except for testing AND you are running Shorewall version 1.4.7 - or later. When using these recent versions, you can test using this kind - of configuration if you specify the arp_filter option in - /etc/shorewall/interfaces for all interfaces - connected to the common hub/switch. Using such a setup with a production - firewall is strongly recommended against.
The Shorewall three-interface sample configuration assumes that the - external interface is eth0, the - local interface is eth1 and the - DMZ interface is eth2. If your - configuration is different, you will have to modify the sample - /etc/shorewall/interfaces file accordingly. While you - are there, you may wish to review the list of options that are specified - for the interfaces. Some hints:
Tip
If your external interface is ppp0 - or ippp0, you can replace the - “detect” in the second column with “-” - (without the quotes).
Tip
If your external interface is ppp0 - or ippp0 or if you have a static - IP address, you can remove “dhcp” from the option list.
Before going further, we should say a few words about Internet - Protocol (IP) addresses. Normally, your ISP will assign you a single - Public IP address. This address may be assigned via the Dynamic Host - Configuration Protocol (DHCP) or as part of establishing your connection - when you dial in (standard modem) or establish your PPP connection. In - rare cases, your ISP may assign you a static IP address; that means that - you configure your firewall's external interface to use that address - permanently. Regardless of how the address is assigned, it will be shared - by all of your systems when you access the Internet. You will have to - assign your own addresses for your internal network (the local and DMZ - Interfaces on your firewall plus your other computers). RFC 1918 reserves - several Private IP address ranges for this purpose:
10.0.0.0 - 10.255.255.255 -172.16.0.0 - 172.31.255.255 -192.168.0.0 - 192.168.255.255 |
Before starting Shorewall, you should look at the IP address of your - external interface and if it is one of the above ranges, you should remove - the norfc1918 option from the external interface's - entry in /etc/shorewall/interfaces.
You will want to assign your local addresses from one sub-network or - subnet and your DMZ addresses from another subnet. For our purposes, we - can consider a subnet to consists of a range of addresses x.y.z.0 - x.y.z.255. - Such a subnet will have a Subnet Mask of 255.255.255.0. - The address x.y.z.0 is reserved - as the Subnet Address and x.y.z.255 - is reserved as the Subnet Broadcast Address. In Shorewall, a subnet is - described using Classless InterDomain Routing (CIDR) notation with - consists of the subnet address followed by /24. The - 24 refers to the number of consecutive “1” - bits from the left of the subnet mask.
Table 1. Example sub-network
| Range: | 10.10.10.0 - - 10.10.10.255 |
| Subnet Address: | 10.10.10.0 |
| Broadcast Address: | 10.10.10.255 |
| CIDR Notation: | 10.10.10.0/24 |
It is conventional to assign the internal interface either the first - usable address in the subnet (10.10.10.1 - in the above example) or the last usable address (10.10.10.254).
One of the purposes of subnetting is to allow all computers in the - subnet to understand which other computers can be communicated with - directly. To communicate with systems outside of the subnetwork, systems - send packets through a gateway (router).
Your local computers (Local Computers 1 & 2) should be - configured with their default gateway set to the IP address of the - firewall's internal interface and your DMZ computers (DMZ Computers 1 - & 2) should be configured with their default gateway set to the IP - address of the firewall's DMZ interface.
The foregoing short discussion barely scratches the surface - regarding subnetting and routing. If you are interested in learning more - about IP addressing and routing, I highly recommend “IP - Fundamentals: What Everyone Needs to Know about Addressing & Routing”, - Thomas A. Maufer, Prentice-Hall, 1999, ISBN 0-13-975483-0.
The remainder of this quide will assume that you have configured - your network as shown here:
Figure 3. DMZ
The default gateway for the DMZ computers would be 10.10.11.254 and the default gateway - for the Local computers would be 10.10.10.254.
Warning
Your ISP might assign your external interface an RFC 1918 - address. If that address is in the 10.10.10.0/24 - subnet then you will need to select a DIFFERENT RFC 1918 subnet - for your local network and if it is in the 10.10.11.0/24 subnet then you will - need to select a different RFC 1918 subnet for your DMZ.
The addresses reserved by RFC 1918 are sometimes referred to as - non-routable because the Internet backbone routers don't forward - packets which have an RFC-1918 destination address. When one of your local - systems (let's assume local computer 1) sends a connection request to - an internet host, the firewall must perform Network Address Translation - (NAT). The firewall rewrites the source address in the packet to be the - address of the firewall's external interface; in other words, the - firewall makes it look as if the firewall itself is initiating the - connection. This is necessary so that the destination host will be able to - route return packets back to the firewall (remember that packets whose - destination address is reserved by RFC 1918 can't be routed accross - the internet). When the firewall receives a return packet, it rewrites the - destination address back to 10.10.10.1 and forwards the packet on to local - computer 1.
On Linux systems, the above process is often referred to as IP - Masquerading and you will also see the term Source Network Address - Translation (SNAT) used. Shorewall follows the convention used with - Netfilter:
Masquerade - describes the case where you let your firewall system automatically detect - the external interface address.
SNAT - refers to the case when you explicitly specify the source address that you - want outbound packets from your local network to use.
- In Shorewall, both Masquerading and SNAT are configured with entries in - the /etc/shorewall/masq - file.
If your external firewall interface is eth0, - your local interface eth1 and your - DMZ interface is eth2 then you do - not need to modify the file provided with the sample. Otherwise, edit - /etc/shorewall/masq - and change it to match your configuration.
If, despite all advice to the contrary, you are using this guide and - want to use one-to-one NAT or Proxy ARP for your DMZ, remove the entry for - eth2 from /etc/shorewall/masq.
If your external IP is static, you can enter it in the third column - in the /etc/shorewall/masq - entry if you like although your firewall will work fine if you leave that - column empty. Entering your static IP in column 3 makes processing - outgoing packets a little more efficient.
If you are using the Debian package, please check your - shorewall.conf file to ensure that the following are - set correctly; if they are not, change them appropriately: -
NAT_ENABLED=Yes - (Shorewall versions earlier than 1.4.6)
IP_FORWARDING=On
One of your goals will be to run one or more servers on your DMZ - computers. Because these computers have RFC-1918 addresses, it is not - possible for clients on the internet to connect directly to them. It is - rather necessary for those clients to address their connection requests to - your firewall who rewrites the destination address to the address of your - server and forwards the packet to that server. When your server responds, - the firewall automatically performs SNAT to rewrite the source address in - the response.
The above process is called Port Forwarding or - Destination Network Address Translation (DNAT). You - configure port forwarding using DNAT rules in the /etc/shorewall/rules - file.
The general form of a simple port forwarding rule in /etc/shorewall/rules is: -
#ACTION SOURCE DEST PROTO DEST PORT(S) -DNAT net dmz:<server local ip address>[:<server port>] <protocol> <port> |
- If you don't specify the <server port>, - it is assumed to be the same as <port>.
Example 1. You run a Web Server on DMZ Computer 2 and you want to forward - incoming TCP port 80 to that system
#ACTION SOURCE DEST PROTO DEST PORT(S) -DNAT net dmz:10.10.11.2 tcp 80 -ACCEPT loc dmz:10.10.11.2 tcp 80 |
Entry - 1 forwards port 80 from the Internet.
Entry - 2 allows connections from the local network.
- Several important points to keep in mind:
When - you are connecting to your server from your local systems, you must use - the server's internal IP address (10.10.11.2).
Many - ISPs block incoming connection requests to port 80. If you have problems - connecting to your web server, try the following rule and try connecting - to port 5000 (e.g., connect to http://w.x.y.z:5000 where - w.x.y.z is your external IP).
#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE -# PORT(S) -DNAT net dmz:10.10.11.2:80 tcp 80 5000
If - you want to be able to access your server from the local network using - your external address, then if you have a static external IP you can - replace the loc->dmz rule above with:
#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL -# PORT(S) DEST -DNAT loc dmz:10.10.11.2 tcp 80 - <external ip>If - you have a dynamic ip then you must ensure that your external interface - is up before starting Shorewall and you must take steps as follows - (assume that your external interface is eth0):
Include - the following in /etc/shorewall/params:
ETH0_IP=$(find_interface_address - eth0)
Make your - loc->dmz rule:
#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL -# PORT(S) DEST -DNAT loc dmz:10.10.11.2 tcp 80 - $ETH0_IP
If - you want to access your server from the DMZ using your external IP - address, see FAQ 2a.
At this point, add the DNAT and ACCEPT rules for your servers.
Normally, when you connect to your ISP, as part of getting an IP - address your firewall's Domain Name Service (DNS) - resolver will be automatically configured (e.g., the /etc/resolv.conf - file will be written). Alternatively, your ISP may have given you the IP - address of a pair of DNS name servers for you to manually configure as - your primary and secondary name servers. It is your responsibility to - configure the resolver in your internal systems. You can take one of two - approaches:
You can configure your internal - systems to use your ISP's name servers. If you ISP gave you the - addresses of their servers or if those addresses are available on their - web site, you can configure your internal systems to use those addresses. - If that information isn't available, look in /etc/resolv.conf - on your firewall system -- the name servers are given in “nameserver” - records in that file.
You can - configure a Caching Name Server on your firewall or - in your DMZ. Red Hat™ has an RPM for a caching name - server (which also requires the 'bind' RPM) and - for Bering users, there is dnscache.lrp. If you take - this approach, you configure your internal systems to use the caching name - server as their primary (and only) name server. You use the internal IP - address of the firewall (10.10.10.254 - in the example above) for the name server address if you choose to run the - name server on your firewall. To allow your local systems to talk to your - caching name server, you must open port 53 (both UDP and TCP) from the - local network to the server; you do that by adding the rules in - /etc/shorewall/rules.
- If you run the name server on the firewall: -
#ACTION SOURCE DEST PROTO DEST PORT(S) -AllowDNS loc fw -AllowDNS dmz fw |
Run name server on DMZ - computer 1:
#ACTION SOURCE DEST PROTO DEST PORT(S) -AllowDNS loc dmz:10.10.11.1 -AllowDNS fw dmz:10.10.11.1 |
In the rules shown above, “AllowDNS” is an example of a - defined action. Shorewall includes a number of - defined actions and you can add - your own. To see the list of actions included with your version of - Shorewall, look in the file /etc/shorewall/actions.std. - Those actions that accept connection requests have names that begin with - “Allow”.
You don't have to use defined actions when coding a rule in - /etc/shorewall/rules; the generated Netfilter ruleset - is slightly more efficient if you code your rules directly rather than - using defined actions. The first example above (name server on the - firewall) could also have been coded as follows:
#ACTION SOURCE DEST PROTO DEST PORT(S) -ACCEPT loc fw tcp 53 -ACCEPT loc fw udp 53 -ACCEPT dmz fw tcp 53 -ACCEPT dmz fw udp 53 |
In cases where Shorewall doesn't include a defined action to - meet your needs, you can either define the action yourself or you can - simply code the appropriate rules directly.
The three-interface sample includes the following rule: -
#ACTION SOURCE DEST PROTO DEST PORT(S) -AllowDNS fw net |
That rule allow DNS access from - your firewall and may be removed if you commented out the line in - /etc/shorewall/policy allowing all connections from - the firewall to the internet.
The sample also includes:
#ACTION SOURCE DEST PROTO DEST PORT(S) -AllowSSH loc fw -AllowSSH loc dmz |
Those rules allow you to run - an SSH server on your firewall and in each of your DMZ systems and to - connect to those servers from your local systems.
If you wish to enable other connections between your systems, the - general format for using a defined action is: -
#ACTION SOURCE DEST PROTO DEST PORT(S) -<action> <source zone> <destination zone> |
The general format when not using a defined action is:
#ACTION SOURCE DEST PROTO DEST PORT(S)
-ACCEPT <source zone> <destination zone> <protocol> <port> |
Example 2. You want to run a publicly-available DNS server on your firewall - system
Using defined actions:
#ACTION SOURCE DEST PROTO DEST PORT(S) -AllowDNS net fw |
Not using defined actions:
#ACTION SOURCE DEST PROTO DEST PORT(S) -ACCEPT net fw tcp 53 -ACCEPT net fw udp 53 |
Those rules would of course be in addition to the rules listed - above under "If you run the name server on your firewall".
If you don't know what port and protocol a particular - application uses, look here.
Important
I don't recommend enabling telnet to/from the internet because - it uses clear text (even for login!). If you want shell access to your - firewall from the internet, use SSH:
#ACTION SOURCE DEST PROTO DEST PORT(S) -AllowSSH net fw |
Bering
- users will want to add the following two rules to be compatible with
- Jacques's Shorewall configuration:
#ACTION SOURCE DEST PROTO DEST PORT(S) -ACCEPT loc fw udp 53 -ACCEPT net fw tcp 80 |
Entry - 1 allows the DNS Cache to be used.
Entry - 2 allows the “weblet” to work.
Now modify /etc/shorewall/rules to add or - remove other connections as required.
The installation procedure - configures your system to start Shorewall at system boot but beginning - with Shorewall version 1.3.9 startup is disabled so that your system - won't try to start Shorewall before configuration is complete. Once - you have completed configuration of your firewall, you can enable - Shorewall startup by removing the file /etc/shorewall/startup_disabled. -
Important
Users of the .deb package must edit - /etc/default/shorewall and set startup=1.
- The firewall is started using the shorewall start - command and stopped using shorewall stop. When the - firewall is stopped, routing is enabled on those hosts that have an entry - in /etc/shorewall/routestopped. - A running firewall may be restarted using the shorewall restart - command. If you want to totally remove any trace of Shorewall from your - Netfilter configuration, use shorewall clear.
The three-interface sample assumes that you want to enable routing - to/from eth1 (your local network) - and eth2 (DMZ) when Shorewall is - stopped. If these two interfaces don't connect to your local network - and DMZ or if you want to enable a different set of hosts, modify - /etc/shorewall/routestopped accordingly. -
Warning
If you are connected to your firewall from the internet, do - not issue a shorewall stop command unless you have - added an entry for the IP address that you are connected from to /etc/shorewall/routestopped. - Also, I don't recommend using shorewall restart; it - is better to create an alternate - configuration and test it using the shorewall try - command.
I highly recommend that you review the Common Configuration File Features - page -- it contains helpful tips about Shorewall features than make - administering your firewall easier.
dhcpfrom the option list.
netzone. Any + traffic that you generate from the local network will be associated + with your local interface and will be treated as loc->fw traffic.
-(minus the quotes).
-+ (minus the quotes).