shorewall-docs-xml-4.5.21/ 0000755 0001750 0001750 00000000000 12223303501 015212 5 ustar teastep teastep shorewall-docs-xml-4.5.21/blacklisting_support.xml 0000644 0001750 0001750 00000033331 12222401136 022203 0 ustar teastep teastep
Shorewall Blacklisting/Whitelisting SupportTomEastep2002-200620102011Thomas M. EastepPermission 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.This article applies to Shorewall 4.4 and
later. If you are running a version of Shorewall earlier than Shorewall
4.3.5 then please see the documentation for that
release.IntroductionShorewall supports two different types of blackliisting; rule-based,
static and dynamic. The BLACKLISTNEWONLY option in
/etc/shorewall/shorewall.conf controls the degree of blacklist
filtering:BLACKLISTNEWONLY=No -- All incoming packets are checked against
the blacklist. New blacklist entries can be used to terminate existing
connections.BLACKLISTNEWONLY=Yes -- The blacklists are only consulted for
new connection requests. Blacklists may not be used to terminate
existing connections.For automatic blacklisting based on exceeding defined threshholds,
see Events.Rule-based BlacklistingBeginning with Shorewall 4.4.25, the preferred method of
blacklisting and whitelisting is to use the blrules file (shorewall-blrules (5)).
There you have access to the DROP, ACCEPT, REJECT and WHITELIST actions,
standard and custom macros as well as standard and custom actions. See
shorewall-rules (5) for
details.Example:#ACTION SOURCE DEST PROTO DEST
# PORTS(S)
SECTION BLACKLIST
WHITELIST net:70.90.191.126 all
DROP net all udp 1023:1033,1434,5948,23773
DROP all net udp 1023:1033
DROP net all tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,5948,6101,8081,9898,23773
DROP net:221.192.199.48 all
DROP net:61.158.162.9 all
DROP net:81.21.54.100 all tcp 25
DROP net:84.108.168.139 all
DROP net:200.55.14.18 all
Beginning with Shorewall 4.4.26, the update
command supports a option that causes your legacy
blacklisting configuration to use the blrules file.If you prefer to keep your blacklisting rules in your rules file
(shorewall-rules
(5)), you can place them in the BLACKLIST section of that file rather
than in blrules.Legacy BlacklistingPrior to 4.4.25, two forms of blacklisting were supported; static
and dynamic. The dynamic variety is still appropriate for
on-the-fly blacklisting; the static form is
deprecated.By default, only the source address is
checked against the blacklists. Blacklists only stop
blacklisted hosts from connecting to you — they do not stop you or your
users from connecting to blacklisted hosts .UPDATEBeginning with Shorewall 4.4.12, you can also blacklist by
destination address. See shorewall-blacklist
(5) and shorewall (8)
for details.Dynamic Shorewall blacklisting is not
appropriate for blacklisting 1,000s of different addresses. Static
Blacklisting can handle large blacklists but only if you use
ipsets. Without ipsets, the blacklists will take forever to
load, and will have a very negative effect on firewall
performance.Static BlacklistingShorewall static blacklisting support has the following
configuration parameters:You specify whether you want packets from blacklisted hosts
dropped or rejected using the BLACKLIST_DISPOSITION setting in
shorewall.conf(5).You specify whether you want packets from blacklisted hosts
logged and at what syslog level using the BLACKLIST_LOGLEVEL setting
in shorewall.conf(5).You list the IP addresses/subnets that you wish to blacklist
in shorewall-blacklist
(5). You may also specify PROTOCOL and Port numbers/Service names in
the blacklist file.You specify the interfaces whose incoming packets you want
checked against the blacklist using the blacklist
option in shorewall-interfaces(5)
(shorewall-zones(5) in
Shorewall 4.4.12 and later).Prior to Shorewall 4.4.20, only source-address static blacklisting
was supported.Users with a large static black list may want to set the
DELAYBLACKLISTLOAD option in shorewall.conf (added in Shorewall version
2.2.0). When DELAYBLACKLISTLOAD=Yes, Shorewall will enable new
connections before loading the blacklist rules. While this may allow
connections from blacklisted hosts to slip by during construction of the
blacklist, it can substantially reduce the time that all new connections
are disabled during "shorewall [re]start".Beginning with Shorewall 2.4.0, you can use ipsets to define your static blacklist. Here's
an example:#ADDRESS/SUBNET PROTOCOL PORT
+Blacklistports[dst]
+Blacklistnets[src,dst]
+Blacklist[src,dst]
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVEIn this example, there is a portmap ipset
Blacklistports that blacklists all traffic with
destination ports included in the ipset. There are also
Blacklistnets (type nethash)
and Blacklist (type iphash)
ipsets that allow blacklisting networks and individual IP addresses.
Note that [src,dst] is specified so that individual entries in the sets
can be bound to other portmap ipsets to allow blacklisting
(source address, destination
port) combinations. For example:ipset -N SMTP portmap --from 1 --to 31
ipset -A SMTP 25
ipset -A Blacklist 206.124.146.177
ipset -B Blacklist 206.124.146.177 -b SMTPThis will blacklist SMTP traffic from host 206.124.146.177.Static WhitelistingBeginning with Shorewall 4.4.20, you can create
whitelist entries in the blacklist file.
Connections/packets matching a whitelist entry are not matched against
the entries in the blacklist file that follow. Whitelist entries are
created using the whitelist option
(OPTIONS column). See shorewall-blacklist
(5).Dynamic BlacklistingBeginning with Shorewall 4.4.7, dynamic blacklisting is enabled by
setting DYNAMIC_BLACKLIST=Yes in shorewall.conf.
Prior to that release, the feature is always enabled.Once enabled, dynamic blacklisting doesn't use any configuration
parameters but is rather controlled using /sbin/shorewall[-lite]
commands. Note that to and from may
only be specified when running Shorewall 4.4.12 or
later.drop [to|from] <ip address list> -
causes packets from the listed IP addresses to be silently dropped
by the firewall.reject [to|from]<ip address list> -
causes packets from the listed IP addresses to be rejected by the
firewall.allow [to|from] <ip address list> -
re-enables receipt of packets from hosts previously blacklisted by a
drop or reject
command.save - save the dynamic blacklisting configuration so that it
will be automatically restored the next time that the firewall is
restarted.Update: Beginning with
Shorewall 4.4.10, the dynamic blacklist is automatically retained
over stop/start sequences and over
restart.show dynamic - displays the dynamic blacklisting
configuration.logdrop [to|from] <ip address list>
- causes packets from the listed IP addresses to be dropped and
logged by the firewall. Logging will occur at the level specified by
the BLACKLIST_LOGLEVEL setting at the last [re]start (logging will
be at the 'info' level if no BLACKLIST_LOGLEVEL was given).logreject [to|from}<ip address
list> - causes packets from the listed IP addresses to
be rejected and logged by the firewall. Logging will occur at the
level specified by the BLACKLIST_LOGLEVEL setting at the last
[re]start (logging will be at the 'info' level if no
BLACKLIST_LOGLEVEL was given).Dynamic blacklisting is not dependent on the
blacklist option in
/etc/shorewall/interfaces.Ignore packets from a pair of systemsshorewall[-lite] drop 192.0.2.124 192.0.2.125Drops packets from hosts 192.0.2.124 and 192.0.2.125Re-enable packets from a systemshorewall[-lite] allow 192.0.2.125Re-enables traffic from 192.0.2.125.Displaying the Dynamic Blacklistshorewall show dynamicDisplays the 'dynamic' chain which contains rules for the
dynamic blacklist. The source column contains
the set of blacklisted addresses.
shorewall-docs-xml-4.5.21/XenMyWay-Routed.xml 0000644 0001750 0001750 00000134322 12222401136 020724 0 ustar teastep teastep
Strong Firewall in a Routed Xen Dom0TomEastep20062007Thomas M. EastepPermission 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.This article applies to Shorewall 4.0 and later. If you are running
a version of Shorewall earlier than Shorewall 4.0.0 then please see the
documentation for that release.Before XenPrior to adopting Xen, I had a home office crowded with 5 systems,
three monitors a scanner and a printer. The systems were:FirewallPublic Server in a DMZ (mail)Private Server (wookie)My personal Linux Desktop (ursa)My work system (docked laptop running Windows XP).The result was a very crowded and noisy room.After XenXen has allowed me to reduce the noise and clutter considerably. I
now have three systems with two monitors. I've also replaced the
individual printer and scanner with a Multifunction
FAX/Scanner/Printer.The systems now include:Combination Firewall/Public Server/Private Server/Wireless
Gateway using Xen (created by building out my Linux desktop system --
Now replaced by a Hewlett-Packard Pavilion a1510y).My work system.My Linux desktop (wookie, which is actually the old public
server box)The Linux systems run either OpenSuSE 10.3 or
Ubuntu "Gutsy Gibbon".Here is a high-level diagram of our network.As shown in this diagram, the Xen system has three physical network
interfaces. These are:eth0 -- connected to our
DSL "Modem".eth1 -- connected to the
switch in my office.eth2 -- connected to a
Wireless Access Point (WAP) that interfaces to our wireless
network.There are three Xen domains.Dom0 (DNS name gateway.shorewall.net) is used as our main
firewall and wireless gateway as well as a local file server. It hosts
Squid running as a
transparent HTTP proxy and a DHCP server that manages IP address
assignment for both the LAN and the Wireless network.A DomU (Domain name lists, DNS
name lists.shorewall.net) that is
used as a public Web/FTP/Mail/DNS server.A DomU (Domain name test, DNS
name test.shorewall.net) that I use
for Shorewall testing.Shorewall runs in Dom0.As the developer of Shorewall, I have enough experience to be very
comfortable with Linux networking and Shorewall/iptables. I arrived at
this configuration after a fair amount of trial and error
experimentation (see Xen and the art of
Consolidation). If you are a Linux networking novice, I
recommend that you do not attempt a configuration like this one for your
first Shorewall installation. You are very likely to frustrate both
yourself and the Shorewall support team. Rather I suggest that you start
with something simple like a standalone
installation in a DomU; once you are comfortable with that then
you will be ready to try something more substantial.As Paul Gear says: Shorewall might make iptables easy,
but it doesn't make understanding fundamental networking principles,
traffic shaping, or multi-ISP routing any easier.The same goes for Xen networking.Domain ConfigurationBelow are the relevant configuration files for the two domains. I
use a partition on my hard drives for the DomU storage device.There is not much documentation about how to configure Xen for
routed operation. I've tried to mark the relevant parts with bold font.The files from /etc/xen/auto shown below correspond to
my configuration under Xen 3.0. I'm now running Xen 3.1 which does
not use configuration files for the domains but rather keeps the
configuration in a database managed by xend. See below.
/boot/grub/menu.lst — here is the entry
that boots Xen in Dom0.
/etc/modprobe.conf.local (This may need to
go in /etc/modprobe.conf or
/etc/modprobe.d/options on your system)
options netloop nloopbacks=0 #Stop netloop from creating 8 useless vifs
/etc/xen/auto/01-lists — configuration file
for the lists domain. Placed in /etc/xen/auto/ so it is started
automatically by Xen's xendomains service.
disk = [ 'phy:/dev/sda9,hda,w', 'phy:/dev/hda,hdb,r' ]
memory = 512
vcpus = 1
builder = 'linux'
name = 'server'
vif = [ 'mac=00:16:3e:b1:d7:90, ip=206.124.146.177, vifname=eth3' ]
localtime = 0
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
extra = ' TERM=xterm'
bootloader = '/usr/lib/xen/boot/domUloader.py'
bootentry = 'hda2:/boot/vmlinuz-xen,/boot/initrd-xen'Note that the vifname is set to 'eth3' for the virtual
interface to this DomU. This will cause the Dom0 interface to the
server to have a fixed name (eth3) which makes it a lot easier to
deal with in Shorewall and elsewhere.Specifying an IP address (ip=206.124.146.177) causes the
vif-route script to create a host route to that IP address on
eth3.
gateway:~ # ip route ls dev eth3
206.124.146.177 scope link src 206.124.146.176
gateway:~ #
Note that the source for the route is 206.124.146.176. That is
the primary IP address of Dom0's eth0. Xen configures eth3 to have that same IP
address.
/etc/xen/auto/02-test — configuration file
for the test domain.
…
# It is possible to use the network-bridge script in more complicated
# scenarios, such as having two outgoing interfaces, with two bridges, and
# two fake interfaces per guest domain. To do things like this, write
# yourself a wrapper script, and call network-bridge from it, as appropriate.
#
#(network-script network-bridge)
…
# If you are using only one bridge, the vif-bridge script will discover that,
# so there is no need to specify it explicitly.
#
#(vif-script vif-bridge)
## Use the following if network traffic is routed, as an alternative to the
# settings for bridged networking given above.
(network-script network-route)
(vif-script vif-route)As of this writing, the vif-route script does not set up
Proxy ARP correctly. So the domU can communicate with the dom0
but not with hosts beyond the dom0.If you configure Shorewall as described below, Shorewall
will correct the Proxy ARP configuration so that it will
work.
Instructions for editing entries in the Xen 3.1 xend
database may be found at http://www.novell.com/documentation/vmserver/config_options/index.html?page=/documentation/vmserver/config_options/data/b8uh3zr.html,
The following are excerpts from the XML representations of the two user
domains (produced by "xm list -l …").lists domain:
With the three Xen domains up and running, the system looks as
shown in the following diagram.The zones correspond to the Shorewall zones in the Dom0
configuration.Readers who are paying attention will notice that eth4 has the
same public IP address (206.124.146.176) as eth0 (and eth3), yet the
test system connected to that interface
has an RFC 1918 address (192.168.1.7). That configuration is established
by Xen which clones the primary IP address of eth0 on all of the routed
virtual interfaces that it creates. test is configured with it's default route via
192.168.1.254 which is the IP address of the firewall's br0. That works
because of the way that the Linux network stack treats local IPv4
addresses; by default, it will respond to ARP "who-has" broadcasts for
any local address and not just for the addresses on the interface that
received the broadcast (but of course the MAC address returned in the
"here-is" response is that of the interface that received the
broadcast). So when test broadcasts
"who-has 192.168.1.254", the firewall responds with "here-is
192.168.1.254 00:16:3e:83:ad:28" (00:16:3e:83:ad:28 is the MAC of
virtual interface eth4).Under some circumstances, UDP and/or TCP communication from a
DomU won't work for no obvious reason. That happened with the
lists domain in my setup. Looking at
the IP traffic with tcpdump -nvvi eth1 in Dom0
showed that UDP packets from the lists DomU had incorrect checksums. That
problem was corrected by arranging for the following command to be
executed in the lists and test domains when the eth0 device was brought up:ethtool -K eth0 tx offUnder OpenSuSE 10.2, I placed the
following in
/etc/sysconfig/network/ifcfg-eth-id-00:16:3e:b1:d7:90
(the config file for eth0):ETHTOOL_OPTIONS='-K iface tx off'Under other distributions, the technique will vary. For example,
under Debian or Ubuntu,
you can just add a 'post-up' entry to
/etc/network/interfaces as shown here: iface eth0 inet static
address 206.124.146.177
netmask 255.255.255.0
post-up ethtool -K eth0 tx offUpdate. Under OpenSuSE 10.2, communication from a domU works
okay without running ethtool but traffic shaping
in dom0 doesn't work! So it's a good idea to run it just to
be safe.Dom0 Shorewall ConfigurationIn Dom0, I run a conventional three-interface firewall with Proxy
ARP DMZ -- it is very similar to the firewall described in the Shorewall Setup Guide with the
exception that I've added a fourth interface for our wireless network.
The firewall runs a routed OpenVPN
server to provide road warrior access for our three laptops and
a bridged OpenVPN server for the wireless network in our home. Here is
the firewall's view of the network:The three laptops can be directly attached to the LAN as shown
above or they can be attached wirelessly -- their IP addresses are the
same in either case; when they are directly attached, the IP address is
assigned by the DHCP server running in Dom0 and when they are attached
wirelessly, the IP address is assigned by OpenVPN.The Shorewall configuration files are shown below. All routing and
secondary IP addresses are handled in the OpenSuSE network
configuration.
/etc/shorewall/shorewall.confSTARTUP_ENABLED=Yes
VERBOSITY=0
SHOREWALL_COMPILER=perl
LOGFILE=/var/log/firewall
LOGFORMAT="Shorewall:%s:%s:"
LOGTAGONLY=No
LOGRATE=
LOGBURST=
LOGALLNEW=
BLACKLIST_LOGLEVEL=
MACLIST_LOG_LEVEL=$LOG
TCP_FLAGS_LOG_LEVEL=$LOG
SMURF_LOG_LEVEL=$LOG
LOG_MARTIANS=No
IPTABLES=
SHOREWALL_SHELL=/bin/ash
SUBSYSLOCK=/var/lock/subsys/shorewall
MODULESDIR=
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
RESTOREFILE=
IPSECFILE=zones
LOCKFILE=
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
IP_FORWARDING=Yes
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
RETAIN_ALIASES=No
TC_ENABLED=internal
TC_EXPERT=No
CLEAR_TC=Yes
MARK_IN_FORWARD_CHAIN=Yes
CLAMPMSS=Yes
ROUTE_FILTER=No
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
ADMINISABSENTMINDED=Yes
BLACKLISTNEWONLY=Yes
DELAYBLACKLISTLOAD=No
MODULE_SUFFIX=
DISABLE_IPV6=Yes
BRIDGING=No
DYNAMIC_ZONES=No
PKTTYPE=No
MACLIST_TABLE=mangle
MACLIST_TTL=60
SAVE_IPSETS=No
MAPOLDACTIONS=No
FASTACCEPT=Yes
IMPLICIT_CONTINUE=Yes
HIGH_ROUTE_MARKS=Yes
USE_ACTIONS=Yes
OPTIMIZE=1
EXPORTPARAMS=No
EXPAND_POLICIES=Yes
KEEP_RT_TABLES=No
DELETE_THEN_ADD=No
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=DROP
TCP_FLAGS_DISPOSITION=DROP/etc/shorewall/zones:#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall #The firewall itself.
net ipv4 #Internet
loc ipv4 #Local wired Zone
dmz ipv4 #DMZ
vpn ipv4 #Open VPN clients
wifi ipv4 #Local Wireless Zone
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE
/etc/shorewall/policy:#SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
$FW $FW ACCEPT
$FW net ACCEPT
loc net ACCEPT
$FW vpn ACCEPT
vpn net ACCEPT
vpn loc ACCEPT
loc vpn ACCEPT
$FW loc ACCEPT
loc $FW ACCEPT
wifi all REJECT $LOG
net $FW DROP $LOG 1/sec:2
net loc DROP $LOG 2/sec:4
net dmz DROP $LOG 8/sec:30
net vpn DROP $LOG
all all REJECT $LOG
#LAST LINE -- DO NOT REMOVENote that the firewall<->local network interface
is wide open so from a security point of view, the firewall system is
part of the local zone./etc/shorewall/params (edited):MIRRORS=<comma-separated list of Shorewall mirrors>
NTPSERVERS=<comma-separated list of NTP servers I sync with>
POPSERVERS=<comma-separated list of server IP addresses>
LOG=info
INT_IF=br0
DMZ_IF=eth3
EXT_IF=eth0
WIFI_IF=eth2
TEST_IF=eth4
OMAK=<IP address at our second home>
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE/etc/shorewall/init:echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal/etc/shorewall/interfaces (don't specify
the BROADCAST addresses if you are using Shorewall-perl):#ZONE INTERFACE BROADCAST OPTIONS
net ${EXT_IF} detect dhcp,logmartians=1,blacklist
dmz $DMZ_IF detect logmartians=1
loc $INT_IF detect dhcp,logmartians=1,routeback,bridge
loc $TEST_IF detect optional
loc $TEST1_IF detect optional
wifi $WIFI_IF detect dhcp,maclist,mss=1400
vpn tun+ -
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE/etc/shorewall/nat:#EXTERNAL INTERFACE INTERNAL ALL LOCAL
# INTERFACES
COMMENT One-to-one NAT
206.124.146.178 $EXT_IF:0 192.168.1.3 No No
206.124.146.180 $EXT_IF:2 192.168.1.6 No No
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE/etc/shorewall/masq (Note the cute trick here and in
the following proxyarp file that allows me to
access the DSL "Modem" using its default IP address
(192.168.1.1)). The leading "+" is required to place the
rule before the SNAT rules generated by entries in
/etc/shorewall/nat above.#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC
COMMENT Handle DSL 'Modem'
+$EXT_IF:192.168.1.1 0.0.0.0/0 192.168.1.254
COMMENT Masquerade VPN clients and Wifi
$EXT_IF 192.168.2.0/24
$EXT_IF 192.168.3.0/24
$EXT_IF:192.168.98.1 192.168.99.1 192.168.1.99
$EXT_IF:192.168.99.1 192.168.98.1 192.168.1.98
COMMENT Masquerade Local Network
$EXT_IF $INT_IF 206.124.146.179
#LAST LINE -- ADD YOUR ENTRIES ABOVE THIS LINE -- DO NOT REMOVE/etc/shorewall/proxyarp:#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
192.168.1.1 $EXT_IF $INT_IF yes
206.124.146.177 $DMZ_IF $EXT_IF yes
192.168.1.7 $TEST_IF $INT_IF yes
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE/etc/shorewall/tunnels:#TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpnserver:udp net 0.0.0.0/0 #Routed server for RoadWarrior access
openvpnserver:udp wifi 192.168.3.0/24 #Home wireless network server
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE/etc/shorewall/blacklist:#ADDRESS/SUBNET PROTOCOL PORT
- udp 1024:1033,1434
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE/etc/shorewall/actions:#ACTION
Mirrors # Accept traffic from Shorewall Mirrors
#LAST LINE - ADD YOUR ENTRIES ABOVE THIS ONE - DO NOT REMOVE/etc/shorewall/action.Mirrors:#TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
ACCEPT $MIRRORS
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE/etc/shorewall/rules:SECTION NEW
###############################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
###############################################################################################################################################################################
REJECT:$LOG loc net tcp 25
REJECT:$LOG loc net udp 1025:1031
#
# Stop NETBIOS crap
#
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
#
# Stop my idiotic work laptop from sending to the net with an HP source/dest IP address
#
DROP loc:!192.168.0.0/22 net
###############################################################################################################################################################################
# Local Network to Firewall
#
REDIRECT- loc 3128 tcp 80 - !192.168.1.1,192.168.0.7,206.124.146.177,155.98.64.80
###############################################################################################################################################################################
# Road Warriors to Firewall
#
ACCEPT vpn fw tcp ssh,time,631,8080
ACCEPT vpn fw udp 161,ntp,631
Ping(ACCEPT) vpn fw
###############################################################################################################################################################################
# Road Warriors to DMZ
#
ACCEPT vpn dmz udp domain
ACCEPT vpn dmz tcp www,smtp,smtps,domain,ssh,imap,https,imaps,ftp,10023,pop3 -
Ping(ACCEPT) vpn dmz
###############################################################################################################################################################################
# Local network to DMZ
#
ACCEPT loc dmz udp domain
ACCEPT loc dmz tcp ssh,smtps,www,ftp,imaps,domain,https -
ACCEPT loc dmz tcp smtp
Trcrt(ACCEPT) loc dmz
###############################################################################################################################################################################
# Internet to ALL -- drop NewNotSyn packets
#
dropNotSyn net fw tcp
#dropNotSyn net loc tcp
dropNotSyn net dmz tcp
###############################################################################################################################################################################
# Internet to DMZ
#
ACCEPT net dmz udp domain
LOG:$LOG net:64.126.128.0/18 dmz tcp smtp
ACCEPT net dmz tcp smtps,www,ftp,imaps,domain,https -
ACCEPT net dmz tcp smtp - 206.124.146.177,206.124.146.178
ACCEPT net dmz udp 33434:33454
Mirrors net dmz tcp rsync
Limit:$LOG:SSHA,3,60\
net dmz tcp 22
Trcrt(ACCEPT) net dmz
##############################################################################################################################################################################
#
# Net to Local
#
# When I'm "on the road", the following two rules allow me VPN access back home using PPTP.
#
DNAT net loc:192.168.1.4 tcp 1729
DNAT net loc:192.168.1.4 gre
#
# Roadwarrior access to Ursa
#
ACCEPT net:$OMAK loc tcp 22
Limit:$LOG:SSHA,3,60\
net loc tcp 22
#
# ICQ
#
ACCEPT net loc:192.168.1.3 tcp 113,4000:4100
#
# Bittorrent
#
ACCEPT net loc:192.168.1.3 tcp 6881:6889,6969
ACCEPT net loc:192.168.1.3 udp 6881:6889,6969
#
# Real Audio
#
ACCEPT net loc:192.168.1.3 udp 6970:7170
#
# Overnet
#
#ACCEPT net loc:192.168.1.3 tcp 4662
#ACCEPT net loc:192.168.1.3 udp 12112
#
# OpenVPN
#
ACCEPT net loc:192.168.1.3 udp 1194
ACCEPT net loc:192.168.1.6 udp 1194
# Skype
#
ACCEPT net loc:192.168.1.6 tcp 1194
#
# Traceroute
#
Trcrt(ACCEPT) net loc:192.168.1.3
#
# Silently Handle common probes
#
REJECT net loc tcp www,ftp,https
DROP net loc icmp 8
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net udp domain,ntp
ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080
ACCEPT dmz net:$POPSERVERS tcp pop3
Ping(ACCEPT) dmz net
#
# Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking
# code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases
# but logs the connection so I can keep an eye on this potential security hole.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# Local to DMZ
#
ACCEPT loc dmz udp domain,xdmcp
ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128
Trcrt(ACCEPT) loc dmz
###############################################################################################################################################################################
# DMZ to Local
#
ACCEPT dmz loc:192.168.1.5 udp 123
ACCEPT dmz loc:192.168.1.5 tcp 21
Ping(ACCEPT) dmz loc
###############################################################################################################################################################################
# DMZ to Firewall -- ntp & snmp, Silently reject Auth
#
#ACCEPT net loc:192.168.1.3 udp 12112
#
# OpenVPN
#
ACCEPT net loc:192.168.1.3 udp 1194
ACCEPT net loc:192.168.1.6 udp 1194
# Skype
#
ACCEPT net loc:192.168.1.6 tcp 1194
#
# Traceroute
#
Trcrt(ACCEPT) net loc:192.168.1.3
#
# Silently Handle common probes
#
REJECT net loc tcp www,ftp,https
DROP net loc icmp 8
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net udp domain,ntp
ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,https,cvspserver,2702,2703,8080
ACCEPT dmz net:$POPSERVERS tcp pop3
Ping(ACCEPT) dmz net
#
# Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking
# code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases
# but logs the connection so I can keep an eye on this potential security hole.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# Local to DMZ
#
ACCEPT loc dmz udp domain,xdmcp
ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128
Trcrt(ACCEPT) loc dmz
###############################################################################################################################################################################
# DMZ to Local
#
ACCEPT dmz loc:192.168.1.5 udp 123
ACCEPT dmz loc:192.168.1.5 tcp 21
Ping(ACCEPT) dmz loc
###############################################################################################################################################################################
# DMZ to Firewall -- ntp & snmp, Silently reject Auth
#
ACCEPT loc dmz udp domain,xdmcp
ACCEPT loc dmz tcp www,smtp,smtps,domain,ssh,imap,rsync,https,imaps,ftp,10023,pop3,3128
Trcrt(ACCEPT) loc dmz
###############################################################################################################################################################################
# DMZ to Local
#
ACCEPT dmz loc:192.168.1.5 udp 123
ACCEPT dmz loc:192.168.1.5 tcp 21
Ping(ACCEPT) dmz loc
###############################################################################################################################################################################
# DMZ to Firewall -- ntp & snmp, Silently reject Auth
#
ACCEPT dmz fw tcp 161,ssh
ACCEPT dmz fw udp 161,ntp
REJECT dmz fw tcp auth
Ping(ACCEPT) dmz fw
###############################################################################################################################################################################
# Internet to Firewall
#
REJECT net fw tcp www,ftp,https
DROP net fw icmp 8
ACCEPT net fw udp 33434:33454
ACCEPT net:$OMAK fw udp ntp
ACCEPT net fw tcp auth
ACCEPT net:$OMAK fw tcp 22
Limit:$LOG:SSHA,3,60\
net fw tcp 22
Trcrt(ACCEPT) net fw
#
# Bittorrent
#
ACCEPT net fw tcp 6881:6889,6969
ACCEPT net fw udp 6881:6889,6969
###############################################################################################################################################################################
# Firewall to DMZ
#
ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,https,993,465
ACCEPT fw dmz udp domain
REJECT fw dmz udp 137:139
Ping(ACCEPT) fw dmz
##############################################################################################################################################################################
# Avoid logging Freenode.net probes
#
DROP net:82.96.96.3 all
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE/etc/shorewall/tcdevices#INTERFACE IN-BANDWITH OUT-BANDWIDTH
$EXT_IF 1300kbit 384kbit
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
/etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
$EXT_IF 10 5*full/10 full 1 tcp-ack,tos-minimize-delay
$EXT_IF 20 3*full/10 9*full/10 2 default
$EXT_IF 30 2*full/10 6*full/10 3
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE/etc/shorewall/tcrules#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST
# PORT(S)
1:110 192.168.0.0/22 $EXT_IF #Our internal nets get priority
#over the server
1:130 206.124.146.177 $EXT_IF tcp - 873 #Throttle rsync traffic to the
#Shorewall Mirrors.
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE
The tap0 device used by
the bridged OpenVPN server is created and bridged to eth1 using a SUSE-specific SysV init
script:
#!/bin/sh
#
# The Shoreline Firewall (Shorewall) Packet Filtering Firewall - V3.0
#
# This program is under GPL [http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt]
#
# (c) 1999,2000,2001,2002,2003,2004,2005 - Tom Eastep (teastep@shorewall.net)
#
# On most distributions, this file should be called /etc/init.d/shorewall.
#
# Complete documentation is available at http://shorewall.net
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of Version 2 of the GNU General Public License
# as published by the Free Software Foundation.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
#
# If an error occurs while starting or restarting the firewall, the
# firewall is automatically stopped.
#
# Commands are:
#
# bridge start Starts the bridge
# bridge restart Restarts the bridge
# bridge reload Restarts the bridge
# bridge stop Stops the bridge
# bridge status Displays bridge status
#
# chkconfig: 2345 4 99
# description: Packet filtering firewall
### BEGIN INIT INFO
# Provides: bridge
# Required-Start: boot.udev
# Required-Stop:
# Default-Start: 2 3 5
# Default-Stop: 0 1 6
# Description: starts and stops the bridge
### END INIT INFO
################################################################################
# Interfaces to be bridged -- may be listed by device name or by MAC
#
INTERFACES="eth1"
#
# Tap Devices
#
TAPS="tap0"
################################################################################
# Give Usage Information #
################################################################################
usage() {
echo "Usage: $0 start|stop|reload|restart|status"
exit 1
}
#################################################################################
# Find the interface with the passed MAC address
#################################################################################
find_interface_by_mac() {
local mac
mac=$1
local first
local second
local rest
local dev
/sbin/ip link ls | while read first second rest; do
case $first in
*:)
dev=$second
;;
*)
if [ "$second" = $mac ]; then
echo ${dev%:}
return
fi
esac
done
}
################################################################################
# Convert MAC addresses to interface names
################################################################################
get_interfaces() {
local interfaces
interfaces=
local interface
for interface in $INTERFACES; do
case $interface in
*:*:*)
interface=$(find_interface_by_mac $interface)
[ -n "$interface" ] || echo "WARNING: Can't find an interface with MAC address $mac"
;;
esac
interfaces="$interfaces $interface"
done
INTERFACES="$interfaces"
}
################################################################################
# Start the Bridge
################################################################################
do_start()
{
local interface
get_interfaces
for interface in $TAPS; do
/usr/sbin/openvpn --mktun --dev $interface
done
/sbin/brctl addbr br0
for interface in $INTERFACES $TAPS; do
/sbin/ip link set $interface up
/sbin/brctl addif br0 $interface
done
}
################################################################################
# Stop the Bridge
################################################################################
do_stop()
{
local interface
get_interfaces
for interface in $INTERFACES $TAPS; do
/sbin/brctl delif br0 $interface
/sbin/ip link set $interface down
done
/sbin/ip link set br0 down
/sbin/brctl delbr br0
for interface in $TAPS; do
/usr/sbin/openvpn --rmtun --dev $interface
done
}
################################################################################
# E X E C U T I O N B E G I N S H E R E #
################################################################################
command="$1"
case "$command" in
start)
do_start
;;
stop)
do_stop
;;
restart|reload)
do_stop
do_start
;;
status)
/sbin/brctl show
;;
*)
usage
;;
esac
shorewall-docs-xml-4.5.21/support.xml 0000644 0001750 0001750 00000046667 12222401136 017475 0 ustar teastep teastep
Shorewall Support Guide2001-20011Thomas M. EastepPermission 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.This article applies to Shorewall 4.0 and
later. If you are running a version of Shorewall earlier than Shorewall
4.0.0 then please see the documentation for that
release.Before Reporting a Problem or Asking a QuestionThere are a number of sources of Shorewall information. Please try
these before you post.The currently-supported Shorewall major release is 4.5.Shorewall versions earlier than 4.5.0 are no longer supported;
we will try to help but we will not spend time reading earlier code
to try to help you solve a problem and we will not release a patch
to correct any defect found.More than half of the questions posted on the support list have
answers directly accessible from the Documentation IndexThe FAQ has solutions to more than
90 common problems.The Troubleshooting
Information contains a number of tips to help you solve common
problems.The Shorewall
Users Mailing List Archives are a good source of
information.Problem Reporting GuidelinesPlease refer to the following flowchart to guide you through the
problem reporting process. It will ensure that you provide us with the
information we need to solve your problem as quickly as possible.Please don't use distribution specific
programs like "service" or init scripts to start/restart Shorewall
while trying to solve a problem, just follow carefully the
instructions below.As a general matter, please do not edit
the diagnostic information in an attempt to conceal your IP
address, netmask, nameserver addresses, domain name, etc. These
aren't secrets, and concealing them
often misleads us (and 80% of the time, a cracker could derive them
anyway from information contained in the SMTP headers of your
post).If your problem is that an error occurs when you try to
shorewall start or if Shorewall is
otherwise failing to start properly, then please do the
following.
If your VERBOSITY setting in shorewall.conf is less than 2 and
you are running the Shorewall-shell compiler, then try running with
a higher verbosity level by using the "-vv" option:
shorewall -vv [re]start
That will give you additional progress messages that may make
it clear which entry in which file is generating the error.If that didn't solve your problem, then please/sbin/shorewall trace start 2> /tmp/traceForward the /tmp/trace file as an
attachment compressed with gzip or bzip2 (If you are running
Shorewall-perl, there is no need to compress the file — it will be
very short).If compilation succeeds but the compiled program fails, then
please include the compiled program with your report. The compiled
program will be named /var/lib/shorewall/.start
if the command is shorewall start and it will be
named /var/lib/shorewall/.restart if the
command is shorewall restart.If you are running Shorewall-perl 4.0.5 or later, you may also
include the word debug as the first
argument to the /sbin/shorewall and
/sbin/shorewall-lite commands.shorewall debug restartIn
most cases, debug is a synonym for
trace. The exceptions are:debug is ignored by the
Shorewall-perl compiler.debug causes altered
behavior of scripts generated by the Shorewall-perl compiler.
These scripts normally use iptables-restore
to install the Netfilter ruleset but with debug, the commands normally passed to
iptables-restore in its input file are passed
individually to iptables. This is a
diagnostic aid which allows identifying the individual command
that is causing iptables-restore to fail; it
should be used when iptables-restore fails when executing a
COMMIT command.The debug feature is
strictly for problem analysis. When debug is used:The firewall is made 'wide open' before the rules are
applied.The routestopped file is not
consulted.The rules are applied in the canonical
iptables-restore order. So if you need
critical hosts to be always available during start/restart,
you may not be able to use debug.
If you are unsure if Shorewall is starting successfully or not
then first note that if Shorewall starts successfully, the last
message produced by Shorewall 3.0 is "Shorewall Started" and the last
message produced by Shorewall is "done.":
…
Activating Rules...
done.
gateway:~#
If you are seeing this message then Shorewall is starting
successfully.If you are still unsure if Shorewall is starting or not, enter
the following command:
/sbin/shorewall status
If Shorewall has started successfully, you will see output
similar to this:
Shorewall-4.0.6 Status at gateway - Thu Mar 30 14:07:29 PDT 2008
Shorewall is running
State:Started (Thu Mar 30 14:07:29 PDT 2006)
If Shorewall has not started properly, you will see output
similar to this:
Shorewall-4.0.6 Status at gateway - Thu Mar 30 14:08:11 PDT 2008
Shorewall is stopped
State:Stopped (Thu Mar 30 14:08:11 PDT 2006)
The "State:" refers to the Shorewall State
Diagram.If Shorewall is starting successfully and your problem is that
some set of connections to/from or
through your firewall isn't working
(examples: local systems can't access the Internet, you can't send
email through the firewall, you can't surf the web from the firewall,
connections that you are certain should be rejected are mysteriously
accepted, etc.) or you are having problems with
traffic shaping then please perform the following six
steps:Be sure that the LOGFILE setting in
/etc/shorewall/shorewall.conf is correct (that it names
the file where 'Shorewall' messages are being logged). See shorewall.conf (5) and
the Shorewall Logging
Article.If you are running Ubuntu Precise with
Shorewall 4.4.26.1, then please edit
/sbin/shorewall and change the first line
to:#!/bin/bashIf your problem has anything to do with IPSEC, be sure that
the ipsec-tools package is installed.If Shorewall isn't started then /sbin/shorewall
start. Otherwise /sbin/shorewall
reset.Try making the connection that is failing./sbin/shorewall dump >
/tmp/shorewall_dump.txtPost the /tmp/status.txt file as an
attachment compressed with gzip or bzip2.Describe where you are trying to make the connection from
(IP address) and what host (IP address) you are trying to connect
to.Otherwise:Shorewall is starting successfully and you have no connection problems and you have no traffic shaping problems. Your problem is
with performance, logging, etc. Please include the following:the exact version of Shorewall you are running./sbin/shorewall versionthe complete exact output ofip addr showthe complete exact output ofip route showA detailed description of your problem.Please remember we only know what is posted in your message. Do
not leave out any information that appears to be correct, or was
mentioned in a previous post. There have been countless posts by
people who were sure that some part of their configuration was correct
when it actually contained a small error. We tend to be skeptics where
detail is lacking.Please keep in mind that you're asking for free technical support. Any help we offer is an
act of generosity, not an obligation. Try to
make it easy for us to help you. Follow good, courteous
practices in writing and formatting your e-mail. Provide details that
we need if you expect good answers. Exact quoting of error messages,
log entries, command output, and other output is better than a
paraphrase or summary.Please give details about what doesn't
work. Reports that say I followed the directions and
it didn't work may elicit sympathy but probably little in the
way of help. Again -- if ping from A to B fails, say so (and see below
for information about reporting ping problems). If
Computer B doesn't show up in Network Neighborhood then
say so. If access by IP address works but by DNS names it doesn't then
say so.Please don't describe your environment and then ask us to send
you custom configuration files. We're here to answer your questions
but we can't do your job for you.Please do NOT include the output
ofiptables -L — the output of shorewall show or shorewall
dump is much more useful to us.Do you see any Shorewall messages
(/sbin/shorewall show log) when you
exercise the function that is giving you problems? If so, include the
message(s) in your post.Please do not include Shorewall
configuration files unless you have been specifically asked
to do so. The output of shorewall dump collected as
described above is much more useful.The list server limits the size of posts
to the lists, so don't post graphics of your network layout, etc. to
the Mailing List -- your post will be rejected.The author gratefully acknowledges that the above list was
heavily plagiarized from the excellent LEAF document by Ray
Olszewski found here.Where to Send your Problem Report or to Ask for HelpIf you haven't read the Problem Reporting Guidelines above, please
read them now — Failure to supply the information that we need will just
delay a solution to your problem.If you run the current development release and
your question involves a feature that is only available in the development
release (see the Shorewall Release
Model page) then please post your question or problem to the
Shorewall
Development Mailing List.Otherwise, please post your question or problem report to the Shorewall users mailing
list.IMPORTANT: You must subscribe to
the mailing lists before you will be able to post to them (see links
below).For quick questions, there is also
a #shorewall channel at irc.freenode.net.Subscribing to the Users Mailing ListTo Subscribe to the users mailing list go to https://lists.sourceforge.net/lists/listinfo/shorewall-users.Subscribing to the Announce Mailing ListTo Subscribe to the announce mailing list (low-traffic,read only) go
to:https://lists.sourceforge.net/lists/listinfo/shorewall-announceSubscribing to the Development Mailing ListTo Subscribe to the development mailing list go to https://lists.sourceforge.net/lists/listinfo/shorewall-devel.Unsubscribing from Shorewall Mailing ListsSee Shorewall FAQ 98.Other Mailing ListsFor information on other Shorewall mailing lists, go to http://sourceforge.net/mail/?group_id=22587
.
shorewall-docs-xml-4.5.21/fallback.xml 0000644 0001750 0001750 00000005546 12222401136 017507 0 ustar teastep teastep
Fallback and UninstallTomEastep2001-2009Thomas M. EastepPermission 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.Falling Back to the Previous Version of Shorewall using the
Fallback ScriptIf you install Shorewall and discover that it doesn't work for you,
you can fall back to your previously installed version. To do that:cd to the distribution directory for the version of Shoreline
Firewall that you want to fall back to.Type ./install.shFalling Back to the Previous Version of Shorewall using rpmIf your previous version of Shorewall was installed using RPM, you
may fall back to that version by typing rpm -Uvh --force <old
rpm> at a root shell prompt (Example: rpm -Uvh --force
/downloads/shorewall-3.1.1-0.noarch.rpm would fall back to the
3.1.1-0 version of Shorewall).Uninstalling ShorewallIf you no longer wish to use Shorewall, you may remove it by:cd to the distribution directory for the version of Shorewall
that you have installed.type ./uninstall.shIf you installed using an rpm, at a root shell prompt type
rpm -e shorewall.If you specified LIBEXEC and/or PERLLIB when you installed
Shorewall, you must specify the same value to the uninstall script.
e.g., LIBEXEC=libexec ./uninstall.sh.
shorewall-docs-xml-4.5.21/shorewall_logging.xml 0000644 0001750 0001750 00000033520 12222401136 021447 0 ustar teastep teastep
Shorewall LoggingTomEastep2001 - 2009Thomas M. EastepPermission 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.This article applies to Shorewall 4.3 and
later. If you are running a version of Shorewall earlier than Shorewall
4.3.5 then please see the documentation for that
release.How to Log Traffic Through a Shorewall FirewallThe disposition of packets entering a Shorewall firewall is
determined by one of a number of Shorewall facilities. Only some of these
facilities permit logging.The packet is part of an established connection. While the
packet can be logged using LOG rules in the ESTABLISHED section of
/etc/shorewall/rules, that
is not recommended because of the large amount of information that may
be logged.The packet represents a connection request that is related to an
established connection (such as a data
connection associated with an FTP control connection). These
packets may be logged using LOG rules in the RELATED section of /etc/shorewall/rules.The packet is rejected because of an option in /etc/shorewall/shorewall.conf
or /etc/shorewall/interfaces.
These packets can be logged by setting the appropriate logging-related
option in /etc/shorewall/shorewall.conf.The packet matches a rule in /etc/shorewall/rules. By
including a syslog level (see below) in the ACTION column of a rule
(e.g., ACCEPT:info net $FW tcp
22), the connection attempt will be logged at that
level.The packet doesn't match a rule so it is handled by a policy
defined in /etc/shorewall/policy.
These may be logged by specifying a syslog level in the LOG LEVEL
column of the policy's entry (e.g., loc net ACCEPT info).Where the Traffic is Logged and How to Change the
DestinationBy default, Shorewall directs Netfilter to log using syslog (8).
Syslog classifies log messages by a facility and a
priority (using the notation
facility.priority).The facilities defined by syslog are auth, authpriv, cron,
daemon, kern, lpr, mail, mark, news, syslog, user, uucp and
local0 through local7.Throughout the Shorewall documentation, I will use the term
level rather than priority since
level is the term used by Netfilter. The syslog
documentation uses the term priority.Syslog LevelsSyslog levels are a method of describing to syslog (8) the
importance of a message. A number of Shorewall parameters have a syslog
level as their value.Valid levels are:7 - debug (Debug-level
messages)6 - info
(Informational)5 - notice (Normal but
significant Condition)4 - warning (Warning
Condition)3 - err (Error
Condition)2 - crit (Critical
Conditions)1 - alert (must be handled
immediately)0 - emerg (System is
unusable)For most Shorewall logging, a level of 6 (info) is appropriate.
Shorewall log messages are generated by Netfilter and are logged using
the kern facility and the level that you specify.
If you are unsure of the level to choose, 6 (info) is a safe bet. You
may specify levels by name or by number.Beginning with Shorewall 4.5.5, the
level name or number may be optionally
followed by a comma-separated list of one or more log
options. The list is enclosed in parentheses. Log options
cause additional information to be included in each log message.Valid log options are:ip_optionsLog messages will include the option settings from the IP
header.macdecodeDecode the MAC address and protocol.tcp_sequenceInclude TCP sequence numbers.tcp_optionsInclude options from the TCP header.uidInclude the UID of the sending program; only valid for
packets originating on the firewall itself.Example: info(tcp_options,tcp_sequence)Syslogd writes log messages to files (typically in /var/log/*) based on their facility and
level. The mapping of these facility/level pairs to log files is done in
/etc/syslog.conf (5). If you make changes to this file, you must restart
syslogd before the changes can take effect.Syslog may also write to your system console. See Shorewall FAQ 16 for ways to avoid having
Shorewall messages written to the console.Configuring a Separate Log for Shorewall Messages (ulogd)There are a couple of limitations to syslogd-based logging:If you give, for example, kern.info its own log destination
then that destination will also receive all kernel messages of
levels 5 (notice) through 0 (emerg).All kernel.info messages will go to that destination and not
just those from Netfilter.If your kernel has ULOG target support (and most vendor-supplied
kernels do), you may also specify a log level of ULOG (must be all
caps). When ULOG is used, Shorewall will direct Netfilter to log the
related messages via the ULOG target which will send them to a process
called ulogd. The ulogd program is included in most
distributions and is also available from http://www.netfilter.org/projects/ulogd/index.html.
Ulogd can be configured to log all Shorewall messages to their own log
file.The ULOG logging mechanism is completely separate from syslog. Once you
switch to ULOG, the settings in /etc/syslog.conf
have absolutely no effect on your Shorewall logging (except for
Shorewall status messages which still go to syslog).You will need to change all instances of log levels (usually
info) in your Shorewall configuration files to
ULOG - this includes entries in the policy, rules and
shorewall.conf files. Here's what I had at one time:gateway:/etc/shorewall# grep -v ^\# * | egrep '\$LOG|ULOG|LOGFILE'
params:LOG=ULOG
policy:loc $FW REJECT $LOG
policy:net all DROP $LOG 10/sec:40
policy:all all REJECT $LOG
rules:REJECT:$LOG loc net tcp 25
rules:REJECT:$LOG loc net udp 1025:1031
rules:REJECT:$LOG dmz net udp 1025:1031
rules:ACCEPT:$LOG dmz net tcp 1024: 20
rules:REJECT:$LOG $FW net udp 1025:1031
shorewall.conf:LOGFILE=/var/log/shorewall
shorewall.conf:LOGUNCLEAN=$LOG
shorewall.conf:MACLIST_LOG_LEVEL=$LOG
shorewall.conf:TCP_FLAGS_LOG_LEVEL=$LOG
shorewall.conf:RFC1918_LOG_LEVEL=$LOG
gateway:/etc/shorewall# Finally edit /etc/shorewall/shorewall.conf
and set LOGFILE=<file that you wish to log
to>. This tells the /sbin/shorewall
program where to look for the log when processing its
show log,
logwatch and
dump commands.The NFLOG target, a successor to ULOG, is supported shorewall.
Both ULOG and NFLOG may be followed by a list of up to three numbers in
parentheses.The first number specifies the netlink group (1-32). If
omitted (e.g., NFLOG(,0,10)) then a value of 1 is assumed.The second number specifies the maximum number of bytes to
copy. If omitted, 0 (no limit) is assumed.The third number specifies the number of log messages that
should be buffered in the kernel before they are sent to user space.
The default is 1.Examples:/etc/shorewall/shorewall.conf:
MACLIST_LOG_LEVEL=NFLOG(1,0,1)/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT:NFLOG(1,0,1) vpn fw tcp ssh,time,631,8080 Syslog-ngHere
is a post describing configuring syslog-ng to work with Shorewall. Recent
SUSE releases come preconfigured with syslog-ng
with Netfilter messages (including Shorewall's) are written to
/var/log/firewall.Understanding the Contents of Shorewall Log MessagesFor general information on the contents of Netfilter log messages,
see http://logi.cc/en/2010/07/netfilter-log-format/.For Shorewall-specific information, see FAQ #17.
shorewall-docs-xml-4.5.21/Helpers.xml 0000644 0001750 0001750 00000042534 12222401136 017350 0 ustar teastep teastep
Netfilter HelpersTomEastep2012Thomas M. EastepPermission 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.Helpers - IntroductionThere are a number of applications that create connections
dynamically between a client and server. These connections use temporary
TCP or UDP ports, so static configuration of firewall rules to allow those
connections would require a very lax firewall configuration. To deal with
these problem applications, Netfilter supports the concept of a
helper. Each helper monitors traffic to/from the
default primary port used by the application and opens the firewall to
accept temporary connections created by the primary session.There are helpers for the following applications; default ports
monitored by each helper are listed in parentheses:Amanda (UDP 10080)FTP (TCP 21)H323 (UDP 1719, TCP 1720)IRC (TCP 6667)Netbios-NS (UDP 137)PPTP (TCP 1729)SANE (TCP 6566)SIP (UDP 5060)SNMP (UDP 161)TFTP (UDP 69)Helper Module LoadingIn a modular kernel, each helper is typically packaged as two
kernel modules. One module handles connection tracking where NAT isn't
involved and the other module handles NAT. For example, the FTP helper
consists of these two modules (kernels 2.6.20 and later):nf_conntrack_ftpnf_nat_ftpNote that the naming convention is
nf_conntrack_application and
nf_nat_application; more about that
below.The modules are not auto-loaded and must be loaded explicitly
using the modprob or insmod
utilities.Many of the modules allow parameters to be specified when the
module is loaded. Among the common parameters is the ports parameter
that lists one or more ports that the module is to monitor. This allows
running the application on a non-standard port.Iptables and HelpersIptables supports two ways of interacting with modules:Helper MatchThis match (-m helper --helper
name) allows selection of packets from
connections monitored or created by the named helper.CT TargetThis target (-j CT --helper name
...) , introduced in the 3.4 kernels, allows for explicit
association of a helper with a connection.It is important to note that the name used in iptables is not
always the same as the name in the kernel module. Names used in iptables
are shown in the following table:Name of kernel moduleName recognized by iptablesnf_conntrack_amandaamandanf_conntrack_ftpftpnf_conntrack_h323RAS (udp 1719), Q.931 (tcp
1720)nf_conntrack_ircircnf_conntrack_netbios_nsnetbios-nsnf_conntrack_pptppptpnf_conntrack_sanesanenf_conntrack_sipsipnf_conntrack_snmpsnmpnf_conntrack_tftptftpNetfilter helpers present an opportunity for attackers to attempt
to breach your firewall by IP address spoofing; See https://home.regit.org/netfilter-en/secure-use-of-helpers/
for a description of the Netfilter facilities available to meet these
attacks.Shorewall Support for HelpersShorewall includes support for helpers is several areas. These areas
are covered in the sections below.Module LoadingShorewall includes support for loading the helper modules as part
of its support for loading kernel modules in general. There are several
options in shorewall.conf (5) that deal with kernel module
loading:MODULESDIRThis option specifies a comma-separated list of directories
where Shorewall will look for kernel modules to load.MODULE_SUFFIXLists the possible suffixes for module names.LOAD_HELPERS_ONLYControls whether Shorewall should load only the helpers and
leave the other modules to the auto-loader. This option
dramatically reduces the time to process a shorewall
start or shorewall restart
command.HELPERSThis option was added in Shorewall 4.5.7 and lists the
modules to be enabled for association with connections. This
option is fully functional only on systems running kernel 3.5 or
later.The module names allowed in this list are amanda, ftp, h323,
irc, netbios-ns, pptp, sane, sip,
snmp and tftp.AUTOHELPERSThis option was also added in Shorewall 4.5.7. When enabled
on systems that support the CT Target capability, it provides
automatic association of helpers to connections in the same manner
as in pre-3.5 kernels (and with the same vulnerabilities).The helper modules to be loaded are listed in the file
/usr/share/shorewall/helpers. If you wish to
customize that file to load only a subset of the helpers or to specify
module parameters, then copy the file to /etc/shorewall/
and modify the copy. That way, your changes won't be
overwritten the next time that Shorewall is updated on your
system.On systems running a a kernel earlier than 3.5, not all of the
helpers can be totally disabled. The following modules can be disabled
by using the parameter ports=0 in
/etc/shorewall/helpers:ftpircsanesiptftpAfter disabling one or more helpers using this method, you
must:Unload the related module(s).Restart Shorewall (use the -c option (e.g., shorewall
restart -c) if you have AUTOMAKE=Yes in shorewall.conf
(5))..Note that if you choose to reboot your system to unload the
modules, then if you have CT:helper entries in shorewall-conntrack (5)
that refer to the module(s) and you have AUTOMAKE=Yes in shorewall.conf (5), then
Shorewall will fail to start at boot time.IptablesThe iptables helper match is supported by Shorewall in the form of
the HELPER column in shorewall-tcrules
(5).The CT target is supported directly in shorewall-conntrack
(5).In these files, Shorewall supports the same module names as
iptables; see the table above.Beginning with Shorewall 4.5.7, there is a HELPER column in shorewall-rules (5). In the
NEW section, this column allows the explicit association of a helper
with connections allowed by a given rules. The column may contain any of
the helper names recognized by iptables (see the table above). In the
RELATED section, the rule will only match the packet if the related
connection has the named helper attached.Also added in Shorewall 4.5.7 is the HELPER action in shorewall-rules (5). HELPER
rules associate the helper listed in the HELPER column with connections
that match the rule. A destination zone should not be specified in
HELPER rules.CapabilitiesThe output of shorewall show capabilities has
two entries for each of the helpers listed above that can be disabled by
adding ports=0 in
/etc/shorewall/helpers.shorewall show capabilities
Amanda Helper: Available
FTP Helper: Not available
FTP-0 Helper: Available IRC Helper: Not available
IRC-0 Helper: Available
Netbios_ns Helper: Available
H323 Helper: Not available
PPTP Helper: Available
SANE Helper: Not available
SANE-0 Helper: Available
SNMP Helper: Available
TFTP Helper: Not available
TFTP-0 Helper: Available
iptables -S (IPTABLES_S): Available
Basic Filter (BASIC_FILTER): Available
CT Target (CT_TARGET): Available
Kernel Version (KERNELVERSION): 30404
Capabilities Version (CAPVERSION): 40507
The above output is produced when this /etc/shorewall/helpers file
is used on a system running kernel 3.4.4:loadmodule nf_conntrack_ftp ports=0
loadmodule nf_conntrack_irc ports=0
loadmodule nf_conntrack_netbios_ns
loadmodule nf_conntrack_sip ports=0
loadmodule nf_conntrack_tftp ports=0
loadmodule nf_conntrack_sane ports=0The reason for the double capabilities is that when ports=0 is specified, the iptables name of the
helper gets '-0' added to it. So in order for the compiler to generate
the correct iptables commands, it needs to know if ports=0 was specified for each of the helprs that
support it.Notice that most of the other helpers are available, even though
their modules were not loaded. That's because auto-loading occurs during
capability detection on those modules whose iptables name matches the
module name.Kernel >= 3.5 and Shorewall >= 4.5.7While the AUTOHELPER option described above provides for seamless
migration to kernel 3.5 and beyond, we recommend setting AUTOHELPER=No at
the first opportunity after migrating. Additionally, you should:Use the HELPER action and the HELPER column in shorewall-rules (5) to
attach helpers to only those connections that you need to
support.If you run one or more servers (such as an FTP server) that
interact with helpers, you should consider adding rules to the RELATED
section of shorewall-rules (5) to
limit the scope of the helper. Suppose that your Linux FTP server is
in zone dmz and has address 70.90.191.123.#ACTION SOURCE DEST PROTO DEST SOURCE
# PORT(S) PORT(2)
SECTION RELATED
ACCEPT all dmz:70.90.191.123 32768: ; helper=ftp # passive FTP to dmz server; /proc/sys/net/ipv4/ip_local_port_range == 32760:65535
ACCEPT dmz:70.90.191.123 all tcp 1024: 20 ; helper=ftp # active FTP to dmz server
ACCEPT loc,dmz,$FW net tcp - 1024: ; helper=ftp # passive FTP to net
ACCEPT net all tcp 1024: 20 ; helper=ftp # active FTP from net
DROP:info all all ; helper=ftp #
SECTION NEW
HELPER all net tcp 21 ; helper=ftp
ACCEPT all dmz:70.90.191.123 tcp 21 ; helper=ftp
shorewall-docs-xml-4.5.21/template.xml 0000644 0001750 0001750 00000002116 12222401136 017551 0 ustar teastep teastep
TomEastep2012Thomas M. EastepPermission 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.
shorewall-docs-xml-4.5.21/troubleshoot.xml 0000644 0001750 0001750 00000054255 12222401136 020502 0 ustar teastep teastep
Shorewall Troubleshooting GuideTomEastep2001-2007Thomas M. EastepPermission 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.shorewall start and shorewall restart
ErrorsIf the error is detected by the Shorewall compiler, it should be
fairly obvious where the problem was found. Each error message includes
the configuration file name and line number where the error was detected
and often gives the particular item in error. The item is either enclosed
in parentheses or is at the end following a colon (":").Example:gateway:~/test # shorewall restart .
Compiling...
ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19)
gateway:~/test # In this case, line 19 in the rules file
specified an invalid ICMP Type (0/400).Additional information about the error can be obtained using the
'debug' keyword (Shorewall 4.4.19 and earlier) or using the (-T)
option.Example (4.4.19 and earlier):gateway:~/test # shorewall debug restart
Compiling...
ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) at /usr/share/shorewall/Shorewall/Config.pm line 338
Shorewall::Config::fatal_error('Invalid ICMP Type (0/400)') called at /usr/share/shorewall/Shorewall/Chains.pm line 885
Shorewall::Chains::validate_icmp('0/400') called at /usr/share/shorewall/Shorewall/Chains.pm line 949
Shorewall::Chains::do_proto('icmp', '0/400', '-') called at /usr/share/shorewall/Shorewall/Rules.pm line 1055
Shorewall::Rules::process_rule1('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1290
Shorewall::Rules::process_rule('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1336
Shorewall::Rules::process_rules() called at /usr/share/shorewall/Shorewall/Compiler.pm line 799
Shorewall::Compiler::compiler('/var/lib/shorewall/.restart', '/root/test', 0, 4) called at /usr/share/shorewall/compiler.pl line 86
gateway:~/test # Example (4.4.20 and later):gateway:~/test # shorewall restart -T
Compiling...
ERROR: Invalid ICMP Type (0/400) : /root/test/rules (line 19) at /usr/share/shorewall/Shorewall/Config.pm line 338
Shorewall::Config::fatal_error('Invalid ICMP Type (0/400)') called at /usr/share/shorewall/Shorewall/Chains.pm line 885
Shorewall::Chains::validate_icmp('0/400') called at /usr/share/shorewall/Shorewall/Chains.pm line 949
Shorewall::Chains::do_proto('icmp', '0/400', '-') called at /usr/share/shorewall/Shorewall/Rules.pm line 1055
Shorewall::Rules::process_rule1('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1290
Shorewall::Rules::process_rule('ACCEPT', 'loc', 'net', 'icmp', '0/400', '-', '-', '-', '-', ...) called at /usr/share/shorewall/Shorewall/Rules.pm line 1336
Shorewall::Rules::process_rules() called at /usr/share/shorewall/Shorewall/Compiler.pm line 799
Shorewall::Compiler::compiler('/var/lib/shorewall/.restart', '/root/test', 0, 4) called at /usr/share/shorewall/compiler.pl line 86
gateway:~/test # This information is useful to Shorewall support if you need to
file a problem report.The end of the compile phase is signaled by a message such as the
following:Shorewall configuration compiled to /var/lib/shorewall/.restartErrors
occurring past that point are said to occur at
run-time because they occur during the running of
the compiled firewall script (/var/lib/shorewall/.restart in the case of
the above message).One common run-time failure is that the iptables-restore program
encounters an error. This will produce an error such as the
following:...
Restarting Shorewall....
iptables-restore v1.3.6: No chain/target/match by that name
Error occurred at line: 83
Try `iptables-restore -h' or 'iptables-restore --help' for more information.
ERROR: iptables-restore Failed. Input is in /var/lib/shorewall/.iptables-restore-input
Restoring Shorewall...
Shorewall restored from /var/lib/shorewall/restore
Terminated
gateway:~/test # A look at /var/lib/shorewall/restore at line
83 might show something like the following:-A reject -p tcp -j REJECT --reject-with tcp-resetIn
this case, the user had compiled his own kernel and had forgotten to
include REJECT target support (see kernel.htm).You may also include the word debug
as the first argument to the /sbin/shorewall and
/sbin/shorewall-lite commands.shorewall debug restartIn
most cases, debug is a synonym for
trace. The exceptions are:debug is ignored by the
Shorewall compiler.debug causes altered behavior
of generated scripts. These scripts normally use
iptables-restore to install the Netfilter ruleset but with
debug, the commands normally passed
to iptables-restore in its input file are passed
individually to iptables. This is a diagnostic aid
which allows identifying the individual command that is causing
iptables-restore to fail; it should be used when
iptables-restore fails when executing a COMMIT
command.The debug feature is strictly for
problem analysis. When debug is
used:The firewall is made 'wide open' before the rules are
applied.The routestopped file is not
consulted.The rules are applied in the canonical
iptables-restore order. So if you need critical
hosts to be always available during start/restart, you may not be
able to use debug.In other run-time failure cases:Make a note of the error message that you see.shorewall debug start 2>
/tmp/traceLook at the /tmp/trace file and see if
that helps you determine what the problem is. Be sure you find the
place in the log where the error message you saw is generated -- you
should find the message near the end of the log.If you still can't determine what's wrong then see the support page.Your Network EnvironmentMany times when people have problems with Shorewall, the problem is
actually an ill-conceived network setup. Here are several popular
snafus:Port Forwarding where client and server are in the same subnet.
See FAQ 2.Trying to test net->loc DNAT rules from inside your firewall.
You must test these rules from outside your firewall.Multiple interfaces connected to the same HUB or Switch. Given
the way that the Linux kernel respond to ARP who-has
requests, this type of setup does NOT work the
way that you expect it to. You can test using this kind of
configuration if you specify the arp_filter option or the arp_ignore 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.New Device Doesn't Work?If you have just added a new device such as VOIP and it doesn't
work, be sure that you have assigned it an IP address in your local
network and that its default gateway has been set to the IP address of
your internal interface. For many of these devices, the simplest solution
is to run a DHCP server; running it on your firewall is fine — be sure to
set the dhcp option on your internal
interface in /etc/shorewall/interfaces.Connection ProblemsOne very important thing to remember is that not all connection
problems are Shorewall configuration problems. If the connection that is
giving you problems is to or from the firewall system or if it doesn't
rely on NAT or Proxy ARP then you can often eliminate Shorewall using a
simple test:/sbin/shorewall clearTry the connection. If it works then the problem is in your
Shorewall configuration; if the connection still doesn't work then the
problem is not with Shorewall or the way that it is configured.Be sure to /sbin/shorewall start after the
test.If you still suspect Shorewall and the appropriate policy for the
connection that you are trying to make is ACCEPT, please DO NOT ADD
ADDITIONAL ACCEPT RULES TRYING TO MAKE IT WORK. Such additional rules will
NEVER make it work, they add clutter to your rule set and they represent a
big security hole in the event that you forget to remove them
later.I also recommend against setting all of your policies to ACCEPT in
an effort to make something work. That robs you of one of your best
diagnostic tools - the Shorewall messages that Netfilter
will generate when you try to connect in a way that isn't permitted by
your rule set.Check your log (/sbin/shorewall show
log). If you don't see Shorewall messages, then your
problem is probably NOT a Shorewall problem. If you DO see packet
messages, it may be an indication that you are missing one or more rules
-- see FAQ 17.While you are troubleshooting, it is a good idea to clear two
variables in
/etc/shorewall/shorewall.conf:LOGRATE=
LOGBURST=""This way, you will see all of the log messages
being generated (be sure to restart shorewall after clearing these
variables).Log MessageJun 27 15:37:56 gateway kernel: Shorewall:all2all:REJECT:IN=eth2
OUT=eth1 SRC=192.168.2.2
DST=192.168.1.3 LEN=67 TOS=0x00
PREC=0x00 TTL=63 ID=5805 DF
PROTO=UDP SPT=1803 DPT=53 LEN=47Let's look at the important parts of this message:all2all:REJECT - This packet was REJECTed out of the all2all
chain -- the packet was rejected under the
all->all REJECT policy (see FAQ 17).IN=eth2 - the packet entered the firewall via eth2OUT=eth1 - if accepted, the packet would be sent on
eth1SRC=192.168.2.2 - the packet was sent by 192.168.2.2DST=192.168.1.3 - the packet is destined for
192.168.1.3PROTO=UDP - UDP ProtocolDPT=53 - DNSIn this case, 192.168.2.2 was in the dmz zone and
192.168.1.3 is in the loc zone. I was missing the
rule:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT dmz loc udp 53Ping ProblemsEither can't ping when you think you should be able to or are able
to ping when you think that you shouldn't be allowed? Shorewall's
Ping Management is described
here. Here are a couple of tips:Remember that Shorewall doesn't automatically allow ICMP type 8
(ping) requests to be sent between zones. If you want
pings to be allowed between zones, you need a rule of the form:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
Ping(ACCEPT)<source zone><destination zone>The ramifications of this can be subtle. For example, if you
have the following in /etc/shorewall/nat:#EXTERNAL INTERFACE INTERNAL
10.1.1.2 eth0 130.252.100.18and you ping 130.252.100.18, unless you have allowed icmp type 8
between the zone containing the system you are pinging from and the
zone containing 10.1.1.2, the ping requests will be dropped.Ping requests are subject to logging under your policies. So
ping floods can cause an equally big flood of log messages. To
eliminate these, as the last rule in your /etc/shorewall/rules file
add:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
Ping(DROP)net allSome Things to Keep in MindYou cannot test your firewall from the
inside. Just because you send requests to your firewall
external IP address does not mean that the request will be associated
with the external interface or the net zone. Any
traffic that you generate from the local network will be associated
with your local interface and will be treated as loc->fw
traffic.IP addresses are properties of systems,
not of interfaces. It is a mistake to believe that your
firewall is able to forward packets just because you can ping the IP
address of all of the firewall's interfaces from the local network.
The only conclusion you can draw from such pinging success is that the
link between the local system and the firewall works and that you
probably have the local system's default gateway set correctly.All IP addresses configured on firewall
interfaces are in the $FW (fw) zone. If 192.168.1.254 is
the IP address of your internal interface then you can write
$FW:192.168.1.254 in a
rule but you may not write loc:192.168.1.254. Similarly, it is
nonsensical to add 192.168.1.254 to the loc zone using an entry in
/etc/shorewall/hosts.Reply packets do NOT automatically follow
the reverse path of the one taken by the original request.
All packets are routed according to the routing table of the host at
each step of the way. This issue commonly comes up when people install
a Shorewall firewall parallel to an existing gateway and try to use
DNAT through Shorewall without changing the default gateway of the
system receiving the forwarded requests. Requests come in through the
Shorewall firewall where the destination IP address gets rewritten but
replies go out unmodified through the old gateway.Shorewall itself has no notion of inside
or outside. These concepts are embodied in how Shorewall is
configured.Other GotchasSeeing rejected/dropped packets logged out of the INPUT or
FORWARD chains? This means that:your zone definitions are screwed up and the host that is
sending the packets or the destination host isn't in any zone
(using an /etc/shorewall/hosts
file are you?); orthe source and destination hosts are both connected to the
same interface and you don't have a policy or rule for the source
zone to or from the destination zone or you haven't set the
routeback option for the
interface in /etc/shorewall/interfaces.You have connected two firewall interfaces (from different
zones) to the same hub or switch.If you specify routefilter for an interface, that
interface must be up prior to starting the firewall.Is your routing correct? For example, internal systems usually
need to be configured with their default gateway set to the IP address
of their nearest firewall interface. One often overlooked aspect of
routing is that in order for two hosts to communicate, the routing
between them must be set up in both
directions. So when setting up routing between A and B, be
sure to verify that the route from B
back to A is defined and
correct.Do you have your kernel properly configured? Click here to see kernel configuration
information.Still Having Problems?See the Shorewall Support
Page.
shorewall-docs-xml-4.5.21/survey-200603.xml 0000644 0001750 0001750 00000050766 12222401136 020041 0 ustar teastep teastep
The Shorewall Environment Survey 2006PaulGear2006Paul D. GearPermission 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.BackgroundIn early March 2006, i embarked on the journey of surveying
Shorewall users. Initially this sprang from my own curiosity: i thought
that some of the systems at work on which i use Shorewall may be bigger
and more complex than most others, and i wanted to find out if there are
people out there who use Shorewall like i do. As started thinking about
the questions i would ask, i realised that if i asked the right questions,
i could create a survey that might help the Shorewall project better to
understand its users.I used Zoomerang to
create the survey. It has a number of tools that make it easy to create
useful surveys. To get the most benefit out of Zoomerang, you have to
subscribe to their professional version.In the long term, it would be great to have a practical free
software alternative that could be self-hosted. A number of free content
management systems such as Drupal
have a survey module, but when i last looked at them, they were more
limited and harder to use than Zoomerang.Survey and results linksThe survey is still open as of this writing, and can be accessed
at the
Zoomerang survey page. Further participation is encouraged. The
figures quoted in this document reflect the results at the time of
writing.The public
results of the survey are available. If you complete the survey,
a link to the results is provided on the thank you page.Sample sizeAn important note about this survey is that it has a small sample
size (103 complete responses at the time of writing), so any conclusions
drawn should be considered tentative.To speculate on the overall number of users that this sample
represents, the Debian popularity
contest reports 478 installations of Shorewall, 285 of which are
in active use. Assuming that the popularity contest represents 30% of
the Debian installed base (likely ridiculously optimistic), this would
make the number of active Shorewall systems approximately:285 / 0.3 (percentage of Debian systems) / 0.26 (percentage Debian
holds of all distributions) = 3654 (rounding up the numbers to the
nearest whole, and assuming the percentages extrapolate
regularly)This means that our survey represents a maximum of 2.8% of the
installed base, likely far less.Other possible inaccuraciesAdditionally, since the survey was open to multiple responses, it
could be that some people answered the questions about themselves more
than once, despite instructions to the contrary in the introduction
page.There is an error in the released version of the survey for
question 15 (RAM size): it was a multiple choice question rather than
single choice, and thus there were more results than expected. The
number of errors doesn't seem to be significant.If you notice any errors in this analysis, or have any suggestions
about how to improve it, please contact the author at pgear@shorewall.net.Results analysisOrganisationsSmall organisations dominate the spectrum of Shorewall users. The
largest group (44%) was 1-10 users - mostly SOHO LANs based on the
comments in that section. Ninety percent (90%) of Shorewall
installations are in organisations with less than 500 users. The results
for the questions about organisational size and the number of users
serviced by Shorewall match fairly closely, which seems to indicate that
the majority of Shorewall systems are servicing the entire organisation
in question.The vast majority (84%) of Shorewall systems are administered by
only one person. One question that needs to be asked is, "Why?" Possible
reasons for this might be:Most of the organisations in which it is used are small, thus
most of them will only have one person skilled in the area of packet
filtering firewalls. This seems a likely scenario, but a cross
correlation of the results of questions 1 and 2 with question 3
indicates that the number of administrators is fairly uniform across
all sizes of organisation and user base.Shorewall works so well that people don't have to touch it
much. Obviously, this is the preferred interpretation of the
Shorewall project team. :-)Shorewall is too hard for new users to comprehend, so one
skilled person in an organisation tends to get the job maintaining
it. Equally obviously, this is a non-preferred interpretation. :-)
However, being a firewall generator, Shorewall is not likely to
attract the same sort of users as a web browser or music
player.Shorewall administrators are a closed bunch and don't like
sharing their job around. Given the nature of firewalls and packet
filtering, this doesn't seem far-fetched.There doesn't seem to be an easy answer to thus question. In
retrospect, since there were no responses indicating 10 or more
administrators, i could have made the granularity of this question
better. A question about a person's role in the organisation may also
have been helpful. Possibly we could follow up with a smaller survey,
specifically about the people and organisations who use
Shorewall.UsersUnsurprisingly, 97% of survey respondents were male. Or to put it
another way: surprisingly, there are actually 3 female Shorewall users.
:-) Being male seems to be an occupational hazard of life in the IT
industry, and even more so in the more "nerdy" specialisations like
Linux and security.The largest age group of users is 25-34 years (42% of all
respondents). There were no retirees (65 and over) or minors (under 18)
in the responses. The distribution of the remaining age groups was
fairly even.The largest group of users in terms of education was those with a
Bachelor's degree, followed by those with a high school education.
Fifty-seven percent (57%) of Shorewall users have a Bachelor's degree or
better. Many users' highest qualifications are not in an IT-related
discipline (42%). This remains fairly constant across the spectrum when
correlated with the highest level of qualifications. Those who do not
claim IT as their highest discipline come from a wide variety of other
fields, including agriculture, art, business, chemistry, education,
various forms of engineering, law, mathematics, physics, and
theology.Almost two-thirds of users (62%) use Shorewall as part of their
paid employment. Of these, 12% (7 of 58) do not use Shorewall as part of
their official duties. Cross correlation with level of education
revealed no major variance in this trend depending on level of
education.The majority of users (73%) began using the Internet in the 1990s.
A smaller majority (61%) have been using the Internet for more than 12
years (1994 or earlier). (The single response indicating use of the
Internet (then ARPANET) since the 1960s seems to be an error.)The majority of users (70%) began using Linux after it reached a
certain stage of maturity - around or after the release of kernel 2.0
(1996). However, nearly all respondents (97%) have been using Linux for
5 years or more, with almost half (47%) having 10 or more years
experience with it. It seems fair to say that as a rule, Shorewall
attracts people with plenty of experience.Around one third of users (30%) have been using Shorewall for more
than 5 years, with two-thirds (66%) having used it since the 1.x series
(2003 or earlier). It seems fair to say that Shorewall users seem to
stick with the product once they are familiar with it. On the other
hand, it seems that Shorewall is not attracting large numbers of new
users, which is a concern for the future of the project.HardwareNinety-three percent (93%) of users run Shorewall on i386 family
hardware, with a further 6% running it on x86-64/EM64T platforms. One
response was received indicating use of Shorewall on MIPS (Linksys WRT
platform). No responses were received for any other hardware platform.
While it is not surprising that Intel would be dominant, given their
market share, it seems a little skewed not to have any representatives
of other architectures.A good spread of CPU power is shown in the survey responses. The
largest group was 400-999 MHz (30%), with only 16% of responses
indicating less than 400 MHz, and the same number greater than 2500 MHz.
A number of responses in the field for additional information suggested
that the machines used were either recycled desktops, or systems that
were specifically built to do the job, and had been running in that role
for a number of years.RAM configuration seemed to mostly mirror CPU power, with a slight
bias towards higher RAM figures. The majority (52%) of systems have
between 256 and 1023 MB; only 11% of systems have less than 128 MB; 28%
have 1024 MB or more. This reflects the more server-oriented workload
that many Shorewall systems run (see the section on server roles
below).Shorewall systems on the whole tend toward smaller OS hard disks,
with 42% having disks 39 GB or smaller. The largest group by a small
margin was 80-159 GB at 23%, with 10-39 GB and 0-9 GB coming in a close
second and third at 22% and 20% respectively.NetworkThe majority of Shorewall systems (82%) use between two and four
network interfaces. The number of devices connected to systems closely
mirrors the size of the organisations in which they are used, with 95%
of systems connecting less than 500 devices, and the largest group (41%)
connecting 2-10 other devices.Ninety percent (90%) of Shorewall systems are connected to 100
Mbps or faster local networks. Most systems have a broadband Internet
connection or better, with only 7% having 512 Kbps or less, and 51%
having 10 Mbps or better. DSL is the most common form of Internet
connection, with over half the responses (51%).SoftwareThe most popular Linux distribution on which users run Shorewall
is Debian (26% of respondents), followed by a group consisting of Fedora
Core (16%), Red Hat 9 and earlier (13%) and Red Hat Enterprise and
derivatives (12%). The next group consists of SUSE (9%), Slackware (8%),
Gentoo (6%), and LEAF/Bering (5%).The message about maintaining an up-to-date Shorewall system seems
to have gotten through, with 61% of respondents running the latest
stable version (3.0), and an additional 22% running the previous stable
version (2.4). Only 14% of users are running unsupported older versions
(2.2 and previous).The most common roles played by Shorewall systems are:External firewall/router (78%)DNS name server (61%)DHCP server (59%)Internal firewall/router (56%)Time server (55%)Comments from usersFollowing is a sample of the comments we received about the survey
- they have been carefully sanitised to make us look good. ;-)More power to Shorewall!Shorewall Rocks! I'm amazed how easy it is every time I need
to do something, even if it's been 6+ months since the last change!
:)Good job and a great product.Shorewall is good, I have recommended it to several people,
mostly working in the University & academic areas.Thanks to everyone who contributes to Shorewall. That's a
*great* piece of software!Shorewall has been incredible. Tom has given so much of
himself to this project, I can only say thank you from one person, I
look up to people like him. I have used Shorewall for many systems,
I am a contractor that "set up shop" all over the world. Depending
on the available ISP services, this project has been flexible in
every situation to date. Also, depending on my needs, it has done
the same. "IP Tables made easy" is really an accurate
description.I'm quite interested in seeing what the 'cross section' of
Shorewall users are like. It's made my life a lot easier over the
years. Thank you.Lessons learned about survey techniqueTreat surveys like releasing free softwaretest on a small group before you go publicrelease early and oftenmake branches (copies) when you release alpha and beta
versionsmerge the changes from branches (lessons you learned in those
versions) into the main trunkStart small and work towards what you want to know with specific,
concrete questionsI tried to do everything in one survey, and ended up confusing
some people. For example, despite the fact that the survey's start page
clearly says "Please answer the questions for only ONE SYSTEM running
Shorewall", i received multiple comments saying that they couldn't
answer accurately because they ran more than one Shorewall
system.It would have been better to have two surveys: one about the
people who use Shorewall, and another about the systems they run it on.
Better still would be for Shorewall to automatically collect appropriate
information about systems and request permission to send it to a central
location for statistical analysis. How to do this and maintain users'
privacy and obtain their permission efficiently is not an easy problem
with a product like Shorewall, which doesn't actually stay running on
user systems, and doesn't present a user interface per se.Be prepared beforehandWithin hours of the survey's release, 50% of the results were in.
Within 3 days, it hit the Zoomerang basic survey limit of 100 responses.
I had not planned for such an enthusiastic response, and also was too
busy to download all of the results before the survey's time limit
expired. Fortunately, i was able to obtain funding to allow a Zoomerang
"pro" subscription to be purchased and thus provide advanced analysis,
and complete downloads of the results.Incrementally improve your surveysThe final version of this survey was released still with a few
bugs. The released version was just a copy of my master survey, and i
continued to maintain the master after the final survey was released
(and during this analysis), and i'm sure the next version will be even
better.Possible implications for the Shorewall projectThe users we have seem, on the whole, rather experienced, and very
loyal. However, we don't seem to be attracting new users, despite new
features such as multi-ISP support and integrated traffic shaping. The
question about a GUI comes up frequently, and one wonders whether this is
would make a significant difference in Shorewall's uptake with new
users.Shorewall seems to be predominantly used in small, i386-based
environments such as home LANs and small businesses. It seems to be
frequently combined with a number of other basic functions, such as DNS,
DHCP, NTP, VPN. Integration with (or perhaps providing a plug-in module
for) a dedicated gateway distribution such as ipcop, Smoothwall, or Clark
Connect might be a good way to serve the needs of our users.Possible implications for other free software projectsThe essence of free software is software by the people, for the
people. Knowing who the people are and what their needs are is
critical to this process.If at all possible, build statistics gathering into your
application, and find a way to encourage people to use it. This
concrete data will help confirm the results of any surveys you might
conduct.
shorewall-docs-xml-4.5.21/shorewall_extension_scripts.xml 0000644 0001750 0001750 00000053625 12222401136 023614 0 ustar teastep teastep
Extension ScriptsTomEastep2001-2010Thomas M. EastepPermission 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.This article applies to Shorewall 4.3 and
later. If you are running a version of Shorewall earlier than Shorewall
4.3.5 then please see the documentation for that
release.Extension ScriptsExtension scripts are user-provided scripts that are invoked at
various points during firewall start, restart, stop and clear. The scripts
are placed in /etc/shorewall and are processed using the Bourne shell
source mechanism.Be sure that you actually need to use an extension script to
do what you want. Shorewall has a wide range of features that cover
most requirements.DO NOT SIMPLY COPY RULES THAT YOU FIND ON THE NET INTO AN
EXTENSION SCRIPT AND EXPECT THEM TO WORK AND TO NOT BREAK SHOREWALL.
TO USE SHOREWALL EXTENSION SCRIPTS YOU MUST KNOW WHAT YOU ARE DOING
WITH RESPECT TO iptables/Netfilter AND SHOREWALL.The following scripts can be supplied:lib.private -- Intended to contain
declarations of shell functions to be called by other run-time
extension scripts. See this
article for an example of its use.compile -- Invoked by the rules compiler
early in the compilation process. Must be written in Perl.init -- invoked early in shorewall
start and shorewall restartinitdone -- invoked after Shorewall has
flushed all existing rules but before any rules have been added to the
builtin chains.start -- invoked after the firewall has
been started or restarted.started -- invoked after the firewall has
been marked as 'running'.stop -- invoked as a first step when the
firewall is being stopped.stopped -- invoked after the firewall has
been stopped.clear -- invoked after the firewall has
been cleared.tcclear -- invoked to clear traffic shaping
when CLEAR_TC=Yes in shorewall.conf.refresh -- called in place of
init when the firewall is being refreshed rather
than started or restarted.refreshed -- invoked after the firewall has
been refreshed.maclog -- invoked while mac filtering rules
are being created. It is invoked once for each interface having
'maclist' specified and it is invoked just before the logging rule is
added to the current chain (the name of that chain will be in
$CHAIN).isusable -- invoked when Shorewall is
trying to determine the usability of the network interface associated
with an optional entry in
/etc/shorewall/providers. $1 is the name of the
interface which will have been determined to be up and configured
before the script is invoked. The return value from the script
indicates whether or not the interface is usable (0 = usable, other =
unusable).Example:# Ping a gateway through the passed interface
case $1 in
eth0)
ping -c 4 -t 1 -I eth0 206.124.146.254 > /dev/null 2>&1
return
;;
eth1)
ping -c 4 -t 1 -I eth1 192.168.12.254 > /dev/null 2>&1
return
;;
*)
# No additional testing of other interfaces
return 0
;;
esacWe recommend that this script only be used with
ADMINISABSENTMINDED=Yes.The firewall state when this script is invoked is
indeterminate. So if you have ADMINISABSENTMINDED=No in shorewall.conf(8) and
output on an interface is not allowed by routestopped(8) then
the isuasable script must blow it's own holes in the firewall
before probing.save -- This script is invoked during
execution of the shorewall save and
shorewall-lite save commands.restored -- This script is invoked at the
completion of a successful shorewall restore and
shorewall-lite restore.findgw -- This script is invoked when Shorewall is attempting to
discover the gateway through a dynamic interface. The script is most
often used when the interface is managed by dhclient which has no
standardized location/name for its lease database. Scripts for use
with dhclient on several distributions are available at http://www.shorewall.net/pub/shorewall/contrib/findgw/scfilter -- Added in Shorewall 4.4.14.
Unlike the other scripts, this script is executed by the command-line
tools (/sbin/shorewall,
/sbin/shorewall6, etc) and can be used to
reformat the output of the show connections
command. The connection information is piped through this script so
that the script can drop information, add information or alter the
format of the information. When using Shorewall Lite or Shorewall6
Lite, the script is encapsulated in a function that is copied into the
generated auxillary configuration file. That function is invoked by
the 'show connections' command.The default script is as follows and simply pipes the output
through unaltered.#! /bin/sh
cat -If your version of Shorewall doesn't have the
file that you want to use from the above list, you can simply create the
file yourself. You can also supply a script with the same name
as any of the filter chains in the firewall and the script will be invoked
after the /etc/shorewall/rules file has been processed but before the
/etc/shorewall/policy file has been processed.The following table indicate which commands invoke the various
scripts.scriptCommandsclearclearcompilecheck, compile, export, load, refresh, reload, restart,
restore,startcontinueinitload, refresh, reload, restart restore, startinitdonecheck, compile, export, refresh, restart, startisusablerefresh, restart, restore, startmaclogcheck, compile, export, refresh, restart, startrefreshrefreshrefreshedrefreshrestoredrestoresavesavescfiltershow connectionsstartload, reload, restart, startstartedload, reload, restart, startstopstop, clearstoppedstop, cleartcclearload, reload, restart, restore, startThere are a couple of special considerations for commands in
extension scripts:When you want to run iptables, use the
command run_iptables instead.
run_iptables will run the iptables utility passing
the arguments to run_iptables and if the command
fails, the firewall will be stopped (or restored from the last
save command, if any).
run_iptables should not be called from the
started or restored
scripts.If you wish to generate a log message, use log_rule_limit. Parameters are:Log LevelChain to insert the rule intoChain name to display in the message (this can be different
from the preceding argument — see the Port Knocking article for an
example of how to use this).Disposition to report in the message (ACCEPT, DROP,
etc)Rate Limit (if passed as "" then $LOGLIMIT is assumed — see
the LOGLIMIT option in /etc/shorewall/shorewall.conf)Log Tag ("" if none)Command (-A or -I for append or insert).The remaining arguments are passed "as is" to
iptablesMany of the extension scripts get executed for both the
shorewall start and shorewall restart commands. You can determine
which command is being executed using the contents of $COMMAND.if [ $COMMAND = start ]; then
...In addition to COMMAND, Shorewall defines three other variables
that may be used for locating Shorewall files:CONFDIR - The configuration directory. Will be /etc/shorewall, /etc/shorewall6/, /etc/shorewall-lite, or /etc/shorewall6-lite depending on
which product is running.SHAREDIR - The product shared directory. Will be /usr/share/shorewall, /usr/share/shorewall6/, /usr/share/shorewall-lite, or
/usr/share/shorewall6-lite
depending on which product is running.VARDIR - The product state directory. Defaults /usr/share/shorewall, /usr/share/shorewall6/, /usr/share/shorewall-lite, or
/usr/share/shorewall6-lite
depending on which product is running, but may be overridden by an
entry in ${CONFDIR}/vardir.Compile-time vs Run-time ScriptsShorewall runs some extension scripts at compile-time rather than
at run-time.The following table summarizes when the various extension scripts
are run:Compile-timeRun-timecompileclearinitdoneinitmaclogisusablePer-chain (including those associated with
actions)startstartedstopstoppedtcclearrefreshrefreshedrestoredscfilterCompile-time extension scripts are executed using the Perl 'eval
`cat <file>`' mechanism. Be sure that each
script returns a 'true' value; otherwise, the compiler will assume that
the script failed and will abort the compilation.Each compile-time script is implicitly prefaced with:package Shorewall::User;Most scripts will need to begin with the following
line:use Shorewall::Chains;For more
complex scripts, you may need to 'use' other Shorewall Perl modules --
browse /usr/share/shorewall/Shorewall/ to see
what's available.When a script is invoked, the $chainref scalar variable will hold a reference
to a chain table entry.$chainref->{name}
contains the name of the chain$chainref->{table} holds
the table nameTo add a rule to the chain:add_rule( $chainref, <the rule> [ , <break lists> ] );Where<the rule> is a scalar argument
holding the rule text. Do not include "-A <chain
name>"Example:add_rule( $chainref, '-j ACCEPT' );The add_rule() function accepts an optional third argument; If
that argument evaluates to true and the passed rule contains a --dports or --sports list with more than 15 ports (a port
range counts as two ports), the rule will be split into multiple rules
where each resulting rule has 15 or fewer ports in its --dports and --sports lists.To insert a rule into the chain: insert_rule( $chainref, <rulenum>, <the rule> );The
log_rule_limit() function works like it
did in the shell compiler with three exceptions:You pass the chain reference rather than the name of the
chain.The commands are 'add' and 'insert' rather than '-A' and
'-I'.There is only a single "pass as-is to iptables" argument (so
you must quote that part).Example:log_rule_limit(
'info' , #Log Level
$chainref , #Chain to add the rule to
$chainref->{name}, #Name of the chain as it will appear in the log prefix
'DROP' , #Disposition of the packet
'', #Limit
'' , #Log tag
'add', #Command
'-p tcp' #Added to the rule as-is
);Note that in the 'initdone' script, there is
no default chain ($chainref). You can
obtain a reference to a standard chain by:my $chainref = $chain_table{<table>}{<chain name>};Example:my $chainref = $chain_table{filter}{INPUT};You can also use the hash references $filter_table, $mangle_table and $nat_table to access chain references in the
three main tables.Example:my $chainref = $filter_table->{INPUT}; #Same as above with a few less keystrokes; runs faster tooFor imformation about the 'compile' extension script, see the
Manual Chains article.
shorewall-docs-xml-4.5.21/NAT.xml 0000644 0001750 0001750 00000025351 12222401136 016366 0 ustar teastep teastep
One-to-one NATTomEastep2001-2004Thomas M. EastepPermission 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.This article applies to Shorewall 4.3 and
later. If you are running a version of Shorewall earlier than Shorewall
4.3.5 then please see the documentation for that
release.One-to-one NATIf all you want to do is forward ports to
servers behind your firewall, you do NOT want to use one-to-one NAT.
Port forwarding can be accomplished with simple entries in the rules
file.One-to-one NAT is a way to make systems behind a firewall and
configured with private IP addresses (those reserved for private use in
RFC 1918) appear to have public IP addresses. Before you try to use this
technique, I strongly recommend that you read the Shorewall Setup Guide.The following figure represents a one-to-one NAT environment.One-to-one NAT can be used to make the systems with the 10.1.1.*
addresses appear to be on the upper (130.252.100.*) subnet. If we assume
that the interface to the upper subnet is eth0, then the following
/etc/shorewall/nat file would make the lower
left-hand system appear to have IP address 130.252.100.18 and the
right-hand one to have IP address 130.252.100.19. It should be stressed
that these entries in the /etc/shorewall/nat file do
not automatically enable traffic between the external network and the
internal host(s) — such traffic is still subject to your policies and
rules./etc/shorewall/nat#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
130.252.100.18 eth0 10.1.1.2 no no
130.252.100.19 eth0 10.1.1.3 no noBe sure that the internal system(s) (10.1.1.2 and 10.1.1.3 in the
above example) is (are) not included in any specification in
/etc/shorewall/masq or
/etc/shorewall/proxyarp.The ALL INTERFACES column is used to specify
whether access to the external IP from all firewall interfaces should
undergo NAT (Yes or yes) or if only access from the interface in the
INTERFACE column should undergo NAT. If you leave this column empty,
No is assumed . Specifying
Yes in this column will not by itself allow systems on
the lower LAN to access each other using their public IP
addresses. For example, the lower left-hand system (10.1.1.2)
cannot connect to 130.252.100.19 and expect to be connected to the lower
right-hand system. See FAQ 2a.Shorewall will automatically add the external address to the
specified interface unless you specify ADD_IP_ALIASES=no
(or No) in
/etc/shorewall/shorewall.conf; If you do not set
ADD_IP_ALIASES or if you set it to Yes or
yes then you must NOT configure your own
alias(es).The contents of the LOCAL column determine whether
packets originating on the firewall itself and destined for the EXTERNAL
address are redirected to the internal ADDRESS. If this column contains
yes or Yes (and the ALL INTERFACES COLUMN
also contains Yes or yes) then such
packets are redirected; otherwise, such packets are not redirected. This
feature requires that you enabled CONFIG_IP_NF_NAT_LOCAL in your
kernel.Entries in /etc/shorewall/nat only arrange for
address translation; they do not allow traffic to pass through the
firewall in violation of your policies. In the above example, suppose that
you wish to run a web server on 10.1.1.2 (a.k.a. 130.252.100.18). You
would need the following entry in
/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST SOURCE ORIG
# PORT(S) PORT(S) DEST
ACCEPT net loc:10.1.1.2 tcp 80 - 130.252.100.18ARP cacheA word of warning is in order here. ISPs typically configure their
routers with a long ARP cache timeout. If you move a system from parallel
to your firewall to behind your firewall with one-to-one NAT, it will
probably be HOURS before that system can communicate with the
Internet.If you sniff traffic on the firewall's external interface, you can
see incoming traffic for the internal system(s) but the traffic is never
sent out the internal interface.You can determine if your ISP's gateway ARP cache is stale using
ping and tcpdump. Suppose that we suspect that the gateway router has a
stale ARP cache entry for 130.252.100.19. On the firewall, run tcpdump as
follows:tcpdump -nei eth0 icmpNow from 10.1.1.3, ping the ISP's gateway (which we will assume is
130.252.100.254):ping 130.252.100.254We can now observe the tcpdump output:13:35:12.159321 0:4:e2:20:20:33 0:0:77:95:dd:19 ip 98: 130.252.100.19 > 130.252.100.254: icmp: echo request (DF)
13:35:12.207615 0:0:77:95:dd:19 0:c0:a8:50:b2:57 ip 98: 130.252.100.254 > 130.252.100.177 : icmp: echo replyNotice that the source MAC address in the echo request is different
from the destination MAC address in the echo reply!! In this case
0:4:e2:20:20:33 was the MAC of the firewall's eth0 NIC while
0:c0:a8:50:b2:57 was the MAC address of the system on the lower right. In
other words, the gateway's ARP cache still associates 130.252.100.19 with
the NIC in that system rather than with the firewall's eth0.If you have this problem, there are a couple of things that you can
try:A reading of TCP/IP Illustrated, Vol 1 by
Stevens revealsCourtesy of Bradey Honsinger that a gratuitous ARP packet should cause
the ISP's router to refresh their ARP cache (section 4.7). A
gratuitous ARP is simply a host requesting the MAC address for its own
IP; in addition to ensuring that the IP address isn't a
duplicate...
if the host sending the gratuitous ARP has just changed its
hardware address..., this packet causes any other host...that has an
entry in its cache for the old hardware address to update its ARP
cache entry accordingly.
Which is, of course, exactly what you want to do when you switch
a host from being exposed to the Internet to behind Shorewall using
one-to-one NAT (or Proxy ARP for that matter). Happily enough, recent
versions of Redhat's iputils package include arping,
whose -U flag does just that:arping -U -I <net if> <newly proxied IP>
arping -U -I eth0 66.58.99.83 # for exampleStevens goes on to mention that not all systems respond
correctly to gratuitous ARPs, but googling for arping
-U seems to support the idea that it works most of the
time.To use arping with one-to-one NAT in the above example, you
would have to:shorewall clear
ip addr add 130.252.100.18 dev eth0 # You need to add the addresses only if Shorewall clear
ip addr add 130.252.100.19 dev eth0 # deletes them
arping -U -c 10 -I eth0 130.252.100.18
arping -U -c 10 -I eth0 130.252.100.19
ip addr del 130.252.100.18 dev eth0 # You need to delete the addresses only if you added
ip addr del 130.252.100.19 dev eth0 # them above
shorewall startYou can call your ISP and ask them to purge the stale ARP cache
entry but many either can't or won't purge individual entries.There are two distinct versions of arping
available:arping by Thomas Habets (Debian package
arping).arping as part of the iputils package by
Alexey Kuznetsov (Debian package
iputils-arping).You want the second one by Alexey Kuznetsov.
shorewall-docs-xml-4.5.21/traffic_shaping.xml 0000644 0001750 0001750 00000323027 12222401136 021074 0 ustar teastep teastep
Complex Traffic Shaping/ControlTomEastepArneBernin2001-2013Thomas M. Eastep2005Arne Bernin & Thomas M. EastepPermission 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.Traffic shaping is complex and the Shorewall community is not well
equipped to answer traffic shaping questions. So if you are the type of
person who needs "insert tab A into slot B" instructions for everything
that you do, then please don't try to implement traffic shaping using
Shorewall. You will just frustrate yourself and we won't be able to help
you.Said another way, reading just Shorewall documentation is not going
to give you enough background to use this material.At a minimum, you will need to refer to at least the following
additional information:The LARTC HOWTO: http://www.lartc.orgThe HTB User's Guide: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htmHFSC Scheduling with Linux: http://linux-ip.net/articles/hfsc.en/Some of the documents listed at http://www.netfilter.org/documentation/index.html#documentation-howto.
The tutorial by Oskar Andreasson is particularly good.The output of man iptablesIntroductionBeginning with Shorewall 4.4.6, Shorewall includes two separate
implementations of traffic shaping. This document describes the original
implementation which is complex and difficult to configure. A much simpler
version is described in Simple Traffic Shaping/Control
and is highly recommended unless you really need to delay certain traffic
passing through your firewall.Shorewall has builtin support for traffic shaping and control. This
support does not cover all options available (and especially all
algorithms that can be used to queue traffic) in the Linux kernel but it
should fit most needs. If you are using your own script for traffic
control and you still want to use it in the future, you will find
information on how to do this, later in this
document. But for this to work, you will also need to enable
traffic shaping in the kernel and Shorewall as covered by the next
sections.Linux traffic shaping and controlThis section gives a brief introduction of how controlling traffic
with the Linux kernel works. Although this might be enough for configuring
it in the Shorewall configuration files, we strongly recommend that you
take a deeper look into the Linux
Advanced Routing and Shaping HOWTO. At the time of writing this,
the current version is 1.0.0.Since kernel 2.2, Linux has extensive support for controlling
traffic. You can define different algorithms that are used to queue the
traffic before it leaves an interface. The standard one is called pfifo
and is (as the name suggests) of the type First In First out. This means,
that it does not shape anything, if you have a connection that eats up all
your bandwidth, this queuing algorithm will not stop it from doing
so.For Shorewall traffic shaping we use three algorithms: HTB
(Hierarchical Token Bucket), HFSC (Hierarchical Fair Service Curves) and
SFQ (Stochastic Fairness Queuing). SFQ is easy to explain: it just tries
to track your connections (tcp or udp streams) and balances the traffic
between them. This normally works well. HTB and HFSC allow you to define a
set of classes, and you can put the traffic you want into these classes.
You can define minimum and maximum bandwidth settings for those classes
and order them hierarchically (the less prioritized classes only get
bandwidth if the more important have what they need). Additionally, HFSC
allows you to specify the maximum queuing delay that a packet may
experience. Shorewall builtin traffic shaping allows you to define these
classes (and their bandwidth limits), and it uses SFQ inside these classes
to make sure, that different data streams are handled equally. If SFQ's
default notion of a 'stream' doesn't work well for you, you can change it
using the flow option described below.You can shape incoming traffic through use of an
Intermediate Functional Block (IFB) device. See below. But beware: using an
IFB can result in queues building up both at your ISPs router and at your
own.You shape and control outgoing traffic by assigning the traffic to
classes. Each class is associated with exactly one
network interface and has a number of attributes:PRIORITY - Used to give preference to one class over another
when selecting a packet to send. The priority is a numeric value with
1 being the highest priority, 2 being the next highest, and so
on.RATE - The minimum bandwidth this class should get, when the
traffic load rises. Classes with a higher priority (lower PRIORITY
value) are served even if there are others that have a guaranteed
bandwidth but have a lower priority (higher PRIORITY value).CEIL - The maximum bandwidth the class is allowed to use when
the link is idle.MARK - Netfilter has a facility for
marking packets. Packet marks have a numeric
value which is limited in Shorewall to the values 1-255 (1-16383 if
you set WIDE_TC_MARKS=Yes in shorewall.conf (5) ). You
assign packet marks to different types of traffic using entries in the
/etc/shorewall/tcrules file.In Shorewall 4.4.26, WIDE_TC_MARKS was superseded by TC_BITS
which specifies the width in bits of the traffic shaping mark field.
The default is based on the setting of WIDE_TC_MARKS so as to
provide upward compatibility. See the Packet Marking using
/etc/shorewall/tcrules article.One class for each interface must be designated as the
default class. This is the class to which unmarked
traffic (packets to which you have not assigned a mark value in
/etc/shorewall/tcrules) is assigned.Netfilter also supports a mark value on each connection. You can
assign connection mark values in
/etc/shorewall/tcrules, you can copy the current
packet's mark to the connection mark (SAVE), or you can copy the
connection mark value to the current packet's mark (RESTORE). For more
information, see this
article.Linux Kernel ConfigurationYou will need at least kernel 2.4.18 for this to work, please take a
look at the following screenshot for what settings you need to enable. For
builtin support, you need the HTB scheduler, the Ingress scheduler, the
PRIO pseudoscheduler and SFQ queue. The other scheduler or queue
algorithms are not needed.This screen shot shows how I configured QoS in a 2.6.16
Kernel:And here's my recommendation for a 2.6.21 kernel:Enable TC support in ShorewallYou need this support whether you use the builtin support or whether
you provide your own tcstart script.To enable the builtin traffic shaping and control in Shorewall, you
have to do the following:Set TC_ENABLED to "Internal" in /etc/shorewall/shorewall.conf.
Setting TC_ENABLED=Yes causes
Shorewall to look for an external tcstart file (See a later section for details).Setting CLEAR_TC parameter in
/etc/shorewall/shorewall.conf to Yes
will clear the traffic shaping configuration during Shorewall
[re]start and Shorewall stop. This is normally what you want when
using the builtin support (and also if you use your own tcstart
script)The other steps that follow depend on whether you use your own
script or the builtin solution. They will be explained in the
following sections.Using builtin traffic shaping/controlShorewall's builtin traffic shaping feature provides a thin layer on
top of the ingress qdesc, HTB and SFQ. That translation layer allows you
to:Define HTB and/or HFSC classes using Shorewall-style
column-oriented configuration files.Integrate the reloading of your traffic shaping configuration
with the reloading of your packet-filtering and marking
configuration.Assign traffic to HTB or HFSC classes by TOS value.Assign outgoing TCP ACK packets to an HTB or HFSC class.Assign traffic to HTB and/or HFSC classes based on packet mark
value or based on packet contents.Those few features are really all that builtin traffic
shaping/control provides; consequently, you need to understand HTB and/or
HFSC and Linux traffic shaping as well as Netfilter packet marking in
order to use the facility. Again, please see the links at top of this
article.For defining bandwidths (for either devices or classes) please use
kbit or kbps (for Kilobytes per second) and make sure there is NO space between the number and the unit (it is
100kbit not 100 kbit). Using mbit, mbps
or a raw number (which means bytes) could be used, but note that only
integer numbers are supported (0.5 is not
valid).To properly configure the settings for your
devices you need to find out the real up- and downstream rates you
have. This is especially the case, if you are using a DSL
connection or one of another type that do not have a guaranteed bandwidth.
Don't trust the values your provider tells you for this; especially
measuring the real download speed is important! There are several online
tools that help you find out; search for "dsl speed test" on google (For
Germany you can use arcor speed
check). Be sure to choose a test site located near you./etc/shorewall/tcdevicesThis file allows you to define the incoming and outgoing bandwidth
for the devices you want traffic shaping to be enabled. That means, if
you want to use traffic shaping for a device, you have to define it
here. For additional information, see shorewall-tcdevices
(5).Columns in the file are as follows:INTERFACE - Name of interface. Each interface may be listed
only once in this file. You may NOT specify the name of an alias
(e.g., eth0:0) here; see FAQ #18.
You man NOT specify wildcards here, e.g. if you have multiple ppp
interfaces, you need to put them all in here! Shorewall will
determine if the device exists and will only configure the device if
it does exist. If it doesn't exist or it is DOWN, the following
warning is issued:WARNING: Device <device name> is
not in the UP state -- traffic-shaping configuration
skippedShorewall assigns a sequential interface
number to each interface (the first entry in
/etc/shorewall/tcdevices is interface 1, the
second is interface 2 and so on) You can also explicitly specify the
interface number by prefixing the interface name with the number and
a colon (":"). Example: 1:eth0.Device numbers are expressed in hexidecimal. So the device
following 9 is A, not 10.IN-BANDWIDTH - The incoming Bandwidth of that interface.
Please note that when you use this column, you are not traffic
shaping incoming traffic, as the traffic is already received before
you could do so. This Column allows you to define the maximum
traffic allowed for this interface in total, if the rate is
exceeded, the excess packets are dropped. You want this mainly if
you have a DSL or Cable Connection to avoid queuing at your
providers side. If you don't want any traffic to be dropped set this
to a value faster than your interface maximum rate (or to 0
(zero).To determine the optimum value for this setting, we recommend
that you start by setting it significantly below your measured
download bandwidth (20% or so). While downloading, measure the
ping response time from the firewall to the
upstream router as you gradually increase the setting.The optimal
setting is at the point beyond which the ping
time increases sharply as you increase the setting.For fast lines, the actually download speed may be well
below what you specify here. If you have this problem, then follow
the bandwidth with a ":" and a burst size.
The default burst is 10kb, but on my 50mbit line, I specify 200kb.
(50mbit:200kb).OUT-BANDWIDTH - Specify the outgoing bandwidth of that
interface. This is the maximum speed your connection can handle. It
is also the speed you can refer as "full" if you define the tc
classes. Outgoing traffic above this rate will be dropped.OPTIONS — A comma-separated list of options from the following
list:classifyIf specified, classification of traffic into the various
classes is done by CLASSIFY entries in
/etc/shorewall/tcrules or by entries in
/etc/shorewall/tcfilters. No MARK value
will be associated with classes on this interface.hfscShorewall normally uses the Hierarchical
Token Bucket (HTB) queuing discipline. When
is specified, the
Hierarchical Fair Service Curves (HFSC)
discipline is used instead.linklayerAdded in Shorewall 4.5.6. Type of link (ethernet, atm,
adsl). When specified, causes scheduler packet size
manipulation as described in tc-stab (8). When this option is
given, the following options may also be given after
it:mtu=mtuThe device MTU; default 2048 (will be rounded up
to a power of two)mpu=mpubytesMinimum packet size used in calculations. Smaller
packets will be rounded up to this sizetsize=tablesizeSize table entries; default is 512overhead=overheadbytesNumber of overhead bytes per packetREDIRECTED INTERFACES — Entries are appropriate in this column
only if the device in the INTERFACE column names a Intermediate Functional Block (IFB). It lists
the physical interfaces that will have their input shaped using
classes defined on the IFB. Neither the IFB nor any of the
interfaces listed in this column may have an IN-BANDWIDTH specified.
You may specify zero (0) or a dash ("-:) in the IN-BANDWIDTH
column.IFB devices automatically get the classify option.Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. The device has an outgoing bandwidth of 500kbit
and an incoming bandwidth of 6000kbit#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 6000kbit 500kbit/etc/shorewall/tcclassesThis file allows you to define the actual classes that are used to
split the outgoing traffic. For additional information, see shorewall-tcclasses
(5).INTERFACE - Name of interface. Users may also specify the
interface number. Must match the name (or number) of an interface
with an entry in /etc/shorewall/tcdevices. If
the interface has the classify
option in /etc/shorewall/tcdevices, then the
interface name or number must be followed by a colon and a
class number. Examples: eth0:1, 4:9. Class
numbers must be unique for a given interface. Normally, all classes
defined here are sub-classes of a root class that is implicitly
defined from the entry in shorewall-tcdevices(5). You
can establish a class hierarchy by specifying a
parent class (e.g.,
interface:parent-class:class)
-- the number of a class that you have previously defined. The
sub-class may borrow unused bandwidth from its parent.Class numbers are expressed in hexidecimal. So the class
following class 9 is A, not 10.MARK - The mark value which is an integer in the range 1-255
(1-16383 if you set WIDE_TC_MARKS=Yes or set TC_BITS=14 in shorewall.conf (5) ). You
define these marks in the tcrules file, marking the traffic you want
to go into the queuing classes defined in here. You can use the same
marks for different Interfaces. You must specify "-' in this column
if the device specified in the INTERFACE column has the classify option in
/etc/shorewall/tcdevices.In Shorewall 4.5.0, WIDE_TC_MARKS was superseded by TC_BITS
which specifies the width in bits of the traffic shaping mark
field. The default is based on the setting of WIDE_TC_MARKS so as
to provide upward compatibility.RATE - The minimum bandwidth this class should get, when the
traffic load rises. Please note that first the classes which equal
or a lesser priority value are served even if there are others that
have a guaranteed bandwidth but a lower priority. If the sum of the RATEs for all classes assigned to an
INTERFACE exceed that interfaces's OUT-BANDWIDTH, then the
OUT-BANDWIDTH limit will not be honored.When using HFSC, this column may contain 1, 2 or 3 pieces of
information separated by colons (":"). In addition to the minimum
bandwidth, leaf classes may specify realtime criteria: DMAX (maximum
delay in milliseconds) and optionally UMAX (the largest packet
expected in the class). See below for
details.CEIL - The maximum bandwidth this class is allowed to use when
the link is idle. Useful if you have traffic which can get full
speed when more important services (e.g. interactive like ssh) are
not used. You can use the value "full" in here for setting the
maximum bandwidth to the defined output bandwidth of that
interface.PRIORITY - you have to define a priority for the class.
packets in a class with a higher priority (=lesser value) are
handled before less prioritized ones. You can just define the mark
value here also, if you are increasing the mark values with lesser
priority.OPTIONS - A comma-separated list of options including the
following:default - this is the default class for that interface
where all traffic should go, that is not classified
otherwise.defining default for exactly one class per interface is
mandatory!tos-<tosname> - this lets you define a filter for
the given <tosname> which lets you define a value of the
Type Of Service bits in the ip package which causes the package
to go in this class. Please note, that this filter overrides all
mark settings, so if you define a tos filter for a class all
traffic having that mark will go in it regardless of the mark on
the package. You can use the following for this option:
tos-minimize-delay (16) tos-maximize-throughput (8)
tos-maximize-reliability (4) tos-minimize-cost (2)
tos-normal-service (0)Each of this options is only valid for one class per interface.tcp-ack - if defined causes an tc filter to be created
that puts all tcp ack packets on that interface that have an
size of <=64 Bytes to go in this class. This is useful for
speeding up downloads. Please note that the size of the ack
packets is limited to 64 bytes as some applications (p2p for
example) use to make every package an ack package which would
cause them all into here. We want only packets WITHOUT payload
to match, so the size limit. Bigger packets just take their
normal way into the classes.This option is only valid for class per interface.occurs=number - Typically used with
an IPMARK entry in tcrules. Causes the rule to be replicated for
a total of number rules. Each rule has a
successively class number and mark value.When 'occurs' is used:The associated device may not have the 'classify'
option.The class may not be the default class.The class may not have any 'tos=' options (including
'tcp-ack').The class should not specify a MARK value. If one is
specified, it will be ignored with a warning message.The 'RATE' and 'CEIL' parameters apply to each instance of
the class. So the total RATE represented by an entry with
'occurs' will be the listed RATE multiplied by
number. For additional information, see
tcrules
(5).flow=keys - Shorewall attaches an SFQ
queuing discipline to each leaf HTB and HFSC class. SFQ ensures
that each flow gets equal access to the
interface. The default definition of a flow corresponds roughly
to a Netfilter connection. So if one internal system is running
BitTorrent, for example, it can have lots of 'flows' and can
thus take up a larger share of the bandwidth than a system
having only a single active connection. The
classifier (module cls_flow) works around
this by letting you define what a 'flow' is. The clasifier must
be used carefully or it can block off all traffic on an
interface! The flow option can be specified for an HTB or HFSC
leaf class (one that has no sub-classes). We recommend that you
use the following:Shaping internet-bound traffic: flow=nfct-srcShaping traffic bound for your local net: flow=dstThese will cause a 'flow' to consists of the traffic
to/from each internal system.When more than one key is give, they must be enclosed in
parenthesis and separated by commas.To see a list of the possible flow keys, run this
command:
tc filter add flow help
Those that begin with "nfct-" are Netfilter connection
tracking fields. As shown above, we recommend flow=nfct-src;
that means that we want to use the source IP address
before SNAT as the key.Shorewall cannot determine ahead of time if the flow
classifier is available in your kernel (especially if it was
built into the kernel as opposed to being loaded as a module).
Consequently, you should check ahead of time to ensure that
both your kernel and 'tc' utility support the feature.You can test the 'tc' utility by typing (as
root):
tc filter add flow help
If flow is supported, you will see: Usage: ... flow ...
[mapping mode]: map key KEY [ OPS ] ...
[hashing mode]: hash keys KEY-LIST ...
...If 'flow' is not supported, you will see: Unknown filter "flow", hence option "help" is unparsableIf your kernel supports module autoloading, just type
(as root):
modprobe cls_flow
If 'flow' is supported, no output is produced;
otherwise, you will see: FATAL: Module cls_flow not found.If your kernel is not modularized or does not support
module autoloading, look at your kernel configuration (either
/proc/config.gz or the
.config file in /lib/modules/<kernel-version>/build/If 'flow' is supported, you will see: NET_CLS_FLOW=m or
NET_CLS_FLOW=y.For modularized kernels, Shorewall will attempt to load
/lib/modules/<kernel-version>/net/sched/cls_flow.ko
by default.pfifo - When specified for a leaf class, the pfifo queing
discipline is applied to the class rather than the sfq queuing
discipline.limit=number - Added in Shorewall
4.4.3. When specified for a leaf class, specifies the maximum
number of packets that may be queued within the class. The
number must be > 2 and less than 128. If
not specified, the value 127 is assumedred=(redoption,...) - Added in
Shorewall 4.5.6. When specified on a leaf class, causes the
class to use the red queuing discipline rather than SFQ. See
tc-red (8) for additional information.See shorewall-tcdevices
(5) for a description of the allowable
redoptions.fq_codel[=(codeloption,...)] -
Added in Shorewall 4.5.12. When specified on a leaf class,
causes the class to use the FQ CODEL (Fair-queuing
Controlled-delay) queuing discipline rather than
SFQ. See tc-fq_codel (8) for additional information.See shorewall-tcdevices
(5) for a description of the allowable
codloptions./etc/shorewall/tcrulesUnlike rules in the shorewall-rules(5) file,
evaluation of rules in this file will continue after a match. So the
final mark for each packet will be the one assigned by the LAST tcrule
that matches.Also unlike rules in the shorewall-rules(5) file,
the tcrules file is not stateful. So every packet that goes into, out
of or through your firewall is subject to entries in the tcrules
file.Because tcrules are not stateful, it is necessary to understand
basic IP socket operation. Here is an edited excerpt from a post on
the Shorewall Users list:
For the purposes of this discussion, the world is separated
into clients and servers. Servers provide services to
clients.When a server starts, it creates a socket and
binds the socket to an
address. For AF_INET (IPv4) and AF_INET6
(IPv6) sockets, that address is an ordered triple consisting of an
IPv4 or IPv6 address, a protocol, and possibly a port number. Port
numbers are only used when the protocol is TCP, UDP, SCTP or DCCP.
The protocol and port number used by a server are typically
well-known so that clients will be able to connect to it or send
datagrams to it. So SSH servers bind to TCP port 22, SMTP servers
bind to TCP port 25, etc. We will call this port the SERVER
PORT.When a client want to use the service provided by a server,
it also creates a socket and, like the server's socket, the
client's socket must be bound to an address. But in the case of
the client, the socket is usually given an automatic address
binding. For AF_INET and AF_INET6 sockets. the IP address is the
IP address of the client system (loose generalization) and the
port number is selected from a local port
range. On Linux systems, the local port range can be
seen by cat
/proc/sys/net/ipv4/ip_local_port_range. So it is not
possible in advance to determine what port the client will be
using. Whatever it is, we'll call it the CLIENT PORT.Now:
Packets sent from the client to the server will
have:
SOURCE PORT = CLIENT PORTDEST PORT = SERVER PORT
Packets sent from the server to the client will have:
SOURCE PORT = SERVER PORTDEST PORT = CLIENT PORT
Since the SERVER PORT is generally the only port known ahead
of time, we must categorize traffic from the server to the client
using the SOURCE PORT.
The fwmark classifier provides a convenient way to classify
packets for traffic shaping. The /etc/shorewall/tcrules
file is used for specifying these marks in a tabular fashion. For an
in-depth look at the packet marking facility in Netfilter/Shorewall,
please see this article.For marking forwarded traffic, you must
either set MARK_IN_FORWARD_CHAIN=Yes shorewall.conf or by using the :F
qualifier (see below).Columns in the file are as follows:ACTION - ACTION (previously called MARK) specifies the mark
value is to be assigned in case of a match. This is an integer in
the range 1-255 (1-16383 if you set WIDE_TC_MARKS=Yes or TC_BITS=14
in shorewall.conf
(5) ).In Shorewall 4.4.26, WIDE_TC_MARKS was superseded by TC_BITS
which specifies the width in bits of the traffic shaping mark
field. The default is based on the setting of WIDE_TC_MARKS so as
to provide upward compatibility.This value may be optionally followed by : and
either F, P or "T" to designate that
the marking will occur in the FORWARD, PREROUTING or POSTROUTING
chains respectively. If this additional specification is omitted,
the chain used to mark packets will be determined as follows:If the SOURCE is
$FW[:<address>], then the rule is
inserted in the OUTPUT chain.Otherwise, the chain is determined by the setting of the
MARK_IN_FORWARD_CHAIN option in shorewall.conf.Use the 'T' qualifier if you want the
rule to apply equally to traffic being routed through the firewall
and to traffic originating on the firewall
itself.Normally, the mark is applied to the packet. If you follow the
mark value with ":" and "C", then the mark is applied to the
connection. "C" can be combined with "F", "P" or "T" to designate
that the connection should be marked in a particular chain (e.g.,
"CF", "CP", "CT").There are additional special values available:RESTORE[/mask] --
restore the packet's mark from the connection's mark using the
supplied mask if any. Your kernel and iptables must include
CONNMARK support.As above, may be followed by :P, :F
or :T.SAVE[/mask] -- save
the packet's mark to the connection's mark using the supplied
mask if any. Your kernel and iptables must include CONNMARK
support.As above, may be followed by :P, :F
or :T.CONTINUE Don't process
any more marking rules in the table.As above, may be followed by :P, :F
or :T.COMMENT -- the rest of
the line will be attached as a comment to the Netfilter rule(s)
generated by the following entries. The comment will appear
delimited by "/* ... */" in the output of shorewall
show mangleTo stop the comment from being attached to further rules,
simply include COMMENT on a line by itself.To use CLASSIFY, your kernel and iptables must include
CLASSIFY target support. In that case, this column contains a
classification (classid) of the form <major>:<minor>
where <major> and <minor> are integers. Corresponds to
the 'class' specification in these traffic shaping modules:atmcbqdsmarkpfifo_fasthtbprioClassification occurs in the POSTROUTING chain except when the SOURCE contains
$FW[:<address>] in which case, the
classify action takes place in the OUTPUT chain. When used with the
builtin traffic shaper, the <major> class is the interface
number and the <minor> class is either:Constructed by Shorewall. The method of construction
depends on the setting of WIDE_TC_MARKS (TC_BITS in shorewall
4.4.26 and later) in (shorewall.conf
(5)).When WIDE_TC_MARKS=No (the default) or TC_BITS > 14,
the <minor> class is:the MARK value of the class preceded by the number "1"
or "10" (MARK value 1 is <minor> class 11, MARK value
22 is <minor> class 122, and so on). "10" is used
where there are more than 10 devices defined in /etc/shorewall/tcdevices.When WIDE_TC_MARKS=Yes (TC_BITS >= 14), the
<minor> class is assigned sequentially beginning with
2.The class number, if specified.SOURCE - Source of the packet.May be:An interface name - matches traffic entering the firewall
on the specified interface. May not be used in classify rules or
in rules using the :T chain qualifier.A comma-separated list of host or network IP addresses or
MAC addresses. This form will not match
traffic that originates on the firewall itself unless either
<major><minor> or the :T chain qualifier is used in
the ACTION column.Examples:0.0.0.0/0192.168.1.0/24, 172.20.4.0/24An interface name followed by a colon (":") followed by a
comma-separated list of host or network IP addresses or MAC
addresses. May not be used in classify rules or in rules using
the :T chain qualifier.$FW optionally followed by a colon (":") and a
comma-separated list of host or network IP addresses. matches
packets originating on the firewall. May not be used with a
chain qualifier (:P, :F, etc.) in the ACTION column.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78If your kernel includes iprange match support, then address
ranges may be included in the address lists.DEST - Destination of the packet.May be:An interface name. May not be used in the PREROUTING chain
(:P in the mark column or no chain qualifier and
MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)). The
interface name may be optionally followed by a colon (":") and
an IP address list.A comma-separated list of host or network IP addresses.
The list may include ip address ranges if your kernel and
iptables include iprange support.PROTO - Protocol - Must be "tcp", "udp", "icmp", "ipp2p",
"ipp2p:udp", "ipp2p:all" a number, or "all". "ipp2p" requires ipp2p
match support in your kernel and iptables.PORT(S) - Destination Ports. A comma-separated list of Port
names (from /etc/services), port numbers or port ranges; if the
protocol is "icmp", this column is interpreted as the destination
icmp-type(s).If the protocol is ipp2p, this column is interpreted as an
ipp2p option without the leading "--" (example "bit" for
bit-torrent). If no PORT is given, "ipp2p" is assumed. Note that the
xtables-addons version of IPP2P does not support the "ipp2p" option;
if the column is empty or contains "ipp2p" when using that version
of IPP2P, Shorewall will substitute "edk,kazaa,gnu,dc".This column is ignored if PROTOCOL = all but must be entered
if any of the following field is supplied. In that case, it is
suggested that this field contain "-"CLIENT PORT(S) - (Optional) Port(s) used by the client. If
omitted, any source port is acceptable. Specified as a
comma-separate list of port names, port numbers or port
ranges.USER/GROUP (Optional) This column may only be non-empty if the
SOURCE is the firewall itself. When this column is non-empty, the
rule applies only if the program generating the output is running
under the effective user and/or group. It may contain :[!][<user name or number>]:[<group name or
number>][+<program name>]The colon is optional when specifying only a user.Examples:joe #program must be run by joe
:kids #program must be run by a member of the 'kids' group
!:kids #program must not be run by a member of the 'kids' group
+upnpd #program named upnpd (This feature was removed from Netfilter in kernel version 2.6.14).TEST (Optional) Defines a test on the existing packet or
connection mark. The rule will match only if the test returns true.
Tests have the format [!]<value>[/<mask>][:C]Where:! Inverts the test (not equal)<value> Value of the packet or connection
mark.<mask> A mask to be applied to the mark before
testing:C Designates a connection mark. If omitted, the packet
mark's value is tested.LENGTH (Optional) This field, if present, allows you to match
the length of a packet against a specific value or range of values.
A range is specified in the form <min>:<max> where
either <min> or <max> (but not both) may be omitted. If
<min> is omitted, then 0 is assumed; if <max> is
omitted, than any packet that is <min> or longer will
match.You must have iptables length support for this to work. If you
let it empty or place an "-" here, no length match will be
done.Examples: 1024, 64:1500, :100TOS (Optional) Type of Service. Either a standard name, or a
numeric value to match.
HELPER (Optional). Names one of the Netfilter protocol helper
modules such as ftp, sip,
amanda, etc.HEADERS (Optioinal, Shorewall6 only, added in Shorewall
4.4.15). List of IPv6 headers that may appear in packets. See shorewall6-tcrules
(5) for details.All packets arriving on eth1 should be marked with 1. All
packets arriving on eth2 and eth3 should be marked with 2. All packets
originating on the firewall itself should be marked with 3.#ACTION SOURCE DESTINATION PROTOCOL PORT(S)
1 eth1 0.0.0.0/0 all
2 eth2 0.0.0.0/0 all
2 eth3 0.0.0.0/0 all
3 $FW 0.0.0.0/0 allAll GRE (protocol 47) packets destined for 155.186.235.151
should be marked with 12.#ACTION SOURCE DESTINATION PROTOCOL PORT(S)
12:T 0.0.0.0/0 155.182.235.151 47All SSH request packets originating in 192.168.1.0/24 and
destined for 155.186.235.151 should be marked with 22.#ACTION SOURCE DESTINATION PROTOCOL PORT(S)
22:T 192.168.1.0/24 155.182.235.151 tcp 22All SSH packets packets going out of the first device in in
/etc/shorewall/tcdevices should be assigned to the class with mark
value 10.#ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT
# PORT(S)
1:110 0.0.0.0/0 0.0.0.0/0 tcp 22
1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22Mark all ICMP echo traffic with packet mark 1. Mark all peer to
peer traffic with packet mark 4.This is a little more complex than otherwise expected. Since the
ipp2p module is unable to determine all packets in a connection are
P2P packets, we mark the entire connection as P2P if any of the
packets are determined to match. We assume packet/connection mark 0 to
means unclassified. Traffic originating on the firewall is not covered
by this example.#ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST
# PORT(S) GROUP
1 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0
CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0
4 0.0.0.0/0 0.0.0.0/0 ipp2p:all
SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0The last four rules can be translated as:
"If a packet hasn't been classified (packet mark is 0), copy
the connection mark to the packet mark. If the packet mark is set,
we're done. If the packet is P2P, set the packet mark to 4. If the
packet mark has been set, save it to the connection mark."
Mark all forwarded VOIP connections with connection mark 1 and
ensure that all VOIP packets also receive that mark (assumes that
nf_conntrack_sip is loaded).#ACTION SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST CONNBYTES TOS HELPER
# PORT(S) GROUP
RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0
CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0
1 0.0.0.0/0 0.0.0.0/0 all - - - - - - sip
SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0ppp devicesIf you use ppp/pppoe/pppoa) to connect to your Internet provider
and you use traffic shaping you need to restart shorewall traffic
shaping. The reason for this is, that if the ppp connection gets
restarted (and it usually does this at least daily), all
tc filters/qdiscs related to that interface are
deleted.The easiest way to achieve this, is just to restart shorewall once
the link is up. To achieve this add a small executable script
to/etc/ppp/ip-up.d.#! /bin/sh
/sbin/shorewall refreshSharing a TC configuration between Shorewall and
Shorewall6Beginning with Shorewall 4.4.15, the traffic-shaping configuration
in the tcdevices, tcclasses and tcfilters files can be shared between
Shorewall and Shorewall6. Only one of the products can control the
configuration but the other can configure CLASSIFY rules in its own
tcrules file that refer to the shared classes.To defined the configuration in Shorewall and shared it with
Shorewall6:Set TC_ENABLED=Internal in shorewall.conf
(5).Set TC_ENABLED=Shared in shorewall6.conf
(5).Create symbolic links from /etc/shorewall6 to
/etc/shorewall/tcdevices and /etc/shorewall/tcclasses:ln -s ../shorewall/tcdevices /etc/shorewall6/tcdevices
ln -s ../shorewall/tcclasses /etc/shorewall6/tcclassesIf you need to define IPv6 tcfilter entries, do so in
/etc/shorewall/tcfilters. That file now allows entries that apply to
IPv6.Shorewall6 compilations to have access to the tcdevices and
tcclasses files although it will create no output. That access allows
CLASSIFY rules in /etc/shorewall6/tcrules to be validated against the TC
configuration.In this configuration, it is Shorewall that controls TC
configuration (except for IPv6 tcrules). You can reverse the settings in
the files if you want to control the configuration using
Shorewall6.Per-IP Traffic ShapingSome network administrators feel that they have to divy up their
available bandwidth by IP address rather than by prioritizing the
traffic based on the type of traffic. This gets really awkward when
there are a large number of local IP addresses.This section describes the Shorewall facility for making this
configuration less tedious (and a lot more efficient). Note that it
requires that you install
xtables-addons. So before you try this facility, we suggest that
first you add the following OPTION to each external interface described
in /etc/shorewall/tcdevices:flow=nfct-srcIf you shape traffic on your internal interface(s), then add this
to their entries:flow=dstYou may find that this simple change is all that is needed to
control bandwidth hogs like Bit Torrent. If it doesn't, then proceed as
described in this section.The facility has two components:An IPMARK MARKing command in
/etc/shorewall/tcrules.An occurs OPTION in
/etc/shorewall/tcclasses.The facility is currently only available with IPv4.In a sense, the IPMARK target is more like an IPCLASSIFY target in
that the mark value is later interpreted as a class ID. A packet mark is
32 bits wide; so is a class ID. The major class
occupies the high-order 16 bits and the minor class
occupies the low-order 16 bits. So the class ID 1:4ff (remember that
class IDs are always in hex) is equivalent to a mark value of 0x104ff.
Remember that Shorewall uses the interface number as the
major number where the first interface in tcdevices
has major number 1, the second has
major number 2, and so on.The IPMARK target assigns a mark to each matching packet based on
the either the source or destination IP address. By default, it assigns
a mark value equal to the low-order 8 bits of the source address.The syntax is as follows:
Default values are:srcmask1 = 0xFFmask2 = 0x00shift = 0src and dst specify whether the mark is to be based on
the source or destination address respectively. The selected address is
first shifted right by shift, then LANDed with
mask1 and then LORed with
mask2. The shift argument is
intended to be used primarily with IPv6 addresses.Example:IPMARK(src,0xff,0x10100)
Source IP address is 192.168.4.3 = 0xc0a80403
0xc0a80403 >> 0 = 0xc0a80403
0xc0a80403 LAND 0xFF = 0x03
0x03 LOR 0x10100 = 0x10103
So the mark value is 0x10103 which corresponds to class id 1:103.It is important to realize that, while class IDs are composed of a
major and a minor value, the
set of minor values must be unique. You must keep
this in mind when deciding how to map IP addresses to class IDs. For
example, suppose that your internal network is 192.168.1.0/29 (host IP
addresses 192.168.1.1 - 192.168.1.6). Your first notion might be to use
IPMARK(src,0xFF,0x10000) so as to produce class IDs 1:1 through 1:6. But
1:1 is the class ID of the base HTB class on interface 1. So you might
chose instead to use IPMARK(src,0xFF,0x10100) as shown in the example
above so as to avoid minor class 1.The occurs option in
/etc/shorewall/tcclasses causes the class
definition to be replicated many times.The synax is:
occurs=number
When occurs is used:The associated device may not have the classify option.The class may not be the default class.The class may not have any tos= options (including tcp-ack).The class should not specify a MARK value. Any MARK value given is
ignored with a warning. The RATE and CEIL parameters apply to each
instance of the class. So the total RATE represented by an entry with
occurs will be the listed RATE
multiplied by number.Example:/etc/shorewall/tcdevices:#INTERFACE IN-BANDWIDTH OUT-BANDWIDTH
eth0 100mbit 100mbit/etc/shorewall/tcclasses:#DEVICE MARK RATE CEIL PRIORITY OPTIONS
eth0:101 - 1kbit 230kbit 4 occurs=6The above defines 6 classes with class IDs 0x101-0x106. Each class
has a guaranteed rate of 1kbit/second and a ceiling of 230kbit./etc/shoreall/tcrules:#ACTION SOURCE DEST
IPMARK(src,0xff,0x10100):F 192.168.1.0/29 eth0This facility also alters the way in which Shorewall generates a
class number when none is given. Prior to the implementation of this
facility, the class number was constructed by concatinating the MARK
value with the either '1' or '10'. '10' was used when there were more
than 10 devices defined in
/etc/shorewall/tcdevices.With this facility, a new method is added; class numbers are
assigned sequentially beginning with 2. The WIDE_TC_MARKS option in
shorewall.conf selects which construction to use.
WIDE_TC_MARKS=No (the default) produces pre-Shorewall 4.4 behavior.
WIDE_TC_MARKS=Yes (TC_BITS >= 14 in Shorewall 4.4.26 and later)
produces the new behavior.Real life examplesA Shorewall User's ExperienceChuck Kollars has provided an excellent
writeup about his traffic shaping experiences.Configuration to replace WondershaperYou are able to fully replace the wondershaper script by using
the buitin traffic control.. In this example it is assumed that your
interface for your Internet connection is ppp0 (for DSL), if you use
another connection type, you have to change it. You also need to
change the settings in the tcdevices.wondershaper file to reflect your
line speed. The relevant lines of the config files follow here. Please
note that this is just a 1:1 replacement doing exactly what
wondershaper should do. You are free to change it...tcdevices file#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 5000kbit 500kbittcclasses file#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay
ppp0 2 3*full/10 9*full/10 2 default
ppp0 3 2*full/10 8*full/10 2tcrules file#ACTION SOURCE DEST PROTO PORT(S) CLIENT USER
# PORT(S)
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
# mark traffic which should have a lower priority with a 3:
# mldonkey
3 0.0.0.0/0 0.0.0.0/0 udp - 4666Wondershaper allows you to define a set of hosts and/or ports
you want to classify as low priority. To achieve this , you have to
add these hosts to tcrules and set the mark to 3 (true if you use
the example configuration files).Setting hosts to low prioritylets assume the following settings from your old wondershaper
script (don't assume these example values are really useful, they
are only used for demonstrating ;-):
# low priority OUTGOING traffic - you can leave this blank if you want
# low priority source netmasks
NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28"
# low priority destination netmasks
NOPRIOHOSTDST=60.0.0.0/24
# low priority source ports
NOPRIOPORTSRC="6662 6663"
# low priority destination ports
NOPRIOPORTDST="6662 6663" This would result in the following additional settings to the
tcrules file:3 192.168.1.128/25 0.0.0.0/0 all
3 192.168.3.28 0.0.0.0/0 all
3 0.0.0.0/0 60.0.0.0/24 all
3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663
3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663
3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663
3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663A simple setupThis is a simple setup for people sharing an Internet connection
and using different computers for this. It just basically shapes
between 2 hosts which have the ip addresses 192.168.2.23 and
192.168.2.42tcdevices file#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 6000kbit 700kbitWe have 6mbit down and 700kbit upstream.tcclasses file#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 10kbit 50kbit 1 tcp-ack,tos-minimize-delay
ppp0 2 300kbit full 2
ppp0 3 300kbit full 2
ppp0 4 90kbit 200kbit 3 defaultWe add a class for tcp ack packets with highest priority, so
that downloads are fast. The following 2 classes share most of the
bandwidth between the 2 hosts, if the connection is idle, they may
use full speed. As the hosts should be treated equally they have the
same priority. The last class is for the remaining traffic.tcrules file#ACTION SOURCE DEST PROTO PORT(S) CLIENT USER
# PORT(S)
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
2:F 192.168.2.23 0.0.0.0/0 all
3:F 192.168.2.42 0.0.0.0/0 allWe mark icmp ping and replies so they will go into the fast
interactive class and set a mark for each host.A Warning to Xen UsersIf you are running traffic shaping in your dom0 and traffic shaping
doesn't seem to be limiting outgoing traffic properly, it may be due to
"checksum offloading" in your domU(s). Check the output of "shorewall show
tc". Here's an excerpt from the output of that command:class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0
Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0)
rate 299288bit 3pps backlog 0b 0p requeues 0
lended: 53963 borrowed: 21361 giants: 90174
tokens: -26688 ctokens: -14783There are two obvious problems in the above output:The rate (299288) is considerably larger than the ceiling
(230000).There are a large number (90174) of giants reported.This problem will be corrected by disabling "checksum offloading" in
your domU(s) using the ethtool utility. See the one of the Xen articles for
instructions.An HFSC ExampleAs mentioned at the top of this article, there is an excellent
introduction to HFSC at http://linux-ip.net/articles/hfsc.en/.
At the end of that article are 'tc' commands that implement the
configuration in the article. Those tc commands correspond to the
following Shorewall traffic shaping configuration./etc/shorewall/tcdevices:#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS
eth0 - 1000kbit hfsc/etc/shorewall/tcclasses:#INTERFACE:CLASS MARK RATE: CEIL PRIORITY OPTIONS
# DMAX:UMAX
1:10 1 500kbit full 1
1:20 2 500kbit full 1
1:10:11 3 400kbit:53ms:1500b full 2
1:10:12 4 100kbit:30ms:1500b full 2The following sub-section offers some notes about the
article.Where Did all of those Magic Numbers come from?As you read the article, numbers seem to be introduced out of thin
air. I'll try to shed some light on those.There is very clear development of these numbers:12ms to transfer a 1500b packet at 1000kbits/second.100kbits per second with 1500b packets, requires 8 packets per
second.A packet from class 1:12 must be sent every 120ms.Total transmit delay can be no more than 132ms (120 +
12).We then learn that the queuing latency can be reduced to 30ms if
we use a two-part service curve whose first part is 400kbits/second.
Where did those come from?The latency is calculated from the rate. If it takes 12ms to
transmit a 1500 byte packet at 1000kbits/second, it takes 30ms to
transmit a 1500b at 400kbits/second.For the slope of the first part of the service curve, in
theory we can pick any number between 100 (the rate of class 1:12)
and 500 (the rate of the parent class) with higher numbers providing
lower latency.The final curious number is the latency for class 1:11 - 52.5ms.
It is a consequence of everything that has gone before.To acheive 400kbits/second with 1500-byte packets, 33.33 packets
per second are required. So a packet from class 1:11 must be sent every
30 ms. As the article says, "...the maximum transmission delay of this
class increases from 30ms to a total of 52.5 ms.". So we are looking for
an additional 22.5 ms.Assume that both class 1:11 and 1:12 transmit for 30 ms at
400kbits/second. That is a total of 800kbits/second for 30ms. So Class
1:11 is punished for the excess. How long is the punishment? The two
classes sent 24,000 bits in 30ms; they are only allowed 0.030 * 500,000
= 15,000. So they are 9,000 bits over their quota. The amount of time
required to transmit 9,000 bits at 400,000 bits/second is
22.5ms!.Intermediate Functional Block (IFB) DevicesThe principles behind an IFB is fairly simple:It looks like a network interface although it is never given an
IPv4 configuration.Because it is a network interface, queuing disciplines can be
associated with an IFB.The magic of an IFB comes in the fact that a filter may be defined
on a real network interface such that each packet that arrives on that
interface is queued for the IFB! In that way, the IFB provides a means for
shaping input traffic.To use an IFB, you must have IFB support in your kernel
(configuration option CONFIG_IFB). Assuming that you have a modular
kernel, the name of the IFB module is 'ifb' and may be loaded using the
command modprobe ifb (if you have modprobe installed)
or insmod /path/to/module/ifb.By default, two IFB devices (ifb0 and ifb1) are created. You can
control that using the numifbs option (e.g., modprobe ifb
numifbs=1).To create a single IFB when Shorewall starts, place the following
two commands in /etc/shorewall/init:modprobe ifb numifbs=1
ip link set ifb0 upEntries in /etc/shorewall/tcrules have no
effect on shaping traffic through an IFB. To allow classification of such
traffic, the /etc/shorewall/tcfilters file has been added. Entries in that
file create u32
classification rules./etc/shorewall/tcfiltersWhile this file was created to allow shaping of traffic through an
IFB, the file may be used for general traffic classification as well.
The file is similar to shorewall-tcrules(5) with the
following key exceptions:The first match determines the classification, whereas in the
tcrules file, the last match determines the classification.ipsets are not supportedDNS Names are not supportedAddress ranges and lists are not supportedExclusion is not supported.filters are applied to packets as they appear on the
wire. So incoming packets will not have DNAT applied yet
(the destination IP address will be the external address) and
outgoing packets will have had SNAT applied.The last point warrants elaboration. When looking at traffic being
shaped by an IFB, there are two cases to consider:Requests — packets being sent from remote clients to local
servers. These packets may undergo subsequent DNAT, either as a
result of entries in /etc/shorewall/nat or as a
result of DNAT or REDIRECT rules.Example: /etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT(S) PORT(S) DEST
DNAT net dmz:192.168.4.5 tcp 80 - 206.124.146.177Requests redirected by this rule will have destination IP
address 206.124.146.177 and destination port 80.Responses — packets being sent from remote servers to local
clients. These packets may undergo subsequent DNAT as a result of
entries in /etc/shorewall/nat or in
/etc/shorewall/masq. The packet's destination
IP address will be the external address specified in the
entry.Example:
/etc/shorewall/masq:#INTERFACE SOURCE ADDRESS
eth0 192.168.1.0/24 206.124.146.179HTTP response packets corresponding to requests that fall
under that rule will have destination IP address 206.124.146.179 and
source port 80.Beginning with Shorewall 4.4.15, both IPv4 and IPv6 rules can be
defined in this file. See shorewall-tcfilters (5)
for details.Columns in the file are as follow. As in all Shorewall
configuration files, a hyphen ("-") may be used to indicate that no
value is supplied in the column.CLASSThe interface name or number followed by a colon (":") and
the class number.SOURCESOURCE IP address (host or network). DNS names are not
allowed.DESTDESTINATION IP address (host or network). DNS names are not
allowed.PROTOProtocol name or number.DEST PORT(S)Comma-separated list of destination port names or numbers.
May only be specified if the protocol is TCP, UDP, SCTP or ICMP.
Port ranges are supported except for ICMP.SOURCE PORTComma-separated list of source port names or numbers. May
only be specified if the protocol is TCP, UDP or SCTP. Port ranges
are supported.TOSSpecifies the value of the TOS field. The value can be any
of the following:hex-numberhex-number/hex-numberThe hex-numbers must be exactly
two digits (e.g., 0x04).LENGTHMust be a power of 2 between 32 and 8192 inclusive. Packets
with a total length that is strictly less than the specified value
will match the rule.Example:I've used this configuration on my own firewall. The IFB portion
is more for test purposes rather than to serve any well-reasoned QOS
strategy./etc/shorewall/init:qt modprobe ifb numifbs=1
qt ip link set dev ifb0 up/etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST
- ifb0/etc/shorewall/tcdevices:
#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED
# INTERFACES
1:eth0 - 384kbit classify
2:ifb0 - 1300kbit - eth0/etc/shorewall/tcclasses:#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
1:110 - 5*full/10 full 1 tcp-ack,tos-minimize-delay
1:120 - 2*full/10 6*full/10 2 default
1:130 - 2*full/10 6*full/10 3
2:110 - 5*full/10 full 1 tcp-ack,tos-minimize-delay
2:120 - 2*full/10 6*full/10 2 default
2:130 - 2*full/10 6*full/10 3/etc/shorewall/tcfilters:#INTERFACE: SOURCE DEST PROTO DEST SOURCE
#CLASS PORT(S) PORT(S)
#
# OUTGOING TRAFFIC
#
1:130 206.124.146.178 - tcp - 49441,49442 #BITTORRENT on wookie
1:110 206.124.146.178 #wookie
1:110 206.124.146.179 #SNAT of internal systems
1:110 206.124.146.180 #Work Laptop
1:110 - - icmp echo-request,echo-reply
1:110 - - icmp echo-reply
1:130 206.124.146.177 - tcp - 873,25 #Bulk Traffic
#
# INCOMING TRAFFIC
#
2:110 - 206.124.146.178 #Wookie
2:110 - 206.124.146.179 #SNAT Responses
2:110 - 206.124.146.180 #Work Laptop
2:130 - 206.124.146.177 tcp 25 #Incoming Email.You can examine the installed filters with the shorewall
show filters command. What follows shows the output for
eth0 with the filters shown
above. Bold font are comments
explaining the rules.gateway:~ # shorewall-lite show filters
Shorewall Lite 4.1.6 Classifiers at gateway - Fri Mar 21 08:06:47 PDT 2008
Device eth1:
Device eth2:
Device eth0:
filter parent 1: protocol ip pref 10 u32
filter parent 1: protocol ip pref 10 u32 fh 3: ht divisor 1 <========= Start of table 3. parses TCP header
filter parent 1: protocol ip pref 10 u32 fh 3::800 order 2048 key ht 3 bkt 0 flowid 1:130 (rule hit 102 success 0)
match 03690000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 873 goes to class 1:130
filter parent 1: protocol ip pref 10 u32 fh 2: ht divisor 1 <========= Start of table 2. parses ICMP header
filter parent 1: protocol ip pref 10 u32 fh 2::800 order 2048 key ht 2 bkt 0 flowid 1:110 (rule hit 0 success 0)
match 08000000/ff000000 at nexthdr+0 (success 0 ) <========= ICMP Type 8 goes to class 1:110
filter parent 1: protocol ip pref 10 u32 fh 2::801 order 2049 key ht 2 bkt 0 flowid 1:110 (rule hit 0 success 0)
match 00000000/ff000000 at nexthdr+0 (success 0 ) <========= ICMP Type 0 goes to class 1:110
filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 <========= Start of table 1. parses TCP header
filter parent 1: protocol ip pref 10 u32 fh 1::800 order 2048 key ht 1 bkt 0 flowid 1:130 (rule hit 0 success 0)
match c1210000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 49441 goes to class 1:130
filter parent 1: protocol ip pref 10 u32 fh 1::801 order 2049 key ht 1 bkt 0 flowid 1:130 (rule hit 0 success 0)
match c1220000/ffff0000 at nexthdr+0 (success 0 ) <========= SOURCE PORT 49442 goes to class 1:130
filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 <========= Start of Table 800. Packets start here!=============== The following 2 rules are generated by the class definition in /etc/shorewall/classes ==================
filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:110 (rule hit 2204 success 138)
match 00060000/00ff0000 at 8 (success 396 ) <========= TCP
match 05000000/0f00ffc0 at 0 (success 250 ) <========= Header length 20 and Packet Length < 64
match 00100000/00ff0000 at 32 (success 138 ) <========= ACK
filter parent 1: protocol ip pref 10 u32 fh 800::801 order 2049 key ht 800 bkt 0 flowid 1:110 (rule hit 2066 success 0)
match 00100000/00100000 at 0 (success 0 ) <========= Minimize-delay goes to class 1:110 =============== Jump to Table 1 if the matches are met ==================
filter parent 1: protocol ip pref 10 u32 fh 800::802 order 2050 key ht 800 bkt 0 link 1: (rule hit 2066 success 0)
match ce7c92b2/ffffffff at 12 (success 1039 ) <========= SOURCE 206.124.146.178
match 00060000/00ff0000 at 8 (success 0 ) <========= PROTO TCP
offset 0f00>>6 at 0 eat
filter parent 1: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800 bkt 0 flowid 1:110 (rule hit 2066 success 1039)
match ce7c92b2/ffffffff at 12 (success 1039 ) <========= SOURCE 206.124.146.178 goes to class 1:110
filter parent 1: protocol ip pref 10 u32 fh 800::804 order 2052 key ht 800 bkt 0 flowid 1:110 (rule hit 1027 success 132)
match ce7c92b3/ffffffff at 12 (success 132 ) <========= SOURCE 206.124.146.179 goes to class 1:110
filter parent 1: protocol ip pref 10 u32 fh 800::805 order 2053 key ht 800 bkt 0 flowid 1:110 (rule hit 895 success 603)
match ce7c92b4/ffffffff at 12 (success 603 ) <========= SOURCE 206.124.146.180 goes to class 1:110 =============== Jump to Table 2 if the matches are met ==================
filter parent 1: protocol ip pref 10 u32 fh 800::806 order 2054 key ht 800 bkt 0 link 2: (rule hit 292 success 0)
match 00010000/00ff0000 at 8 (success 0 ) <========= PROTO ICMP
offset 0f00>>6 at 0 eat
=============== Jump to Table 3 if the matches are met ==================
filter parent 1: protocol ip pref 10 u32 fh 800::807 order 2055 key ht 800 bkt 0 link 3: (rule hit 292 success 0)
match ce7c92b1/ffffffff at 12 (success 265 ) <========= SOURCE 206.124.146.177
match 00060000/00ff0000 at 8 (success 102 ) <========= PROTO TCP
offset 0f00>>6 at 0 eat Understanding the output of 'shorewall show tc'The shorewall show tc (shorewall-lite
show tc) command displays information about the current state of
traffic shaping. For each device, it executes the following
commands: echo Device $device:
tc -s -d qdisc show dev $device
echo
tc -s -d class show dev $device
echo So, the traffic-shaping output is generated entirely by the
tc utility.Here's the output of for eth0. The configuration is the one shown in
the preceding section (the output was obtained almost 24 hours later than
the shorewall show filters output shown above).Device eth0:
============== The primary queuing discipline is HTB (Hierarchical Token Bucket) ====================
qdisc htb 1: r2q 10 default 120 direct_packets_stat 9 ver 3.17
Sent 2133336743 bytes 4484781 pkt (dropped 198, overlimits 4911403 requeues 21) <=========== Note the overlimits and dropped counts
rate 0bit 0pps backlog 0b 8p requeues 21
============== The ingress filter. If you specify IN-BANDWIDTH, you can see the 'dropped' count here. =========In this case, the packets are being sent to the IFB for shaping
qdisc ingress ffff: ----------------
Sent 4069015112 bytes 4997252 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
============ Each of the leaf HTB classes has an SFQ qdisc to ensure that each flow gets its turn ============
qdisc sfq 110: parent 1:110 limit 128p quantum 1514b flows 128/1024 perturb 10sec
Sent 613372519 bytes 2870225 pkt (dropped 0, overlimits 0 requeues 6)
rate 0bit 0pps backlog 0b 0p requeues 6
qdisc sfq 120: parent 1:120 limit 128p quantum 1514b flows 128/1024 perturb 10sec
Sent 18434920 bytes 60961 pkt (dropped 0, overlimits 0 requeues 0)
rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 130: parent 1:130 limit 128p quantum 1514b flows 128/1024 perturb 10sec
Sent 1501528722 bytes 1553586 pkt (dropped 198, overlimits 0 requeues 15)
rate 0bit 0pps backlog 11706b 8p requeues 15
============= Class 1:110 -- the high-priority class ===========
Note the rate and ceiling calculated from 'full'
class htb 1:110 parent 1:1 leaf 110: prio 1 quantum 4800 rate 192000bit ceil 384000bit burst 1695b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 0
Sent 613372519 bytes 2870225 pkt (dropped 0, overlimits 0 requeues 0)
rate 195672bit 28pps backlog 0b 0p requeues 0 <=========== Note the current rate of traffic. There is no queuing (no packet backlog)
lended: 2758458 borrowed: 111773 giants:
tokens: 46263 ctokens: 35157
============== The root class ============
class htb 1:1 root rate 384000bit ceil 384000bit burst 1791b/8 mpu 0b overhead 0b cburst 1791b/8 mpu 0b overhead 0b level 7
Sent 2133276316 bytes 4484785 pkt (dropped 0, overlimits 0 requeues 0) <==== Total output traffic since last 'restart'
rate 363240bit 45pps backlog 0b 0p requeues 0
lended: 1081936 borrowed: 0 giants: 0
tokens: -52226 ctokens: -52226
============= Bulk Class (outgoing rsync, email and bittorrent) ============
class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1900 rate 76000bit ceil 230000bit burst 1637b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0
Sent 1501528722 bytes 1553586 pkt (dropped 198, overlimits 0 requeues 0)
rate 162528bit 14pps backlog 0b 8p requeues 0 <======== Queuing is occurring (8 packet backlog). The rate is still below the ceiling.
lended: 587134 borrowed: 966459 giants: 0 During peak activity, the rate tops out at around 231000 (just above ceiling).
tokens: -30919 ctokens: -97657
================= Default class (mostly serving web pages) ===============
class htb 1:120 parent 1:1 leaf 120: prio 2 quantum 1900 rate 76000bit ceil 230000bit burst 1637b/8 mpu 0b overhead 0b cburst 1714b/8 mpu 0b overhead 0b level 0
Sent 18434920 bytes 60961 pkt (dropped 0, overlimits 0 requeues 0)
rate 2240bit 2pps backlog 0b 0p requeues 0
lended: 57257 borrowed: 3704 giants: 0
tokens: 156045 ctokens: 54178
Using your own tc scriptReplacing builtin tcstart fileIf you prefer your own tcstart file, just install it in
/etc/shorewall/tcstart.In your tcstart script, when you want to run the tc
utility, use the run_tc function supplied by Shorewall if you want tc
errors to stop the firewall.Set TC_ENABLED=Yes and CLEAR_TC=YesSupply an /etc/shorewall/tcstart script to configure your
traffic shaping rules.Optionally supply an /etc/shorewall/tcclear script to stop
traffic shaping. That is usually unnecessary.If your tcstart script uses the fwmark
classifier, you can mark packets using entries in
/etc/shorewall/tcrules.Traffic control outside ShorewallTo start traffic shaping when you bring up your network
interfaces, you will have to arrange for your traffic shaping
configuration script to be run at that time. How you do that is
distribution dependent and will not be covered here. You then
should:Set TC_ENABLED=No and CLEAR_TC=NoIf your script uses the fwmark classifier, you
can mark packets using entries in /etc/shorewall/tcrules.Testing ToolsAt least one Shorewall user has found this tool helpful: http://e2epi.internet2.edu/network-performance-toolkit.html
shorewall-docs-xml-4.5.21/Shorewall-init.xml 0000644 0001750 0001750 00000023655 12222401136 020652 0 ustar teastep teastep
Shorewall InitTomEastep2010Thomas M. EastepPermission 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.IntroductionThe Shorewall init scripts released from shorewall.net and by most
distributions start Shorewall after networking. This allows Shorewall to
detect the network configuration and taylor itself accordingly. It is
possible to start Shorewall prior to networking but doing so limits the
set of Shorewall features that can be used.When Shorewall starts after networking, there is the possibility of
unwanted connections being accepted between the time that an interface
comes up and the time that Shorewall has finished starting up. Also,
Shorewall has had no means of reacting when interfaces are brought up and
down.Beginning with Shorewall 4.4.10, a new package, Shorewall
Init, is available. Shorewall Init serves two purposes:It can 'close' the firewall before the network interfaces are
brought up during boot.It can change the firewall state as the result of interfaces
being brought up or taken down.These two features can be controlled independently. Shorewall Init
can be used together with any combination of the other Shorewall packages.
Shorewall-init works on RedHat-based, SuSE-based and Debian-based
distributions.Closing the Firewall before the Network Interfaces are brought
upWhen Shorewall-init is first installed, it does nothing until you
configure it.The configuration file is /etc/default/shorewall-init
on Debian-based systems and
/etc/sysconfig/shorewall-init otherwise. There are
two settings in the file:PRODUCTSLists the Shorewall packages that you want to integrate with
Shorewall-init.Example: PRODUCTS="shorewall shorewall6"IFUPDOWNWhen set to 1, enables integration with NetworkManager and the
ifup/ifdown scripts.To close your firewall before networking starts:In the Shorewall-init configuration file, set PRODUCTS to the
firewall products installed on your system.Be sure that your current firewall script(s) (normally in
/var/lib/<product>/firewall) is(are)
compiled with the 4.4.10 compiler.Shorewall and Shorewall6 users can execute these
commands:shorewall compileshorewall6 compileShorewall-lite and Shorewall6-lite users can execute these
commands on the administrative system:shorewall export
firewall-name-or-ip-addressshorewall6 export
firewall-name-or-ip-addressThat's all that is required.Integration with NetworkManager and ifup/ifdown ScriptsTo integrate with NetworkManager and ifup/ifdown, additional steps
are required. You probably don't want to enable this feature if you run a
link status monitor like swping or LSM.In the Shorewall-init configuration file, set IFUPDOWN=1.In your Shorewall interfaces file(s), set the
option on any interfaces that must be up in
order for the firewall to start. At least one interface must have the
or option if you
perform the next optional step.Optional) -- If you have specified at least one
or interface, you
can then disable automatic firewall startup at boot time. On Debian
systems, set startup=0 in
/etc/default/product.
On other systems, use your service startup configuration tool
(chkconfig, insserv, ...) to disable startup.If your system uses Upstart as it's system initialization
daemon, you should not disable startup. Upstart is standard on
recent Ubuntu and Fedora releases and is optional on Debian.The following actions occur when an interface comes up:FIREWALL STATEINTERFACEACTIONAnyRequiredstartstoppedOptionalstartstartedOptionalenablestartedAnyrestartThe following actions occur when an interface goes down:FIREWALL STATEINTERFACEACTIONAnyRequiredstopstoppedOptionalstartstartedOptionaldisablestartedAnyrestartFor optional interfaces, the
/var/lib/product/interface.state
files are maintained to reflect the state of the interface so that they
may be used by the standard isusable script. Please
note that the action is carried out using the current compiled script; the
configuration is not recompiled.A new option has been added to shorewall.conf
and shorewall6.conf. The REQUIRE_INTERFACE option
determines the outcome when an attempt to start/restart/restore/refresh
the firewall is made and none of the optional interfaces are available.
With REQUIRE_INTERFACE=No (the default), the operation is performed. If
REQUIRE_INTERFACE=Yes, then the operation fails and the firewall is placed
in the stopped state. This option is suitable for a laptop with both
ethernet and wireless interfaces. If either come up, the firewall starts.
If neither comes up, the firewall remains in the stopped state.Similarly, if an optional interface goes down and there are no
optional interfaces remaining in the up state, then the firewall is
stopped.On Debian-based systems, during system shutdown the firewall is
opened prior to network shutdown (/etc/init.d/shorewall
stop performs a 'clear' operation rather than a 'stop'). This is
required by Debian standards. You can change this default behavior by
setting SAFESTOP=1 in /etc/default/shorewall
(/etc/default/shorewall6, ...).
shorewall-docs-xml-4.5.21/QOSExample.xml 0000644 0001750 0001750 00000037776 12222401136 017740 0 ustar teastep teastep
QOS ConfigurationTomEastep2012Thomas M. EastepPermission 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.IntroductionThis configuration was inspired by the one in this thread on the
OpenWRT Forum: https://forum.openwrt.org/viewtopic.php?pid=154533#p154533.
The configuration has been adapted to Shorewall 4.5.6 with the following
changes:The configuration uses an IFB, yet only uses firewall marks in
the OUTPUT and FORWARD chains to classify packets; clearly that
doesn't workTo be more precise, it doesn't work with an unpatched
kernel. The OpenWRT script assumes an 'act_conntrack' patch which
performs conntrack processing on packets before they are sent to
the IFB. That patch is not generally available.The configuration presented here uses U32 classifiers
(shorewall-tcfilters(5)) to classify traffic for download shaping and
uses the POSTROUTING chain for upload shaping.The sample uses a weak form of P2P classification; the one
presented below uses IPP2P.The OpenWRT script assumed that the uplink was ATM -- the one
below makes no assumption (it specifies 'ethernet' with overhead
'0')./etc/shorewall/paramsThe shell variables set in the OpenWRT script are set in the
Shorewall params file:DOWNLOAD=40000 #download speed in kbit. set xx% of real download speed
UPLOAD=7000 # set xx% of real upload speed
# multiports = up to 15 ports
# ports to be classified as bulk #set after connection mark save and after connection mark restore
TCP_BULK="1024:" #S and D ports
UDP_BULK="1024:" #S and D ports
# Destination ports to be classified as P2P
TCP_P2P="13769" #D ports
UDP_P2P="13769" #D ports
IP_P2P="192.168.0.133"
# Destination ports to be classified as normal
TCP_NORMAL="80,443,25,20,21,110,993,995" # D ports
UDP_NORMAL=""
# Destination ports to be classified as Prio (overules bulk ports)
TCP_PRIO="22,53" #destination ports
UDP_PRIO="22,53" #destination ports
# Destination ports to be classified as VoIP (overules bulk ports)
TCP_VOIP=""
UDP_VOIP="18080"
IP_VOIP="192.168.0.226" #destination and source IP
IP_VOIP="192.168.0.226" #destination and source IP
#!!!!!uplink leaf class parameters!!!!!!!!!
#bulk
UP_LS_BULK_RATE=$(($UPLOAD*5/100))
UP_UL_BULK_RATE=$UPLOAD
#settings leaf qdisc
UP_BULK_RED_PROB=0.05 #red drob probability
UP_BULK_RED_min=6250 #real limit. To limit BULK traffic
UP_BULK_RED_min2=6250 #min for doing the calculations (burst and etc)
UP_BULK_RED_max=$((2 * $UP_BULK_RED_min2 + $UP_BULK_RED_min))
UP_BULK_RED_burst=$(((5 * $UP_BULK_RED_min2) / (3 * 1000)))
UP_BULK_RED_limit=$(($UP_BULK_RED_max * 5))
#P2P
UP_LS_P2P_RATE=$(($UPLOAD * 5 / 100))
UP_UL_P2P_RATE=$UPLOAD
#settings leaf qdisc
UP_P2P_RED_PROB=0.05 #red drob probability
UP_P2P_RED_min=32000 #real limit. To limit P2P traffic
UP_P2P_RED_min2=32000 #min for doing the calculations (burst and etc)
UP_P2P_RED_max=$((5 * $UP_P2P_RED_min2 + $UP_P2P_RED_min))
UP_P2P_RED_burst=$(((5 * $UP_P2P_RED_min2) / (3 * 1000)))
UP_P2P_RED_limit=$(($UP_P2P_RED_max * 5))
#normal class
UP_LS_NORMAL_RATE=$(($UPLOAD * 40 / 100))
UP_UL_NORMAL_RATE=$UPLOAD
#settings leaf qdisc
UP_NORMAL_RED_PROB=0.05 #red drob probability
UP_NORMAL_RED_min=6250 #real limit. To limit NORMAL traffic
UP_NORMAL_RED_min2=6250 #min for doing the calculations (burst and etc)
UP_NORMAL_RED_max=$((2 * $UP_NORMAL_RED_min2 + $UP_NORMAL_RED_min))
UP_NORMAL_RED_burst=$(((5 * $UP_NORMAL_RED_min2) / (3 * 1000)))
UP_NORMAL_RED_limit=$(($UP_NORMAL_RED_max * 5))
#prio
UP_LS_PRIO_RATE=$(($UPLOAD*50/100))
UP_RT_PRIO_RATE="200" #rate in kbit
UP_RT_PRIO_UMAX="400" #lengte of the packets [byte]
UP_RT_PRIO_DMAX="15" #delay in ms
UP_UL_PRIO_RATE=$UPLOAD
#Voip
UP_UL_VOIP_RATE=$UPLOAD
UP_SC_VOIP_RATE="200"
UP_SC_VOIP_UMAX="350" #length of the voip packets [byte]
UP_SC_VOIP_DMAX="10" #delay in ms
#bulk
DOWN_LS_BULK_RATE=$(($DOWNLOAD*5/100))
DOWN_UL_BULK_RATE=$DOWNLOAD
#leaf qdisc parameters
DOWN_BULK_RED_PROB=0.05 #red drob probability
DOWN_BULK_RED_min=62500 #real limit. To limit BULK traffic
DOWN_BULK_RED_min2=62500 #min for doing the calculations (burst and etc)
DOWN_BULK_RED_max=$((2 * $DOWN_BULK_RED_min2 + $DOWN_BULK_RED_min))
DOWN_BULK_RED_burst=$(((5 * $DOWN_BULK_RED_min2) / (3 * 1000)))
DOWN_BULK_RED_limit=$(($DOWN_BULK_RED_max * 5))
#P2P
DOWN_LS_P2P_RATE=$(($DOWNLOAD*5/100))
DOWN_UL_P2P_RATE=4000
#leaf qdisc parameters
DOWN_P2P_RED_PROB=0.05 #red drob probability
DOWN_P2P_RED_min=200000 #real limit. To limit P2P traffic
DOWN_P2P_RED_min2=200000 #min for doing the calculations (burst and etc)
DOWN_P2P_RED_max=$((2 * $DOWN_P2P_RED_min2 + $DOWN_P2P_RED_min))
DOWN_P2P_RED_burst=$(((5 * $DOWN_P2P_RED_min2) / (3 * 1000)))
DOWN_P2P_RED_limit=$(($DOWN_P2P_RED_max * 5))
#normal class
DOWN_LS_NORMAL_RATE=$(($DOWNLOAD*75/100))
DOWN_UL_NORMAL_RATE=$DOWNLOAD
#leaf qdisc parameters
DOWN_NORMAL_RED_PROB=0.05 #red drob probability
DOWN_NORMAL_RED_min=62500 #real limit. To limit NORMAL traffic
DOWN_NORMAL_RED_min2=62500 #min for doing the calculations (burst and etc)
DOWN_NORMAL_RED_max=$((2 * $DOWN_NORMAL_RED_min2 + $DOWN_NORMAL_RED_min))
DOWN_NORMAL_RED_burst=$(((5 * $DOWN_NORMAL_RED_min2) / (3 * 1000)))
DOWN_NORMAL_RED_limit=$(($DOWN_NORMAL_RED_max * 5))
#prio
DOWN_RT_PRIO_RATE="500" #rate in kbit
DOWN_RT_PRIO_UMAX="400" #length of the packets [byte]/
DOWN_RT_PRIO_DMAX="1.5" #delay in ms
DOWN_UL_PRIO_RATE=$DOWNLOAD
#Voip
DOWN_UL_VOIP_RATE=$DOWNLOAD
DOWN_SC_VOIP_RATE="250"
DOWN_SC_VOIP_UMAX="350" #lengt of voip packets [byte]
DOWN_SC_VOIP_DMAX="1.2" #delay in ms/etc/shorewall/initThe init file loads the ifb module, creating a single device:modprobe ifb numifbs=1
ip link set ifb0 up/etc/shorewall/tcdevicesThe tcdevices file describes the two devices:#NUMBER: IN-BANDWITH OUT-BANDWIDTH OPTIONS REDIRECTED
#INTERFACE INTERFACES
1:eth0 - ${UPLOAD}kbit hfsc,linklayer=ethernet,overhead=0
2:ifb0 - ${DOWNLOAD}kbit hfsc eth0/etc/shorewall/tcclassesThe tcclasses file defines the class hierarchy for both
devices:#IFACE: MARK RATE: CEIL PRIORITY OPTIONS
#CLASS DMAX:UMAX
1 1 ${UP_SC_VOIP_RATE}kbit:\
${UP_SC_VOIP_DMAX}:\
${UP_SC_VOIP_UMAX} ${UP_UL_VOIP_RATE}kbit 1
1 2 ${UP_RT_PRIO_RATE}kbit:\
${UP_RT_PRIO_DMAX}:\
${UP_RT_PRIO_UMAX} ${UP_LS_PRIO_RATE}kbit:\
${UP_UL_PRIO_RATE}kbit 1
1 3 - ${UP_LS_NORMAL_RATE}kbit:\
${UP_UL_NORMAL_RATE}kbit 1 red=(limit=$UP_NORMAL_RED_limit,\
min=$UP_NORMAL_RED_min,\
max=$UP_NORMAL_RED_max,\
burst=$UP_NORMAL_RED_burst,\
probability=$UP_NORMAL_RED_PROB,\
ecn)
1 4 - ${UP_LS_P2P_RATE}kbit:\
${UP_UL_P2P_RATE}kbit 1 red=(limit=$UP_P2P_RED_limit,\
min=$UP_P2P_RED_min,\
max=$UP_P2P_RED_max,\
burst=$UP_P2P_RED_burst,\
probability=$UP_P2P_RED_PROB,\
ecn)
1 5 - ${UP_LS_BULK_RATE}kbit:\
${UP_UL_BULK_RATE}kbit 1 default,\
red=(limit=$UP_BULK_RED_limit,\
min=$UP_BULK_RED_min,\
max=$UP_BULK_RED_max,\
burst=$UP_BULK_RED_burst,\
probability=$UP_BULK_RED_PROB,\
ecn)
2:10 - ${UP_SC_VOIP_RATE}kbit:\
${UP_SC_VOIP_DMAX}:\
${UP_SC_VOIP_UMAX} ${UP_UL_VOIP_RATE}kbit 1
2:20 - ${DOWN_RT_PRIO_RATE}kbit:\
${DOWN_RT_PRIO_DMAX}:\
${DOWN_RT_PRIO_UMAX} ${DOWN_UL_PRIO_RATE}kbit 1
2:30 - - ${DOWN_LS_NORMAL_RATE}kbit:\
${DOWN_UL_NORMAL_RATE}kbit 1 red=(limit=$DOWN_NORMAL_RED_limit,\
min=$DOWN_NORMAL_RED_min,\
max=$DOWN_NORMAL_RED_max,\
burst=$DOWN_NORMAL_RED_burst,\
probability=$DOWN_NORMAL_RED_PROB)
2:40 - - ${DOWN_LS_P2P_RATE}kbit:\
${DOWN_UL_P2P_RATE}kbit 1 red=(limit=$DOWN_P2P_RED_limit,\
min=$DOWN_P2P_RED_min,\
max=$DOWN_P2P_RED_max,\
burst=$DOWN_P2P_RED_burst,\
probability=$DOWN_P2P_RED_PROB)
2:50 - - ${DOWN_LS_BULK_RATE}kbit:\
${DOWN_UL_BULK_RATE}kbit 1 default,\
red=(limit=$DOWN_BULK_RED_limit,\
min=$DOWN_BULK_RED_min,\
max=$DOWN_BULK_RED_max,\
burst=$DOWN_BULK_RED_burst,\
probability=$DOWN_BULK_RED_PROB)/etc/shorewall/tcrulesThe tcrules file classifies upload packets:#MARK SOURCE DEST PROTO DEST SOURCE USER TEST
# PORT(S) PORT(S)
RESTORE:T - - - - - - !0:C
CONTINUE:T - - - - - - !0
2:T - - icmp
1:T - - udp $UDP_VOIP - - 0
1:T $IP_VOIP - - - - - 0
1:T - $IP_VOIP - - - - 0
2:T - - tcp $TCP_PRIO - - 0
2:T - - udp $UDP_PRIO - - 0
2:T - - tcp - $TCP_PRIO - 0
2:T - - udp - $UDP_PRIO - 0
3:T - - tcp $TCP_NORMAL - - 0
4:T - - ipp2p:all - - - 0
5:T - - tcp $TCP_BULK - - 0
5:T - - tcp - $TCP_BULK - 0
5:T - - udp $UDP_BULK - - 0
5:T - - udp - $UDP_BULK - 0
SAVE:T - - - - - - !0/etc/shorewall/tcfiltersThe tcfilters file classifies download packets:#INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH
#CLASS PORT(S) PORT(S)
#
# These classify download traffic
#
2:10 - $MYNET udp - $UDP_VOIP
2:20 - $MYNET tcp - $TCP_PRIO
2:20 - $MYNET udp - $UDP_PRIO
2:20 - $MYNET tcp $TCP_PRIO
2:20 - $MYNET udp $UDP_PRIO
2:30 - $MYNET tcp - $TCP_NORMAL
2:50 - $MYNET tcp $TCP_BULK
2:50 - $MYNET tcp - $TCP_BULK
2:50 - $MYNET udp $UDP_BULK
2:50 - $MYNET tcp - $UDP_BULK
shorewall-docs-xml-4.5.21/Shorewall_and_Routing.xml 0000644 0001750 0001750 00000020420 12222401136 022225 0 ustar teastep teastep
Shorewall and RoutingTomEastep200520062007Thomas M. EastepPermission 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.Routing vs. Firewalling.One of the most misunderstood aspects of Shorewall is its
relationship with routing. This article attempts to clear some of the fog
that surrounds this issue.As a general principle:Routing determines where packets are to be sent.Once routing determines where the packet is to go, the firewall
(Shorewall) determines if the packet is allowed to go there.There are ways that Shorewall can affect routing which are described
in the following sections.Routing and NetfilterThe following diagram shows the relationship between routing
decisions and Netfilter.The light blue boxes indicate where routing decisions are made. Upon
exit from one of these boxes, if the packet is being sent to another
system then the interface and the next hop have been uniquely
determined.The green boxes show where Netfilter processing takes place (as
directed by Shorewall). You will notice that there are two different paths
through this maze, depending on where the packet originates. We will look
at each of these separately.Packets Entering the Firewall from OutsideWhen a packet arrives from outside, it first undergoes Netfilter
PREROUTING processing. In Shorewall terms:Packets may be marked using entries in the /etc/shorewall/tcrules file. Entries in that file
containing ":P" in the mark column are applied here as are rules
that default to the MARK_IN_FORWARD_CHAIN=No setting in
/etc/shorewall/shorewall.conf. These marks may
be used to specify that the packet should be routed using an
alternate routing table; see the Shorewall Squid
documentation for examples.Marking packets then using the fwmark
selector in your "ip rule add"
commands should NOT be your first choice. In most cases, you can
use the from or dev
selector instead.The destination IP address may be rewritten as a consequence
of:DNAT[-] rules.REDIRECT[-] rules.Entries in /etc/shorewall/nat.So the only influence that Shorewall has over where these packets
go is via NAT or by marking them so that they may be routed using an
alternate routing table.Packets Originating on the FirewallProcessing of packets that originate on the firewall itself are
initially routed using the default routing table then passed through the
OUTPUT chains. Shorewall can influence what happens here:Packets may be marked using entries in the /etc/shorewall/tcrules file (rules with "$FW" in
the SOURCE column). These marks may be used to specify that the
packet should be re-routed using an alternate routing table.The destination IP address may be rewritten as a consequence
of:DNAT[-] rules that specify $FW as the SOURCE.Entries in /etc/shorewall/nat that
have "Yes" in LOCAL column.So again in this case, the only influence that Shorewall has over
the packet destination is NAT or marking.Alternate Routing Table ConfigurationThe Shorewall 2.x Shorewall
Squid documentation shows how alternate routing tables can be
created and used. That documentation shows how you can use logic in
/etc/shorewall/init to create and populate an
alternate table and to add a routing rule for its use. It is fine to use
that technique so long as you understand that you are basically just using
the Shorewall init script (/etc/init.d/shorewall) to
configure your alternate routing table at boot time and that other than as described in the previous section, there is no
connection between Shorewall and routing when using Shorewall versions
prior to 2.3.2.Routing and Proxy ARPThere is one instance where Shorewall creates main routing table
entries. When an entry in /etc/shorewall/proxyarp
contains "No" in the HAVEROUTE column then Shorewall will create a host
route to the IP address listed in the ADDRESS column through the interface
named in the INTERFACE column. This is the only case
where Shorewall directly manipulates the main routing
table.Example:/etc/shorewall/proxyarp:#ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT
206.124.146.177 eth1 eth0 No
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVEThe above entry will cause Shorewall to execute the following
command:ip route add 206.124.146.177 dev eth1Multiple Internet Connection Support in Shorewall 2.4.2 and
LaterBeginning with Shorewall 2.3.2, support is included for multiple
Internet connections. If you wish to use this feature, we recommend
strongly that you upgrade to version 2.4.2 or later.Shorewall multi-ISP support is now covered in a separate article.
shorewall-docs-xml-4.5.21/UPnP.xml 0000644 0001750 0001750 00000011534 12222401136 016564 0 ustar teastep teastep
Shorewall and UPnPTomEastep20052010Thomas M. EastepPermission 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.UPnPShorewall includes support for UPnP (Universal Plug and Play) using
linux-igd (http://linux-igd.sourceforge.net).
UPnP is required by a number of popular applications including MSN
IM.From a security architecture viewpoint, UPnP is a disaster. It
assumes that:All local systems and their users are completely
trustworthy.No local system is infected with any worm or trojan.If either of these assumptions are not true then UPnP can be used
to totally defeat your firewall and to allow incoming connections to
arbitrary local systems on any port whatsoever. In short: USE UPnP
AT YOUR OWN RISK.Shorewall and linux-igd implement a UPnP Internet
Gateway Device. It will not allow clients on one LAN subnet
to access a UPnP Media Server on another subnet.linux-igd ConfigurationIn /etc/upnpd.conf, you will want:create_forward_rules = yes
prerouting_chain_name = UPnP
forward_chain_name = forwardUPnPShorewall ConfigurationIn /etc/shorewall/interfaces, you need the
'upnp' option on your external interface.Example:#ZONE INTERFACE BROADCAST OPTIONS
net eth1 detect dhcp,routefilter,tcpflags,upnpIf your loc->fw policy is not ACCEPT then you need this
rule:#ACTION SOURCE DEST
allowinUPnP loc $FWYou MUST have this rule:#ACTION SOURCE DEST
forwardUPnP net locYou must also ensure that you have a route to 224.0.0.0/4 on your
internal (local) interface as described in the linux-igd
documentation.The init script included with the Debian linux-idg package adds
this route during start and deletes it during
stop.Shorewall versions prior to 4.4.10 do not retain the dynamic rules
added by linux-idg over a shorewall restart.Shorewall on a UPnP ClientIt is sometimes desirable to run UPnP-enabled client programs like
Transmission
(BitTorrent client) on a Shorewall-protected system. Shorewall provides
support for UPnP client access in the form of the upnpclient option in shorewall-interfaces
(5).The upnpclient option causes
Shorewall to detect the default gateway through the interface and to
accept UDP packets from that gateway. Note that, like all aspects of UPnP,
this is a security hole so use this option at your own risk.Note that when multiple clients behind the firewall use UPnP, they
must configure their applications to use unique ports.
shorewall-docs-xml-4.5.21/MyNetwork.xml 0000644 0001750 0001750 00000104027 12222401136 017701 0 ustar teastep teastep
My Network ConfigurationTomEastep2009Thomas M. EastepPermission 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.The ruleset shown in this article uses Shorewall features that are
not available in Shorewall versions prior to 4.4.0.IntroductionThe configuration described in this article represents the network
at shorewall.net during the summer of 2009. It uses the following
Shorewall features:Two Internet
InterfacesA DMZ with two "systems" using Proxy
ARP and running in OpenVZ Virtual
EnvironmentsIPv6 Access through a 6to4
TunnelOpenVPN and IPSEC for access when we are on the
road.IpsetsDynamic ZonesTransparent proxy using
SquidManual ChainsTraffic ShapingLinux runs the firewall and the servers (although they run in OpenVZ
containers on the firewall system). Linux is not used natively on any of
our other systems except for an HP mini
which runs HP Mobile Internet Experience (MIE) -- essentially
Ubuntu Hardy. I rather run Windows natively (either Vista Home Premium or
XP Professional) and run Linux in VMs under VirtualBox.
This approach has a number of advantages:Efficient disk utilization.The virtual disks used by Linux are just files in the NTFS file
system. There is no need to pre-allocate one or more partitions for
use by Linux. Some large applications, like Google Earth, are
installed only on Windows.Avoids proprietary hardware issues.The Linux VMs emulate standard hardware that is well-supported
by Linux.Avoids DRM hasslesAll DRM-protected media can be handled under Windows.Websites that don't work with Firefox (or at least with Linux
Firefox)VirtualBox is fast (when your processor supports virtualization
extensions) and very easy to use. I highly recommend it!Network TopologyOur network is diagrammed in the following graphic.We have accounts with two different ISPs:ComcastThis is a high-speed (20mb/4mb) link with a single dynamic IPv4
address. We are not allowed to run servers accessible through this
account.AvvantaThis is a low-speec (1.5mb/384kbit) link with five static IP
address. Our servers are accessed through this account.The wired local network is restricted to my home office. The
wireless network is managed by a Linksys WRT300N pre-N router which we use
only as an access point -- its WAN interface is unused and it is
configured to not do NAT. The wireless network uses WPA2 personal security
and MAC filtering is enabled in the router. These two factors make it a
hassle when guests visit with a laptop but provide good security for the
network.Shorewall ConfigurationThis section contains exerpts from the Shorewall
configuration.It is important to keep in mind that parts of my configuration are
there just to provide a test bed for Shorewall features. So while they
show correct usage, they don't necessarily provide any useful benefit. I
have tried to point those out in the sub-sections that follow./etc/shorewall/paramsMIRRORS=62.216.169.37,\
63.229.2.114,\
...
NTPSERVERS=...
POPSERVERS=...
LOG=ULOG
INT_IF=eth1
EXT_IF=eth2
COM_IF=eth0
VPS_IF=venet0As shown, this file defines variables to hold
the various lists of IP addresses that I need to maintain. To simplify
network reconfiguration, I also use variables to define the log level
and the network interfaces./etc/shorewall/shorewall.conf###############################################################################
# S T A R T U P E N A B L E D
###############################################################################
STARTUP_ENABLED=Yes
###############################################################################
# V E R B O S I T Y
###############################################################################
VERBOSITY=0
###############################################################################
# C O M P I L E R
# (setting this to 'perl' requires installation of Shorewall-perl)
###############################################################################
SHOREWALL_COMPILER=perl
###############################################################################
# L O G G I N G
###############################################################################
LOGFILE=/var/log/ulog/syslogemu.log
STARTUP_LOG=/var/log/shorewall-init.log
LOG_VERBOSITY=2
LOGFORMAT="%s:%s:"
LOGTAGONLY=No
LOGRATE=
LOGBURST=
LOGALLNEW=
BLACKLIST_LOGLEVEL=
MACLIST_LOG_LEVEL=
TCP_FLAGS_LOG_LEVEL=$LOG
SMURF_LOG_LEVEL=$LOG
LOG_MARTIANS=No
###############################################################################
# L O C A T I O N O F F I L E S A N D D I R E C T O R I E S
###############################################################################
IPTABLES=
IPSET=
PATH=/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin
SHOREWALL_SHELL=/bin/sh
SUBSYSLOCK=
MODULESDIR=
CONFIG_PATH=/etc/shorewall:/usr/share/shorewall
RESTOREFILE=
IPSECFILE=zones
LOCKFILE=
###############################################################################
# D E F A U L T A C T I O N S / M A C R O S
###############################################################################
DROP_DEFAULT="Drop"
REJECT_DEFAULT="Reject"
ACCEPT_DEFAULT="none"
QUEUE_DEFAULT="none"
###############################################################################
# R S H / R C P C O M M A N D S
###############################################################################
RSH_COMMAND='ssh ${root}@${system} ${command}'
RCP_COMMAND='scp ${files} ${root}@${system}:${destination}'
###############################################################################
# F I R E W A L L O P T I O N S
###############################################################################
IP_FORWARDING=Yes
ADD_IP_ALIASES=No
ADD_SNAT_ALIASES=No
RETAIN_ALIASES=No
TC_ENABLED=Internal
TC_EXPERT=No
CLEAR_TC=Yes
MARK_IN_FORWARD_CHAIN=Yes
CLAMPMSS=Yes
ROUTE_FILTER=No
DETECT_DNAT_IPADDRS=Yes
MUTEX_TIMEOUT=60
ADMINISABSENTMINDED=Yes
BLACKLISTNEWONLY=Yes
DELAYBLACKLISTLOAD=No
MODULE_SUFFIX=ko
DONT_LOAD=
DISABLE_IPV6=No
BRIDGING=No
DYNAMIC_ZONES=No
PKTTYPE=No
MACLIST_TABLE=mangle
MACLIST_TTL=60
SAVE_IPSETS=No
MAPOLDACTIONS=No
FASTACCEPT=No
IMPLICIT_CONTINUE=Yes
HIGH_ROUTE_MARKS=Yes
USE_ACTIONS=Yes
OPTIMIZE=1
EXPORTPARAMS=Yes
EXPAND_POLICIES=Yes
KEEP_RT_TABLES=No
DELETE_THEN_ADD=No
MULTICAST=Yes
AUTO_COMMENT=Yes
MANGLE_ENABLED=Yes
NULL_ROUTE_RFC1918=Yes
USE_DEFAULT_RT=No
RESTORE_DEFAULT_ROUTE=No
FAST_STOP=Yes
AUTOMAKE=No
LOG_MARTIANS=Yes
WIDE_TC_MARKS=Yes
###############################################################################
# P A C K E T D I S P O S I T I O N
###############################################################################
BLACKLIST_DISPOSITION=DROP
MACLIST_DISPOSITION=ACCEPT
TCP_FLAGS_DISPOSITION=DROP
I don't believe that there is anything remarkable
there/etc/shorewall/actions#ACTION
Mirrors # Accept traffic from Shorewall Mirrors
I make this into an action so the rather long list of rules
go into their own chain./etc/shorewall/action.Mirrors#TARGET SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
COMMENT Accept traffic from Mirrors
ACCEPT $MIRRORS
See the rules file -- this
action is used for rsync traffic./etc/shorewall/zonesfw firewall
loc ipv4 #Local Zone
dmz ipv4 #DMZ
net ipv4 #Internet
vpn:loc,net ipsec #IPSEC
drct:loc ipv4 #Direct internet accessThe
vpn zone is mostly for testing
Shorewall IPSEC support. It is nested in loc and net to
test a feature added in Shorewall 4.4.0. The drct zone is a dynamic zone whose members bypass
the transparent proxy. Some applications (such as VirtualBox
registration) don't work through the proxy./etc/shorewall/interfaces#ZONE INTERFACE BROADCAST OPTIONS
loc $INT_IF detect dhcp,logmartians=1,routefilter=1,tcpflags
dmz $VPS_IF detect logmartians=1,routefilter=0,routeback
net $EXT_IF detect dhcp,blacklist,tcpflags,optional,routefilter=0,nosmurfs,logmartians=0,proxyarp=1
net $COM_IF detect dhcp,blacklist,tcpflags,optional,upnp,routefilter=0,nosmurfs,logmartians=0
loc tun+ detectNotice that VPN clients are treated
the same as local hosts.I set the proxyarp option on
$EXT_IF so thatThe firewall will respond to ARP who-has requests for the
servers in the DMZ.To keep OpenVZ happy (it issues dire warnings if the option is
not set on the associated external interface)./etc/shorewall/hosts#ZONE HOST(S) OPTIONS
vpn $EXT_IF:0.0.0.0/0
vpn $COM_IF:0.0.0.0/0
vpn $INT_IF:0.0.0.0/0
drct $INT_IF:dynamicThe vpn zone includes ipsec hosts interfacing from
either external interface as well as the local interface. drct is defined as dynamic through the local
interface (recall that it is a sub-zone of loc)./etc/shorewall/policy#SOURCE DEST POLICY LOG LIMIT:BURST
# LEVEL
$FW dmz REJECT $LOG
$FW all ACCEPT
loc net ACCEPT -
loc fw ACCEPT
loc vpn ACCEPT
vpn fw ACCEPT
vpn loc ACCEPT
net net NONE
net all DROP $LOG 8/sec:30
dmz fw REJECT $LOG
all fw DROP $LOG
all all REJECT $LOGI'm a bit
sloppy with my fw<->loc policies -- I should fix that
someday.../etc/shorewall/accounting#ACTION CHAIN SOURCE DESTINATION PROTO DEST SOURCE USER/
# PORT(S) PORT(S) GROUP
hp:COUNT accounting $COM_IF $INT_IF:172.20.1.107 UDP
hp:COUNT accounting $INT_IF:172.20.1.107 $COM_IF UDP
DONE hp
mail:COUNT - $EXT_IF $VPS_IF:206.124.146.0/24 tcp 25
mail:COUNT - $VPS_IF:206.124.146.0/24 $EXT_IF tcp 25
DONE mail
web - $EXT_IF $VPS_IF:206.124.146.0/24 tcp 80
web - $EXT_IF $VPS_IF:206.124.146.0/24 tcp 443
web - $VPS_IF:206.124.146.0/24 $EXT_IF tcp - 80
web - $VPS_IF:206.124.146.0/24 $EXT_IF tcp - 443
COUNT web $EXT_IF $VPS_IF:206.124.146.0/24
COUNT web $VPS_IF:206.124.146.0/24 $EXT_IF
The accounting chains are as follows:hpCounts traffic to/from my work laptop to HP. The VPN users
NAT-Traversal (UDP 4500) so I just count all UDP traffic to/from my
work system.mailIncoming and outgoing emailwebWebsite traffic (both HTTP and HTTPS)/etc/shorewall/blacklist#ADDRESS/SUBNET PROTOCOL PORT
- udp 1024:1033,1434
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898This
configuration silently drops a few ports that get lots of
traffic./etc/shorewall/compileuse strict;
use Shorewall::Chains;
my $chainref = ensure_manual_chain qw/DNS_DDoS/;
add_rule $chainref, q(-m string --algo bm --from 30 --to 31 --hex-string "|010000010000000000000000020001|" -j DROP);
add_rule $chainref, q(-m string --algo bm --from 30 --to 31 --hex-string "|000000010000000000000000020001|" -j DROP);
add_rule $chainref, q(-j ACCEPT);
1;The above was created during a recent DDOS incident that
targeted DNS servers. It illustrates how manual chains can be
created./etc/shorewall/findgwif [ -f /var/lib/dhcp3/dhclient.${1}.leases ]; then
grep 'option routers' /var/lib/dhcp3/dhclient.${1}.leases | tail -n 1 | while read j1 j2 gateway; do echo $gateway | sed 's/;//'; return 0; done
fiThe Comcast line has a dynamic IP address assigned with the
help of dhclient./etc/shorewall/isusablelocal status
status=0
[ -f /etc/shorewall/${1}.status ] && status=$(cat /etc/shorewall/${1}.status)
return $statusFor use with lsm./etc/shorewall/lib.privatestart_lsm() {
killall lsm 2> /dev/null
cat <<EOF > /etc/lsm/shorewall.conf
connection {
name=Avvanta
checkip=206.124.146.254
device=$EXT_IF
ttl=2
}
connection {
name=Comcast
checkip=${ETH0_GATEWAY:-71.231.152.1}
device=$COM_IF
ttl=1
}
EOF
rm -f /etc/shorewall/*.status
/usr/sbin/lsm /etc/lsm/lsm.conf >> /var/log/lsm
}
This function configures and starts lsm./etc/shorewall/masq#INTERFACE SOURCE ADDRESS
COMMENT Masquerade Local Network
$COM_IF 0.0.0.0/0
$EXT_IF !206.124.146.0/24 206.124.146.179
All connections out through Comcast must have the dynamically
assigned address as their source address. Traffic from hosts without an
Avvanta public IP address get 206.124.146.179 as their source
address./etc/shorewall/notrack#SOURCE DESTINATION PROTO DEST SOURCE USER/
# PORT(S) PORT(S) GROUP
net:!192.88.99.1 - 41
dmz 206.124.146.255 udp
dmz 255.255.255.255 udp
loc 172.20.1.255 udp
loc 255.255.255.255 udp
$FW 255.255.255.255 udp
$FW 172.20.1.255 udp
$FW 206.124.146.255 udpThis file omits the
6to4 traffic originating from 6to4 relays as well as broadcast traffic
(which Netfilter doesn't handle)./etc/shorewall/providers#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
Avvanta 1 0x10000 main $EXT_IF 206.124.146.254 track,loose,fallback $INT_IF,$VPS_IF,tun*
Comcast 2 0x20000 main $COM_IF detect track,balance $INT_IF,$VPS_IF,tun*See
the Multi-ISP article for an explaination of
the multi-ISP aspects of this configuration./etc/shorewall/proxyarp<empty>As mentioned above, I set the proxyarp on the associated
external interface instead of defining proxy ARP in this file./etc/shorewall/restoredif [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then
start_lsm
fi
chmod 744 ${VARDIR}/stateIf lsm isn't running then start it.
Make the state file world-readable./etc/shorewall/rtrules#SOURCE DEST PROVIDER PRIORITY
- 172.20.0.0/24 main 1000 #OpenVPN clients
- 206.124.146.177 main 1001 #Servers -- Routes configured by OpenVZ
- 206.124.146.178 main 1001 #
- 216.168.3.44 Avvanta 1001 #NNTP -- Does source IP verification
206.124.146.176/30 - Avvanta 26000 #Avvanta public IP addresses
206.124.146.180 - Avvanta 26000 #These
entries simply ensure that outgoing traffic uses the correct
interface./etc/shorewall/routestopped#INTERFACE HOST(S) OPTIONS PROTO
$INT_IF 172.20.1.0/24 source,dest
$VPS_IF 206.124.146.177,206.124.146.178
$EXT_IF - notrack 41Keep
the lights on while Shorewall is stopped./etc/shorewall/rules###############################################################################################################################################################################
#ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/
# PORT PORT(S) DEST LIMIT GROUP
###############################################################################################################################################################################
SECTION ESTABLISHED
SECTION RELATED
SECTION NEW
REJECT:$LOG loc net tcp 25 #Stop direct loc->net SMTP (Comcast uses submission).
REJECT:$LOG loc net udp 1025:1031 #MS Messaging
COMMENT Stop NETBIOS crap
REJECT loc net tcp 137,445
REJECT loc net udp 137:139
COMMENT Stop my idiotic work laptop from sending to the net with an HP source IP address
DROP loc:!172.20.0.0/23 net
COMMENT
###############################################################################################################################################################################
# Local Network to Firewall
#
NONAT drct -
REDIRECT- loc 3128 tcp 80 - !66.199.187.46,172.20.1.108,206.124.146.177,155.98.64.80,81.19.16.0/21
###############################################################################################################################################################################
# Local network to DMZ
#
ACCEPT loc dmz udp domain,177
ACCEPT loc dmz tcp ssh,smtp,465,587,www,ftp,imaps,domain,https,5901:5903 -
ACCEPT loc dmz udp 33434:33524
###############################################################################################################################################################################
# Internet to ALL -- drop NewNotSyn packets
#
dropNotSyn net fw tcp
dropNotSyn net loc tcp
dropNotSyn net dmz tcp
###############################################################################################################################################################################
# Internet to DMZ
#
DNS_DDoS net dmz udp domain
ACCEPT net dmz tcp smtp,www,ftp,465,587,imaps,domain,https
ACCEPT net dmz udp 33434:33454
Mirrors:none net dmz tcp 873
ACCEPT net dmz tcp 22 - - s:ssh:3/min:3
#############################################################################################################################################################
#################
#
# Net to Local
#
Limit:$LOG:SSHA,3,60\
net loc tcp 22
#
# BitTorrent from Wireless Network
#
#DNAT net:$COM_IF loc:172.20.1.102 tcp 6881:6889
#DNAT net:$COM_IF loc:172.20.1.102 udp 6881
#
# UPnP
#
forwardUPnP net loc
#
# Silently Handle common probes
#
REJECT net loc tcp www,ftp,https
DROP net loc icmp 8
###############################################################################################################################################################################
# DMZ to Internet
#
ACCEPT dmz net udp domain,ntp
REJECT dmz net:$COM_IF tcp smtp
ACCEPT dmz net tcp echo,ftp,ssh,smtp,whois,domain,www,81,nntp,https,2401,2702,2703,8080
ACCEPT dmz net:$POPSERVERS tcp pop3
#
# Some FTP clients seem prone to sending the PORT command split over two packets. This prevents the FTP connection tracking
# code from processing the command and setting up the proper expectation. The following rule allows active FTP to work in these cases
# but logs the connection so I can keep an eye on this potential security hole.
#
ACCEPT:$LOG dmz net tcp 1024: 20
###############################################################################################################################################################################
# DMZ to Local
#
ACCEPT dmz loc tcp 22 - - s:ssh:3/min:3
###############################################################################################################################################################################
# DMZ to Firewall -- ntp & snmp Silently reject Auth
#
ACCEPT dmz fw tcp 161,ssh
ACCEPT dmz fw udp 161,ntp
REJECT dmz fw tcp auth
###############################################################################################################################################################################
# Internet to Firewall
#
REJECT net fw tcp www,ftp,https
DROP net fw icmp 8
ACCEPT net fw udp 33434:33454
ACCEPT net fw tcp 22 - - s:ssh:3/min:3
ACCEPT net fw udp 33434:33524
###############################################################################################################################################################################
# Firewall to DMZ
#
ACCEPT fw dmz tcp domain,www,ftp,ssh,smtp,https,993,465,587,5901
ACCEPT fw dmz udp domain
REJECT fw dmz udp 137:139
##############################################################################################################################################################################
#
COMMENT Freenode Probes
DROP net:82.96.96.3,85.190.0.3 any
COMMENT
##############################################################################################################################################################################
# Allow Ping except where disallowed earlier
#
ACCEPT any any icmp 8/etc/shorewall/startedif [ -z "$(ps ax | grep 'lsm ' | grep -v 'grep ' )" ]; then
start_lsm
fi
chmod 744 ${VARDIR}/stateIf lsm isn't running then start it.
Make the state file world-readable./etc/shorewall/stoppedif [ "$COMMAND" = stop -o "$COMMAND" = clear ]; then
killall lsm 2> /dev/null
fi
chmod 744 ${VARDIR}/stateKill lsm if the command is stop or
clear. Make the state file world-readable./etc/shorewall/tcdevices#INTERFACE IN-BANDWITH OUT-BANDWIDTH OPTIONS
$EXT_IF - 300kbit classify
$INT_IF - 80mbit classify
$COM_IF - 4mbit classify,hfsc
The use of HFSC on the Comcast link is largely to provide a
test bed for that qdisc; I really don't have any real-time requirement
such as VOIP./etc/shorewall/tcclasses#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
1:110 - full/4 full 1 tcp-ack,tos-minimize-delay
1:120 - full/4 full 2 flow=nfct-src
1:130 - full/4 230kbit 3 default,flow=nfct-src
1:140 - full/4 230kbit 4 flow=nfct-src
2:10 - 95*full/100 full 1 flow=dst
2:100 - 14mbit 20mbit 2
2:100:101 - 7mbit 20mbit 3 default,flow=dst
2:100:102 - 7mbit 20mbit 3 flow=dst
3:10 - 2mbit:4ms full 1 flow=nfct-src
3:100 - 2mbit full 2
3:100:101 - 1mbit full 3 default,flow=nfct-src
3:100:102 - 1mbit full 3 flow=nfct-src
Note that most of the outgoing bandwidth on the local
interface is allocated to one class. That class is used for local
traffic./etc/shorewall/tcfilters#INTERFACE: SOURCE DEST PROTO DEST SOURCE TOS LENGTH
#CLASS PORT(S) PORT(S)
# =============================== AVVANTA ====================================
#
# Give Highest priority to LSM's pings to the gateway and to DNS queries
#
1:110 206.124.146.176 206.124.146.254 icmp
1:110 206.124.146.177 - udp 53
#
# Second Highest priority to IPv6 Tunnel
#
1:120 206.124.146.180
#
# Lowest priority to bulk traffic
#
1:140 206.124.146.177 - tcp - 873 - 2048
1:140 206.124.146.177 - - - - tos-minimize-cost
The tcfilters file is only used for the Avvanta provider
because it has static public IP addresses./etc/shorewall/tcrules#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST LENGTH TOS
# PORT(S)
COMMENT Shape incoming traffic
#
# Most of the bandwidth is reserved for local traffic since the downlinks aren't that fast
#
2:10 206.124.146.176/30 $INT_IF
2:10 206.124.146.177 $INT_IF
2:10 172.20.1.254 $INT_IF
#
# Guarantee 1/2 of the incoming bandwidth for my work system
#
2:102 0.0.0.0/0 $INT_IF:172.20.1.107
COMMENT Shape outgoing traffic to Comcast
#
# Give 1/2 to my work system and add a latency guarantee
#
3:10 172.20.1.107 $COM_IF
#
# Restrict Torrent uploads
#
3:102 172.20.1.0/24 $COM_IF tcp - 6881:6889
The tcrules file is used to classify traffic that deals with
the local network and/or with Comcast./etc/shorewall/tunnels#TYPE ZONE GATEWAY GATEWAY
# ZONE
openvpnserver:udp net
6to4 net
ipsec net
ipsec loc
ipip vpn 0.0.0.0/0The ipip tunnel from
the vpn zone handles IP compression on IPSEC connections.
shorewall-docs-xml-4.5.21/manpages/ 0000755 0001750 0001750 00000000000 12223303501 017005 5 ustar teastep teastep shorewall-docs-xml-4.5.21/manpages/shorewall-stoppedrules.xml 0000644 0001750 0001750 00000015334 12222401136 024266 0 ustar teastep teastep
shorewall-stoppedrules5stoppedrulesThe Shorewall file that governs what traffic flows through the
firewall while it is in the 'stopped' state./etc/shorewall/stoppedrulesDescriptionThis file is used to define the hosts that are accessible when the
firewall is stopped or is being stopped.Changes to this file do not take effect until after the next
shorewall start, shorewall
restart, or command.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION -
Determines the disposition of the packet.
means that the packet will be accepted.
indicates that no conntrack entry should be
created for the packet. does not imply
.SOURCE - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets originating on the
firewall itself, while interface
specifies packets arriving on the named interface.This column may also include a comma-separated list of
IP/subnet addresses. If your kernel and iptables include iprange
match support, IP address ranges are also allowed. Ipsets and
exclusion are also supported. When or interface
are specified, the list must be preceded by a colon (":").If left empty or supplied as "-", 0.0.0.0/0 is assumed.DEST - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets addressed the firewall
itself, while interface specifies packets
arriving on the named interface. Neither may be specified if the
target is .This column may also include a comma-separated list of
IP/subnet addresses. If your kernel and iptables include iprange
match support, IP address ranges are also allowed. Ipsets and
exclusion are also supported. When or interface
are specified, the list must be preceded by a colon (":").If left empty or supplied as "-", 0.0.0.0/0 is assumed.PROTO (Optional) ‒
protocol-name-or-number[,...]Protocol.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT(S) (dport) ‒
service-name/port-number-listOptional. A comma-separated list of port numbers and/or
service names from /etc/services. May also
include port ranges of the form
low-port:high-port
if your kernel and iptables include port range support.SOURCE PORT(S) (sport) ‒
service-name/port-number-listOptional. A comma-separated list of port numbers and/or
service names from /etc/services. May also
include port ranges of the form
low-port:high-port
if your kernel and iptables include port range support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.FILES/etc/shorewall/stoppedrulesSee ALSOhttp://shorewall.net/starting_and_stopping_shorewall.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-init.xml 0000644 0001750 0001750 00000013414 12222401136 022475 0 ustar teastep teastep
shorewall-init8shorewall-initCompanion package/etc/init.d/shorewall-initstart|stopDescriptionShorewall-init is an optional package (added in Shorewall 4.4.10)
that can be installed along with Shorewall, Shorewall6, Shorewall-lite
and/or Shorewall6-lite. It provides two key features:It can close (stop) the firewall during boot prior to starting
the network. This can prevent unwanted connections from being accepted
after the network comes up but before the firewall is started.It can interface with your distribution's ifup/ifdown scripts
and/or NetworkManager to allow firewall actions when an interface
starts or stops.These two capabilities can be enabled separately.After you install the shorewall-init package, you can activate it by
modifying the Shorewall-init configuration
file:On Debian-based system, the file is
/etc/default/shorewall-init.On other systems, the file is
/etc/sysconfig/shorewall-init.To activate the safe boot feature, edit the configuration file and
set PRODUCTS to a space-separated list of Shorewall products that you want
to be closed before networking starts.Example:PRODUCTS="shorewall shorewall6"You also must insure that the compiled scripts for the listed
products are compiled using Shorewall 4.4.10 or later.Shorewallshorewall compileShorewall6shorewall6 compileShorewall-liteOn the administrative system, enter the command
shorewall export firewall from the firewall's
configuration directory.Shorewall6-liteOn the administrative system, enter the command
shorewall6 export firewall from the firewall's
configuration directory.The second feature (ifup/ifdown and NetworkManager integration)
should only be activated on systems that do not use a link status monitor
line swping or LSM.Edit the configuration file and set IFUPDOWN=1For NetworkManager integration, you will want to disable firewall
startup at boot and delay it to when your interface comes up. For this to
work correctly, you must set the required or the
optional option on at least one interface
then:On Debian-based systems, edit
/etc/default/product for each
product listed in the PRODUCTS setting and
set startup=0.On other systems, use the distribution's service control tool
(insserv, chkconfig, etc.) to disable startup of the products listed
in the PRODUCTS setting.On a laptop with both Ethernet and wireless interfaces, you will
want to make both interfaces optional and set the REQUIRE_INTERFACE option
to Yes in shorewall.conf (5) or
shorewall6.conf
(5). This causes the firewall to remain stopped until at least one of the
interfaces comes up.FILES/etc/default/shorewall-init (Debian-based
systems) or /etc/sysconfig/shorewall-init (other
distributions)See ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-lite.xml 0000644 0001750 0001750 00000114622 12222401136 022472 0 ustar teastep teastep
shorewall-lite8shorewall-liteAdministration tool for Shoreline Firewall Lite (Shorewall
Lite)shorewall-lite|-optionsinterface[:host-list]zoneshorewall-lite|-optionsaddressshorewall-lite|-optionsshorewall-lite|-optionsinterface[:host-list]zoneshorewall-lite|-options{ interface |
provider }shorewall-lite|-optionsaddressshorewall-lite|-optionsshorewall-lite|-options{ interface |
provider }shorewall-lite|-optionsfilenameshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionsaddressmaskaddress/vlsmshorewall-lite|-optionsaddress1address2shorewall-lite|-optionsiptables match
expressionshorewall-lite|-optionsaddressshorewall-lite|-optionsrefresh-intervalshorewall-lite|-optionsaddressshorewall-lite|-optionsiptables match
expressionshorewall-lite|-optionsaddressshorewall-lite|-optionsshorewall-lite|-optionsdirectoryshorewall-lite|-optionsfilenameshorewall-lite|-optionsfilenameshorewall-lite|-options
{|||}chainshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionseventshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionsshorewall-lite|-optionsDescriptionThe shorewall-lite utility is used to control the Shoreline Firewall
Lite (Shorewall Lite).OptionsThe and options are
used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace.The nolock prevents the command from
attempting to acquire the Shorewall-lite lockfile. It is useful if you
need to include shorewall commands in
/etc/shorewall/started.The options control the amount of output that
the command produces. They consist of a sequence of the letters v and q. If the
options are omitted, the amount of output is determined by the setting of
the VERBOSITY parameter in shorewall.conf(5). Each v adds one to the effective verbosity and each
q subtracts one from the effective
VERBOSITY. Alternately, v may be followed
immediately with one of -1,0,1,2 to specify a specify VERBOSITY. There may
be no white-space between v and the
VERBOSITY.The options may also include the letter
which causes all progress messages to be
timestamped.CommandsThe available commands are listed below.addAdds a list of hosts or subnets to a dynamic zone usually used
with VPN's.The interface argument names an interface
defined in the shorewall-interfaces(5)
file. A host-list is comma-separated list whose
elements are host or network addresses.The add command is not very robust. If
there are errors in the host-list, you
may see a large number of error messages yet a subsequent
shorewall-lite show zones command will indicate
that all hosts were added. If this happens, replace
add by delete and run the
same command again. Then enter the correct command.allowRe-enables receipt of packets from hosts previously
blacklisted by a drop, logdrop, reject, or logreject command.clearClear will remove all rules and chains installed by
Shorewall-lite. The firewall is then wide open and unprotected.
Existing connections are untouched. Clear is often used to see if
the firewall is causing connection problems.If is given, the command will be processed
by the compiled script that executed the last successful start, restart or refresh command if that script exists.deleteThe delete command reverses the effect of an earlier add command.The interface argument names an interface
defined in the shorewall-interfaces(5)
file. A host-list is comma-separated list whose
elements are a host or network address.disableAdded in Shorewall 4.4.26. Disables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.dropCauses traffic from the listed addresses
to be silently dropped.dumpProduces a verbose report about the firewall configuration for
the purpose of problem analysis.The -x option causes actual
packet and byte counts to be displayed. Without that option, these
counts are abbreviated. The -m
option causes any MAC addresses included in Shorewall-lite log
messages to be displayed.The -l option causes the rule
number for each Netfilter rule to be displayed.enableAdded in Shorewall 4.4.26. Enables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.forgetDeletes /var/lib/shorewall-lite/filename
and /var/lib/shorewall-lite/save. If no
filename is given then the file specified by
RESTOREFILE in shorewall.conf(5) is
assumed.helpDisplays a syntax summary.hitsGenerates several reports from Shorewall-lite log messages in
the current log file. If the option is included,
the reports are restricted to log messages generated today.ipcalcIpcalc displays the network address, broadcast address,
network in CIDR notation and netmask corresponding to the
input[s].iprangeIprange decomposes the specified range of IP addresses into
the equivalent list of network/host addresses.iptraceThis is a low-level debugging command that causes iptables
TRACE log records to be created. See iptables(8) for details.The iptables match expression must
be one or more matches that may appear in both the raw table OUTPUT
and raw table PREROUTING chains.The trace records are written to the kernel's log buffer with
facility = kernel and priority = warning, and they are routed from
there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) --
Shorewall-lite has no control over where the messages go; consult
your logging daemon's documentation.logdropCauses traffic from the listed addresses
to be logged then discarded. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5).logwatchMonitors the log file specified by the LOGFILE option in
shorewall.conf(5) and
produces an audible alarm when new Shorewall-lite messages are
logged. The -m option causes the
MAC address of each packet source to be displayed if that
information is available. The
refresh-interval specifies the time in
seconds between screen refreshes. You can enter a negative number by
preceding the number with "--" (e.g., shorewall-lite
logwatch -- -30). In this case, when a packet count
changes, you will be prompted to hit any key to resume screen
refreshes.logrejectCauses traffic from the listed addresses
to be logged then rejected. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5).noiptraceThis is a low-level debugging command that cancels a trace
started by a preceding iptrace command.The iptables match expression must
be one given in the iptrace command being
canceled.resetAll the packet and byte counters in the firewall are
reset.restartRestart is similar to shorewall-lite
start except that it assumes that the firewall is already
started. Existing connections are maintained.The option causes Shorewall-lite to avoid
updating the routing table(s).The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.restoreRestore Shorewall-lite to a state saved using the shorewall-lite save command. Existing
connections are maintained. The filename names
a restore file in /var/lib/shorewall-lite created using shorewall-lite save; if no
filename is given then Shorewall-lite will be
restored from the file specified by the RESTOREFILE option in shorewall.conf(5).saveThe dynamic blacklist is stored in
/var/lib/shorewall-lite/save. The state of the firewall is stored in
/var/lib/shorewall-lite/filename for use by the
shorewall-lite restore. If
filename is not given then the state is saved
in the file specified by the RESTOREFILE option in shorewall.conf(5).showThe show command can have a number of different
arguments:capabilitiesDisplays your kernel/iptables capabilities. The
-f option causes the display
to be formatted as a capabilities file for use with compile -e.[ [ ] chain...
]The rules in each chain are
displayed using the iptables
-Lchain-n -v command. If no
chain is given, all of the chains in the
filter table are displayed. The -x option is passed directly through to
iptables and causes actual packet and byte counts to be
displayed. Without this option, those counts are abbreviated.
The -t option specifies the
Netfilter table to display. The default is filter.The -b ('brief') option
causes rules which have not been used (i.e. which have zero
packet and byte counts) to be omitted from the output. Chains
with no rules displayed are also omitted from the
output.The -l option causes
the rule number for each Netfilter rule to be
displayed.If the t option and the
keyword are both omitted and any of the
listed chains do not exist, a usage
message is displayed.classifiers|filtersDisplays information about the packet classifiers
defined on the system as a result of traffic shaping
configuration.configDisplays distribution-specific defaults.connectionsDisplays the IP connections currently being tracked by
the firewall.event
eventAdded in Shorewall 4.5.19. Displays the named
event.eventsAdded in Shorewall 4.5.19. Displays all events.ipDisplays the system's IPv4 configuration.ipaAdded in Shorewall 4.4.17. Displays the per-IP
accounting counters (shorewall-accounting
(5)).logDisplays the last 20 Shorewall-lite messages from the
log file specified by the LOGFILE option in shorewall.conf(5). The
-m option causes the MAC
address of each packet source to be displayed if that
information is available.marksAdded in Shorewall 4.4.26. Displays the various fields
in packet marks giving the min and max value (in both decimal
and hex) and the applicable mask (in hex).natDisplays the Netfilter nat table using the command
iptables -t nat -L -n -v.The
-x option is passed directly
through to iptables and causes actual packet and byte counts
to be displayed. Without this option, those counts are
abbreviated.policiesAdded in Shorewall 4.4.4. Displays the applicable policy
between each pair of zones. Note that implicit intrazone
ACCEPT policies are not displayed for zones associated with a
single network where that network doesn't specify
.routingDisplays the system's IPv4 routing configuration.rawDisplays the Netfilter raw table using the command
iptables -t raw -L -n -v.The
-x option is passed directly
through to iptables and causes actual packet and byte counts
to be displayed. Without this option, those counts are
abbreviated.tcDisplays information about queuing disciplines, classes
and filters.zonesDisplays the current composition of the Shorewall zones
on the system.startStart Shorewall Lite. Existing connections through
shorewall-lite managed interfaces are untouched. New connections
will be allowed only if they are allowed by the firewall rules or
policies.The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.stopStops the firewall. All existing connections, except those
listed in shorewall-routestopped(5)
or permitted by the ADMINISABSENTMINDED option in shorewall.conf(5), are taken down.
The only new traffic permitted through the firewall is from systems
listed in shorewall-routestopped(5)
or by ADMINISABSENTMINDED.If is given, the command will be processed
by the compiled script that executed the last successful start, restart or refresh command if that script exists.statusProduces a short report about the state of the
Shorewall-configured firewall.versionDisplays Shorewall's version. The option
is included for compatibility with earlier Shorewall releases and is
ignored.EXIT STATUSIn general, when a command succeeds, status 0 is returned; when the
command fails, a non-zero status is returned.The status command returns exit status as
follows:0 - Firewall is started.3 - Firewall is stopped or cleared4 - Unknown state; usually means that the firewall has never been
started.FILES/etc/shorewall-lite/See ALSOhttp://www.shorewall.net/starting_and_stopping_shorewall.htmshorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-actions.xml 0000644 0001750 0001750 00000012052 12222401136 023167 0 ustar teastep teastep
shorewall-actions5actionsShorewall action declaration file/etc/shorewall/actionsDescriptionThis file allows you to define new ACTIONS for use in rules (see
shorewall-rules(5)). You define
the iptables rules to be performed in an ACTION in
/etc/shorewall/action.action-name.Columns are:NAMEThe name of the action. ACTION names should begin with an
upper-case letter to distinguish them from Shorewall-generated chain
names and be composed of letters, digits or numbers. If you intend
to log from the action then the name must be no longer than 11
characters in length if you use the standard LOGFORMAT.OPTIONSAdded in Shorewall 4.5.10. Available options are:builtinAdded in Shorewall 4.5.16. Defines the action as a rule
target that is supported by your iptables but is not directly
supported by Shorewall. The action may be used as the rule
target in an INLINE rule in shorewall-rules(5).inlineCauses the action body (defined in
action.action-name) to be expanded
in-line like a macro rather than in its own chain. You can
list Shorewall Standard Actions in this file to specify the
option.Some of the Shorewall standard actions cannot be used
in-line and will generate a warning and the compiler will
ignore if you try to use them that
way:BroadcastDropSmurfsInvalid (Prior to Shorewall 4.5.13)NotSyn (Prior to Shorewall 4.5.13)RST (Prior to Shorewall 4.5.13)TCPFlagsnoinlineCauses any later option for the
same action to be ignored with a warning.nologAdded in Shorewall 4.5.11. When this option is
specified, the compiler does not automatically apply the log
level and/or tag from the invocation of the action to all
rules inside of the action. Rather, it simply sets the
$_loglevel and $_logtag shell variables which can be used
within the action body to apply those logging options only to
a subset of the rules.FILES/etc/shorewall/actionsSee ALSOhttp://shorewall.net/Actions.htmlshorewall(8), shorewall-accounting(5), shorewall-blacklist(5),
shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-params.xml 0000644 0001750 0001750 00000010064 12222401136 023013 0 ustar teastep teastep
shorewall-params5paramsShorewall parameters file/etc/shorewall/paramsDescriptionAssign any shell variables that you need in this file. The file is
always processed by /bin/sh or by the shell specified
through SHOREWALL_SHELL in shorewall.conf (5) so the full range of
shell capabilities may be used.It is suggested that variable names begin with an upper case letter
to distinguish them from variables used internally within the Shorewall
programsThe following variable names must be avoided. Those in bold font must be avoided in all Shorewall
versions; those in regular font must be avoided in versions prior to
4.4.8.Any option from shorewall.conf (5)COMMANDCONFDIRDEBUGECHO_EECHO_NEXPORTFASTFILEMODEHOSTNAMEIPT_OPTIONSNOROUTESPREVIEWPRODUCTPROFILEPURGERECOVERINGRESTOREPATHRING_BELLSHAREDIRAny name beginning with SHOREWALL_ or
SW_STOPPINGTESTTIMESTAMPUSE_VERBOSITYVARDIRVERBOSEVERBOSE_OFFSETVERSIONExample params file:NET_IF=eth0
NET_BCAST=130.252.100.255
NET_OPTIONS=routefilter,norfc1918Example shorewall-interfaces(5)
file.ZONE INTERFACE BROADCAST OPTIONS
net $NET_IF $NET_BCAST $NET_OPTIONSThis is the same as if the interfaces file had contained:ZONE INTERFACE BROADCAST OPTIONS
net eth0 130.252.100.255 routefilter,norfc1918FILES/etc/shorewall/paramsSee ALSOhttp://www.shorewall.net/configuration_file_basics.htm#Variablesshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-ipsets.xml 0000644 0001750 0001750 00000011173 12222401136 023041 0 ustar teastep teastep
shorewall-ipsets5ipsetsSpecifying the name if an ipset in Shorewall configuration
files+ipsetname+ipsetname[flag,...]+[ipsetname,...]DescriptionNote: In the above syntax descriptions, the square brackets ("[]")
are to be taken literally rather than as meta-characters.In most places where a network address may be entered, an ipset may
be substituted. Set names must be prefixed by the character "+", must
start with a letter and may be composed of alphanumeric characters, "-"
and "_".Whether the set is matched against the packet source or destination
is determined by which column the set name appears (SOURCE or DEST). For
those set types that specify a tuple, two alternative syntaxes are
available:[number] - Indicates that 'src' or
'dst' should be repeated number times.
Example: myset[2].[flag,...] where
flag is or
. Example: myset[src,dst].In a SOURCE column, the following pairs are equivalent:+myset[2] and +myset[src,src]In a DEST column, the following pairs are equivalent:+myset[2] and +myset[dst,dst]Beginning with Shorewall 4.4.14, multiple source or destination
matches may be specified by enclosing the set names within +[...]. The set
names need not be prefixed with '+'. When such a list of sets is
specified, matching packets must match all of the listed sets.For information about set lists and exclusion, see shorewall-exclusion (5).Beginning with Shorewall 4.5.16, you can increment one or more
nfacct objects each time a packet matches an ipset. You do that by listing
the objects separated by commas within parentheses.Example:+myset[src](myobject)In that example, when the source address of a packet matches the
myset ipset, the myobject nfacct counter will be incremented.Examples+myset+myset[src]+myset[2]+[myset1,myset2[dst]]FILES/etc/shorewall/accounting/etc/shorewall/blacklist/etc/shorewall/hosts -- Note:
Multiple matches enclosed in +[...] may not be used in this file./etc/shorewall/maclist -- Note:
Multiple matches enclosed in +[...] may not be used in this file./etc/shorewall/masq/etc/shorewall/rules/etc/shorewall/secmarks/etc/shorewall/tcrulesSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-modules.xml 0000644 0001750 0001750 00000006266 12222401136 023211 0 ustar teastep teastep
shorewall-modules5modulesShorewall file/usr/share/shorewall/modules/usr/share/shorewall/helpersDescriptionThese files specify which kernel modules Shorewall will load before
trying to determine your iptables/kernel's capabilities.The modules file is used when
LOAD_HELPERS_ONLY=No in shorewall.conf(8); the
helpers file is used when
LOAD_HELPERS_ONLY=YesEach record in the files has the following format:loadmodulemodulenamemoduleoptionThe modulename names a kernel module
(without suffix). Shorewall will search for modules based on your
MODULESDIR and MODULE_SUFFIX settings in shorewall.conf(8). The
moduleoptions are passed to modprobe (if
installed) or to insmod.The /usr/share/shorewall/modules file contains a large number of
modules. Users are encouraged to copy the file to /etc/shorewall/modules
and modify the copy to load only the modules required or to use
LOAD_HELPERS_ONLY=Yes.If you build monolithic kernels and have not installed
module-init-tools, then create an empty /etc/shorewall/modules file;
that will prevent Shorewall from trying to load modules at all.Exampleloadmodule ip_conntrack_ftp ports=21,221FILES/usr/share/shorewall/modules/usr/share/shorewall/helpers/etc/shorewall/modules/etc/shorewall/helpersSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-conntrack.xml 0000644 0001750 0001750 00000046557 12222401136 023532 0 ustar teastep teastep
shorewall6-conntrack5conntrackshorewall conntrack file/etc/shorewall/conntrackDescriptionThe original intent of the notrack
file was to exempt certain traffic from Netfilter connection tracking.
Traffic matching entries in the file were not to be tracked.The role of the file was expanded in Shorewall 4.4.27 to include all
rules that can be added in the Netfilter raw table. In 4.5.7, the file's name was changed to
conntrack.The file supports two different column layouts: FORMAT 1, FORMAT 2,
and FORMAT 3, FORMAT 1 being the default. The three differ as
follows:in FORMAT 2 and 3, there is an additional leading ACTION
column.in FORMAT 3, the SOURCE column accepts no zone name; rather the
ACTION column allows a SUFFIX that determines the chain(s) that the
generated rule will be added to.When an entry in the following form is encountered, the format of
the following entries are assumed to be of the specified
format.[?]FORMATformatwhere format is either 1,2 or 3.Format 3 was introduced in Shorewall 4.5.10. The optional '?' was
introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form
without the '?' is deprecated.Comments may be attached to Netfilter rules generated from entries
in this file through the use of COMMENT lines. These lines begin with the
word COMMENT; the remainder of the line is treated as a comment which is
attached to subsequent rules until another COMMENT line is found or until
the end of the file is reached. To stop adding comments to rules, use a
line with only the word COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT
and is preferred.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION - {NOTRACK|CT:helper:name[(arg=val[,...])|CT:notrack|DROP}[:chain-designator]This column is only present when FORMAT >= 2. Values other
than NOTRACK or DROP require CT Target
support in your iptables and kernel. or
Disables connection tracking for this packet.Added in Shorewall 4.5.10. Silently discard the
packet.:nameAttach the helper identified by the
name to this connection. This is more
flexible than loading the conntrack helper with preset
ports.At this writing, the available helpers are:amandaRequires that the amanda netfilter helper is
present.ftpRequires that the FTP netfilter helper is
present.ircRequires that the IRC netfilter helper is
present.netbios-nsRequires that the netbios_ns (sic) helper is
present.RAS and Q.931These require that the H323 netfilter helper is
present.pptpRequires that the pptp netfilter helper is
present.saneRequires that the SANE netfilter helper is
present.sipRequires that the SIP netfilter helper is
present.snmpRequires that the SNMP netfilter helper is
present.tftpRequires that the TFTP netfilter helper is
present.May be followed by an option list of
arg=val
pairs in parentheses:=event[,...]Only generate the specified conntrack events for this
connection. Possible event types are: new, related, destroy, reply, assured, protoinfo, helper, mark (this is connection mark, not
packet mark), natseqinfo,
and secmark. If more than
one event is listed, the
event list must be enclosed in
parentheses (e.g., ctevents=(new,related)).Only generate a new
expectation events for this connection.When FORMAT = 1, this column is not present and the rule is
processed as if NOTRACK had been entered in this column.Beginning with Shorewall 4.5.10, when FORMAT = 3, this column
can end with a colon followed by a
chain-designator. The
chain-designator can be one of the
following:PThe rule is added to the raw table PREROUTING chain.
This is the default if no
chain-designator is present.OThe rule is added to the raw table OUTPUT chain.PO or OPThe rule is added to the raw table PREROUTING and OUTPUT
chains.SOURCE (formats 1 and 2) ‒
{zone[:interface][:address-list]|COMMENT}where zone is the name of a zone,
interface is an interface to that zone,
and address-list is a comma-separated
list of addresses (may contain exclusion - see shorewall-exclusion
(5)).Beginning with Shorewall 4.5.7, can be
used as the zone name to mean
all zones.Beginning with Shorewall 4.5.10, can be
used as the zone name to mean all
off-firewall zones.SOURCE (format 3) ‒
{-|interface[:address-list]|address-list}Where interface is an interface to
that zone, and address-list is a
comma-separated list of addresses (may contain exclusion - see
shorewall-exclusion
(5)).COMMENT is only allowed in format 1; the remainder of the line
is treated as a comment that will be associated with the generated
rule(s).DEST ‒
{-|interface[:address-list]|address-list}where address-list is a
comma-separated list of addresses (may contain exclusion - see
shorewall6-exclusion
(5)).PROTO ‒
protocol-name-or-number[,...]A protocol name from /etc/protocols or a
protocol number.Beginning with Shorewall 4.5.12, this column is labeled
PROTOS and can accept a
comma-separated list of protocols. Either proto or protos is accepted in the alternate input
format.DEST PORT(S) (dport) - port-number/service-name-listA comma-separated list of port numbers and/or service names
from /etc/services. May also include port
ranges of the form
low-port:high-port
if your kernel and iptables include port range support.SOURCE PORT(S) (sport) - port-number/service-name-listA comma-separated list of port numbers and/or service names
from /etc/services. May also include port
ranges of the form
low-port:high-port
if your kernel and iptables include port range support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.USER/GROUP (user) ‒
[user][:group]May only be specified if the SOURCE
zone is $FW. Specifies the effective user
id and or group id of the process sending the traffic.SWITCH -
[!]switch-name[={0|1}]Added in Shorewall 4.5.10 and allows enabling and disabling
the rule without requiring shorewall
restart.The rule is enabled if the value stored in
/proc/net/nf_condition/switch-name
is 1. The rule is disabled if that file contains 0 (the default). If
'!' is supplied, the test is inverted such that the rule is enabled
if the file contains 0.Within the switch-name, '@0' and
'@{0}' are replaced by the name of the chain to which the rule is a
added. The switch-name (after '...'
expansion) must begin with a letter and be composed of letters,
decimal digits, underscores or hyphens. Switch names must be 30
characters or less in length.Switches are normally off. To
turn a switch on:echo 1 >
/proc/net/nf_condition/switch-nameTo turn it off again:echo 0 >
/proc/net/nf_condition/switch-nameSwitch settings are retained over shorewall
restart.When the switch-name is followed by
or , then the switch is
initialized to off or on respectively by the
start command. Other commands do not affect the
switch setting.EXAMPLEExample 1:#ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP
# PORT(S) PORT(S)
CT:helper:ftp(expevents=new) fw - tcp 21 Example 2 (Shorewall 4.5.10 or later):Drop traffic to/from all zones to IP address 1.2.3.4FORMAT 2
#ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP
# PORT(S) PORT(S)
DROP all-:1.2.3.4 -
DROP all 1.2.3.4orFORMAT 3
#ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP
# PORT(S) PORT(S)
DROP:P 1.2.3.4 -
DROP:PO - 1.2.3.4
FILES/etc/shorewall/notrackSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall.xml 0000644 0001750 0001750 00000213232 12222401136 021534 0 ustar teastep teastep
shorewall8shorewallAdministration tool for Shoreline Firewall
(Shorewall)shorewall|-optionsinterface[:host-list]zone zone host-listshorewall|-optionsaddressshorewall|-optionsdirectoryshorewall|-optionsshorewall|-optionsdirectorypathnameshorewall|-optionsinterface[:host-list]zone zone host-listshorewall|-options{ interface |
provider }shorewall|-optionsaddressshorewall|-optionsshorewall|-options{ interface |
provider }shorewall|-optionsdirectory1[user@]system[directory2]shorewall|-optionsfilenameshorewall|-optionsshorewall|-optionsshorewall|-optionsaddressmaskaddress/vlsmshorewall|-optionsaddress1address2shorewall|-optionsiptables match
expressionshorewall|-optionsroot-user-namedirectorysystemshorewall|-optionsaddressshorewall|-optionsrefresh-intervalshorewall|-optionsaddressshorewall|-optionsiptables match
expressionshorewall|-options-
directorychainshorewall|-optionsaddressshorewall|-optionsroot-user-namedirectorysystemshorewall|-optionsshorewall|-optionsdirectoryshorewall|-optionsfilenameshorewall|-optionstimeoutdirectoryshorewall|-optionstimeoutdirectoryshorewall|-optionsfilenameshorewall|-options
{|||}chainshorewall|-optionsshorewall|-optionsshorewall|-optionseventshorewall|-optionsmacroshorewall|-optionsshorewall|-optionsshorewall|-optionsshorewall|-optionsdirectoryshorewall|-optionsshorewall|-optionsshorewall|-optionsdirectorytimeoutshorewall|-optionsdirectoryshorewall|-optionsDescriptionThe shorewall utility is used to control the Shoreline Firewall
(Shorewall).OptionsThe and options are
used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace.The nolock prevents the command from
attempting to acquire the Shorewall lockfile. It is useful if you need to
include shorewall commands in
/etc/shorewall/started.The options control the amount of output that
the command produces. They consist of a sequence of the letters v and q. If the
options are omitted, the amount of output is determined by the setting of
the VERBOSITY parameter in shorewall.conf(5). Each v adds one to the effective verbosity and each
q subtracts one from the effective
VERBOSITY. Alternatively, v may be
followed immediately with one of -1,0,1,2 to specify a specify VERBOSITY.
There may be no white-space between v and
the VERBOSITY.The options may also include the letter
which causes all progress messages to be
timestamped.CommandsThe available commands are listed below.addAdds a list of hosts or subnets to a dynamic zone usually used
with VPN's.The interface argument names an interface
defined in the shorewall-interfaces(5)
file. A host-list is comma-separated list whose
elements are host or network addresses.The add command is not very robust. If
there are errors in the host-list,
you may see a large number of error messages yet a subsequent
shorewall show zones command will indicate
that all hosts were added. If this happens, replace
add by delete and run the
same command again. Then enter the correct command.Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall-zones(5)) allows a
single ipset to handle entries for multiple interfaces. When that
option is specified for a zone, the add command
has the alternative syntax in which the
zone name precedes the
host-list.allowRe-enables receipt of packets from hosts previously
blacklisted by a drop, logdrop, reject, or logreject command.checkCompiles the configuration in the specified
directory and discards the compiled output
script. If no directory is given, then
/etc/shorewall is assumed.The -e option causes the
compiler to look for a file named capabilities. This file is
produced using the command shorewall-lite show
-f capabilities > capabilities on a system with
Shorewall Lite installed.The option causes the compiler to be run
under control of the Perl debugger.The option causes the compiler to be
profiled via the Perl command-line
option.The option was added in Shorewall 4.5.2
and causes the compiler to print the generated ruleset to standard
out.The option was added in Shorewall 4.4.20
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.clearClear will remove all rules and chains installed by Shorewall.
The firewall is then wide open and unprotected. Existing connections
are untouched. Clear is often used to see if the firewall is causing
connection problems.If is given, the command will be processed
by the compiled script that executed the last successful start, restart or refresh command if that script exists.compileCompiles the current configuration into the executable file
pathname. If a
directory is supplied, Shorewall will
look in that directory first for configuration files. If the
pathname is omitted, the file
firewall in the VARDIR (normally /var/lib/shorewall/) is assumed. A
pathname of '-' causes the compiler to send the
generated script to it's standard output file. Note that '-v-1' is
usually specified in this case (e.g., shorewall -v-1
compile -- -) to suppress the 'Compiling...' message
normally generated by /sbin/shorewall.When -e is specified, the compilation is being performed on a
system other than where the compiled script will run. This option
disables certain configuration options that require the script to be
compiled where it is to be run. The use of -e requires the presence
of a configuration file named capabilities
which may be produced using the command shorewall-lite show -f capabilities >
capabilities on a system with Shorewall Lite
installedThe -c option was added in
Shorewall 4.5.17 and causes conditional compilation of a script. The
script specified by pathname (or implied
if pathname is omitted) is compiled
if it doesn't exist or if there is any file in the
directory or in a directory on the
CONFIG_PATH that has a modification time later than the file to be
compiled. When no compilation is needed, a message is issued and an
exit status of zero is returned.The option causes the compiler to be run
under control of the Perl debugger.The option causes the compiler to be
profiled via the Perl command-line
option.The option was added in Shorewall 4.4.20
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.deleteThe delete command reverses the effect of an earlier add command.The interface argument names an interface
defined in the shorewall-interfaces(5)
file. A host-list is comma-separated list whose
elements are a host or network address.Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall-zones(5)) allows a
single ipset to handle entries for multiple interfaces. When that
option is specified for a zone, the delete
command has the alternative syntax in which the
zone name precedes the
host-list.disableAdded in Shorewall 4.4.26. Disables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.Beginning with Shorewall 4.5.10, this command may be used with
any optional network interface. interface
may be either the logical or physical name of the interface. The
command removes any routes added from shorewall-routes(5) and any
traffic shaping configuration for the interface.dropCauses traffic from the listed addresses
to be silently dropped.dumpProduces a verbose report about the firewall configuration for
the purpose of problem analysis.The -x option causes actual
packet and byte counts to be displayed. Without that option, these
counts are abbreviated. The -m
option causes any MAC addresses included in Shorewall log messages
to be displayed.The -l option causes the rule
number for each Netfilter rule to be displayed.enableAdded in Shorewall 4.4.26. Enables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.Beginning with Shorewall 4.5.10, this command may be used with
any optional network interface. interface
may be either the logical or physical name of the interface. The
command sets /proc entries for the interface,
adds any route specified in shorewall-routes(5) and installs
the interface's traffic shaping configuration, if any.exportIf directory1 is omitted, the current
working directory is assumed.Allows a non-root user to compile a shorewall script and stage
it on a system (provided that the user has access to the system via
ssh). The command is equivalent to:/sbin/shorewall compile -edirectory1directory1/firewall &&\scp directory1/firewalldirectory1/firewall.conf [user@]system:[directory2]In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called firewall in that
directory. If compilation succeeds, then firewall and firewall.conf
are copied to system using scp.forgetDeletes /var/lib/shorewall/filename and
/var/lib/shorewall/save. If no filename is
given then the file specified by RESTOREFILE in shorewall.conf(5) is
assumed.helpDisplays a syntax summary.hitsGenerates several reports from Shorewall log messages in the
current log file. If the option is included, the
reports are restricted to log messages generated today.ipcalcIpcalc displays the network address, broadcast address,
network in CIDR notation and netmask corresponding to the
input[s].iprangeIprange decomposes the specified range of IP addresses into
the equivalent list of network/host addresses.iptraceThis is a low-level debugging command that causes iptables
TRACE log records to be created. See iptables(8) for details.The iptables match expression must
be one or more matches that may appear in both the raw table OUTPUT
and raw table PREROUTING chains.The trace records are written to the kernel's log buffer with
facility = kernel and priority = warning, and they are routed from
there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) --
Shorewall has no control over where the messages go; consult your
logging daemon's documentation.loadIf directory is omitted, the current
working directory is assumed. Allows a non-root user to compile a
shorewall script and install it on a system (provided that the user
has root access to the system via ssh). The command is equivalent
to:/sbin/shorewall compile -edirectorydirectory/firewall &&\scpdirectory/firewalldirectory/firewall.confroot@system:/var/lib/shorewall-lite/ &&\ssh root@system'/sbin/shorewall-lite start'In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called firewall in that
directory. If compilation succeeds, then firewall is copied to
system using scp. If the copy succeeds,
Shorewall Lite on system is started via
ssh.If -s is specified and the
start command succeeds, then the
remote Shorewall-lite configuration is saved by executing shorewall-lite save via ssh.if -c is included, the
command shorewall-lite show capabilities -f
> /var/lib/shorewall-lite/capabilities is executed via
ssh then the generated file is copied to
directory using scp. This step is
performed before the configuration is compiled.If is included, it specifies that the root
user on system is named
root-user-name rather than "root".The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.logdropCauses traffic from the listed addresses
to be logged then discarded. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5).logwatchMonitors the log file specified by the LOGFILE option in
shorewall.conf(5) and
produces an audible alarm when new Shorewall messages are logged.
The -m option causes the MAC
address of each packet source to be displayed if that information is
available. The refresh-interval specifies
the time in seconds between screen refreshes. You can enter a
negative number by preceding the number with "--" (e.g.,
shorewall logwatch -- -30). In this case, when a
packet count changes, you will be prompted to hit any key to resume
screen refreshes.logrejectCauses traffic from the listed addresses
to be logged then rejected. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall.conf (5).noiptraceThis is a low-level debugging command that cancels a trace
started by a preceding iptrace command.The iptables match expression must
be one given in the iptrace command being
canceled.refreshAll steps performed by restart are
performed by refresh with the exception that
refresh only recreates the chains specified in
the command while restart recreates the entire
Netfilter ruleset. If no chain is given,
the static blacklisting chain blacklst is assumed.The listed chains are assumed to be in the filter table. You
can refresh chains in other tables by prefixing the chain name with
the table name followed by ":" (e.g., nat:net_dnat). Chain names
which follow are assumed to be in that table until the end of the
list or until an entry in the list names another table. Built-in
chains such as FORWARD may not be refreshed.The option was added in Shorewall 4.5.3
causes Shorewall to avoid updating the routing table(s).The option was added in Shorewall 4.5.3
causes the compiler to run under the Perl debugger.The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.The - option was added in Shorewall 4.5.3
and causes Shorewall to look in the given
directory first for configuration files.Example:shorewall refresh net2fw nat:net_dnat #Refresh the 'net2loc' chain in the filter table and the 'net_dnat' chain in the nat tableThe refresh command has
slightly different behavior. When no chain name is given to the
refresh command, the mangle table
is refreshed along with the blacklist chain (if any). This allows
you to modify /etc/shorewall/tcrules and
install the changes using refresh.reloadIf directory is omitted, the current
working directory is assumed. Allows a non-root user to compile a
shorewall script and install it on a system (provided that the user
has root access to the system via ssh). The command is equivalent
to:/sbin/shorewall compile -edirectorydirectory/firewall &&\scpdirectory/firewalldirectory/firewall.confroot@system:/var/lib/shorewall-lite/ &&\ssh root@system'/sbin/shorewall-lite restart'In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called firewall in that
directory. If compilation succeeds, then firewall is copied to
system using scp. If the copy succeeds,
Shorewall Lite on system is restarted via
ssh.If -s is specified and the
restart command succeeds, then the
remote Shorewall-lite configuration is saved by executing shorewall-lite save via ssh.if -c is included, the
command shorewall-lite show capabilities -f
> /var/lib/shorewall-lite/capabilities is executed via
ssh then the generated file is copied to
directory using scp. This step is performed
before the configuration is compiled.If is included, it specifies that the root
user on system is named
root-user-name rather than "root".The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.resetAll the packet and byte counters in the firewall are
reset.restartRestart is similar to shorewall
start except that it assumes that the firewall is already
started. Existing connections are maintained. If a
directory is included in the command, Shorewall
will look in that directory first for
configuration files.The option causes Shorewall to avoid
updating the routing table(s).The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.The option causes the compiler to run
under the Perl debugger.The option suppresses the compilation step
and simply reused the compiled script which last started/restarted
Shorewall, provided that /etc/shorewall and its contents have not
been modified since the last start/restart.The option was added in Shorewall 4.4.20
and performs the compilation step unconditionally, overriding the
AUTOMAKE setting in shorewall.conf(5). When both
and are present, the result
is determined by the option that appears last.The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.restoreRestore Shorewall to a state saved using the shorewall save command. Existing connections
are maintained. The filename names a restore
file in /var/lib/shorewall created using shorewall save; if no
filename is given then Shorewall will be
restored from the file specified by the RESTOREFILE option in shorewall.conf(5).safe-restartOnly allowed if Shorewall is running. The current
configuration is saved in /var/lib/shorewall/safe-restart (see the
save command below) then a shorewall
restart is done. You will then be prompted asking if you
want to accept the new configuration or not. If you answer "n" or if
you fail to answer within 60 seconds (such as when your new
configuration has disabled communication with your terminal), the
configuration is restored from the saved configuration. If a
directory is given, then Shorewall will look in that directory first
when opening configuration files.Beginning with Shorewall 4.5.0, you may specify a different
timeout value using the
option. The numeric
timeout may optionally be followed by an
, or suffix
(e.g., 5m) to specify seconds, minutes or hours respectively. If the
suffix is omitted, seconds is assumed.safe-startShorewall is started normally. You will then be prompted
asking if everything went all right. If you answer "n" or if you
fail to answer within 60 seconds (such as when your new
configuration has disabled communication with your terminal), a
shorewall clear is performed for you. If a directory is given, then
Shorewall will look in that directory first when opening
configuration files.Beginning with Shorewall 4.5.0, you may specify a different
timeout value using the
option. The numeric
timeout may optionally be followed by an
, or suffix
(e.g., 5m) to specify seconds, minutes or hours respectively. If the
suffix is omitted, seconds is assumed.saveThe dynamic blacklist is stored in /var/lib/shorewall/save.
The state of the firewall is stored in
/var/lib/shorewall/filename for use by the
shorewall restore and shorewall -f start commands. If
filename is not given then the state is saved
in the file specified by the RESTOREFILE option in shorewall.conf(5).showThe show command can have a number of different
arguments:actionsProduces a report about the available actions (built-in,
standard and user-defined).capabilitiesDisplays your kernel/iptables capabilities. The
-f option causes the display
to be formatted as a capabilities file for use with compile -e.[ [ ] chain...
]The rules in each chain are
displayed using the iptables
-Lchain-n -v command. If no
chain is given, all of the chains in the
filter table are displayed. The -x option is passed directly through to
iptables and causes actual packet and byte counts to be
displayed. Without this option, those counts are abbreviated.
The -t option specifies the
Netfilter table to display. The default is filter.The -b ('brief') option
causes rules which have not been used (i.e. which have zero
packet and byte counts) to be omitted from the output. Chains
with no rules displayed are also omitted from the
output.The -l option causes
the rule number for each Netfilter rule to be
displayed.If the -t option and
the keyword are both omitted and any of
the listed chains do not exist, a
usage message is displayed.classifiers|filtersDisplays information about the packet classifiers
defined on the system as a result of traffic shaping
configuration.configDisplays distribution-specific defaults.connectionsDisplays the IP connections currently being tracked by
the firewall.event
eventAdded in Shorewall 4.5.19. Displays the named
event.eventsAdded in Shorewall 4.5.19. Displays all events.ipDisplays the system's IPv4 configuration.ipaAdded in Shorewall 4.4.17. Displays the per-IP
accounting counters (shorewall-accounting
(5)).logDisplays the last 20 Shorewall messages from the log
file specified by the LOGFILE option in shorewall.conf(5). The
-m option causes the MAC
address of each packet source to be displayed if that
information is available.macrosDisplays information about each macro defined on the
firewall system.macroAdded in Shorewall 4.4.6. Displays the file that
implements the specified macro
(usually
/usr/share/shorewall/macro.macro).marksAdded in Shorewall 4.4.26. Displays the various fields
in packet marks giving the min and max value (in both decimal
and hex) and the applicable mask (in hex).natDisplays the Netfilter nat table using the command
iptables -t nat -L -n -v.The
-x option is passed directly
through to iptables and causes actual packet and byte counts
to be displayed. Without this option, those counts are
abbreviated.policiesAdded in Shorewall 4.4.4. Displays the applicable policy
between each pair of zones. Note that implicit intrazone
ACCEPT policies are not displayed for zones associated with a
single network where that network doesn't specify
.routingDisplays the system's IPv4 routing configuration.rawDisplays the Netfilter raw table using the command
iptables -t raw -L -n -v.The
-x option is passed directly
through to iptables and causes actual packet and byte counts
to be displayed. Without this option, those counts are
abbreviated.tcDisplays information about queuing disciplines, classes
and filters.zonesDisplays the current composition of the Shorewall zones
on the system.startStart shorewall. Existing connections through shorewall
managed interfaces are untouched. New connections will be allowed
only if they are allowed by the firewall rules or policies. If a
directory is included in the command,
Shorewall will look in that directory first for
configuration files. If -f is
specified, the saved configuration specified by the RESTOREFILE
option in shorewall.conf(5)
will be restored if that saved configuration exists and has been
modified more recently than the files in /etc/shorewall. When
-f is given, a
directory may not be specified.Update: In Shorewall 4.4.20, a new LEGACY_FASTSTART option was
added to shorewall.conf(5).
When LEGACY_FASTSTART=No, the modification times of files in
/etc/shorewall are compared with that of /var/lib/shorewall/firewall
(the compiled script that last started/restarted the
firewall).The option causes Shorewall to avoid
updating the routing table(s).The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.The option was added in Shorewall 4.4.20
and performs the compilation step unconditionally, overriding the
AUTOMAKE setting in shorewall.conf(5). When both
and are present, the result
is determined by the option that appears last.The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.stopStops the firewall. All existing connections, except those
listed in shorewall-routestopped(5)
or permitted by the ADMINISABSENTMINDED option in shorewall.conf(5), are taken down.
The only new traffic permitted through the firewall is from systems
listed in shorewall-routestopped(5)
or by ADMINISABSENTMINDED.If is given, the command will be processed
by the compiled script that executed the last successful start, restart or refresh command if that script exists.statusProduces a short report about the state of the
Shorewall-configured firewall.tryIf Shorewall is started then the firewall state is saved to a
temporary saved configuration
(/var/lib/shorewall/.try). Next, if Shorewall
is currently started then a restart
command is issued using the specified configuration
directory; otherwise, a start command is performed using the
specified configuration directory. if an
error occurs during the compilation phase of the restart or start, the command terminates without
changing the Shorewall state. If an error occurs during the
restart phase, then a shorewall restore is performed using the
saved configuration. If an error occurs during the start phase, then Shorewall is cleared. If
the start/restart succeeds and a
timeout is specified then a clear or restore is performed after
timeout seconds.Beginning with Shorewall 4.5.0, the numeric
timeout may optionally be followed by an
, or suffix
(e.g., 5m) to specify seconds, minutes or hours respectively. If the
suffix is omitted, seconds is assumed.updateAdded in Shorewall 4.4.21 and causes the compiler to update
/etc/shorewall/shorewall.conf then validate the
configuration. The update will add options not present in
the old file with their default values, and will move deprecated
options with non-defaults to a deprecated options section at the
bottom of the file. Your existing
shorewall.conf file is renamed
shorewall.conf.bak.The option causes the updated
shorewall.conf file to be annotated with
documentation.The option was added in Shorewall 4.4.26
and causes legacy blacklisting rules (shorewall-blacklist (5) ) to
be converted to entries in the blrules file (shorewall-blrules (5) ). The
blacklist keyword is removed from shorewall-zones (5), shorewall-interfaces (5) and
shorewall-hosts (5). The
unmodified files are saved with a .bak suffix.The option was added in Shorewall 4.5.11.
When this option is specified, the compiler will walk through the
directories in the CONFIG_PATH replacing FORMAT and COMMENT entries
to compiler directives (e.g., ?FORMAT and ?COMMENT. When a file is
updated, the original is saved in a .bak file in the same
directory.For a description of the other options, see the check command above.versionDisplays Shorewall's version. The option
is included for compatibility with earlier Shorewall releases and is
ignored.EXIT STATUSIn general, when a command succeeds, status 0 is returned; when the
command fails, a non-zero status is returned.The status command returns exit status as
follows:0 - Firewall is started.3 - Firewall is stopped or cleared4 - Unknown state; usually means that the firewall has never been
started.FILES/etc/shorewall/See ALSOhttp://www.shorewall.net/starting_and_stopping_shorewall.htmshorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-rules.xml 0000644 0001750 0001750 00000231537 12222401136 022674 0 ustar teastep teastep
shorewall-rules5rulesShorewall rules file/etc/shorewall/rulesDescriptionEntries in this file govern connection establishment by defining
exceptions to the policies laid out in shorewall-policy(5). By default,
subsequent requests and responses are automatically allowed using
connection tracking. For any particular (source,dest) pair of zones, the
rules are evaluated in the order in which they appear in this file and the
first terminating match is the one that determines the disposition of the
request. All rules are terminating except LOG and COUNT rules.If you masquerade or use SNAT from a local system to the internet,
you cannot use an ACCEPT rule to allow traffic from the internet to that
system. You must use a DNAT rule
instead.The rules file is divided into sections. Each section is introduced
by a "Section Header" which is a line beginning with SECTION and followed
by the section name.Sections are as follows and must appear in the order listed:ALLThis section was added in Shorewall 4.4.23. Rules in this
section are applied, regardless of the connection tracking state of
the packet.ESTABLISHEDPackets in the ESTABLISHED state are processed by rules in
this section.The only ACTIONs allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUEThere is an implicit ACCEPT rule inserted at the end of this
section.RELATEDPackets in the RELATED state are processed by rules in this
section.The only ACTIONs allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUEThere is an implicit rule added at the end of this section
that invokes the RELATED_DISPOSITION (shorewall.conf(5)).INVALIDAdded in Shorewall 4.5.13. Packets in the INVALID state are
processed by rules in this section.The only Actions allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUE.There is an implicit rule added at the end of this section
that invokes the INVALID_DISPOSITION (shorewall.conf(5)).UNTRACKEDAdded in Shorewall 4.5.13. Packets in the UNTRACKED state are
processed by rules in this section.The only Actions allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUE.There is an implicit rule added at the end of this section
that invokes the UNTRACKED_DISPOSITION (shorewall.conf(5)).NEWPackets in the NEW, INVALID and UNTRACKED states are processed
by rules in this section.If you are not familiar with Netfilter to the point where you are
comfortable with the differences between the various connection tracking
states, then it is suggested that you omit the ESTABLISHED and RELATED sections and place all of your
non-blacklisting rules in the NEW section (That's after the line that
reads SECTION NEW').If you specify FASTACCEPT=Yes in shorewall.conf(5) then the ALL, ESTABLISHED and RELATED sections must be empty.An except is made if you are running Shorewall 4.4.27 or later and
you have specified a non-default value for RELATED_DISPOSITION or
RELATED_LOG_LEVEL. In that case, you may have rules in the RELATED
section of this file.You may omit any section that you don't need. If no Section Headers
appear in the file then all rules are assumed to be in the NEW
section.When defining rules that rewrite the destination IP address and/or
port number (namely DNAT and REDIRECT rules), it is important to keep
straight which columns in the file specify the packet before rewriting and
which specify how the packet will look after rewriting.The DEST column specifies the final destination for the packet
after rewriting and can include the final IP address and/or port
number.The remaining columns specify characteristics of the packet
before rewriting. In particular, the ORIGINAL DEST column gives the
original destination IP address of the packet and the DEST PORT(S)
column give the original destination port(s).The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION - target[:{log-level|none}[!][:tag]]Specifies the action to be taken if the connection request
matches the rule. target must be one of
the following.ACCEPTAllow the connection request.ACCEPT+like ACCEPT but also excludes the connection from any
subsequent matching DNAT[-] or REDIRECT[-] rules.ACCEPT!like ACCEPT but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall.conf(5).actionThe name of an action declared in
shorewall-actions(5) or
in /usr/share/shorewall/actions.std.ADD(ipset:flags)Added in Shorewall 4.4.12. Causes addresses and/or port
numbers to be added to the named
ipset. The
flags specify the address or tuple
to be added to the set and must match the type of ipset
involved. For example, for an iphash ipset, either the SOURCE
or DESTINATION address can be added using
flagssrc or dst respectively (see the -A command in
ipset (8)).ADD is non-terminating. Even if a packet matches the
rule, it is passed on to the next rule.AUDIT[(accept|drop|reject)]Added in Shorewall 4.5.10. Audits the packet with the
specified type; if the type is omitted, then
is assumed. Require AUDIT_TARGET support
in the kernel and iptables.A_ACCEPT, A_ACCEPT+ and A_ACCEPT!Added in Shorewall 4.4.20. Audited versions of ACCEPT,
ACCEPT+ and ACCEPT! respectively. Require AUDIT_TARGET support
in the kernel and iptables.A_DROP and A_DROP!Added in Shorewall 4.4.20. Audited versions of DROP and
DROP! respectively. Require AUDIT_TARGET support in the kernel
and iptables.A_REJECT AND A_REJECT!Added in Shorewall 4.4.20. Audited versions of REJECT
and REJECT! respectively. Require AUDIT_TARGET support in the
kernel and iptables.[?]COMMENTthe rest of the line will be attached as a comment to
the Netfilter rule(s) generated by the following entries. The
comment will appear delimited by "/* ... */" in the output of
"shorewall show <chain>". To stop the comment from being
attached to further rules, simply include COMMENT on a line by
itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CONTINUEFor experts only.Do not process any of the following rules for this
(source zone,destination zone). If the source and/or
destination IP address falls into a zone defined later in
shorewall-zones(5)
or in a parent zone of the source or destination zones, then
this connection request will be passed to the rules defined
for that (those) zone(s). See shorewall-nesting(5) for
additional information.CONTINUE!like CONTINUE but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall.conf(5).COUNTSimply increment the rule's packet and byte count and
pass the packet to the next rule.DEL(ipset:flags)Added in Shorewall 4.4.12. Causes an entry to be deleted
from the named ipset. The
flags specify the address or tuple
to be deleted from the set and must match the type of ipset
involved. For example, for an iphash ipset, either the SOURCE
or DESTINATION address can be deleted using
flagssrc or dst respectively (see the -D command in
ipset (8)).DEL is non-terminating. Even if a packet matches the
rule, it is passed on to the next rule.DNATForward the request to another system (and optionally
another port).DNAT-Advanced users only.Like DNAT but only
generates the DNAT iptables
rule and not the companion ACCEPT rule.DROPIgnore the request.DROP!like DROP but exempts the rule from being suppressed by
OPTIMIZE=1 in shorewall.conf(5).HELPERAdded in Shorewall 4.5.7. This action requires that the
HELPER column contains the name of the Netfilter helper to be
associated with connections matching this connection. May only
be specified in the NEW section and is useful for being able
to specify a helper when the applicable policy is ACCEPT. No
destination zone should be specified in HELPER rules.INLINE[(action)]Added in Shorewall 4.5.16. This action allows you to
construct most of the rule yourself using iptables syntax. The
part that you specify must follow a semicolon (';') and is
completely free-form. If the target of the rule (the part
following 'j') is something that Shorewall supports in the
ACTION column, then you may enclose it in parentheses (e.g.,
INLINE(ACCEPT)). Otherwise, you can include it after the
semicolon. In this case, you must declare the target as a
builtin action in shorewall-actions(5).Some considerations when using INLINE:The , ,
, ,
, , and state
match ( or ) matches will always appear in the
front of the rule in that order.When multiple matches are specified, the compiler
will keep them in the order in which they appear
(excluding the above listed ones), but they will not
necessarily be at the end of the generated rule. For
example, if addresses are specified in the SOURCE and/or
DEST columns, their generated matches will appear after
those specified using ';'.LOG:levelSimply log the packet and continue with the next
rule.macro[(macrotarget)]The name of a macro defined in a file named
macro.macro. If the macro accepts an
action parameter (Look at the macro source to see if it has
PARAM in the TARGET column) then the
macro name is followed by the
parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted for the
parameter.Example: FTP(ACCEPT).The older syntax where the macro name and the target are
separated by a slash (e.g. FTP/ACCEPT) is still allowed but is
deprecated.NFLOG[(nflog-parameters)]Added in Shorewall 4.5.9.3. Queues matching packets to a
back end logging daemon via a netlink socket then continues to
the next rule. See http://www.shorewall.net/shorewall_logging.html.Similar to
LOG:NFLOG[(nflog-parameters)],
except that the log level is not changed when this ACTION is
used in an action or macro body and the invocation of that
action or macro specifies a log level.NFQUEUE[(queuenumber)]Queues the packet to a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not specified, queue
zero (0) is assumed.NFQUEUE![(queuenumber)]like NFQUEUE but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall.conf(5).NONATExcludes the connection from any subsequent DNAT[-] or REDIRECT[-] rules but doesn't generate
a rule to accept the traffic.QUEUEQueue the packet to a user-space application such as
ftwall (http://p2pwall.sf.net). The application may reinsert
the packet for further processing.QUEUE!like QUEUE but exempts the rule from being suppressed by
OPTIMIZE=1 in shorewall.conf(5).REJECTdisallow the request and return an icmp-unreachable or
an RST packet.REJECT!like REJECT but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall.conf(5).REDIRECTRedirect the request to a server running on the
firewall.REDIRECT-Advanced users only.Like REDIRECT but only
generates the REDIRECT
iptables rule and not the companion ACCEPT rule.ULOG[(ulog-parameters)]Added in Shorewall 4.5.10. Queues matching packets to a
back end logging daemon via a netlink socket then continues to
the next rule. See http://www.shorewall.net/shorewall_logging.html.Similar to
LOG:ULOG[(ulog-parameters)],
except that the log level is not changed when this ACTION is
used in an action or macro body and the invocation of that
action or macro specifies a log level.The target may optionally be
followed by ":" and a syslog log level (e.g, REJECT:info or
Web(ACCEPT):debug). This causes the packet to be logged at the
specified level. Note that if the ACTION involves destination network address
translation (DNAT, REDIRECT, etc.) then the packet is logged
before the destination address is
rewritten.If the ACTION names an
action declared in shorewall-actions(5) or in
/usr/share/shorewall/actions.std then:If the log level is followed by "!' then all rules in the
action are logged at the log level.If the log level is not followed by "!" then only those
rules in the action that do not specify logging are logged at
the specified level.The special log level none! suppresses logging by the
action.You may also specify ULOG or
NFLOG (must be in upper case) as a
log level.This will log to the ULOG or NFLOG target for routing to a
separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html).Actions specifying logging may be followed by a log tag (a
string of alphanumeric characters) which is appended to the string
generated by the LOGPREFIX (in shorewall.conf(5)).Example: ACCEPT:info:ftp would include 'ftp ' at the end of
the log prefix generated by the LOGPREFIX setting.SOURCE -
{zone|zone-list[+]|{all|any}[+][-]}[:interface][:{address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list}Source hosts to which the rule applies. May be a
zone declared in /etc/shorewall/zones,
$FW to indicate the firewall
itself, all, all+, all-,
all+- or none.Beginning with Shorewall 4.4.13, you may use a
zone-list which consists of a
comma-separated list of zones declared in shorewall-zones (5). This
zone-list may be optionally followed by
"+" to indicate that the rule is to apply to intra-zone traffic as
well as inter-zone traffic.When none is used either in
the SOURCE or DEST column, the rule is ignored.all means "All Zones",
including the firewall itself. all-
means "All Zones, except the firewall itself". When all[-] is
used either in the SOURCE or
DEST column intra-zone traffic is
not affected. When all+[-] is "used, intra-zone traffic is affected.
Beginning with Shorewall 4.4.13, exclusion is supported -- see see
shorewall-exclusion(5).Except when all[+][-] or
any[+][-] is
specified, clients may be further restricted to a list of networks
and/or hosts by appending ":" and a comma-separated list of network
and/or host addresses. Hosts may be specified by IP or MAC address;
mac addresses must begin with "~" and must use "-" as a
separator.The above restriction on all[+][-] and
any[+][-] is
removed in Shorewall-4.4.13.any is equivalent to
all when there are no nested zones.
When there are nested zones, any
only refers to top-level zones (those with no parent zones). Note
that any excludes all vserver
zones, since those zones are nested within the firewall zone.Hosts may also be specified as an IP address range using the
syntax
lowaddress-highaddress.
This requires that your kernel and iptables contain iprange match
support. If your kernel and iptables have ipset match support then
you may give the name of an ipset prefaced by "+". The ipset name
may be optionally followed by a number from 1 to 6 enclosed in
square brackets ([]) to indicate the number of levels of source
bindings to be matched.Beginning with Shorewall 4.4.17, the primary IP address of a
firewall interface can be specified by an ampersand ('&')
followed by the logical name of the interface as found in the
INTERFACE column of shorewall-interfaces
(5).Beginning with Shorewall 4.5.4, A
countrycode-list may be specified. A
countrycode-list is a comma-separated list of up to 15 two-character
ISO-3661 country codes enclosed in square brackets ('[...]') and
preceded by a caret ('^'). When a single country code is given, the
square brackets may be omitted. A list of country codes supported by
Shorewall may be found at http://www.shorewall.net/ISO-3661.html.
Specifying a countrycode-list requires
GeoIP Match support in your iptables and
Kernel.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).Examples:dmz:192.168.2.2Host 192.168.2.2 in the DMZnet:155.186.235.0/24Subnet 155.186.235.0/24 on the Internetloc:192.168.1.1,192.168.1.2Hosts 192.168.1.1 and 192.168.1.2 in the local
zone.loc:~00-A0-C9-15-39-78Host in the local zone with MAC address
00:A0:C9:15:39:78.net:192.0.2.11-192.0.2.17Hosts 192.0.2.11-192.0.2.17 in the net zone.net:!192.0.2.11-192.0.2.17All hosts in the net zone except for
192.0.2.11-192.0.2.17.net:155.186.235.0/24!155.186.235.16/28Subnet 155.186.235.0/24 on the Internet except for
155.186.235.16/28$FW:ð0The primary IP address of eth0 in the firewall zone
(Shorewall 4.4.17 and later).DEST -
{zone|zone-list[+]|{all|any}[+][-]}[:{interface|address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list}][port[:random]]Location of Server. May be a zone declared in shorewall-zones(5), $FW to indicate the firewall itself, all. all+ or
none.Beginning with Shorewall 4.4.13, you may use a
zone-list which consists of a
comma-separated list of zones declared in shorewall-zones (5). This
zone-list may be optionally followed by
"+" to indicate that the rule is to apply to intra-zone traffic as
well as inter-zone traffic.Beginning with Shorewall 4.5.4, A
countrycode-list may be specified. A
countrycode-list is a comma-separated list of up to 15 two-character
ISO-3661 country codes enclosed in square brackets ('[...]') and
preceded by a caret ('^'). When a single country code is given, the
square brackets may be omitted. A list of country codes supported by
Shorewall may be found at http://www.shorewall.net/ISO-3661.html.
Specifying a countrycode-list requires
GeoIP Match support in your iptables and
Kernel.When none is used either in
the SOURCE or DEST column, the rule is ignored.When all is used either in
the SOURCE or DEST column intra-zone traffic is not
affected. When all+ is used,
intra-zone traffic is affected. Beginning with Shorewall 4.4.13,
exclusion is supported -- see see shorewall-exclusion(5).any is equivalent to
all when there are no nested zones.
When there are nested zones, any
only refers to top-level zones (those with no parent zones).The zone should be omitted in
DNAT-, REDIRECT- and NONAT rules.If the DEST zone is a bport zone,
then either:the SOURCE must be , orthe SOURCE zone must be
another bport zone associated with the same bridge, orthe SOURCE zone must be an
ipv4 zone that is associated with only the same bridge.Except when all[+]|[-] is specified, the server may be
further restricted to a particular network, host or interface by
appending ":" and the network, host or interface. See SOURCE above.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).Restriction: MAC addresses are not allowed (this is a
Netfilter restriction).Like in the SOURCE column,
you may specify a range of IP addresses using the syntax
lowaddress-highaddress.
When the ACTION is DNAT or DNAT-, the connections will be assigned to
addresses in the range in a round-robin fashion.If you kernel and iptables have ipset match support then you
may give the name of an ipset prefaced by "+". The ipset name may be
optionally followed by a number from 1 to 6 enclosed in square
brackets ([]) to indicate the number of levels of destination
bindings to be matched. Only one of the SOURCE and DEST columns may specify an ipset
name.Beginning with Shorewall 4.4.17, the primary IP address of a
firewall interface can be specified by an ampersand ('&')
followed by the logical name of the interface as found in the
INTERFACE column of shorewall-interfaces
(5).The port that the server is
listening on may be included and separated from the server's IP
address by ":". If omitted, the firewall will not modify the
destination port. A destination port may only be included if the
ACTION is DNAT or REDIRECT.Example:loc:192.168.1.3:3128
specifies a local server at IP address 192.168.1.3 and
listening on port 3128.The port may be specified as a service
name. You may specify a port range in the form
lowport-highport to cause connections to be
assigned to ports in the range in round-robin fashion. When a port
range is specified, lowport and
highport must be given as integers; service
names are not permitted. Additionally, the port range may be
optionally followed by :random
which causes assignment to ports in the list to be random.If the ACTION is REDIRECT or REDIRECT-, this column needs only to contain
the port number on the firewall that the request should be
redirected to. That is equivalent to specifying
::port.PROTO- {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}Optional Protocol - ipp2p*
requires ipp2p match support in your kernel and iptables. tcp:syn implies tcp plus the SYN flag must be set and the
RST,ACK and FIN flags must be reset.Beginning with Shorewall 4.4.19, this column can contain a
comma-separated list of protocol-numbers and/or protocol
names.DEST PORT(S) (dport) -
{-|port-name-number-or-range[,port-name-number-or-range]...}Optional destination Ports. A comma-separated list of Port
names (from services(5)), port numbers or port ranges; if the
protocol is icmp, this column is
interpreted as the destination icmp-type(s). ICMP types may be
specified as a numeric type, a numeric type and code separated by a
slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.
Note that prior to Shorewall 4.4.19, only a single ICMP type may be
listed.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no port is given, ipp2p is
assumed.A port range is expressed as
lowport:highport.This column is ignored if PROTO = all
but must be entered if any of the following columns are supplied. In
that case, it is suggested that this field contain a dash (-).If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and the
CLIENT PORT(S) list below:1. There are 15 or less ports listed.2. No port ranges are included or your kernel and iptables
contain extended multi-port match support.SOURCE PORT(S) (sport) -
{-|port-name-number-or-range[,port-name-number-or-range]...}Optional port(s) used by the client. If omitted, any source
port is acceptable. Specified as a comma- separated list of port
names, port numbers or port ranges.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.Unless you really understand IP, you should leave this
column empty or place a dash (-)
in the column. Most people who try to use this column get it
wrong.If you don't want to restrict client ports but need to specify
an ORIGINAL DEST in the next
column, then place "-" in this column.If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and the
DEST PORT(S) list above:1. There are 15 or less ports listed.2. No port ranges are included or your kernel and iptables
contain extended multi-port match support.ORIGINAL DEST (origdest) -
[-|address[,address]...[exclusion]|exclusion]Optional. If ACTION is DNAT[-] or
REDIRECT[-] then if this column is included and is
different from the IP address given in the DEST column, then connections destined for
that address will be forwarded to the IP and port specified in the
DEST column.A comma-separated list of addresses may also be used. This is
most useful with the REDIRECT
target where you want to redirect traffic destined for particular
set of hosts. Finally, if the list of addresses begins with "!"
(exclusion) then the rule will be followed only
if the original destination address in the connection request does
not match any of the addresses listed.Beginning with Shorewall 4.4.17, the primary IP address of a
firewall interface can be specified by an ampersand ('&')
followed by the logical name of the interface as found in the
INTERFACE column of shorewall-interfaces
(5).For other actions, this column may be included and may contain
one or more addresses (host or network) separated by commas. Address
ranges are not allowed. When this column is supplied, rules are
generated that require that the original destination address matches
one of the listed addresses. This feature is most useful when you
want to generate a filter rule that corresponds to a DNAT- or REDIRECT- rule. In this usage, the list of
addresses should not begin with "!".It is also possible to specify a set of addresses then exclude
part of those addresses. For example, 192.168.1.0/24!192.168.1.16/28 specifies the
addresses 192.168.1.0-182.168.1.15 and 192.168.1.32-192.168.1.255.
See shorewall-exclusion(5).See http://shorewall.net/PortKnocking.html
for an example of using an entry in this column with a user-defined
action rule.RATE LIMIT (rate) - [-|[{s|d}:[[name]:]]]rate/{sec|min|hour|day}[:burst]You may optionally rate-limit the rule by placing a value in
this column:rate is the number of connections per
interval (sec or min) and burst is the
largest burst permitted. If no burst is given,
a value of 5 is assumed. There may be no no white-space embedded in
the specification.Example: 10/sec:20When or is specified,
the rate applies per source IP address or per destination IP address
respectively. The name may be chosen by
the user and specifies a hash table to be used to count matching
connections. If not given, the name shorewallN (where N is a unique integer) is
assumed. Where more than one rule specifies the same name, the
connections counts for the rules are aggregated and the individual
rates apply to the aggregated count.Example: s:ssh:3/min:5USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][,...]This optional column may only be non-empty if the SOURCE is
the firewall itself.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Beginning with Shorewall 4.5.8, multiple user or group
names/ids separated by commas may be specified.Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group2001-2099UIDs 2001 through 2099 (Shorewall 4.5.6 and
later)MARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.CONNLIMIT - [!]limit[:mask]May be used to limit the number of simultaneous connections
from each individual host to limit
connections. Requires connlimit match in your kernel and iptables.
While the limit is only checked on rules specifying CONNLIMIT, the
number of current connections is calculated over all current
connections from the SOURCE host. By default, the limit is applied
to each host but can be made to apply to networks of hosts by
specifying a mask. The
mask specifies the width of a VLSM mask
to be applied to the source address; the number of current
connections is then taken over all hosts in the subnet
source-address/mask.
When is specified, the rule matches when the
number of connection exceeds the
limit.TIME -
timeelement[&timeelement...]May be used to limit the rule to a particular time period each
day, to particular days of the week or month, or to a range defined
by dates and times. Requires time match support in your kernel and
iptables.timeelement may be:timestart=hh:mm[:ss]Defines the starting time of day.timestop=hh:mm[:ss]Defines the ending time of day.utcTimes are expressed in Greenwich Mean Time.localtzDeprecated by the Netfilter team in favor of kerneltz. Times are expressed in Local
Civil Time (default).kerneltzAdded in Shorewall 4.5.2. Times are expressed in Local
Kernel Time (requires iptables 1.4.12 or later).weekdays=ddd[,ddd]...where ddd is one of
, ,
, ,
, or
monthdays=dd[,dd],...where dd is an ordinal day of
the monthdatestart=yyyy[-mm[-dd[hh[:mm[:ss]]]]]Defines the starting date and time.datestop=yyyy[-mm[-dd[hh[:mm[:ss]]]]]Defines the ending date and time.HEADERSAdded in Shorewall 4.4.15. Not used in IPv4 configurations. If
you with to supply a value for one of the later columns, enter '-'
in this column.SWITCH -
[!]switch-name[={0|1}]Added in Shorewall 4.4.24 and allows enabling and disabling
the rule without requiring shorewall
restart.The rule is enabled if the value stored in
/proc/net/nf_condition/switch-name
is 1. The rule is disabled if that file contains 0 (the default). If
'!' is supplied, the test is inverted such that the rule is enabled
if the file contains 0.Within the switch-name, '@0' and
'@{0}' are replaced by the name of the chain to which the rule is a
added. The switch-name (after '@...'
expansion) must begin with a letter and be composed of letters,
decimal digits, underscores or hyphens. Switch names must be 30
characters or less in length.Switches are normally off. To
turn a switch on:echo 1 >
/proc/net/nf_condition/switch-nameTo turn it off again:echo 0 >
/proc/net/nf_condition/switch-nameSwitch settings are retained over shorewall
restart.Beginning with Shorewall 4.5.10, when the
switch-name is followed by
or , then the switch is
initialized to off or on respectively by the
start command. Other commands do not affect the
switch setting.HELPER - [helper]Added in Shorewall 4.5.7.In the NEW section, causes the named conntrack
helper to be associated with this
connection; the contents of this column are ignored unless ACTION is
ACCEPT*, DNAT* or REDIRECT*.In the RELATED section, will only match if the related
connection has the named helper
associated with it.The helper may be one of:If the HELPERS option is specified in shorewall.conf(5), then any module
specified in this column must be listed in the HELPERS
setting.ExamplesExample 1:Accept SMTP requests from the DMZ to the internet #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
ACCEPT dmz net tcp smtpExample 2:Forward all ssh and http connection requests from the internet
to local system 192.168.1.3 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
DNAT net loc:192.168.1.3 tcp ssh,httpExample 3:Forward all http connection requests from the internet to
local system 192.168.1.3 with a limit of 3 per second and a maximum
burst of 10 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT PORT(S) DEST LIMIT
DNAT net loc:192.168.1.3 tcp http - - 3/sec:10Example 4:Redirect all locally-originating www connection requests to
port 3128 on the firewall (Squid running on the firewall system)
except when the destination address is 192.168.2.2 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
REDIRECT loc 3128 tcp www - !192.168.2.2Example 5:All http requests from the internet to address 130.252.100.69
are to be forwarded to 192.168.1.3 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
DNAT net loc:192.168.1.3 tcp 80 - 130.252.100.69Example 6:You want to accept SSH connections to your firewall only from
internet IP addresses 130.252.100.69 and 130.252.100.70 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
ACCEPT net:130.252.100.69,130.252.100.70 $FW \
tcp 22Example 7:You wish to accept connections from the internet to your
firewall on port 2222 and you want to forward them to local system
192.168.1.3, port 22 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
DNAT net loc:192.168.1.3:22 tcp 2222Example 8:You want to redirect connection requests to port 80 randomly
to the port range 81-90. #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
REDIRECT net $FW::81-90:random tcp wwwExample 9:Shorewall does not impose as much structure on the Netfilter
rules in the 'nat' table as it does on those in the filter table. As
a consequence, when using Shorewall versions before 4.1.4, care must
be exercised when using DNAT and REDIRECT rules with zones defined
with wildcard interfaces (those ending with '+'. Here is an
example:shorewall-zones(8): #ZONE TYPE OPTIONS
fw firewall
net ipv4
dmz ipv4
loc ipv4shorewall-interfaces(8): #ZONE INTERFACE BROADCAST OPTIONS
net ppp0
loc eth1 detect
dmz eth2 detect
- ppp+ # Addresses are assigned from 192.168.3.0/24shorewall-host(8): #ZONE HOST(S) OPTIONS
loc ppp+:192.168.3.0/24rules: #ACTION SOURCE DEST PROTO DEST
# PORT(S)
REDIRECT loc 3128 tcp 80 Note that it would have been tempting to simply define the
loc zone entirely in shorewall-interfaces(8): #******************* INCORRECT *****************
#ZONE INTERFACE BROADCAST OPTIONS
net ppp0
loc eth1 detect
loc ppp+
dmz eth2This would have made it impossible to run a
internet-accessible web server in the DMZ because all traffic
entering ppp+ interfaces would have been redirected to port 3128 on
the firewall and there would have been no net->fw ACCEPT rule for
that traffic.Example 10:Add the tuple (source IP, dest port, dest IP) of an incoming
SSH connection to the ipset S: #ACTION SOURCE DEST PROTO DEST
# PORT(S)
ADD(+S:dst,src,dst) net fw tcp 22Example 11:You wish to limit SSH connections from remote systems to 1/min
with a burst of three (to allow for limited retry): #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT(S) PORT(S) DEST LIMIT
SSH(ACCEPT) net all - - - - s:1/min:3Example 12:Forward port 80 to dmz host $BACKUP if switch 'primary_down'
is on. #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH
# PORT(S) PORT(S) DEST LIMIT GROUP
DNAT net dmz:$BACKUP tcp 80 - - - - - - - - primary_downExample 13:Drop all email from the Anonymous Proxy
and Satellite Provider address ranges: #ACTION SOURCE DEST PROTO DEST
# PORT(S)
DROP net:^A1,A2 fw tcp 25Example 14:You want to generate your own rule involving iptables targets
and matches not supported by Shorewall. #ACTION SOURCE DEST PROTO DEST
# PORT(S)
INLINE $FW net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3The above will generate the following iptables-restore
input: -A fw2net -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3Note that SECCTX must be defined as a builtin action in shorewall-actions(5): #ACTION OPTIONS
SECCTX builtinFILES/etc/shorewall/rulesSee ALSOhttp://www.shorewall.net/ipsets.htmlhttp://www.shorewall.net/configuration_file_basics.htm#Pairshttp://www.shorewall.net/shorewall_logging.htmlshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-blrules(5), shorewall-hosts(5),
shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5),
shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5),
shorewall-params(5), shorewall-policy(5), shorewall-providers(5),
shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-secmarks.xml 0000644 0001750 0001750 00000037023 12222401136 023344 0 ustar teastep teastep
shorewall-secmarks5secmarksShorewall file/etc/shorewall/secmarksDescriptionUnlike rules in the shorewall-rules(5) file, evaluation
of rules in this file will continue after a match. So the final secmark
for each packet will be the one assigned by the LAST rule that
matches.The secmarks file is used to associate an SELinux context with
packets. It was added in Shorewall version 4.4.13.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).SECMARK -
{SAVE|RESTORE|context|COMMENT
comment}SAVEIf an SELinux context is associated with the packet, the
context is saved in the connection. Normally, the remaining
columns should be left blank.RESTOREIf an SELinux context is not currently associated with
the packet, then the saved context (if any) is associated with
the packet. Normally, the remaining columns should be left
blank.contextAn SELinux context.[?]COMMENTThe remainder of the line is treated as a comment which
is attached to subsequent rules until another COMMENT line is
found or until the end of the file is reached. To stop adding
comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CHAIN:STATE (chain) -
{P|I|F|O|T}[:{N|I|U|IU|NI|NU|NIU|NUI:E|ER}]This column determines the CHAIN where the SELinux context is
to be applied:P - PREROUTINGI - INPUTF - FORWARDO - OUTPUTT - POSTROUTINGIt may be optionally followed by a colon and an indication of
the Netfilter connection state(s) at which the context is to be
applied::N - NEW connection:I - INVALID connection:NI - NEW or INVALID connection:E - ESTABLISHED connection:ER - ESTABLISHED or RELATED connectionBeginning with Shorewall 4.5.10, the following additional
options are available:U - UNTRACKED connection:IU - INVALID or UNTRACKED connection:NU - NEW or UNTRACKED connection:NIU - NEW, INVALID or UNTRACKED connection.SOURCE - {-interface|[interface:]address-or-range[,address-or-range]...}[exclusion]May be:An interface name - matches traffic entering the firewall
on the specified interface. May not be used in classify rules or
in rules using the T in the CHAIN column.A comma-separated list of host or network IP addresses or
MAC addresses.An interface name followed by a colon (":") followed by a
comma-separated list of host or network IP addresses or MAC
addresses.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).Addresses may be specified using an ipset name preceded by
'+'.DEST - {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion]May be:An interface name. May not be used in the PREROUTING or
INPUT chains. The interface name may be optionally followed by a
colon (":") and an IP address list.A comma-separated list of host or network IP addresses.
The list may include ip address ranges if your kernel and
iptables include iprange support.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).Addresses may be specified using an ipset name preceded by
'+'.PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]Protocol - ipp2p requires
ipp2p match support in your kernel and iptables.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...]Optional destination Ports. A comma-separated list of Port
names (from services(5)), port numbers or
port ranges; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s). ICMP types may be specified as a numeric
type, a numeric type and code separated by a slash (e.g., 3/4), or
a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no PORT is given, ipp2p is
assumed.This column is ignored if PROTOCOL = all but must be entered
if any of the following field is supplied. In that case, it is
suggested that this field contain "-"SOURCE PORT(S) (sport) -
[-|port-name-number-or-range[,port-name-number-or-range]...]Optional source port(s). If omitted, any source port is
acceptable. Specified as a comma-separated list of port names, port
numbers or port ranges.USER - [!][user-name-or-number][:group-name-or-number]This optional column may only be non-empty if the SOURCE is
the firewall itself.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
groupMARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.EXAMPLEMark the first incoming packet of a connection on the loopback
interface and destined for address 127.0.0.1 and tcp port 3306 with
context system_u:object_r:mysqld_t:s0 and save that context in the
conntrack table. On subsequent input packets in the connection, set the
context from the conntrack table./etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
- lo - ignore/etc/shorewall/secmarks:#SECMARK CHAIN: SOURCE DEST PROTO DEST SOURCE USER/ MARK
# STATE PORT(S) PORT(S) GROUP
system_u:object_r:mysqld_packet_t:s0 I:N lo 127.0.0.1 tcp 3306
SAVE I:N lo 127.0.0.1 tcp 3306
RESTORE I:ERFILES/etc/shorewall/secmarksSee ALSOhttp://james-morris.livejournal.com/11010.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-accounting.xml 0000644 0001750 0001750 00000076162 12222401136 023675 0 ustar teastep teastep
shorewall-accounting5accountingShorewall Accounting file/etc/shorewall/accountingDescriptionAccounting rules exist simply to count packets and bytes in
categories that you define in this file. You may display these rules and
their packet and byte counters using the shorewall show
accounting command.Beginning with Shorewall 4.4.18, the accounting structure can be
created with three root chains:accountin: Rules that are valid
in the INPUT chain (may not specify
an output interface).accountout: Rules that are
valid in the OUTPUT chain (may not specify an input interface or a MAC
address).accounting: Other rules.The new structure is enabled by sectioning the accounting file in a
manner similar to the rules
file. The sections are INPUT,
OUTPUT and FORWARD and must appear in that order (although any
of them may be omitted). The first non-commentary record in the accounting
file must be a section header when sectioning is used.If sections are not used, the Shorewall rules compiler cannot
detect certain violations of netfilter restrictions. These violations
can result in run-time errors such as the following:
iptables-restore v1.4.13: Can't use -o
with INPUT
Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was
added to shorewall.conf and shorewall6.conf. That setting determines the
Netfilter table (filter or mangle) where the accounting rules are added.
When ACCOUNTING_TABLE=mangle is specified, the available sections are
PREROUTING, INPUT, OUTPUT,
FORWARD and POSTROUTING.Section headers have the form:section-nameWhen sections are enabled:A jump to a user-defined accounting chain must appear before
entries that add rules to that chain. This eliminates loops and
unreferenced chains.An output interface may not be specified in the PREROUTING and INPUT sections.In the OUTPUT and POSTROUTING sections:An input interface may not be specifiedJumps to a chain defined in the INPUT or PREROUTING sections that specifies an input
interface are prohibitedMAC addresses may not be usedJump to a chain defined in the INPUT or PREROUTING section that specifies a MAC
address are prohibited.The default value of the CHAIN column is:accountin in the INPUT sectionaccountout in the OUTPUT sectionaccountfwd in the FORWARD sectionaccountpre in the PREROUTING sectionaccountpost in the
POSTROUTING sectionTraffic addressed to the firewall goes through the rules defined
in the INPUT section.Traffic originating on the firewall goes through the rules
defined in the OUTPUT section.Traffic being forwarded through the firewall goes through the
rules from the FORWARD sections.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax):ACTION - {COUNT|DONE|chain[:{COUNT|JUMP}]|ACCOUNT(table,network)|[?]COMMENT
comment}What to do when a matching packet is found.COUNTSimply count the match and continue with the next
ruleDONECount the match and don't attempt to match any other
accounting rules in the chain specified in the CHAIN column.chain[:COUNT]Where chain is the name of a chain;
shorewall will create the chain automatically if it doesn't
already exist. If a second chain is mentioned in the CHAIN
column, then a jump from this second chain to
chain is created. If no chain is
named in the CHAIN column, then a jump from the default chain
to chain is created. If :COUNT is included, a counting rule
matching this entry will be added to
chain. The chain may
not exceed 29 characters in length and may be composed of
letters, digits, dash ('-') and underscore ('_').chain:JUMPLike the previous option without the :COUNT part.ACCOUNT(table,network)This action implements per-IP accounting and was added
in Shorewall 4.4.17. Requires the ACCOUNT
Target capability in your iptables and kernel (see
the output of shorewall show
capabilities).tableis the name of an accounting table (you choose the
name). All rules specifying the same name will have
their per-IP counters accumulated in the same
table.networkis an IPv4 network in CIDR notation (e.g.,
192.168.1.0/24). The network can be as large as a /8
(class A).One nice feature of per-IP accounting is that the
counters survive shorewall restart. This
has a downside, however. If you change the network associated
with an accounting table, then you must shorewall
stop; shorewall start to have a successful restart
(counters will be cleared).The counters in a table are
printed using the iptaccount utility. For a
command synopsis, type:iptaccount --helpAs of February 2011, the ACCOUNT Target capability and
the iptaccount utility are only available when xtables-addons
is installed. See http://www.shorewall.net/Accounting.html#perIP
for additional information.INLINEAdded in Shorewall 4.5.16. Allows free form iptables
matches to be specified following a ';'. In the generated
iptables rule(s), the free form matches will follow any
matches that are generated by the column contents.NFACCT({object[!]}[,...])Added in Shorewall 4.5.7. Provides a form of accounting
that survives shorewall stop/shorewall
start and shorewall restart. Requires the
NFaccnt Match capability in your kernel and iptables.
object names an nfacct object (see
man nfaccnt(8)). Multiple rules can specify the same
object; all packets that match any
of the rules increment the packet and bytes count of the
object.Prior to Shorewall 4.5.16, only one
object could be specified.
Beginning with Shorewall 4.5.16, an arbitrary number of
objects may be given.With Shorewall 4.5.16 or later, an nfacct
object in the list may optionally
be followed by ! to indicate
that the nfacct object will be
incremented unconditionally for each packet. When ! is omitted, the
object will be incremented only if
all of the matches in the rule succeed.NFLOG[(nflog-parameters)]
- Added in Shorewall-4.4.20.Causes each matching packet to be sent via the currently
loaded logging back-end (usually nfnetlink_log) where it is
available to accounting daemons through a netlink
socket.[?]COMMENTThe remainder of the line is treated as a comment which
is attached to subsequent rules until another COMMENT line is
found or until the end of the file is reached. To stop adding
comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CHAIN - {-|chain}The name of a chain. If specified as
- the accounting chain is assumed when the file is
un-sectioned. When the file is sectioned, the default is one of
accountin, accountout, etc. depending on the section. This is the
chain where the accounting rule is added. The
chain will be created if it doesn't already
exist. The chain may not exceed 29 characters
in length.SOURCE - {-|any|all|interface|interface:address|address}Packet Source.The name of an interface, an
address (host or net) or an
interface name followed by ":" and a host
or net address. An ipset name is also
accepted as an address.DESTINATION (dest) - {-|any|all|interface|interface:address|address}Packet Destination.Format same as SOURCE
column.PROTOCOL (proto) - {-|{any|all|protocol-name|protocol-number|ipp2p[:{udp|all}]}[,...]}A protocol-name (from protocols(5)), a
protocol-number, ipp2p, ipp2p:udp or ipp2p:allBeginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT(S) (dport) -
{-|any|all|ipp2p-option|port-name-or-number[,port-name-or-number]...}Destination Port number. Service name from services(5) or
port number. May only be specified if the
protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE
(136).You may place a comma-separated list of port names or numbers
in this column if your kernel and iptables include multi-port match
support.If the PROTOCOL is ipp2p then
this column must contain an ipp2p-option
("iptables -m ipp2p --help") without the leading "--". If no option
is given in this column, ipp2p is
assumed.SOURCE PORT(S) (sport)-
{-|any|all|port-name-or-number[,port-name-or-number]...}Service name from services(5) or port
number. May only be specified if the protocol is TCP (6),
UDP (17), DCCP (33), SCTP (132) or UDPLITE (136).You may place a comma-separated list of port numbers in this
column if your kernel and iptables include multi-port match
support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][+program-name]This column may only be non-empty if the CHAIN is OUTPUT.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group+upnpd#program named upnpdThe ability to specify a program name was removed from
Netfilter in kernel version 2.6.14.MARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.IPSEC - option-list
(Optional - Added in Shorewall 4.4.13 but broken until 4.5.4.1
)The option-list consists of a comma-separated list of options
from the following list. Only packets that will be encrypted or have
been decrypted via an SA that matches these options will have their
source address changed.reqid=numberwhere number is specified using
setkey(8) using the 'unique:number option
for the SPD level.spi=<number>where number is the SPI of the SA
used to encrypt/decrypt packets.proto=ah|esp|ipcompIPSEC Encapsulation Protocolmss=numbersets the MSS field in TCP packetsmode=transport|tunnelIPSEC modetunnel-src=address[/mask]only available with mode=tunneltunnel-dst=address[/mask]only available with mode=tunnelstrictMeans that packets must match all rules.nextSeparates rules; can only be used with strictyes or ipsecWhen used by itself, causes all traffic that will be
encrypted/encapsulated or has been decrypted/un-encapsulated
to match the rule.no or noneWhen used by itself, causes all traffic that will not be
encrypted/encapsulated or has been decrypted/un-encapsulated
to match the rule.inMay only be used in the FORWARD section and must be the
first or the only item the list. Indicates that matching
packets have been decrypted in input.outMay only be used in the FORWARD section and must be the
first or the only item in the list. Indicates that matching
packets will be encrypted on output.If this column is non-empty and sections are not used,
then:A chain NAME appearing in the ACTION column must be a
chain branched either directly or indirectly from the accipsecin or accipsecout chain.The CHAIN column must contain either accipsecin or accipsecout or a chain branched either
directly or indirectly from those chains.These rules will NOT appear in the accounting chain.In all of the above columns except ACTION and CHAIN,
the values -, any and all may be
used as wildcard'gs. Omitted trailing columns are also treated as
wildcard'g.FILES/etc/shorewall/accountingSee ALSOhttp://shorewall.net/Accounting.html
http://shorewall.net/shorewall_logging.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-actions(5), shorewall-blacklist(5),
shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcfilters.xml 0000644 0001750 0001750 00000026563 12222401136 023542 0 ustar teastep teastep
shorewall-tcfilters5tcfiltersShorewall u32 classifier rules file/etc/shorewall/tcfiltersDescriptionEntries in this file cause packets to be classified for traffic
shaping.Beginning with Shorewall 4.4.15, the file may contain entries for
both IPv4 and IPv6. By default, all rules apply to IPv4 but that can be
changed by inserting a line as follows:IPV4Following entries apply to IPv4.IPV6Following entries apply to IPv6ALLFollowing entries apply to both IPv4 and IPv6. Each entry is
processed twice; once for IPv4 and once for IPv6.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).CLASS -
interface:classThe name or number of an interface
defined in shorewall-tcdevices(5)
followed by a class number defined for
that interface in shorewall-tcclasses(5).SOURCE - {-|address}Source of the packet. May be a host or network
address. DNS names are not
allowed.DEST - {-|address}}Destination of the packet. May be a host or network
address. DNS names are not
allowed.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).PROTO - {-|{protocol-number|protocol-name|all}[,...]}Protocol.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT (dport) - [-|port-name-or-number]Optional destination Ports. A Port name (from services(5)) or
a port number; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s).SOURCE PORT (sport) -
[-|port-name-or-number]Optional source port.TOS (Optional) - [-|tos]Specifies the value of the TOS field. The
tos value can be any of the
following:hex-numberhex-number/hex-numberThe hex-numbers must be exactly two
digits (e.g., 0x04)x.LENGTH - [-|number]Optional - Must be a power of 2 between 32 and 8192 inclusive.
Packets with a total length that is strictly less than the specified
number will match the rule.PRIORITY - [-|priority]Added in Shorewall 4.5.8. Specifies the rule
priority. The
priority value must be > 0 and <=
65535.When a priority is not
given:For Shorewall versions prior to 4.5.8 - all filters have
priority 10.For Shorewall 4.5.8 and later - for each device, the
compiler maintains a high-water priority
with an initial value of 0. When a filter has no
priority, the high-water priority is
incremented by 1 and assigned to the filter. When a
priority greater than the high-water
priority is entered in this column, the high-water priority is
set to the specified priority. An
attempt to assign a priority value greater than 65535
(explicitly or implicitly) raises an error.The default priority values used by other Shorewall-generated
filters are as follows:Classify by packet mark - ( class
priority << 8 ) | 20.Ingress policing - 10Simple TC ACK packets - 1Complex TC ACK packets - ( class
priority << 8 ) | 10.Classify by TOS - ( class
priority << 8 ) | 15.Class with 'occurs' - 65535ExampleExample 1:Place all 'ping' traffic on interface 1 in class 10. Note that
ALL cannot be used because IPv4 ICMP and IPv6 ICMP are two different
protocols. #CLASS SOURCE DEST PROTO DEST
# PORT
IPV4
1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
IPV6
1:10 ::/0 ::/0 icmp6 echo-request
1:10 ::/0 ::/0 icmp6 echo-replyExample 2:Add two filters with priority 10 (Shorewall 4.5.8 or
later). #CLASS SOURCE DEST PROTO DEST PRIORITY
# PORT
IPV4
1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-request 10
1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 10FILES/etc/shorewall/tcfiltersSee ALSOhttp://shorewall.net/traffic_shaping.htmhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/PacketMarking.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(5),
shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-blacklist.xml 0000644 0001750 0001750 00000017335 12222401136 023510 0 ustar teastep teastep
shorewall-blacklist5blacklistShorewall Blacklist file/etc/shorewall/blacklistDescriptionThe blacklist file is used to perform static blacklisting by source
address (IP or MAC), or by application. The use of this file is deprecated
and beginning with Shorewall 4.5.7, the file is no longer
installed.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ADDRESS/SUBNET (networks) -
{-|~mac-address|ip-address|address-range|+ipset}Host address, network address, MAC address, IP address range
(if your kernel and iptables contain iprange match support) or ipset
name prefaced by "+" (if your kernel supports ipset match).
Exclusion (shorewall-exclusion(5)) is
supported.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78A dash ("-") in this column means that any source address will
match. This is useful if you want to blacklist a particular
application using entries in the PROTOCOL and PORTS columns.PROTOCOL (proto) - {-|[!]protocol-number|[!]protocol-name}Optional - If specified, must be a protocol number or a
protocol name from protocols(5).PORTS - {-|[!]port-name-or-number[,port-name-or-number]...}Optional - may only be specified if the protocol is TCP (6) or
UDP (17). A comma-separated list of destination port numbers or
service names from services(5).OPTIONS - {-|{dst|src|whitelist|audit}[,...]}Optional - added in 4.4.12. If specified, indicates whether
traffic from ADDRESS/SUBNET (src) or traffic to
ADDRESS/SUBNET (dst) should be
blacklisted. The default is src. If
the ADDRESS/SUBNET column is empty, then this column has no effect
on the generated rule.In Shorewall 4.4.12, the keywords from and to were used in
place of src and dst respectively. Blacklisting was still
restricted to traffic arriving on an
interface that has the 'blacklist' option set. So to block traffic
from your local network to an internet host, you had to specify
on your internal interface in shorewall-interfaces
(5).Beginning with Shorewall 4.4.13, entries are applied based
on the blacklist setting in
shorewall-zones(5):'blacklist' in the OPTIONS or IN_OPTIONS column. Traffic
from this zone is passed against the entries in this file that
have the src option
(specified or defaulted).'blacklist' in the OPTIONS or OUT_OPTIONS column.
Traffic to this zone is passed against the entries in this
file that have the dst
option.In Shorewall 4.4.20, the whitelist option was added. When whitelist is specified, packets/connections
that match the entry are not matched against the remaining entries
in the file.The audit option was also
added in 4.4.20 and causes packets matching the entry to be audited.
The audit option may not be
specified in whitelist entries and require AUDIT_TARGET support in
the kernel and iptables.ExampleExample 1:To block DNS queries from address 192.0.2.126: #ADDRESS/SUBNET PROTOCOL PORT
192.0.2.126 udp 53Example 2:To block some of the nuisance applications: #ADDRESS/SUBNET PROTOCOL PORT
- udp 1024:1033,1434
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898FILES/etc/shorewall/blacklistSee ALSOhttp://shorewall.net/blacklisting_support.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-routestopped.xml 0000644 0001750 0001750 00000020705 12222401136 024270 0 ustar teastep teastep
shorewall-routestopped5routestoppedThe Shorewall file that governs what traffic flows through the
firewall while it is in the 'stopped' state./etc/shorewall/routestoppedDescriptionThis file is deprecated in favor of the shorewall-stoppedrules(5)
file.This file is used to define the hosts that are accessible when the
firewall is stopped or is being stopped.Changes to this file do not take effect until after the next
shorewall start or shorewall
restart command.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).INTERFACE -
interfaceInterface through which host(s) communicate with the
firewallHOST(S) (hosts) - [-|address[,address]...]Optional. Comma-separated list of IP/subnet addresses. If your
kernel and iptables include iprange match support, IP address ranges
are also allowed.If left empty or supplied as "-", 0.0.0.0/0 is assumed.OPTIONS - [-|option[,option]...]Optional. A comma-separated list of options. The order of the
options is not important but the list can contain no embedded
white-space. The currently-supported options are:routebackSet up a rule to ACCEPT traffic from these hosts back to
themselves. Beginning with Shorewall 4.4.9, this option is
automatically set if routeback is specified in shorewall-interfaces
(5) or if the rules compiler detects that the interface is a
bridge.sourceAllow traffic from these hosts to ANY destination.
Without this option or the dest option, only traffic from this
host to other listed hosts (and the firewall) is allowed. If
source is specified then
routeback is
redundant.destAllow traffic to these hosts from ANY source. Without
this option or the source
option, only traffic from this host to other listed hosts (and
the firewall) is allowed. If dest is specified then routeback is redundant.notrackThe traffic will be exempted from connection
tracking.PROTO (Optional) ‒
protocol-name-or-numberProtocol.DEST PORT(S) (dport) ‒
service-name/port-number-listOptional. A comma-separated list of port numbers and/or
service names from /etc/services. May also
include port ranges of the form
low-port:high-port
if your kernel and iptables include port range support.SOURCE PORT(S) (sport) ‒
service-name/port-number-listOptional. A comma-separated list of port numbers and/or
service names from /etc/services. May also
include port ranges of the form
low-port:high-port
if your kernel and iptables include port range support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.The source and dest options work best when used in conjunction
with ADMINISABSENTMINDED=Yes in shorewall.conf(5).ExampleExample 1: #INTERFACE HOST(S) OPTIONS PROTO DEST SOURCE
# PORT(S) PORT(S)
eth2 192.168.1.0/24
eth0 192.0.2.44
br0 - routeback
eth3 - source
eth4 - notrack 41FILES/etc/shorewall/routestoppedSee ALSOhttp://shorewall.net/starting_and_stopping_shorewall.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-masq.xml 0000644 0001750 0001750 00000064747 12222401136 022512 0 ustar teastep teastep
shorewall-masq5masqShorewall Masquerade/SNAT definition file/etc/shorewall/masqDescriptionUse this file to define dynamic NAT (Masquerading) and to define
Source NAT (SNAT).The entries in this file are order-sensitive. The first entry that
matches a particular connection will be the one that is used.If you have more than one ISP link, adding entries to this file
will not force connections to go out
through a particular link. You must use entries in shorewall-rtrules(5) or PREROUTING
entries in shorewall-tcrules(5) to do
that.The columns in the file are as follows.INTERFACE:DEST - {[+]interfacelist[:[digit]][:[dest-address[,dest-address]...[exclusion]]|[?]COMMENT}Outgoing interfacelist. This may be a
comma-separated list of interface names. This is usually your
internet interface. If ADD_SNAT_ALIASES=Yes in shorewall.conf(5), you may add ":"
and a digit to indicate that you want the alias
added with that name (e.g., eth0:0). This will allow the alias to be
displayed with ifconfig. That is the only use
for the alias name; it may not appear in any other place in your
Shorewall configuration.Each interface must match an entry in shorewall-interfaces(5).
Shorewall allows loose matches to wildcard entries in shorewall-interfaces(5). For
example, ppp0 in this file
will match a shorewall-interfaces(5)
entry that defines ppp+.Where more that
one internet provider share a single interface, the provider
is specified by including the provider name or number in
parentheses: eth0(Avvanta)In that case, you will want to specify the interface's
address for that provider in the ADDRESS column.The interface may be qualified by adding the character ":"
followed by a comma-separated list of destination host or subnet
addresses to indicate that you only want to change the source IP
address for packets being sent to those particular destinations.
Exclusion is allowed (see shorewall-exclusion(5)) as
are ipset names preceded by a plus sign '+';If you wish to inhibit the action of ADD_SNAT_ALIASES for this
entry then include the ":" but omit the digit: eth0(Avvanta):
eth2::192.0.2.32/27Normally Masq/SNAT rules are evaluated after those for
one-to-one NAT (defined in shorewall-nat(5)). If you want the
rule to be applied before one-to-one NAT rules, prefix the interface
name with "+": +eth0
+eth0:192.0.2.32/27
+eth0:2This feature should only be required if you need to insert
rules in this file that preempt entries in shorewall-nat(5).Comments may be attached to Netfilter rules generated from
entries in this file through the use of COMMENT lines. These lines
begin with the word COMMENT; the remainder of the line is treated as
a comment which is attached to subsequent rules until another
COMMENT line is found or until the end of the file is reached. To
stop adding comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for
COMMENT and is preferred.SOURCE (Formerly called SUBNET)
-
{interface|address[,address][exclusion]}Set of hosts that you wish to masquerade. You can specify this
as an address (net or host) or as an
interface (use of an
interface is deprecated). If you give the name
of an interface, the interface must be up before you start the
firewall and the Shorewall rules compiler will warn you of that
fact. (Shorewall will use your main routing table to determine the
appropriate addresses to masquerade).The preferred way to specify the SOURCE is to supply one or
more host or network addresses separated by comma. You may use ipset
names preceded by a plus sign (+) to specify a set of hosts.ADDRESS (Optional) - [-|NONAT|[address-or-address-range[,address-or-address-range]...][:lowport-highport][:random][:persistent]|detect|random]If you specify an address here, SNAT will be used and this
will be the source address. If ADD_SNAT_ALIASES is set to Yes or yes
in shorewall.conf(5) then
Shorewall will automatically add this address to the INTERFACE named
in the first column.You may also specify a range of up to 256 IP addresses if you
want the SNAT address to be assigned from that range in a
round-robin fashion by connection. The range is specified by
first.ip.in.range-last.ip.in.range.
You may follow the port range with
:random in which case assignment of ports from the list
will be random. random may also be
specified by itself in this column in which case random local port
assignments are made for the outgoing connections.Example: 206.124.146.177-206.124.146.180You may follow the port range (or :random) with :persistent. This is only useful when an
address range is specified and causes a client to be given the same
source/destination IP pair. This feature replaces the SAME modifier
which was removed from Shorewall in version 4.4.0. Unlike random, persistent may not be used by itself.You may also use the special value "detect" which causes
Shorewall to determine the IP addresses configured on the interface
named in the INTERFACES column and substitute them in this
column.Finally, you may also specify a comma-separated list of ranges
and/or addresses in this column.This column may not contain DNS Names.Normally, Netfilter will attempt to retain the source port
number. You may cause netfilter to remap the source port by
following an address or range (if any) by ":" and a port range with
the format
lowport-highport. If this
is done, you must specify "tcp" or "udp" in the PROTO column.Examples: 192.0.2.4:5000-6000
:4000-5000If you simply place NONAT in
this column, no rewriting of the source IP address or port number
will be performed. This is useful if you want particular traffic to
be exempt from the entries that follow in the file.If you want to leave this column empty but you need to specify
the next column then place a hyphen ("-") here.PROTO (Optional) - {-|[!]{protocol-name|protocol-number}[,...]}If you wish to restrict this entry to a particular protocol
then enter the protocol name (from protocols(5)) or number
here.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) (Optional) -
[[!]port-name-or-number[,port-name-or-number]...]If the PROTO column specifies TCP (6), UDP (17), DCCP (33),
SCTP (132) or UDPLITE (136) then you may list one or more port
numbers (or names from services(5)) or port ranges separated by
commas.Port ranges are of the form
lowport:highport.IPSEC (Optional) -
[option[,option]...]If you specify a value other than "-" in this column, you must
be running kernel 2.6 and your kernel and iptables must include
policy match support.Comma-separated list of options from the following. Only
packets that will be encrypted via an SA that matches these options
will have their source address changed.reqid=numberwhere number is specified using
setkey(8) using the 'unique:number option
for the SPD level.spi=<number>where number is the SPI of the SA
used to encrypt/decrypt packets.proto=ah|esp|ipcompIPSEC Encapsulation Protocolmss=numbersets the MSS field in TCP packetsmode=transport|tunnelIPSEC modetunnel-src=address[/mask]only available with mode=tunneltunnel-dst=address[/mask]only available with mode=tunnelstrictMeans that packets must match all rules.nextSeparates rules; can only be used with strictyesWhen used by itself, causes all traffic that will be
encrypted/encapsulated to match the rule.MARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.USER/GROUP (Optional) -
[!][user-name-or-number][:group-name-or-number][+program-name]Only locally-generated connections will match if this column
is non-empty.When this column is non-empty, the rule matches only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group+upnpd#program named upnpdThe ability to specify a program name was removed from
Netfilter in kernel version 2.6.14.SWITCH -
[!]switch-name[={0|1}]Added in Shorewall 4.5.1 and allows enabling and disabling the
rule without requiring shorewall restart.The rule is enabled if the value stored in
/proc/net/nf_condition/switch-name
is 1. The rule is disabled if that file contains 0 (the default). If
'!' is supplied, the test is inverted such that the rule is enabled
if the file contains 0.Within the switch-name, '@0' and
'@{0}' are replaced by the name of the chain to which the rule is a
added. The switch-name (after '@...'
expansion) must begin with a letter and be composed of letters,
decimal digits, underscores or hyphens. Switch names must be 30
characters or less in length.Switches are normally off. To
turn a switch on:echo 1 >
/proc/net/nf_condition/switch-nameTo turn it off again:echo 0 >
/proc/net/nf_condition/switch-nameSwitch settings are retained over shorewall
restart.Beginning with Shorewall 4.5.10, when the
switch-name is followed by
or , then the switch is
initialized to off or on respectively by the
start command. Other commands do not affect the
switch setting.ORIGINAL DEST (origdest) -
[-|address[,address]...[exclusion]|exclusion](Optional) Added in Shorewall 4.5.6. This column may be
included and may contain one or more addresses (host or network)
separated by commas. Address ranges are not allowed. When this
column is supplied, rules are generated that require that the
original destination address matches one of the listed addresses. It
is useful for specifying that SNAT should occur only for connections
that were acted on by a DNAT when they entered the firewall.ExamplesExample 1:You have a simple masquerading setup where eth0 connects to a
DSL or cable modem and eth1 connects to your local network with
subnet 192.168.0.0/24.Your entry in the file will be: #INTERFACE SOURCE
eth0 192.168.0.0/24Example 2:You add a router to your local network to connect subnet
192.168.1.0/24 which you also want to masquerade. You then add a
second entry for eth0 to this file: #INTERFACE SOURCE
eth0 192.168.1.0/24Example 3:You have an IPSEC tunnel through ipsec0 and you want to
masquerade packets coming from 192.168.1.0/24 but only if these
packets are destined for hosts in 10.1.1.0/24: #INTERFACE SOURCE
ipsec0:10.1.1.0/24 196.168.1.0/24Example 4:You want all outgoing traffic from 192.168.1.0/24 through eth0
to use source address 206.124.146.176 which is NOT the primary
address of eth0. You want 206.124.146.176 to be added to eth0 with
name eth0:0. #INTERFACE SOURCE ADDRESS
eth0:0 192.168.1.0/24 206.124.146.176Example 5:You want all outgoing SMTP traffic entering the firewall from
172.20.1.0/29 to be sent from eth0 with source IP address
206.124.146.177. You want all other outgoing traffic from
172.20.1.0/29 to be sent from eth0 with source IP address
206.124.146.176. #INTERFACE SOURCE ADDRESS PROTO PORT(S)
eth0 172.20.1.0/29 206.124.146.177 tcp smtp
eth0 172.20.1.0/29 206.124.146.176The order of the above two rules is significant!Example 6:Connections leaving on eth0 and destined to any host defined
in the ipset myset should have the source IP
address changed to 206.124.146.177. #INTERFACE SOURCE ADDRESS
eth0:+myset[dst] - 206.124.146.177Example 7:SNAT outgoing connections on eth0 from 192.168.1.0/24 in
round-robin fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9
(Shorewall 4.5.9 and later)./etc/shorewall/tcrules:
#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST
# PORT(S)
1-3:CF 192.168.1.0/24 eth0 ; state=NEW
/etc/shorewall/masq:
#INTERFACE SOURCE ADDRESS ...
eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C
eth0 192.168.1.0/24 1.1.1.3 ; mark=2:C
eth0 192.168.1.0/24 1.1.1.4 ; mark=3:CFILES/etc/shorewall/masqSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-exclusion(5), shorewall-hosts(5),
shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-nesting.xml 0000644 0001750 0001750 00000022064 12222401136 023202 0 ustar teastep teastep
shorewall-nesting5nestingShorewall Nested Zoneschild-zone[:parent-zone[,parent-zone]...]DescriptionIn shorewall-zones(5), a
zone may be declared to be a sub-zone of one or more other zones using the
above syntax. The child-zone may be neither the
firewall zone nor a vserver zone. The firewall zone may not appear as a
parent zone, although all vserver zones are handled as sub-zones of the
firewall zone.Where zones are nested, the CONTINUE policy in shorewall-policy(5) allows hosts that
are within multiple zones to be managed under the rules of all of these
zones.Example/etc/shorewall/zones: #ZONE TYPE OPTION
fw firewall
net ipv4
sam:net ipv4
loc ipv4/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS
- eth0 detect dhcp,norfc1918
loc eth1 detect/etc/shorewall/hosts: #ZONE HOST(S) OPTIONS
net eth0:0.0.0.0/0
sam eth0:206.191.149.197/etc/shorewall/policy: #SOURCE DEST POLICY LOG LEVEL
loc net ACCEPT
sam all CONTINUE
net all DROP info
all all REJECT infoThe second entry above says that when Sam is the client, connection
requests should first be processed 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). You can have this policy
generated for you automatically by using the IMPLICIT_CONTINUE option in
shorewall.conf(5).Partial /etc/shorewall/rules: #ACTION SOURCE DEST PROTO DEST PORT(S)
...
DNAT sam loc:192.168.1.3 tcp ssh
DNAT net loc:192.168.1.5 tcp www
...Given these two rules, Sam can connect to the firewall's internet
interface with ssh and the connection request will be forwarded to
192.168.1.3. Like all hosts in the net zone, Sam can connect to the
firewall's internet interface on TCP port 80 and the connection request
will be forwarded to 192.168.1.5. The order of the rules is not
significant. Sometimes it is necessary to suppress port forwarding for a
sub-zone. For example, suppose that all hosts can SSH to the firewall and
be forwarded to 192.168.1.5 EXCEPT Sam. When Sam connects to the
firewall's external IP, he should be connected to the firewall itself.
Because of the way that Netfilter is constructed, this requires two rules
as follows: #ACTION SOURCE DEST PROTO DEST PORT(S)
...
ACCEPT+ sam $FW tcp ssh
DNAT net loc:192.168.1.3 tcp ssh
...The first rule allows Sam SSH access to the firewall. The second
rule says that any clients from the net zone with the exception of those
in the “sam” zone should have their connection port forwarded to
192.168.1.3. If you need to exclude more than one zone, simply use
multiple ACCEPT+ rules. This technique also may be used when the ACTION is
REDIRECT.Care must be taken when nesting occurs as a result of the use of
wildcard interfaces (interface names ends in '+').Here's an example. /etc/shorewall/zones:/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS
net ppp0
loc eth1
loc ppp+
dmz eth2Because the net zone is declared before the loc zone, net is an
implicit sub-zone of loc and in the absence of a net->... CONTINUE
policy, traffic from the net zone will not be passed through loc->...
rules. But DNAT and REDIRECT rules are an exception!DNAT and REDIRECT rules generate two Netfilter rules: a 'nat'
table rule that rewrites the destination IP address and/or port
number, and a 'filter' table rule that ACCEPTs the rewritten
connection.Policies only affect the 'filter' table.As a consequence, the following rules will have unexpected
behavior: #ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT net dmz tcp 80
REDIRECT loc 3128 tcp 80The second rule is intended to redirect local web requests to a
proxy running on the firewall and listening on TCP port 3128. But the
'nat' part of that rule will cause all connection requests for TCP port 80
arriving on interface ppp+ (including ppp0!) to have their destination
port rewritten to 3128. Hence, the web server running in the DMZ will be
inaccessible from the web.The above problem can be corrected in several ways.The preferred way is to use the pppd option
to change the 'net' interface to something other than ppp0. That way, it
won't match ppp+.If you are running Shorewall version 4.1.4 or later, a second way is
to simply make the nested zones explicit: #ZONE TYPE OPTION
fw firewall
loc ipv4
net:loc ipv4
dmz ipv4If you take this approach, be sure to set IMPLICIT_CONTINUE=No in
shorewall.conf.When using other Shorewall versions, another way is to rewrite the
DNAT rule (assume that the local zone is entirely within
192.168.2.0/23): #ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT net dmz tcp 80
REDIRECT loc:192.168.2.0/23 3128 tcp 80Another way is to restrict the definition of the loc zone:/etc/shorewall/interfaces: #ZONE INTERFACE BROADCAST OPTIONS
net ppp0
loc eth1
- ppp+
dmz eth2/etc/shorewall/hosts: #ZONE HOST(S) OPTIONS
loc ppp+:192.168.2.0/23FILES/etc/shorewall/zones/etc/shorewall/interfaces/etc/shorewall/hosts/etc/shorewall/policy/etc/shorewall/rulesSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-interfaces.xml 0000644 0001750 0001750 00000111256 12222401136 023660 0 ustar teastep teastep
shorewall-interfaces5interfacesShorewall interfaces file/etc/shorewall/interfacesDescriptionThe interfaces file serves to define the firewall's network
interfaces to Shorewall. The order of entries in this file is not
significant in determining zone composition.Beginning with Shorewall 4.5.3, the interfaces file supports two
different formats:FORMAT 1 (default - deprecated)There is a BROADCAST column which can be used to specify the
broadcast address associated with the interface.FORMAT 2The BROADCAST column is omitted.The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is
the preferred form; the form without the '?' is deprecated.The columns in the file are as follows.ZONE -
zone-nameZone for this interface. Must match the name of a zone
declared in /etc/shorewall/zones. You may not list the firewall zone
in this column.If the interface serves multiple zones that will be defined in
the shorewall-hosts(5)
file, you should place "-" in this column.If there are multiple interfaces to the same zone, you must
list them in separate entries.Example:
#ZONE INTERFACE BROADCAST
loc eth1 -
loc eth2 -
INTERFACE -
interface[:port]Logical name of interface. Each interface may be listed only
once in this file. You may NOT specify the name of a "virtual"
interface (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18.
If the option is not specified, then the
logical name is also the name of the actual interface.You may use wildcards here by specifying a prefix followed by
the plus sign ("+"). For example, if you want to make an entry that
applies to all PPP interfaces, use 'ppp+'; that would match ppp0,
ppp1, ppp2, … Please note that the '+' means 'one or more additional characters' so 'ppp'
does not match 'ppp+'.When using Shorewall versions before 4.1.4, care must be
exercised when using wildcards where there is another zone that uses
a matching specific interface. See shorewall-nesting(5) for a
discussion of this problem.Shorewall allows '+' as an interface name.There is no need to define the loopback interface (lo) in this
file.If a port is given, then the
interface must have been defined
previously with the option. The OPTIONS
column may not contain the following options when a
port is given.arp_filterarp_ignorebridgelog_martiansmssoptionalproxyarprequiredroutefiltersourcerouteupnpwaitBeginning with Shorewall 4.5.17, if you specify a zone for the
'lo' interface, then that zone must be defined as type
in shorewall6-zones(5).BROADCAST (Optional) -
{-|detect|address[,address]...}Only available if FORMAT 1.If you use the special value detect, Shorewall will detect the broadcast
address(es) for you if your iptables and kernel include Address Type
Match support.If your iptables and/or kernel lack Address Type Match support
then you may list the broadcast address(es) for the network(s) to
which the interface belongs. For P-T-P interfaces, this column is
left blank. If the interface has multiple addresses on multiple
subnets then list the broadcast addresses as a comma-separated
list.If you don't want to give a value for this column but you want
to enter a value in the OPTIONS column, enter - in this column.OPTIONS (Optional) -
[option[,option]...]A comma-separated list of options from the following list. The
order in which you list the options is not significant but the list
should have no embedded white-space.arp_filter[={0|1}]If specified, this interface will only respond to ARP
who-has requests for IP addresses configured on the interface.
If not specified, the interface can respond to ARP who-has
requests for IP addresses on any of the firewall's interface.
The interface must be up when Shorewall is started.Only those interfaces with the
option will have their setting
changed; the value assigned to the setting will be the value
specified (if any) or 1 if no value is given.This option does not work with a wild-card
interface name (e.g., eth0.+) in
the INTERFACE column.arp_ignore[=number]If specified, this interface will respond to arp
requests based on the value of number
(defaults to 1).1 - reply only if the target IP address is local address
configured on the incoming interface2 - reply only if the target IP address is local address
configured on the incoming interface and the sender's IP
address is part from same subnet on this interface's
address3 - do not reply for local addresses configured with
scope host, only resolutions for global and link4-7 - reserved8 - do not reply for all local addressesThis option does not work with a wild-card
interface name (e.g., eth0.+) in
the INTERFACE column.Do not specify arp_ignore for any interface involved
in Proxy ARP.blacklistChecks packets arriving on this interface against the
shorewall-blacklist(5)
file.Beginning with Shorewall 4.4.13:If a zone is given in the
ZONES column, then the behavior is as if blacklist had been specified in the
IN_OPTIONS column of shorewall-zones(5).Otherwise, the option is ignored with a
warning:
WARNING: The 'blacklist'
option is ignored on multi-zone
interfaces
bridgeDesignates the interface as a bridge. Beginning with
Shorewall 4.4.7, setting this option also sets
.destonlyAdded in Shorewall 4.5.17. Causes the compiler to omit
rules to handle traffic from this interface.dhcpSpecify this option when any of the following are
true:the interface gets its IP address via DHCPthe interface is used by a DHCP server running on
the firewallthe interface has a static IP but is on a LAN
segment with lots of DHCP clients.the interface is a simple bridge with a
DHCP server on one port and DHCP clients on another
port.If you use Shorewall-perl for
firewall/bridging, then you need to include
DHCP-specific rules in shorewall-rules(8).
DHCP uses UDP ports 67 and 68.This option allows DHCP datagrams to enter and leave the
interface.ignore[=1]When specified, causes the generated script to ignore
up/down events from Shorewall-init for this device.
Additionally, the option exempts the interface from hairpin
filtering. When '=1' is omitted, the ZONE column must contain
'-' and must be the only
OPTION.Beginning with Shorewall 4.5.5, may be specified as
'' which only causes the generated
script to ignore up/down events from Shorewall-init; hairpin
filtering is still applied. In this case, the above
restrictions on the ZONE and OPTIONS columns are
lifted.logmartians[={0|1}]Turn on kernel martian logging (logging of packets with
impossible source addresses. It is strongly suggested that if
you set routefilter on an
interface that you also set logmartians. Even if you do not specify
the option, it is a good idea to
specify because your distribution
may have enabled route filtering without you knowing
it.Only those interfaces with the
option will have their setting
changed; the value assigned to the setting will be the value
specified (if any) or 1 if no value is given.To find out if route filtering is set on a given
interface, check the contents of
/proc/sys/net/ipv4/conf/interface/rp_filter
- a non-zero value indicates that route filtering is
enabled.Example: teastep@lists:~$ cat /proc/sys/net/ipv4/conf/eth0/rp_filter
1
teastep@lists:~$ This option does not work with a wild-card
interface name (e.g., eth0.+) in
the INTERFACE column.
This option may also be enabled globally in the shorewall.conf(5)
file.
maclistConnection requests from this interface are compared
against the contents of shorewall-maclist(5). If
this option is specified, the interface must be an Ethernet
NIC and must be up before Shorewall is started.mss=numberAdded in Shorewall 4.0.3. Causes forwarded TCP SYN
packets entering or leaving on this interface to have their
MSS field set to the specified
number.nets=(net[,...])Limit the zone named in the ZONE column to only the
listed networks. The parentheses may be omitted if only a
single net is given (e.g.,
nets=192.168.1.0/24). Limited broadcast to the zone is
supported. Beginning with Shorewall 4.4.1, multicast traffic
to the zone is also supported.nets=dynamicDefines the zone as dynamic.
Requires ipset match support in your iptables and kernel. See
http://www.shorewall.net/Dynamic.html
for further information.nosmurfsFilter packets for smurfs (packets with a broadcast
address as the source).Smurfs will be optionally logged based on the setting of
SMURF_LOG_LEVEL in shorewall.conf(5). After
logging, the packets are dropped.optionalWhen is specified for an
interface, Shorewall will be silent when:a /proc/sys/net/ipv4/conf/
entry for the interface cannot be modified (including for
proxy ARP).The first address of the interface cannot be
obtained.May not be specified with required.physical=nameAdded in Shorewall 4.4.4. When specified, the interface
or port name in the INTERFACE column is a logical name that
refers to the name given in this option. It is useful when you
want to specify the same wildcard port name on two or more
bridges. See http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple.If the interface name is a wildcard
name (ends with '+'), then the physical
name must also end in '+'.If is not specified, then it's
value defaults to the interface
name.proxyarp[={0|1}]Sets
/proc/sys/net/ipv4/conf/interface/proxy_arp.
Do NOT use this option if you are employing Proxy ARP through
entries in shorewall-proxyarp(5).
This option is intended solely for use with Proxy ARP
sub-networking as described at: http://tldp.org/HOWTO/Proxy-ARP-Subnet/index.html.
Note: This option does
not work with a wild-card interface
name (e.g., eth0.+) in the INTERFACE column.Only those interfaces with the
option will have their setting changed; the value assigned to
the setting will be the value specified (if any) or 1 if no
value is given.requiredAdded in Shorewall 4.4.10. If this option is set, the
firewall will fail to start if the interface is not usable.
May not be specified together with optional.routeback[={0|1}]If specified, indicates that Shorewall should include
rules that allow traffic arriving on this interface to be
routed back out that same interface. This option is also
required when you have used a wildcard in the INTERFACE column
if you want to allow traffic between the interfaces that match
the wildcard.Beginning with Shorewall 4.4.20, if you specify this
option, then you should also specify either
(see below) or
on all interfaces (see
below).Beginning with Shorewall 4.5.18, you may specify this
option to explicitly reset (e.g., routeback=0). This can be used to
override Shorewall's default setting for bridge devices which
is routeback=1.routefilter[={0|1|2}]Turn on kernel route filtering for this interface
(anti-spoofing measure).Only those interfaces with the
option will have their setting
changes; the value assigned to the setting will be the value
specified (if any) or 1 if no value is given.The value 2 is only available with Shorewall 4.4.5.1 and
later when the kernel version is 2.6.31 or later. It specifies
a loose form of reverse path
filtering.This option does not work with a wild-card
interface name (e.g., eth0.+) in
the INTERFACE column.This option can also be enabled globally via the
ROUTE_FILTER option in the shorewall.conf(5)
file.If ROUTE_FILTER=Yes in shorewall.conf(5), or if
your distribution sets net.ipv4.conf.all.rp_filter=1 in
/etc/sysctl.conf, then setting
routefilter=0 in an
interface entry will not disable
route filtering on that
interface! The effective setting
for an interface is the maximum
of the contents of
/proc/sys/net/ipv4/conf/all/rp_filter
and the routefilter setting specified in this file
(/proc/sys/net/ipv4/conf/interface/rp_filter).There are certain cases where
cannot be used on an
interface:If USE_DEFAULT_RT=Yes in shorewall.conf(5) and
the interface is listed in shorewall-providers(5).If there is an entry for the interface in shorewall-providers(5)
that doesn't specify the
option.If IPSEC is used to allow a road-warrior to have a
local address, then any interface through which the
road-warrior might connect cannot specify
.rpfilterAdded in Shorewall 4.5.7. This is an anti-spoofing
measure that requires the 'RPFilter Match' capability in your
iptables and kernel. It provides a more efficient alternative
to the option below. It performs a
function similar to (see above)
but works with Multi-ISP configurations that do now use
balanced routes.sfilter=(net[,...])Added in Shorewall 4.4.20. This option provides an
anti-spoofing alternative to on
interfaces where that option cannot be used, but where the
option is required (on a bridge,
for example). On these interfaces,
should list those local networks that are connected to the
firewall through other interfaces.sourceroute[={0|1}]If this option is not specified for an interface, then
source-routed packets will not be accepted from that interface
unless it has been explicitly enabled via sysconf. Only set
this option to 1 (enable source routing) if you know what you
are doing. This might represent a security risk and is usually
unneeded.Only those interfaces with the
option will have their setting
changed; the value assigned to the setting will be the value
specified (if any) or 1 if no value is given.This option does not work with a wild-card
interface name (e.g., eth0.+) in
the INTERFACE column.tcpflagsPackets arriving on this interface are checked for
certain illegal combinations of TCP flags. Packets found to
have such a combination of flags are handled according to the
setting of TCP_FLAGS_DISPOSITION after having been logged
according to the setting of TCP_FLAGS_LOG_LEVEL.unmanagedAdded in Shorewall 4.5.18. Causes all traffic between
the firewall and hosts on the interface to be accepted. When
this option is given:The ZONE column must contain '-'.Only the following other options are allowed with
unmanaged:arp_filterarp_ignoreignoreroutefilteroptionalphysicalroutefiltersourcerouteproxyndpupnpIncoming requests from this interface may be remapped
via UPNP (upnpd). See http://www.shorewall.net/UPnP.html.upnpclientThis option is intended for laptop users who always run
Shorewall on their system yet need to run UPnP-enabled client
apps such as Transmission (BitTorrent client). The option
causes Shorewall to detect the default gateway through the
interface and to accept UDP packets from that gateway. Note
that, like all aspects of UPnP, this is a security hole so use
this option at your own risk.wait=secondsAdded in Shorewall 4.4.10. Causes the generated script
to wait up to seconds seconds for the
interface to become usable before applying the required or optional options.ExampleExample 1:Suppose you have eth0 connected to a DSL modem and eth1
connected to your local network and that your local subnet is
192.168.1.0/24. The interface gets its IP address via DHCP from
subnet 206.191.149.192/27. You have a DMZ with subnet 192.168.2.0/24
using eth2. Your iptables and/or kernel do not support "Address Type
Match" and you prefer to specify broadcast addresses explicitly
rather than having Shorewall detect them.Your entries for this setup would look like:FORMAT 1
#ZONE INTERFACE BROADCAST OPTIONS
net eth0 206.191.149.223 dhcp
loc eth1 192.168.1.255
dmz eth2 192.168.2.255Example 2:The same configuration without specifying broadcast addresses
is:FORMAT 2
#ZONE INTERFACE OPTIONS
net eth0 dhcp
loc eth1
dmz eth2Example 3:You have a simple dial-in system with no Ethernet
connections.FORMAT 2
#ZONE INTERFACE OPTIONS
net ppp0 -Example 4 (Shorewall 4.4.9 and later):You have a bridge with no IP address and you want to allow
traffic through the bridge.FORMAT 2
#ZONE INTERFACE OPTIONS
- br0 routebackFILES/etc/shorewall/interfacesSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-maclist(5),
shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5),
shorewall-params(5), shorewall-policy(5), shorewall-providers(5),
shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5),
shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall.conf.xml 0000644 0001750 0001750 00000357403 12222401136 022471 0 ustar teastep teastep
shorewall.conf5shorewall.confShorewall global configuration file/etc/shorewall/shorewall.confDescriptionThis file sets options that apply to Shorewall as a whole.The file consists of Shell comments (lines beginning with '#'),
blank lines and assignment statements
(variable=value). If the
value contains shell meta characters or white-space,
then it must be enclosed in quotes. Example:
MACLIST_LOG_LEVEL="NFLOG(1,0,1)".OPTIONSMany options have as their value a log-level.
Log levels are a method of describing to syslog (8) the importance of a
message and a number of parameters in this file have log levels as their
value.These levels are defined by syslog and are used to determine the
destination of the messages through entries in /etc/syslog.conf (5). The
syslog documentation refers to these as "priorities"; Netfilter calls them
"levels" and Shorewall also uses that term.Valid levels are: 7 debug
6 info
5 notice
4 warning
3 err
2 crit
1 alert
0 emergFor most Shorewall logging, a level of 6 (info) is appropriate.
Shorewall log messages are generated by NetFilter and are logged using
facility 'kern' and the level that you specify. If you are unsure of the
level to choose, 6 (info) is a safe bet. You may specify levels by name or
by number.If you have built your kernel with ULOG and/or NFLOG target support,
you may also specify a log level of ULOG and/or NFLOG (must be all caps).
Rather than log its messages to syslogd, Shorewall will direct netfilter
to log the messages via the ULOG or NFLOG target which will send them to a
process called 'ulogd'. ulogd is available with most Linux distributions
(although it probably isn't installed by default). Ulogd is also available
from http://www.netfilter.org/projects/ulogd/index.html
and can be configured to log all Shorewall messages to their own log
file.Beginning with Shorewall 4.4.22, LOGMARK is also a valid level which
logs the packet's mark value along with the other usual information. The
syntax is:LOGMARK[(priority)]where priority is one of the levels
listed in the list above. If omitted, the default is info (6).The following options may be set in shorewall.conf.ACCEPT_DEFAULT={action[(parameters)][:level]|none}DROP_DEFAULT={action[(parameters)][:level]|none}NFQUEUE_DEFAULT={action[(parameters)][:level]|none}QUEUE_DEFAULT={action[(parameters)][:level]|none}REJECT_DEFAULT={action[(parameters)][:level]|none}In earlier Shorewall versions, a "default action" for DROP and
REJECT policies was specified in the file
/usr/share/shorewall/actions.std.In Shorewall 4.4.0, the DROP_DEFAULT, REJECT_DEFAULT,
ACCEPT_DEFAULT, QUEUE_DEFAULT and NFQUEUE_DEFAULT options were
added.DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other three are similar for ACCEPT,
QUEUE and NFQUEUE policies.The value applied to these may be:The default values are:DROP_DEFAULT="Drop"REJECT_DEFAULT="Reject"ACCEPT_DEFAULT="none"QUEUE_DEFAULT="none"NFQUEUE_DEFAULT="None"If you set the value of either option to "None" then no
default action will be used and the default action or macro must be
specified in shorewall-policy(5).You can pass parameters to the
specified action (e.g.,
myaction(audit,DROP)).Beginning with Shorewall 4.5.10, the action name can be
followed optionally by a colon and a log
level. The level will be applied to each
rule in the action or body that does not already have a log
level.ACCOUNTING=[Yes|No]Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
is enabled (see shorewall-accounting(5)). If
not specified or set to the empty value, ACCOUNTING=Yes is
assumed.ACCOUNTING_TABLE=[filter|mangle]Added in Shorewall 4.4.20. This setting determines which
Netfilter table the accounting rules are added in. By default,
ACCOUNTING_TABLE=filter is assumed. See also shorewall-accounting(5).ADD_IP_ALIASES=[Yes|No]This parameter determines whether Shorewall automatically adds
the external address(es) in shorewall-nat(5). 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.If this variable is not set or is given an empty value
(ADD_IP_ALIASES="") then ADD_IP_ALIASES=Yes is assumed.Addresses added by ADD_IP_ALIASES=Yes are deleted and
re-added during shorewall restart. As a consequence, connections
using those addresses may be severed.ADD_SNAT_ALIASES=[Yes|No]This parameter determines whether Shorewall automatically adds
the SNAT ADDRESS in shorewall-masq(5). 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.If this variable is not set or is given an empty value
(ADD_SNAT_ALIASES="") then ADD_SNAT_ALIASES=No is assumed.Addresses added by ADD_SNAT_ALIASES=Yes are deleted and
re-added during shorewall restart. As a consequence, connections
using those addresses may be severed.ADMINISABSENTMINDED=[Yes|No]The value of this variable affects Shorewall's stopped state.
When ADMINISABSENTMINDED=No, only traffic to/from those addresses
listed in shorewall-routestopped(5)
is accepted when Shorewall is stopped. When ADMINISABSENTMINDED=Yes,
in addition to traffic to/from addresses in shorewall-routestopped(5),
connections that were active when Shorewall stopped continue to work
and all new connections from the firewall system itself are allowed.
If this variable is not set or is given the empty value then
ADMINISABSENTMINDED=No is assumed.ARPTABLES=[pathname]Added in Shorewall 4.5.12. This parameter names the arptables
executable to be used by Shorewall. If not specified or if specified
as a null value, then the arptables executable located using the
PATH option is used.Regardless of how the arptables utility is located (specified
via arptables= or located via PATH), Shorewall uses the
arptables-restore and arptables-save utilities from that same
directory.AUTOCOMMENT=[Yes|No]Formerly named AUTO_COMMENT. If set, if there is not a current
comment when a macro is invoked, the behavior is as if the first
line of the macro file was "COMMENT <macro name>". The
AUTO_COMMENT option has a default value of 'Yes'.The setting of the AUTOMAKE option is ignored if the
start or restart command
includes a directory name (e.g., shorewall restart
/etc/shorewall.new).AUTOHELPERS=[Yes|No]Added in Shorewall 4.5.7. When set to
(the default), the generated ruleset will automatically associate
helpers with applications that require them (FTP, IRC, etc.). When
configuring your firewall on systems running kernel 3.5 or later, it
is recommended that you:Set AUTOHELPERS=No.Either:Modify shorewall-conntrack
(5) to only apply helpers where they are required; orSpecify the appropriate helper in the HELPER column in
shorewall-rules
(5).The macros for those applications requiring a helper
automatically specify the appropriate HELPER where
required.AUTOMAKE=[Yes|No]If set, the behavior of the 'start' command is changed; if no
files in /etc/shorewall have been changed since the last successful
start or restart command, then
the compilation step is skipped and the compiled script that
executed the last start or
restart command is used. The default is
AUTOMAKE=No.BLACKLIST=[{ALL|state[,...]}]where state is one of NEW, ESTABLISHED, RELATED, INVALID,or
UNTRACKED.Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY
option below. Specifies the connection tracking states that are to
be subject to blacklist screening. If neither BLACKLIST nor
BLACKLISTNEWONLY are specified then the states subject to
blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.ALL sends all packets through the blacklist chains.Note: The ESTABLISHED state may not be specified if FASTACCEPT
is specified.BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]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.A_DROP and A_REJECT are audited versions of DROP and REJECT
respectively and were added in Shorewall 4.4.20. They require
AUDIT_TARGET in the kernel and iptables.The BLACKLIST_DISPOSITION setting has no effect on entries in
the BLACKLIST section of shorewall-rules (5). It
determines the disposition of packets sent to the blacklog target of shorewall-blrules (5).BLACKLIST_LOG_LEVEL=[log-level]Formerly named BLACKLIST_LOGLEVEL. This parameter 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_LOG_LEVEL=debug). If you do not assign a
value or if you assign an empty value then packets from blacklisted
hosts are not logged. The setting determines the log level of
packets sent to the blacklog target
of shorewall-blrules(5).BLACKLISTNEWONLY={Yes|No}Deprecated in Shorewall 4.5.13 in favor of BLACKLIST
above.When set to Yes or yes, blacklists are only consulted for new
connections and for packets in the INVALID connection state (such as
TCP SYN,ACK when there has been no corresponding SYN). That includes
entries in the shorewall-blrules (5) file
and in the BLACKLIST section of shorewall-rules (5).When set to No or no, blacklists are consulted for every packet
(will slow down your firewall noticeably if you have large
blacklists). If the BLACKLISTNEWONLY option is not set or is set to
the empty value then BLACKLISTNEWONLY=No is assumed.BLACKLISTNEWONLY=No is incompatible with
FASTACCEPT=Yes.CHAIN_SCRIPTS={Yes|No}Added in Shorewall 4.5.16. Prior to the availability of BEGIN
PERL....END PERL in configuration files, the only way to execute a
chain-specific script was to create a script file with the same name
as the chain and place it in a directory on the CONFIG_PATH. That
facility has the drawback that the compiler will attempt to run a
non-script file just because it has the same name as a chain. To
disable this facility, set CHAIN_SCRIPTS=No. If not specified or
specified as the empty value, CHAIN_SCRIPTS=Yes is assumed.CLAMPMSS=[Yes|No|value]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.Important: This option
requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.You may also set CLAMPMSS to a numeric
value (e.g., CLAMPMSS=1400). This will set the
MSS field in TCP SYN packets going through the firewall to the
value that you specify.CLEAR_TC=[Yes|No]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 who 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 shorewall-tcrules(5). If not
specified, CLEAR_TC=Yes is assumed.COMPLETE=[Yes|No]Added in Shorewall 4.4.12. When you set this option to Yes,
you are asserting that the configuration is complete so that your
set of zones encompasses any hosts that can send or receive traffic
to/from/through the firewall. This causes Shorewall to omit the
rules that catch packets in which the source or destination IP
address is outside of any of your zones. Default is No. It is
recommended that this option only be set to Yes if:You have defined an interface whose effective physical
setting is '+'.That interface is assigned to a zone.You have no CONTINUE policies or rules.CONFIG_PATH=[directory[:directory]...]Specifies where configuration files other than shorewall.conf
may be found. CONFIG_PATH is specifies as a list of directory names
separated by colons (":"). When looking for a configuration file
other than shorewall.conf:If the command is "try" or a "<configuration
directory>" was specified in the command (e.g.,
shorewall check ./gateway) then the directory
given in the command is searched first.Next, each directory in the CONFIG_PATH setting is
searched in sequence.If CONFIG_PATH is not given or if it is set to the empty value
then the contents of /usr/share/shorewall/configpath are used. As
released from shorewall.net, that file sets the CONFIG_PATH to
/etc/shorewall:/usr/share/shorewall but your particular distribution
may set it differently. See the output of shorewall show config for
the default on your system.DEFER_DNS_RESOLUTION=[Yes|No]Added in Shorewall 4.5.12. When set to 'Yes' (the default),
DNS names are validated in the compiler and then passed on to the
generated script where they are resolved by iptables-restore. This
is an advantage if you use AUTOMAKE=Yes and the IP address
associated with the DNS name is subject to change. When
DEFER_DNS_RESOLUTION=No, DNS names are converted into IP addresses
by the compiler. This has the advantage that when AUTOMAKE=Yes, the
start and restart commands
will succeed even if no DNS server is reachable (assuming that the
configuration hasn't changed since the compiled script was last
generated).DELETE_THEN_ADD={Yes|No}If set to Yes (the default value), entries in the
/etc/shorewall/route_stopped files cause an 'ip rule del' command to
be generated in addition to an 'ip rule add' command. Setting this
option to No, causes the 'ip rule del' command to be omitted.DETECT_DNAT_IPADDRS=[Yes|No]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_IPADDRS=Yes” is assumed.DISABLE_IPV6=[Yes|No]If set to Yes or yes, IPv6 traffic to, from and through the
firewall system is disabled. If set to No or no,
Shorewall will take no action with respect to allowing or
disallowing IPv6 traffic. If not specified or empty,
“DISABLE_IPV6=No” is assumed.It is important to note that changing DISABLE_IPV6=Yes to
DISABLE_IPV6=No does not enable IPV6. The
recommended approach for enabling IPv6 on your system is:Install, configure and start Shorewall6.Change DISABLE_IPV6=Yes to DISABLE_IPV6=NoRestart ShorewallDONT_LOAD=[module[,module]...]Causes Shorewall to not load the listed kernel modules.DYNAMIC_BLACKLIST={Yes|No}Added in Shorewall 4.4.7. When set to No or no,
dynamic blacklisting using the shorewall drop,
shorewall reject, shorewall
logdrop and shorewall logreject is
disabled. Default is Yes.EXPAND_POLICIES={Yes|No}Normally, when the SOURCE or DEST columns in
shorewall-policy(5) contains 'all', a single policy chain is created
and the policy is enforced in that chain. For example, if the policy
entry is#SOURCE DEST POLICY LOG
# LEVEL
net all DROP infothen the chain name is 'net2all'
which is also the chain named in Shorewall log messages generated as
a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will
create a separate chain for each pair of zones covered by the
policy. This makes the resulting log messages easier to interpret
since the chain in the messages will have a name of the form 'a2b'
where 'a' is the SOURCE zone and 'b' is the DEST zone.EXPORTMODULES=[Yes|No]Added in Shorewall 4.4.17. When set to Yes when compiling for
use by Shorewall Lite (shorewall load,
shorewall reload or shorewall
export commands), the compiler will copy the modules or
helpers file from the administrative system into the script. When
set to No or not specified, the compiler will not copy the modules
or helpers file from /usr/share/shorewall but
will copy the found in another location on the CONFIG_PATH.When compiling for direct use by Shorewall, causes the
contents of the local module or helpers file to be copied into the
compiled script. When set to No or not set, the compiled script
reads the file itself.EXPORTPARAMS={Yes|No}Deprecated in Shorewall 4.4.17.Beginning with Shorewall 4.4.17, the variables set in the
'params' file at compile time are available at run time with
EXPORTPARAMS=No. As a consequence, beginning with that version the
recommended setting is EXPORTPARAMS=No.It is quite difficult to code a 'params' file that assigns
other than constant values such that it works correctly with
Shorewall Lite. The EXPORTPARAMS option works around this problem.
When EXPORTPARAMS=No, the 'params' file is not copied to the
compiler output.With EXPORTPARAMS=No, if you need to set environmental
variables on the firewall system for use by your extension scripts,
then do so in the init extension script.The default is EXPORTPARAMS=Yes which is the recommended
setting unless you are using Shorewall Lite.FASTACCEPT={Yes|No}Normally, Shorewall defers accepting ESTABLISHED/RELATED
packets until these packets reach the chain in which the original
connection was accepted. So for packets going from the 'loc' zone to
the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
'loc2net' chain.If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets
are accepted early in the INPUT, FORWARD and OUTPUT chains. If you
set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED
or RELATED sections of shorewall-rules(5).FASTACCEPT=Yes is incompatible with
BLACKLISTNEWONLY=No.FORWARD_CLEAR_MARK={Yes|No}Added in Shorewall 4.4.11 Beta 3. Traditionally, Shorewall has
cleared the packet mark in the first rule in the mangle FORWARD
chain. This behavior is maintained with the default setting of this
option (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to
'No', packet marks set in the mangle PREROUTING chain are retained
in the FORWARD chains.GEOIPDIR=[pathname]Added in Shorewall 4.5.4. Specifies the pathname of the
directory containing the GeoIP Match
database. See http://www.shorewall.net/ISO-3661.html.
If not specified, the default value is
/usr/share/xt_geoip/LE which is the default
location of the little-endian database.HELPERS=[helper[,helper...]]Added in Shorewall 4.5.7. This option lists the Netfilter
application helps that are to be enabled. If not specified, the
default is to enable all helpers.Possible values for helper
are:amandaftph323ircnetbios-nsnone - This special value
was added in Shorewall 4.5.16 and indicates that no helpers are
to be enabled. It also prevents the compiler for probing for
helper support; such probing generates messages on the system
log of the form "xt_CT: No such helper XXX" where XXX is the
helper name. When used, none
must be the only helper specified.pptpsanesipsnmptftpWhen HELPERS is specified on a system running Kernel 3.5.0 or
later, automatic association of helpers to connections is
disabled.HIGH_ROUTE_MARKS={Yes|No}Deprecated in Shorewall 4.4.26 in favor of
PROVIDER_OFFSET.Prior to version 3.2.0, it was not possible to use connection
marking in shorewall-tcrules(5) if you had
a multi-ISP configuration that uses the track option.You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the
packet mark and connection mark into two mark fields.The width of the fields are determined by the setting of
WIDE_TC_MARKS. If WIDE_TC_MARKS=No (the default):The MARK field in the providers file must have a value
that is less than 65536 and that is a multiple of 256 (using hex
representation, the values are 0x0100-0xFF00 with the low-order
8 bits being zero).You may only set those mark values in the PREROUTING
chain.Marks used for traffic shaping must still be in the range
of 1-255 and may still not be set in the PREROUTING
chain.When WIDE_TC_MARKS=Yes:The MARK field in the providers file must have a value
that is a multiple of 65536 (using hex representation, the
values are 0x010000-0xFF0000 with the low-order 16 bits being
zero).You may only set those mark values in the PREROUTING
chain.Marks used for traffic shaping must be in the range of
1-16383 and may still not be set in the PREROUTING chain.Regardless of the setting of WIDE_TC_MARKS, when you SAVE or
RESTORE in tcrules, only the TC mark value is saved or restored.
Shorewall handles saving and restoring the routing (provider)
marks.IGNOREUNKNOWNVARIABLES=[Yes|No]Added in Shorewall 4.5.11. Normally, if an unknown shell
variable is encountered in a configuration file (except in ?IF and
?ELSIF directives), the compiler raises a fatal error. If
IGNOREUNKNOWNVARIABLES is set to Yes, then such variables simply expand to an
empty string. Default is No.IMPLICIT_CONTINUE={Yes|No}When this option is set to Yes, it causes subzones to be treated
differently with respect to policies.Subzones are defined by following their name with ":" and a
list of parent zones (in shorewall-zones(5)). Normally,
you want to have a set of special rules for the subzone and if a
connection doesn't match any of those subzone-specific rules then
you want the parent zone rules and policies to be applied; see
shorewall-nesting(5).
With IMPLICIT_CONTINUE=Yes, that happens automatically.If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set,
then subzones are not subject to this special treatment. With
IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
by including an explicit policy (one that does not specify "all" in
either the SOURCE or the DEST columns).INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]Added in Shorewall 4.5.13. Shorewall has traditionally passed
INVALID packets through the NEW section of shorewall-rules (5). When a
packet in INVALID state fails to match any rule in the INVALID
section, the packet is disposed of based on this setting. The
default value is CONTINUE for compatibility with earlier
versions.INVALID_LOG_LEVEL=log-levelAdded in Shorewall 4.5.13. Packets in the INVALID state that
do not match any rule in the INVALID section of shorewall-rules (5) are
logged at this level. The default value is empty which means no
logging is performed.IP=[pathname]If specified, gives the pathname of the 'ip' executable. If
not specified, 'ip' is assumed and the utility will be located using
the current PATH setting.IP_FORWARDING=[On|Off|Keep]This parameter determines whether Shorewall enables or
disables IPV4 Packet Forwarding (/proc/sys/net/ipv4/ip_forward).
Possible values are:On or onpacket forwarding will be enabled.Off or offpacket forwarding will be disabled.Keep or keepShorewall 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.
IPSECFILE=zonesThis option indicates that zone-related ipsec information is
found in the zones file (shorewall-zones(5)). The option
indicates to the compiler that this is not a legacy configuration
where the ipsec information was contained in a separate file. The
value of this option must not be changed and the option must not be
deleted.IPSET=[pathname]If specified, gives the pathname of the 'ipset' executable. If
not specified, 'ipset' is assumed and the utility will be located
using the current PATH setting.IPSET_WARNINGS={Yes|No}Added in Shorewall 4.5.2. Default is Yes. When set, causes the
rules compiler to issue a warning when:The compiler is being run by root and an ipset specified
in the configuration does not exists. Only one warning is issued
for each missing ipset.When [src] is specified in a destination column and when
[dst] is specified in a source column.IPTABLES=[pathname]This parameter names the iptables executable to be used by
Shorewall. If not specified or if specified as a null value, then
the iptables executable located using the PATH option is
used.Regardless of how the iptables utility is located (specified
via IPTABLES= or located via PATH), Shorewall uses the
iptables-restore and iptables-save utilities from that same
directory.KEEP_RT_TABLES={Yes|No}When set to , this option prevents
generated scripts from altering the /etc/iproute2/rt_tables database
when there are entries in
/etc/shorewall/providers. If you set this
option to while Shorewall (Shorewall-lite) is
running, you should remove the file
/var/lib/shorewall/rt_tables
(/var/lib/shorewall-lite/rt_tables) before your
next stop, refresh,
restore on restart
command.The default is KEEP_RT_TABLES=No.LEGACY_FASTSTART={Yes|No}Added in Shorewall 4.4.20. If not specified, the default is
Yes which preserves the legacy behavior of start
-f (the modification times of the files in
/etc/shorewall are compare with that of
/var/lib/shorewall/restore). If set to No, then
the times are compared with that of /var/lib/shorewall/firewall,
which is consistent with the way that restart -f
works.LOAD_HELPERS_ONLY={Yes|No}Added in Shorewall 4.4.7. When set to Yes, restricts the set
of modules loaded by shorewall to those listed in
/var/lib/shorewall/helpers and those that are actually used. When
not set, or set to the empty value, LOAD_HELPERS_ONLY=No is
assumed.LOCKFILE=[pathname]Specifies the name of the Shorewall lock file, used to prevent
simultaneous state-changing commands. If not specified,
${VARDIR}/shorewall/lock is assumed (${VARDIR} is normally /var/lib
but can be changed when Shorewall-core is installed -- see the
output of shorewall show vardir).LOG_MARTIANS=[Yes|No|Keep]If set to Yes or yes, sets
/proc/sys/net/ipv4/conf/*/log_martians to 1
with the exception of
/proc/sys/net/ipv4/conf/all/log_martians which is set to
0. The default value is Yes which sets both of the above to one. If
you do not enable martian logging for all interfaces, you may still
enable it for individual interfaces using the logmartians interface option in shorewall-interfaces(5).The value Keep causes
Shorewall to ignore the option. If the option is set to Yes, then martians are logged on all
interfaces. If the option is set to No, then martian logging is disabled on all
interfaces except those specified in shorewall-interfaces(5).LOG_VERBOSITY=[number]This option controls the amount of information logged to the
file specified in the STARTUP_LOG option.Values are:-1 - Logging is disabled0 - Silent. Only error messages are logged.1 - Major progress messages logged.2 - All progress messages loggedIf not specified, then -1 is assumed.LOGALLNEW=[log-level]This option is intended for use as a debugging aid. When set
to a log level, this option causes Shorewall to generate a logging
rule as the first rule in each builtin chain.The table name is used as the chain name in the log
prefix.The chain name is used as the target in the log
prefix.
For example, using the default LOGFORMAT, the log prefix for
logging from the nat table's PREROUTING chain is: Shorewall:nat:PREROUTING
To help insure that all packets in the NEW state are
logged, rate limiting (LOGBURST and LOGRATE) should be disabled
when using LOGALLNEW. Use LOGALLNEW at your own risk; it may
cause high CPU and disk utilization and you may not be able to
control your firewall after you enable this option.Do not use this option if the resulting log messages will
be sent to another system.
LOGFILE=[pathname]This parameter tells the /sbin/shorewall program where to look
for Shorewall messages when processing the dump, logwatch, show
log, and hits commands.
If not assigned or if assigned an empty value, /var/log/messages is
assumed. For further information, see http://www.shorewall.net/shorewall_logging.html.LOGFORMAT=["formattemplate"]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, 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.The setting of LOGFORMAT has an effect of the permitted
length of zone names. See shorewall-zones (5).LOGLIMIT=[[{s|d}:]rate/{sec|min|hour|day}[:burst]]Added in Shorewall 4.4.12. Limits the logging rate, either
overall, or by source or destination IP address.If the value starts with 's:' then logging is limited per
source IP. If the value starts with 'd:', then logging is limited
per destination IP. Otherwise, the overall logging rate is
limited.If burst is not specified, then a
value of 5 is assumed.LOGBURST=[burst]Deprecated in Shorewall 4.4.12.LOGRATE=[rate/{minute|second}]Deprecated in Shorewall 4.4.12. These options are ignored when
LOGLIMIT is specified.These parameters set the match rate and initial burst size for
logged packets. Please see iptables(8) 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. If you supply one of
these, then you should also supply the other.Example: LOGRATE=10/minute
LOGBURST=5For each logging rule, the first time the rule is reached, the
packet will be logged; in fact, since the burst is 5, the first five
packets will be logged. After this, it will be 6 seconds (1 minute
divided by the rate of 10) before a message will be logged from the
rule, regardless of how many packets reach it. Also, every 6
seconds, one of the bursts will be regained; if no packets hit the
rule for 30 seconds, the burst will be fully recharged; back where
we started.LOGTAGONLY=[Yes|No]Using the default LOGFORMAT, chain names may not exceed 11
characters or truncation of the log prefix may occur. Longer chain
names may be used with log tags if you set LOGTAGONLY=Yes. With
LOGTAGONLY=Yes, if a log tag is specified then the tag is included
in the log prefix in place of the chain name.Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have
more control over the generated log prefix. Beginning with that
release, the tag is interpreted as a chain
name and a disposition
separated by a comma. So this rule:#ACTION SOURCE DEST
LOG:info:foo,bar net fwwould generate the following log prefix when using the default
LOGFORMAT setting:Shorewall:foo:bar:Similarly,#ACTION SOURCE DEST
LOG:info:,bar net fwwould generateShorewall:net2fw:bar:MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]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.A_DROP and A_REJECT are audited versions of DROP and REJECT
respectively and were added in Shorewall 4.4.20. They require
AUDIT_TARGET in the kernel and iptables.MACLIST_LOG_LEVEL=[log-level]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="").MACLIST_TABLE=[filter|mangle]Normally, MAC verification occurs in the filter table (INPUT
and FORWARD) chains. When forwarding a packet from an interface with
MAC verification to a bridge interface, that doesn't work.This problem can be worked around by setting
MACLIST_TABLE=mangle which will cause Mac verification to occur out
of the PREROUTING chain. Because REJECT isn't available in that
environment, you may not specify MACLIST_DISPOSITION=REJECT or
MACLIST_DISPOSITION=A_REJECT with MACLIST_TABLE=mangle.MACLIST_TTL=[number]The performance of configurations with a large numbers of
entries in shorewall-maclist(5) can be
improved by setting the MACLIST_TTL variable in shorewall.conf(5).If your iptables and kernel support the "Recent Match" (see
the output of "shorewall check" near the top), you can cache the
results of a 'maclist' file lookup and thus reduce the overhead
associated with MAC Verification.When a new connection arrives from a 'maclist' interface, the
packet passes through then list of entries for that interface in
shorewall-maclist(5). If
there is a match then the source IP address is added to the 'Recent'
set for that interface. Subsequent connection attempts from that IP
address occurring within $MACLIST_TTL seconds will be accepted
without having to scan all of the entries. After $MACLIST_TTL from
the first accepted connection request from an IP address, the next
connection request from that IP address will be checked against the
entire list.If MACLIST_TTL is not specified or is specified as empty (e.g,
MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
not be cached).MANGLE_ENABLED=[Yes|No]Determines whether Shorewall will generate rules in the
Netfilter mangle table. Setting MANGLE_ENABLED=No disables all
Shorewall features that require the mangle table. The default is
MANGLE_ENABLED=Yes.MAPOLDACTIONS=[Yes|No]This option is included for compatibility with old Shorewall
configuration. New installs should always have
MAPOLDACTIONS=No.MARK_IN_FORWARD_CHAIN=[Yes|No]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 DNAT is 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.MASK_BITS=[number]Added in Shorewall 4.4.26. Number of bits on the right of the
32-bit packet mark to be masked when clearing the traffic shaping
mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if
PROVIDER_OFFSET > 0). Default value and the default values of the
other mark layout options is determined as follows:
MODULE_SUFFIX=["extension ..."]The value of this option determines the possible file
extensions of kernel modules. The default value is "ko ko.gz o o.gz
gz".MODULESDIR=[pathname[:pathname]...]This parameter specifies the directory/directories 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" in versions of Shorewall prior to
3.2.4 and "/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter:/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter" in later versions.MULTICAST=[Yes|No]This option will normally be set to 'No' (the default). It
should be set to 'Yes' under the following circumstances:You have an interface that has parallel zones defined via
/etc/shorewall/hosts.You want to forward multicast packets to two or more of
those parallel zones.In such cases, you will configure a
network on each zone receiving multicasts.MUTEX_TIMEOUT=[seconds]The value of this variable determines the number of seconds
that programs will wait for exclusive access to the Shorewall lock
file. After the number of seconds corresponding to the value of this
variable, programs will assume that the last program to hold the
lock died without releasing the lock.If not set or set to the empty value, a value of 60 (60
seconds) is assumed.An appropriate value for this parameter would be twice the
length of time that it takes your firewall system to process a
shorewall restart command.NFACCT=[pathname]Added in Shorewall 4.5.7. Specifies the pathname of the nfacct
utility. If not specified, Shorewall will use the PATH setting to
find the program.NULL_ROUTE_RFC1918=[Yes|No|blackhole|unreachable|prohibit]When set to Yes, causes Shorewall to null-route the IPv4
address ranges reserved by RFC1918. The default value is
'No'.When combined with route filtering (ROUTE_FILTER=Yes or
in shorewall-interfaces(5)),
this option ensures that packets with an RFC1918 source address are
only accepted from interfaces having known routes to networks using
such addresses.Beginning with Shorewall 4.5.15, you may specify
, or
to set the type of route to be created.
See http://www.shorewall.net/MultiISP.html#null_routing.OPTIMIZE=[value]The specified value enables certain
optimizations. Each optimization category is associated with a power
of two. To enable multiple optimization categories, simply add their
corresponding numbers together.Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All
to enable all optimization categories, and you may also specify
OPTIMIZE=None to disable optimization.Optimization category 1 - Traditionally, Shorewall has
created rules for the complete matrix of
host groups defined by the zones, interfaces and hosts
files. Any traffic that didn't correspond to an element
of that matrix was rejected in one of the built-in chains. When
the matrix is sparse, this results in lots of largely useless
rules.These extra rules can be eliminated by setting the 1 bit
in OPTIMIZE.The 1 bit setting also controls the suppression of
redundant wildcard rules (those specifying "all" in the SOURCE
or DEST column). A wildcard rule is considered to be redundant
when it has the same ACTION and Log Level as the applicable
policy.Optimization level 1 is ignored when optimization level
4 is also selected, since level 4 performs similar
optimizations in a more robust way.Optimization category 2 - Added in Shorewall 4.4.7. When
set, suppresses superfluous ACCEPT rules in a policy chain that
implements an ACCEPT policy. Any ACCEPT rules that immediately
precede the final blanket ACCEPT rule in the chain are now
omitted.Optimization category 4 - Added in Shorewall 4.4.7. When
set, causes short chains (those with less than 2 rules) to be
optimized away. The following chains are excluded from
optimization:accounting chains (unless
OPTIMIZE_ACCOUNTING=Yes)action chains (user-defined)'blacklst' chaindynamicforwardUPnPUPnP (nat table)Additionally:If a built-in chain has a single rule that branches to
a second chain, then the rules from the second chain are
moved to the built-in chain and the target chain is
omitted.Chains with no references are deleted.Accounting chains are subject to optimization if the
OPTIMIZE_ACCOUNTING option is set to 'Yes'.If a chain ends with an unconditional branch to a
second chain (other than to 'reject'), then the branch is
deleted from the first chain and the rules from the second
chain are appended to it.An additional optimization was added in Shorewall 4.5.4.
If the last rule in a chain is an unqualified jump to a simple
target, then all immediately preceding rules with the same
simple target are omitted.For example, consider this chain: -A fw-net -p udp --dport 67:68 -j ACCEPT
-A fw-net -p udp --sport 1194 -j ACCEPT
-A fw-net -p 41 -j ACCEPT
-A fw-net -j ACCEPT
Since all of the rules are jumps to the simple target
ACCEPT, this chain is totally optimized away and jumps to the
chain are replace with jumps to ACCEPT.Optimization category 8 - Added in Shorewall 4.4.9. When
set, causes chains with identical rules to be collapsed into a
single chain.Optimization category 16 - Added in Shorewall 4.4.26. When
set, causes sequences of compatible rules
to be combined into a single rule. Rules are considered
compatible if they differ only in their destination ports and
comments.A sequence of compatible rules is often generated when
macros are invoked in sequence.The ability to combine adjacent rules is limited by two
factors:Destination port lists may only be combined up to a
maximum of 15 ports, where a port-pair counts as two
ports.Rules may only be combined until the length of their
concatenated comment reaches 255 characters.When either of these limits would be exceeded, the current
combined rule is emitted and the compiler attempts to combine
rules beginning with the one that would have exceeded the limit.
Adjacent combined comments are separated by ', '. Empty comments
at the front of a group of combined comments are replaced by
'Others and'. Empty comments at the end of a group of combined
comments are replaced by 'and others'.Beginning in Shorewall 4.5.10, this option also suppresses
duplicate adjacent rules and duplicate non-adjacent rules that
don't include mark, connmark, dscp, ecn, set, tos
or u32 matches.Example 1:Rules with comments "FOO", <empty> and "BAR"
would result in the combined comment "FOO and others,
BAR".Example 2:Rules with comments <empty>, "FOO" and "BAR"
would result in the combined comment "Others and FOO,
BAR". Note: Optimize level 16 requires "Extended
Multi-port Match" in your iptables and kernel.The default value is zero which disables all
optimizations.OPTIMIZE_ACCOUNTING=[Yes|No]Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
assumed.PATH=pathname[:pathname]...Determines the order in which Shorewall searches directories
for executable files.PERL=pathnameAdded in Shorewall 4.4.11 RC1. Specifies the path name of the
Perl executable. Default is /usr/bin/perl. If
the pathname specified by this option does not exist or the named
file is not executable, then Shorewall falls back to
/usr/bin/perl/PROVIDER_BITS=[number]Added in Shorewall 4.4.26. The number of bits in the 32-bit
packet mark to be used for provider numbers. May be zero. See MASK_BITS above for default value.PROVIDER_OFFSET=[number]IfAdded in Shorewall 4.4.26. The offset from the right
(low-order end) of the provider number field in the 32-bit packet
mark. If non-zero, must be >= TC_BITS (Shorewall automatically
adjusts PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS +
ZONE_BITS must be < 32. See MASK_BITS above for default value.RCP_COMMAND="command"RSH_COMMAND="command"Earlier generations of Shorewall Lite required that remote
root login via ssh be enabled in order to use the
load and reload commands.
Beginning with release 3.9.5, you may define an alternative means
for accessing the remote firewall system. In that release, two new
options were added to shorewall.conf:RSH_COMMANDRCP_COMMANDThe default values for these are as
follows:RSH_COMMAND: ssh ${root}@${system} ${command}RCP_COMMAND: scp ${files}
${root}@${system}:${destination}Shell variables that will be set when the commands
are invoked are as follows:root - root user. Normally
but may be overridden using the '-r'
option.system - The name/IP address
of the remote firewall system.command - For RSH_COMMAND,
the command to be executed on the firewall system.files - For RCP_COMMAND, a
space-separated list of files to be copied to the remote
firewall system.destination - The directory
on the remote system that the files are to be copied
into.RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]Added in Shorewall 4.4.27. Shorewall has traditionally
ACCEPTed RELATED packets that don't match any rule in the RELATED
section of shorewall-rules
(5). Concern about the safety of this practice resulted in the
addition of this option. When a packet in RELATED state fails to
match any rule in the RELATED section, the packet is disposed of
based on this setting. The default value is ACCEPT for compatibility
with earlier versions.RELATED_LOG_LEVEL=log-levelAdded in Shorewall 4.4.27. Packets in the related state that
do not match any rule in the RELATED section of shorewall-rules (5) are logged at
this level. The default value is empty which means no logging is
performed.REJECT_ACTION=actionAdded in Shorewall 4.5.21. When a REJECT target is specified,
Shorewall normally handles the response as follows:If the destination address of the packet is a broadcast or
multicast address, the packet is dropped.if the protocol is ICMP (2) then the packet is
dropped.if the protocol is TCP (6) then the packet is rejected
with an RST.if the protocol is UDP (17) then the packet is rejected
with an 'port-unreachable' ICMP (ICMP6).if the protocol is ICMP (1) then the packet is rejected
with a 'host-unreachable' ICMP.otherwise, the packet is rejected with a 'host-prohibited'
ICMP.You can modify this behavior by implementing your own
action that handles REJECT and specifying
it's name in this option. The nolog
and inline options will
automatically be assumed for the specified
action.The following action implements the standard behavior:?format 2
#TARGET SOURCE DEST PROTO
Broadcast(DROP) - - -
DROP - - 2
INLINE - - 6 ; -j REJECT --reject-with tcp-reset
?if __ENHANCED_REJECT
INLINE - - 17 ; -j REJECT
?if __IPV4
INLINE - - 1 ; -j REJECT --reject-with icmp-host-unreachable
INLINE - - - ; -j REJECT --reject-with icmp-host-prohibited
?else
INLINE - - 58 ; -j REJECT --reject-with icmp6-addr-unreachable
INLINE - - - ; -j REJECT --reject-with icmp6-adm-prohibited
?endif
?else
INLINE - - - ; -j REJECT
?endifREQUIRE_INTERFACE=[Yes|No]Added in Shorewall 4.4.10. The default is No. If set to Yes,
at least one optional interface must be up in order for the firewall
to be in the started state. Intended to be used with the Shorewall Init Package.RESTORE_DEFAULT_ROUTE=[Yes|No]This option determines whether to restore the default route
saved when here are 'balance' providers defined but all of them are
down.The default is RESTORE_DEFAULT_ROUTE=Yes which preserves the
pre-4.2.6 behavior.RESTORE_DEFAULT_ROUTE=No is appropriate when you don't want a
default route in the main table (USE_DEFAULT_RT=No) or in the
default table (USE_DEFAULT_RT=Yes) when there are no balance
providers available. In that case, RESTORE_DEFAULT_ROUTE=No will
cause any default route in the relevant table to be deleted.RESTORE_ROUTEMARKS=[Yes|No]Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
restored unconditionally at the top of the mangle OUTPUT and
PREROUTING chains, even if the saved mark is zero. When this option
is set to No, the mark is restored
even when it is zero. If you have problems with IPSEC ESP packets
not being routed correctly on output, try setting this option to
No.RESTOREFILE=filenameSpecifies the simple name of a file in /var/lib/shorewall to
be used as the default restore script in the shorewall save, shorewall restore, shorewall forget and shorewall -f start commands.RETAIN_ALIASES={Yes|No}During shorewall start, IP
addresses to be added as a consequence of ADD_IP_ALIASES=Yes and
ADD_SNAT_ALIASES=Yes are quietly deleted when shorewall-nat(5) and shorewall-masq(5) are processed
then are re-added later. This is done to help ensure that the
addresses can be added with the specified labels but can have the
undesirable side effect of causing routes to be quietly deleted.
When RETAIN_ALIASES is set to Yes, existing addresses will not be
deleted. Regardless of the setting of RETAIN_ALIASES, addresses
added during shorewall start are
still deleted at a subsequent shorewall
stop or shorewall
restart.ROUTE_FILTER=[Yes|No|Keep]If this parameter is given the value Yes or yes
then route filtering (anti-spoofing) is enabled on all network
interfaces which are brought up while Shorewall is in the started
state. The default value is no.The value Keep causes
Shorewall to ignore the option. If the option is set to Yes, then route filtering occurs on all
interfaces. If the option is set to No, then route filtering is disabled on all
interfaces except those specified in shorewall-interfaces(5).If you need to disable route filtering on any interface,
then you must set ROUTE_FILTER=No then set routefilter=1 or
routefilter=2 on those interfaces where you want route filtering.
See shorewall-interfaces(5)
for additional details.RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]Added in Shorewall 4.5.7. Determines the disposition of
packets entering from interfaces the
option (see shorewall-interfaces(5)).
Packets disposed of by this option are those whose response packets
would not be sent through the same interface receiving the
packet.RPFILTER_LOG_LEVEL=log-levelAdded in shorewall 4.5.7. Determines the logging of packets
disposed via the RPFILTER_DISPOSITION. The default value is
.SAVE_ARPTABLES={Yes|No}Added in Shorewall 4.5.12. If SAVE_ARPTABLES=Yes, then the
current arptables contents will be saved by shorewall save command and restored by
shorewall restore command. Default
value is No.SAVE_IPSETS={Yes|No}Re-enabled in Shorewall 4.4.6. If SAVE_IPSETS=Yes, then the
current contents of your ipsets will be saved by the shorewall stop and shorewall save commands and restored by the
shorewall start and shorewall restore commands.SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]Added in Shorewall 4.4.20. Determines the disposition of
packets matching the option (see shorewall-interfaces(5)) and
of hairpin packets on interfaces without the
option.Hairpin packets are packets that are routed out of the
same interface that they arrived on. interfaces without the routeback option.SFILTER_LOG_LEVEL=log-levelAdded on Shorewall 4.4.20. Determines the logging of packets
matching the option (see shorewall-interfaces(5)) and
of hairpin packets on interfaces without the
option.Hairpin packets are packets that are routed out of the
same interface that they arrived on. interfaces without the routeback option. The default
is . If you don't wish for these packets to be
logged, use SFILTER_LOG_LEVEL=none.SHOREWALL_SHELL=[pathname]This option is used to specify the shell program to be used to
run the Shorewall compiler and to interpret the compiled script. If
not specified or specified as a null value, /bin/sh is assumed.
Using a light-weight shell such as ash or dash can significantly
improve performance.SMURF_DISPOSITION=[DROP|A_DROP]Added in Shorewall 4.4.20. The default setting is DROP which
causes smurf packets (see the nosmurfs option in shorewall-interfaces(5)) to
be dropped. A_DROP causes the packets to be audited prior to being
dropped and requires AUDIT_TARGET support in the kernel and
iptables.SMURF_LOG_LEVEL=[log-level]Specifies the logging level for smurf packets (see the
nosmurfs option in shorewall-interfaces(5)). If
set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not
logged.STARTUP_ENABLED={Yes|No}Determines if Shorewall is allowed to start. As released from
shorewall.net, this option is set to No. When set to Yes or yes,
Shorewall may be started. Used as a guard against Shorewall being
accidentally started before it has been configured.STARTUP_LOG=[pathname]If specified, determines where Shorewall will log the details
of each start, restart and refresh command. Logging verbosity is
determined by the setting of LOG_VERBOSITY above.SUBSYSLOCK=[pathname]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 and OpenSuSE, this
should be set to /var/lock/subsys/shorewall. For Debian, the value
is /var/lock/shorewall and in LEAF it is /var/run/shorewall.TC=[pathname]If specified, gives the pathname of the 'tc' executable. If
not specified, 'tc' is assumed and the utility will be located using
the current PATH setting.TC_BITS=[number]The number of bits at the low end of the 32-bit packet mark to
be used for traffic shaping marking. May be zero. See MASK_BITS above for default value.TC_ENABLED=[Yes|No|Internal|Simple|Shared]If you say Yes or yes here, Shorewall will use a script that
you supply to configure traffic shaping. The script must be named
'tcstart' and must be placed in a directory on your
CONFIG_PATH.If you say No or no then traffic shaping is not
enabled.If you set TC_ENABLED=Simple (Shorewall 4.4.6 and later),
simple traffic shaping using shorewall-tcinterfaces(5)
and shorewall-tcpri(5) is
enabled.If you set TC_ENABLED=Internal or internal or leave the option
empty then Shorewall will use its builtin traffic shaper
(tc4shorewall written by Arne Bernin.Beginning with Shorewall 4.4.15, you can set
TC_ENABLED=Shared. This allows you to configure the tcdevices and
tcclasses in your Shorewall6 configuration yet make them available
to the compiler when compiling your Shorewall configuration. In
addition to setting TC_ENABLED=Shared, you need to create symbolic
links from your Shorewall configuration directory (normally
/etc/shorewall/) to the tcdevices and tcclasses files in your
Shorewall6 configuration directory (normally
/etc/shorewall6/).TC_EXPERT={Yes|No}Normally, Shorewall tries to protect users from themselves by
preventing PREROUTING and OUTPUT tcrules from being applied to
packets that have been marked by the 'track' option in shorewall-providers(5).If you know what you are doing, you can set TC_EXPERT=Yes and
Shorewall will not include these cautionary checks.TC_PRIOMAP=mapAdded in Shorewall 4.4.6. Determines the mapping of a packet's
TOS field to priority bands. See shorewall-tcpri(5). The
map consists of 16 space-separated digits with
values 1, 2 or 3. A value of 1 corresponds to Linux priority 0, 2 to
Linux priority 1, and 3 to Linux Priority 2. The first entry gives
the priority of TOS value 0, the second of TOS value 1, and so on.
See tc-prio(8) for additional information.The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2
2 2".TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]Determines the disposition of TCP packets that fail the checks
enabled by the tcpflags interface
option (see shorewall-interfaces(5)) 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.A_DROP and A_REJECT are audited versions of DROP and REJECT
respectively and were added in Shorewall 4.4.20. They require
AUDIT_TARGET in the kernel and iptables.TCP_FLAGS_LOG_LEVEL=[log-level]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="").TRACK_PROVIDERS={Yes|No}Added in Shorewall 4.4.3. When set to Yes, causes the
option to be assumed on all providers defined
in shorewall-providers(5). May
be overridden on an individual provider through use of the
option. The default value is 'No'.Beginning in Shorewall 4.4.6, setting this option to 'Yes'
also simplifies PREROUTING rules in shorewall-tcrules(5).
Previously, when TC_EXPERT=No, packets arriving through 'tracked'
provider interfaces were unconditionally passed to the PREROUTING
tcrules. This was done so that tcrules could reset the packet mark
to zero, thus allowing the packet to be routed using the 'main'
routing table. Using the main table allowed dynamic routes (such as
those added for VPNs) to be effective. The rtrules file was created
to provide a better alternative to clearing the packet mark. As a
consequence, passing these packets to PREROUTING complicates things
without providing any real benefit. Beginning with Shorewall 4.4.6,
when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving through
'tracked' interfaces will not be passed to the PREROUTING rules.
Since TRACK_PROVIDERS was just introduced in 4.4.3, this change
should be transparent to most, if not all, users.TRACK_RULES={Yes|No}Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a comment to
iptables rules to indicate the file name and line number of the
configuration entry that generated the rule. If set to No (the default), then no such comments are
added.Setting this option to Yes
requires the Comments capability in iptables
and kernel.UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]Added in Shorewall 4.5.13. Shorewall has traditionally passed
UNTRACKED packets through the NEW section of shorewall-rules (5). When a
packet in UNTRACKED state fails to match any rule in the UNTRACKED
section, the packet is disposed of based on this setting. The
default value is CONTINUE for compatibility with earlier
versions.UNTRACKED_LOG_LEVEL=log-levelAdded in Shorewall 4.5.13. Packets in the UNTRACKED state that
do not match any rule in the UNTRACKED section of shorewall-rules (5) are logged at
this level. The default value is empty which means no logging is
performed.USE_DEFAULT_RT=[Yes|No]When set to 'Yes', this option causes the Shorewall multi-ISP
feature to create a different set of routing rules which are
resilient to changes in the main routing table. Such changes can
occur for a number of reasons, VPNs going up and down being an
example. The idea is to send packets through the main table prior to
applying any of the Shorewall-generated routing rules. So changes to
the main table will affect the routing of packets by default.When USE_DEFAULT_RT=Yes:Both the DUPLICATE and the COPY columns in providers(5) file must
remain empty (or contain "-").The default route is added to the the 'default' table
rather than to the main table.balance is assumed unless
loose is specified.Packets are sent through the main routing table by a rule
with priority 999. In routing_rules(5), the
range 1-998 may be used for inserting rules that bypass the main
table.All provider gateways must be specified explicitly in the
GATEWAY column. detect may not
be specified.detect may be
specified for interfaces whose configuration is managed by
dhcpcd. Shorewall will use dhcpcd's database to find the
interface's gateway.You should disable all default route management outside of
Shorewall. If a default route is added to the main table while
Shorewall is started, then all policy routing will stop working
(except for those routing rules in the priority range
1-998).If USE_DEFAULT_RT is not set or if it is set to the empty
string then USE_DEFAULT_RT=No is assumed.USE_PHYSICAL_NAMES=[Yes|No]Added in Shorewall 4.4.27. Normally, when Shorewall creates a
Netfilter chain that relates to an interface, it uses the
interface's logical name as the base of the chain name. For example,
if the logical name for an interface is OAKLAND, then the input
chain for traffic arriving on that interface would be 'OAKLAND_in'.
If this option is set to Yes, then the physical name of the
interface will be used the base of the chain name.USE_RT_NAMES=[Yes|No]Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will
use routing table (provider) names in the generated script rather
than table numbers. When set to 'No' (the default), routing table
numbers will be used.If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you
must insure that all of your providers have entries in
/etc/iproute2/rt_tables as well as the following entries:255 local254 main253 default250 balance0 unspecWithout these entries, the firewall will fail to
start.VERBOSITY=[number]Shorewall has traditionally been very noisy (produced lots of
output). You may set the default level of verbosity using the
VERBOSITY OPTION.Values are:0 - Silent. You may make it more verbose using the -v
option1 - Major progress messages displayed2 - All progress messages displayed (pre Shorewall-3.2.0
behavior)If not specified, then 2 is assumed.WARNOLDCAPVERSION=[Yes|No]Added in Shorewall 4.5.12. When set to Yes (the default), the compiler issues a
warning when it finds a capabilities file that doesn't specify all
of the capabilities supported by the compiler. When
WARNOLDCAPVERSION is set to No, no
warning is issued.WIDE_TC_MARKS={Yes|No}Deprecated in Shorewall 4.4.26 in favor of TC_BITS and
MASK_BITS.When set to No (the default), traffic shaping marks are 8
bytes wide (possible values are 1-255). When WIDE_TC_MARKS=Yes,
traffic shaping marks are 14 bytes wide (values 1-16383). The
setting of WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS
option (see above).ZONE_BITS=[number]Added in Shorewall 4.4.26. When non-zero, enables automatic
packet marking by source zone and determines the number of bits in
the 32-bit packet mark to be used for the zone mark. Default value
is 0.ZONE2ZONE={|}Added in Shorewall 4.4.4. This option determines how Shorewall
constructs chain names involving zone names and/or 'all'. The
default is '2' (e.g., fw2net).FILES/etc/shorewall/shorewall.confSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcinterfaces(5),
shorewall-tcpri(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-maclist.xml 0000644 0001750 0001750 00000010650 12222401136 023165 0 ustar teastep teastep
shorewall-maclist5maclistShorewall MAC Verification file/etc/shorewall/maclistDescriptionThis file is used to define the MAC addresses and optionally their
associated IP addresses to be allowed to use the specified interface. The
feature is enabled by using the maclist
option in the shorewall-interfaces(5) or shorewall-hosts(5) configuration
file.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).DISPOSITION - {ACCEPT|DROP|REJECT}[log-level]ACCEPT or DROP (if MACLIST_TABLE=filter in shorewall.conf(5), then REJECT is
also allowed). If specified, the
log-level causes packets matching the
rule to be logged at that level.INTERFACE -
interfaceNetwork interface to a host.MAC -
addressMAC address of the host -- you do not
need to use the Shorewall format for MAC addresses here. If
IP ADDRESSES is supplied then
MAC can be supplied as a dash
(-)IP ADDRESSES (addresses) -
[address[,address]...]Optional - if specified, both the MAC and IP address must
match. This column can contain a comma-separated list of host and/or
subnet addresses. If your kernel and iptables have iprange match
support then IP address ranges are also allowed. Similarly, if your
kernel and iptables include ipset support than set names (prefixed
by "+") are also allowed.FILES/etc/shorewall/maclistSee ALSOhttp://shorewall.net/MAC_Validation.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-zones.xml 0000644 0001750 0001750 00000042337 12222401136 022676 0 ustar teastep teastep
shorewall-zones5zonesShorewall zone declaration file/etc/shorewall/zonesDescriptionThe /etc/shorewall/zones file declares your network zones. You
specify the hosts in each zone through entries in
/etc/shorewall/interfaces or
/etc/shorewall/hosts.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ZONE -
zone[:parent-zone[,parent-zone]...]Name of the zone. Must start with a
letter and consist of letters, digits or '_'. The names "all",
"none", "any", "SOURCE" and "DEST" are reserved and may not be used
as zone names. The maximum length of a zone name is determined by
the setting of the LOGFORMAT option in shorewall.conf(5). With the
default LOGFORMAT, zone names can be at most 5 characters
long.
The maximum length of an iptables log prefix is 29 bytes. As
explained in shorewall.conf (5), the default
LOGPREFIX formatting string is “Shorewall:%s:%s:” where the first
%s is replaced by the chain name and the second is replaced by the
disposition.The default formatting string has 12 fixed characters
("Shorewall" and three colons).The longest of the standard dispositions are ACCEPT and
REJECT which have 6 characters each.The canonical name for the chain containing the rules
for traffic going from zone 1 to zone 2 is "<zone
1>2<zone 2>" or "<zone 1>-<zone
2>".So if M is the maximum zone name length, such chains can
have length 2*M + 1.12 + 6 + 2*M + 1 = 29 which reduces to2*M = 29 - 12 - 6 - 1 = 10 orM = 5
The order in which Shorewall matches addresses from packets to
zones is determined by the order of zone declarations. Where a zone
is nested in one or more other zones, you may either ensure that the
nested zone precedes its parents in this file, or you may follow the
(sub)zone name by ":" and a comma-separated list of the parent
zones. The parent zones must have been declared in earlier records
in this file. See shorewall-nesting(5) for
additional information.Example:#ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
a ipv4
b ipv4
c:a,b ipv4Currently, Shorewall uses this information to reorder the zone
list so that parent zones appear after their subzones in the list.
The IMPLICIT_CONTINUE option in shorewall.conf(5) can also create
implicit CONTINUE policies to/from the subzone.Where an ipsec zone is
explicitly included as a child of an ipv4 zone, the ruleset allows CONTINUE
policies (explicit or implicit) to work as expected.In the future, Shorewall may make additional use of nesting
information.TYPEipv4This is the standard Shorewall zone type and is the
default if you leave this column empty or if you enter "-" in
the column. Communication with some zone hosts may be
encrypted. Encrypted hosts are designated using the 'ipsec'
option in shorewall-hosts(5).ipsec (or ipsec4)Communication with all zone hosts is encrypted. Your
kernel and iptables must include policy match support.firewallDesignates the firewall itself. You must have exactly
one 'firewall' zone. No options are permitted with a
'firewall' zone. The name that you enter in the ZONE column
will be stored in the shell variable $FW which you may use in
other configuration files to designate the firewall
zone.bport (or bport4)The zone is associated with one or more ports on a
single bridge.vserverAdded in Shorewall 4.4.11 Beta 2 - A zone composed of
Linux-vserver guests. The zone contents must be defined in
shorewall-hosts
(5).Vserver zones are implicitly handled as subzones of the
firewall zone.loopbackAdded in Shorewall 4.5.17.Normally, Shorewall treats the loopback interface (lo)
in the following way:By default, all traffic through the interface is
ACCEPTed.If a $FW -> $FW policy is defined or $FW ->
$FW rules are defined, they are placed in a chain named
${FW}2${F2} or ${FW}-${FW} (e.g., 'fw2fw' or 'fw-fw' )
depending on the ZONE2ZONE setting in shorewall.conf(5).$FW -> $FW traffic is only filtered in the OUTPUT
chain.By defining a loopback
zone and associating it with the loopback interface in
shorewall-interfaces(5), you can effect a slightly different
model. Suppose that the loopback zone name is 'local';
then:Both $FW -> local and local -> $FW chains are
created.The $FW -> local and local -> $FW policies may
be different.Both $FW -> local and local -> $FW rules may
be specified.Rules to/from the loopback zone and any zone other than
the firewall zone are ignored with a warning.loopback zones may be
nested within other loopback
zones.localAdded in Shorewall 4.5.17. local is the same as ipv4 with the exception that the zone
is only accessible from the firewall and vserver zones.OPTIONS, IN OPTIONS and OUT
OPTIONS (options, in_options, out_options) -
[option[,option]...]A comma-separated list of options. With the exception of the
and options, these
only apply to TYPE zones.blacklistAdded in Shorewall 4.4.13. May not be specified for
firewall or vserver zones.When specified in the IN_OPTIONS column, causes all
traffic from this zone to be passed against the src entries in shorewall-blacklist(5).When specified in the OUT_OPTIONS column, causes all
traffic to this zone to be passed against the dst entries in shorewall-blacklist(5).Specifying this option in the OPTIONS column is
equivalent to entering it in both of the IN_OPTIONS and
OUT_OPTIONS column.dynamic_sharedAdded in Shorewall 4.5.9. May only be specified in the
OPTIONS column and indicates that only a single ipset should
be created for this zone if it has multiple dynamic entries in
shorewall-hosts(5).
Without this option, a separate ipset is created for each
interface.reqid=numberwhere number is specified using
setkey(8) using the 'unique:number option
for the SPD level.spi=<number>where number is the SPI of the SA
used to encrypt/decrypt packets.proto=ah|esp|ipcompIPSEC Encapsulation Protocolmss=numbersets the MSS field in TCP packets. If you supply this
option, you should also set FASTACCEPT=No in shorewall.conf(5) to insure
that both the SYN and SYN,ACK packets have their MSS field
adjusted.mode=transport|tunnelIPSEC modetunnel-src=address[/mask]only available with mode=tunneltunnel-dst=address[/mask]only available with mode=tunnelstrictMeans that packets must match all rules.nextSeparates rules; can only be used with strictThe options in the OPTIONS column are applied to both incoming
and outgoing traffic. The IN OPTIONS are applied to incoming traffic
(in addition to OPTIONS) and the OUT OPTIONS are applied to outgoing
traffic.If you wish to leave a column empty but need to make an entry
in a following column, use "-".FILES/etc/shorewall/zonesSee ALSOhttp://www.shorewall.net/Multiple_Zones.html.http://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-nesting(8), shorewall-netmap(5),
shorewall-params(5), shorewall-policy(5), shorewall-providers(5),
shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5),
shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcdevices.xml 0000644 0001750 0001750 00000030232 12222401136 023500 0 ustar teastep teastep
shorewall-tcdevices5tcdevicesShorewall Traffic Shaping Devices file/etc/shorewall/tcdevicesDescriptionEntries in this file define the bandwidth for interfaces on which
you want traffic shaping to be enabled.If you do not plan to use traffic shaping for a device, don't put it
in here as it limits the throughput of that device to the limits you set
here.A note on the bandwidth definitions used in
this file:don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is not.you can use one of the following units:kbpsKilobytes per second.mbpsMegabytes per second.kbitKilobits per second.mbitMegabits per second.bps or numberBytes per second.Only whole integers are allowed.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).INTERFACE -
[number:]interfaceName of interface. Each interface may be
listed only once in this file. You may NOT specify the name of an
alias (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18You may NOT specify wildcards here, e.g. if you have multiple
ppp interfaces, you need to put them all in here!If the device doesn't exist, a warning message will be issued
during "shorewall [re]start" and "shorewall refresh" and traffic
shaping configuration will be skipped for that device.Shorewall assigns a sequential interface
number to each interface (the first entry in the file is
interface 1, the second is interface 2 and so on) You can explicitly
specify the interface number by prefixing the interface name with
the number and a colon (":"). Example: 1:eth0.IN-BANDWIDTH (in_bandwidth) -
{-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}The incoming bandwidth of that interface.
Please note that you are not able to do traffic shaping on incoming
traffic, as the traffic is already received before you could do so.
But this allows you to define the maximum traffic allowed for this
interface in total, if the rate is exceeded, the packets are
dropped. You want this mainly if you have a DSL or Cable connection
to avoid queuing at your providers side.If you don't want any traffic to be dropped, set this to a
value to zero in which case Shorewall will not create an ingress
qdisc.Must be set to zero if the REDIRECTED INTERFACES column is
non-empty.The optional burst option was added in Shorewall 4.4.18. The
default burst is 10kb. A larger
burst can help make the
bandwidth more accurate; often for fast
lines, the enforced rate is well below the specified
bandwidth.What is described above creates a rate/burst policing filter.
Beginning with Shorewall 4.4.25, a rate-estimated policing filter
may be configured instead. Rate-estimated filters should be used
with Ethernet adapters that have Generic Receive Offload enabled by
default. See Shorewall FAQ
97a.To create a rate-estimated filter, precede the bandwidth with
a tilde ("~"). The optional interval and decay_interval determine
how often the rate is estimated and how many samples are retained
for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt
for details.OUT-BANDWIDTH (out_bandwidth) -
bandwidthThe outgoing bandwidth of that interface.
This is the maximum speed your connection can handle. It is also the
speed you can refer as "full" if you define the tc classes in shorewall-tcclasses(5).
Outgoing traffic above this rate will be dropped.OPTIONS - {-|{classify|htb|hfsc|linklayer={ethernet|atm|adsl}|tsize=tsize|mtu=mtu|mpu=mpu|overhead=overhead}
,...} ― When specified, Shorewall will not
generate tc or Netfilter rules to classify traffic based on packet
marks. You must do all classification using CLASSIFY rules in shorewall-tcrules(5). - Use the Hierarchical Token
Bucket queuing discipline. This is the default. - Shorewall normally uses the
Hierarchical Token Bucket queuing discipline. When
is specified, the Hierarchical Fair
Service Curves discipline is used instead (see tc-hfsc
(7)).linklayer - Added in
Shorewall 4.5.6. Type of link (ethernet, atm, adsl). When specified,
causes scheduler packet size manipulation as described in tc-stab
(8). When this option is given, the following options may also be
given after it:
mtu=mtu - The
device MTU; default 2048 (will be rounded up to a power of
two)mpu=mpubytes -
Minimum packet size used in calculations. Smaller packets will be
rounded up to this sizetsize=tablesize
- Size table entries; default is 512overhead=overheadbytes
- Number of overhead bytes per packet.
REDIRECTED INTERFACES
(redirect)-
[interface[,interface]...]May only be specified if the interface in the INTERFACE column
is an Intermediate Frame Block (IFB) device. Causes packets that
enter each listed interface to be passed through the egress filters
defined for this device, thus providing a form of incoming traffic
shaping. When this column is non-empty, the classify option is assumed.ExamplesExample 1:Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. The device has an outgoing bandwidth of 500kbit
and an incoming bandwidth of 6000kbit #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED
# INTERFACES
1:ppp0 6000kbit 500kbitFILES/etc/shorewall/tcdevicesSee ALSOtc-hfsc (7)http://shorewall.net/traffic_shaping.htmhttp://shorewall.net/configuration_file_basics.htm#Pairshttp://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txtshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-exclusion.xml 0000644 0001750 0001750 00000014750 12222401136 023547 0 ustar teastep teastep
shorewall-exclusion5exclusionExclude a set of hosts from a definition in a shorewall
configuration file.address-or-range[,address-or-range]zone-name[,zone-name]DescriptionThe first form of exclusion is used when you wish to exclude one or
more addresses from a definition. An exclamation point is followed by a
comma-separated list of addresses. The addresses may be single host
addresses (e.g., 192.168.1.4) or they may be network addresses in CIDR
format (e.g., 192.168.1.0/24). If your kernel and iptables include iprange
support, you may also specify ranges of ip addresses of the form
lowaddress-highaddressNo embedded white-space is allowed.Exclusion can appear after a list of addresses and/or address
ranges. In that case, the final list of address is formed by taking the
first list and then removing the addresses defined in the
exclusion.Beginning in Shorewall 4.4.13, the second form of exclusion is
allowed after all and any in the SOURCE and DEST columns of
/etc/shorewall/rules. It allows you to omit arbitrary zones from the list
generated by those key words.If you omit a sub-zone and there is an explicit or explicit
CONTINUE policy, a connection to/from that zone can still be matched by
the rule generated for a parent zone.For example:
/etc/shorewall/zones:#ZONE TYPE
z1 ip
z2:z1 ip
.../etc/shorewall/policy:#SOURCE DEST POLICY
z1 net CONTINUE
z2 net REJECT/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT all!z2 net tcp 22In this case, SSH connections from z2 to net will
be accepted by the generated z1 to
net ACCEPT rule.
In most contexts, ipset names can be used as an
address-or-range. Beginning with Shorewall
4.4.14, ipset lists enclosed in +[...] may also be included (see shorewall-ipsets (5)). The semantics
of these lists when used in an exclusion are as follows:!+[set1,set2,...setN]
produces a packet match if the packet does not match at least one of
the sets. In other words, it is like NOT match
set1 OR NOT match
set2 ... OR NOT match
setN.+[!set1,!set2,...!setN]
produces a packet match if the packet does not match any of the sets.
In other words, it is like NOT match set1
AND NOT match set2 ... AND NOT match
setN.ExamplesExample 1 - All IPv4 addresses except 192.168.3.4!192.168.3.4Example 2 - All IPv4 addresses except the network 192.168.1.0/24
and the host 10.2.3.4!192.168.1.0/24,10.1.3.4Example 3 - All IPv4 addresses except the range
192.168.1.3-192.168.1.12 and the network 10.0.0.0/8!192.168.1.3-192.168.1.12,10.0.0.0/8Example 4 - The network 192.168.1.0/24 except hosts 192.168.1.3
and 192.168.1.9192.168.1.0/24!192.168.1.3,192.168.1.9Example 5 - All parent zones except locany!locFILES/etc/shorewall/hosts/etc/shorewall/masq/etc/shorewall/rules/etc/shorewall/tcrulesSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcinterfaces.xml 0000644 0001750 0001750 00000020617 12222401136 024207 0 ustar teastep teastep
shorewall-tcinterfaces5tcinterfacesShorewall file/etc/shorewall/tcinterfacesDescriptionThis file lists the interfaces that are subject to simple traffic
shaping. Simple traffic shaping is enabled by setting TC_ENABLED=Simple in
shorewall.conf(5).A note on the bandwidth definition used in this
file:don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is not.you can use one of the following units:kbpsKilobytes per second.mbpsMegabytes per second.kbitKilobits per second.mbitMegabits per second.bps or numberBytes per second.k or kbKilo bytes.m or mbMegabytes.Only whole integers are allowed.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).INTERFACEThe logical name of an interface. If you run both IPv4 and
IPv6 Shorewall firewalls, a given interface should only be listed in
one of the two configurations.TYPE - [external|internal]Optional. If given specifies whether the interface is
external (facing toward the
Internet) or internal (facing
toward a local network) and enables SFQ flow classification.Simple traffic shaping is only useful on interfaces where
queuing occurs. As a consequence, internal interfaces seldom
benefit from simple traffic shaping. VPN interfaces are an
exception because the encapsulated packets are later transferred
over a slower external link.IN-BANDWIDTH (in_bandwidth) -
{-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}The incoming bandwidth of that interface.
Please note that you are not able to do traffic shaping on incoming
traffic, as the traffic is already received before you could do so.
But this allows you to define the maximum traffic allowed for this
interface in total, if the rate is exceeded, the packets are
dropped. You want this mainly if you have a DSL or Cable connection
to avoid queuing at your providers side.If you don't want any traffic to be dropped, set this to a
value to zero in which case Shorewall will not create an ingress
qdisc.Must be set to zero if the REDIRECTED INTERFACES column is
non-empty.The optional burst option was added in Shorewall 4.4.18. The
default burst is 10kb. A larger
burst can help make the
bandwidth more accurate; often for fast
lines, the enforced rate is well below the specified
bandwidth.What is described above creates a rate/burst policing filter.
Beginning with Shorewall 4.4.25, a rate-estimated policing filter
may be configured instead. Rate-estimated filters should be used
with Ethernet adapters that have Generic Receive Offload enabled by
default. See Shorewall FAQ
97a.To create a rate-estimated filter, precede the bandwidth with
a tilde ("~"). The optional interval and decay_interval determine
how often the rate is estimated and how many samples are retained
for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt
for details.OUT-BANDWIDTH (out_bandwidth) -
[rate[:[burst][:[latency][:[peek][:[minburst]]]]]]Added in Shorewall 4.4.13. The terms are defined in
tc-tbf(8).Shorewall provides defaults as follows:burst - 10kblatency - 200msThe remaining options are defaulted by tc(8).FILES/etc/shorewall/tcinterfaces.See ALSOhttp://ace-host.stuart.id.au/russell/files/tc/doc/sch_tbf.txthttp://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txtshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcpri(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-hosts.xml 0000644 0001750 0001750 00000025363 12222401136 022700 0 ustar teastep teastep
shorewall-hosts5hostsShorewall file/etc/shorewall/hostsDescriptionThis file is used to define zones in terms of subnets and/or
individual IP addresses. Most simple setups don't need to (should not)
place anything in this file.The order of entries in this file is not significant in determining
zone composition. Rather, the order that the zones are declared in shorewall-zones(5) determines the order
in which the records in this file are interpreted.The only time that you need this file is when you have more than
one zone connected through a single interface.If you have an entry for a zone and interface in shorewall-interfaces(5) then do
not include any entries in this file for that same (zone, interface)
pair.The columns in the file are as follows.ZONE -
zone-nameThe name of a zone declared in shorewall-zones(5). You may not
list the firewall zone in this column.HOST(S) -
interface:{[{address-or-range[,address-or-range]...|+ipset|dynamic}[exclusion]The name of an interface defined in the shorewall-interfaces(5) file
followed by a colon (":") and a comma-separated list whose elements
are either:The IP address of a
host.A network in CIDR format.An IP address range of the form
low.address-high.address.
Your kernel and iptables must have iprange match support.The name of an ipset.The word which makes the zone
dynamic in that you can use the shorewall add
and shorewall delete commands to change to
composition of the zone.
You may also exclude certain hosts through use of an
exclusion (see shorewall-exclusion(5).
OPTIONS (Optional) -
[option[,option]...]A comma-separated list of options from the following list. The
order in which you list the options is not significant but the list
must have no embedded white-space.blacklistCheck packets arriving on this port against the shorewall-blacklist(5)
file.broadcastUsed when you want to include limited broadcasts
(destination IP address 255.255.255.255) from the firewall to
this zone. Only necessary when:The network specified in the HOST(S) column does not
include 255.255.255.255.The zone does not have an entry for this interface
in shorewall-interfaces(5).destonlyNormally used with the Multi-cast IP address range
(224.0.0.0/4). Specifies that traffic will be sent to the
specified net(s) but that no traffic will be received from the
net(s).ipsecThe zone is accessed via a kernel 2.6 ipsec SA. Note
that if the zone named in the ZONE column is specified as an
IPSEC zone in the shorewall-zones(5) file
then you do NOT need to specify the 'ipsec' option
here.maclistConnection requests from these hosts are compared
against the contents of shorewall-maclist(5). If
this option is specified, the interface must be an Ethernet
NIC or equivalent and must be up before Shorewall is
started.mss=mssAdded in Shorewall 4.5.2. When present, causes the TCP
mss for new connections to/from the hosts given in the HOST(S)
column to be clamped at the specified
mss.nosmurfsThis option only makes sense for ports on a
bridge.Filter packets for smurfs (packets with a broadcast
address as the source).Smurfs will be optionally logged based on the setting of
SMURF_LOG_LEVEL in shorewall.conf(5). After
logging, the packets are dropped.routebackShorewall should set up the infrastructure to pass
packets from this/these address(es) back to themselves. This
is necessary if hosts in this group use the services of a
transparent proxy that is a member of the group or if DNAT is
used to send requests originating from this group to a server
in the group.tcpflagsPackets arriving from these hosts are checked for
certain illegal combinations of TCP flags. Packets found to
have such a combination of flags are handled according to the
setting of TCP_FLAGS_DISPOSITION after having been logged
according to the setting of TCP_FLAGS_LOG_LEVEL.ExamplesExample 1The firewall runs a PPTP server which creates a ppp interface
for each remote client. The clients are assigned IP addresses in the
network 192.168.3.0/24 and in a zone named 'vpn'.#ZONE HOST(S) OPTIONS
vpn ppp+:192.168.3.0/24FILES/etc/shorewall/hostsSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-nesting(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tos.xml 0000644 0001750 0001750 00000014135 12222401136 022340 0 ustar teastep teastep
shorewall-tos5tosShorewall Type of Service rules file/etc/shorewall/tosDescriptionThis file defines rules for setting Type Of Service (TOS). Its use
is deprecated, beginning in Shorewall 4.5.1, in favor of the TOS target in
shorewall-tcrules (5).The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).SOURCE - {all|address]|all:address|$FW}If all, may optionally be
followed by ":" and an IP address, a MAC address, a subnet
specification or the name of an interface.Example: all:192.168.2.3MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78DEST - {all|address]|all:address}Example: 192.168.2.3PROTOCOL (proto) -
proto-name-or-numberProtocol name or number.SOURCE PORT(S) (sport) -
{-|port|lowport:highport}Source port or port range. If all ports, use "-".DEST PORT(S) (dport) -
{-|port|lowport:highport}Destination port or port range. If all ports, use "-"TOS -
tosMust may one of the following;tos-minimize-delay (16)
tos-maximize-throughput (8)
tos-maximize-reliability (4)
tos-minimize-cost (2)
tos-normal-service (0)To specify more than one flag, add their values together and
specify the numeric result.MARK - [!]value[/mask][:C]If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.FILES/etc/shorewall/tosSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tunnels.xml 0000644 0001750 0001750 00000030050 12222401136 023215 0 ustar teastep teastep
shorewall-tunnels5tunnelsShorewall VPN definition file/etc/shorewall/tunnelsDescriptionThe tunnels file is used to define rules for encapsulated (usually
encrypted) traffic to pass between the Shorewall system and a remote
gateway. Traffic flowing through the tunnel is handled using the normal
zone/policy/rule mechanism. See http://www.shorewall.net/VPNBasics.html
for details.The columns in the file are as follows.TYPE - {ipsec[:{noah|ah}]|ipsecnat|ipip|gre|l2tp|pptpclient|pptpserver|[?]COMMENT|{openvpn|openvpnclient|openvpnserver}[:{tcp|udp}][:port]|generic:protocol[:port]}Types are as follows:6to4 or 6in4 - 6to4 or 6in4 tunnel. The 6in4 synonym was added in 4.4.24.
ipsec - IPv4 IPSEC
ipsecnat - IPv4 IPSEC with NAT Traversal (UDP port 4500 encapsulation)
ipip - IPv4 encapsulated in IPv4 (Protocol 4)
gre - Generalized Routing Encapsulation (Protocol 47)
l2tp - Layer 2 Tunneling Protocol (UDP port 1701)
pptpclient - PPTP Client runs on the firewall
pptpserver - PPTP Server runs on the firewall
openvpn - OpenVPN in point-to-point mode
openvpnclient - OpenVPN client runs on the firewall
openvpnserver - OpenVPN server runs on the firewall
generic - Other tunnel typeIf the type is ipsec, it may
be followed by :ah to indicate that
the Authentication Headers protocol (51) is used by the tunnel (the
default is which means that protocol 51 is
not used). NAT traversal is only supported with ESP (protocol 50) so
ipsecnat tunnels don't allow the
ah option (ipsecnat:noah may be specified but is
redundant).If type is openvpn, openvpnclient or openvpnserver it may optionally be followed
by ":" and tcp or udp to specify the protocol to be used. If
not specified, udp is
assumed.If type is openvpn, openvpnclient or openvpnserver it may optionally be followed
by ":" and the port number used by the tunnel. if no ":" and port
number are included, then the default port of 1194 will be used. .
Where both the protocol and port are specified, the protocol must be
given first (e.g., openvpn:tcp:4444).If type is generic, it must
be followed by ":" and a protocol name (from /etc/protocols) or a
protocol number. If the protocol is tcp or udp
(6 or 17), then it may optionally be followed by ":" and a port
number.Comments may be attached to Netfilter rules generated from
entries in this file through the use of COMMENT lines. These lines
begin with the word COMMENT; the remainder of the line is treated as
a comment which is attached to subsequent rules until another
COMMENT line is found or until the end of the file is reached. To
stop adding comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for
COMMENT and is preferred.ZONE -
zoneThe zone of the physical interface
through which tunnel traffic passes. This is normally your internet
zone.GATEWAY(S) (gateway or
gateways) - address-or-range[ , ... ]The IP address of the remote tunnel gateway. If the remote
gateway has no fixed address (Road Warrior) then specify the gateway
as 0.0.0.0/0. May be specified as a
network address and if your kernel and iptables include iprange
match support then IP address ranges are also allowed.Beginning with Shorewall 4.5.3, a list of addresses or ranges
may be given. Exclusion (shorewall-exclusion (5) ) is
not supported.GATEWAY ZONES (gateway_zone or
gateway_zones) - [zone[,zone]...]Optional. If the gateway system specified in the third column
is a standalone host then this column should contain a
comma-separated list of the names of the zones that the host might
be in. This column only applies to IPSEC tunnels where it enables
ISAKMP traffic to flow through the tunnel to the remote
gateway(s).ExampleExample 1:IPSec tunnel.The remote gateway is 4.33.99.124 and the remote subnet is
192.168.9.0/24. The tunnel does not use the AH protocol #TYPE ZONE GATEWAY
ipsec:noah net 4.33.99.124Example 2:Road Warrior (LapTop that may connect from anywhere) where the
"gw" zone is used to represent the remote LapTop #TYPE ZONE GATEWAY GATEWAY ZONES
ipsec net 0.0.0.0/0 gwExample 3:Host 4.33.99.124 is a standalone system connected via an ipsec
tunnel to the firewall system. The host is in zone gw. #TYPE ZONE GATEWAY GATEWAY ZONES
ipsec net 4.33.99.124 gwExample 4:Road Warriors that may belong to zones vpn1, vpn2 or vpn3. The
FreeS/Wan _updown script will add the host to the appropriate zone
using the shorewall add command on connect and
will remove the host from the zone at disconnect time. #TYPE ZONE GATEWAY GATEWAY ZONES
ipsec net 0.0.0.0/0 vpn1,vpn2,vpn3Example 5:You run the Linux PPTP client on your firewall and connect to
server 192.0.2.221. #TYPE ZONE GATEWAY GATEWAY ZONES
pptpclient net 192.0.2.221Example 6:You run a PPTP server on your firewall. #TYPE ZONE GATEWAY GATEWAY ZONES
pptpserver net 0.0.0.0/0Example 7:OPENVPN tunnel. The remote gateway is 4.33.99.124 and openvpn
uses port 7777. #TYPE ZONE GATEWAY GATEWAY ZONES
openvpn:7777 net 4.33.99.124Example 8:You have a tunnel that is not one of the supported types. Your
tunnel uses UDP port 4444. The other end of the tunnel is
4.3.99.124. #TYPE ZONE GATEWAY GATEWAY ZONES
generic:udp:4444 net 4.3.99.124FILES/etc/shorewall/tunnelsSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-lite.conf.xml 0000644 0001750 0001750 00000016251 12222401136 023415 0 ustar teastep teastep
shorewall-lite.conf5shorewall-lite.confShorewall Lite global configuration file/etc/shorewall-lite/shorewall-lite.confDescriptionThis file sets options that apply to Shorewall Lite as a
whole.The file consists of Shell comments (lines beginning with '#'),
blank lines and assignment statements
(variable=value). Each
variable's setting is preceded by comments that describe the variable and
it's effect.Any option not specified in this file gets its value from the
shorewall.conf file used during compilation of
/var/lib/shorewall-lite/firewall. Those settings may be found in the file
/var/lib/shorewall-lite/firewall.conf.OPTIONSThe following options may be set in shorewall.conf.IPTABLES=[pathname]This parameter names the iptables executable to be used by
Shorewall. If not specified or if specified as a null value, then
the iptables executable located using the PATH option is
used.LOGFILE=[pathname]This parameter tells the /sbin/shorewall program where to look
for Shorewall messages when processing the dump, logwatch, show
log, and hits commands.
If not assigned or if assigned an empty value, /var/log/messages is
assumed.LOGFORMAT=["formattemplate"]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, 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.PATH=pathname[:pathname]...Determines the order in which Shorewall searches directories
for executable files.RESTOREFILE=[filename]Specifies the simple name of a file in /var/lib/shorewall to
be used as the default restore script in the shorewall save, shorewall restore, shorewall forget and shorewall -f start commands.SHOREWALL_SHELL=[pathname]This option is used to specify the shell program to be used to
run the Shorewall compiler and to interpret the compiled script. If
not specified or specified as a null value, /bin/sh is assumed.
Using a light-weight shell such as ash or dash can significantly
improve performance.SUBSYSLOCK=[pathname]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/shorewall.VERBOSITY=[number]Shorewall has traditionally been very noisy (produced lots of
output). You may set the default level of verbosity using the
VERBOSITY OPTION.Values are:0 - Silent. You may make it more verbose using the -v
option1 - Major progress messages displayed2 - All progress messages displayed (old default
behavior)If not specified, then 2 is assumed.FILES/etc/shorewall-lite/shorewall.confSee ALSOhttp://www.shorewall.net/Documentation_Index.htmlshorewall-lite(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
shorewall-ipsec(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-route_rules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-providers.xml 0000644 0001750 0001750 00000043216 12222401136 023552 0 ustar teastep teastep
shorewall-providers5providersShorewall Providers file/etc/shorewall/providersDescriptionThis file is used to define additional routing tables. You will want
to define an additional table if:You have connections to more than one ISP or multiple
connections to the same ISPYou run Squid as a transparent proxy on a host other than the
firewall.You have other requirements for policy routing.Each entry in the file defines a single routing table.If you wish to omit a column entry but want to include an entry in
the next column, use "-" for the omitted entry.The columns in the file are as follows.NAME -
nameThe provider name. Must be a valid shell
variable name. The names 'local', 'main', 'default' and 'unspec' are
reserved and may not be used as provider names.NUMBER -
numberThe provider number -- a number between 1 and 15. Each
provider must be assigned a unique value.MARK (Optional) -
valueA FWMARK value used in your shorewall-tcrules(5) file to
direct packets to this provider.If HIGH_ROUTE_MARKS=Yes in shorewall.conf(5), then the value
must be a multiple of 256 between 256 and 65280 or their hexadecimal
equivalents (0x0100 and 0xff00 with the low-order byte of the value
being zero). Otherwise, the value must be between 1 and 255. Each
provider must be assigned a unique mark value. This column may be
omitted if you don't use packet marking to direct connections to a
particular provider.DUPLICATE -
routing-table-nameThe name of an existing table to duplicate to create this
routing table. May be or the name of a
previously listed provider. You may select only certain entries from
the table to copy by using the COPY column below. This column should
contain a dash ("-') when USE_DEFAULT_RT=Yes in shorewall.conf(5).INTERFACE -
interface[:address]The name of the network interface to the provider. Must be
listed in shorewall-interfaces(5). In
general, that interface should not have the
option specified unless
is given in the OPTIONS column of this
entry.Where more than one provider is serviced through a single
interface, the interface must be followed by a
colon and the IP address of the interface that
is supplied by the associated provider.GATEWAY - {-|address|detect}The IP address of the provider's gateway router.You can enter "detect" here and Shorewall will attempt to
detect the gateway automatically.For PPP devices, you may omit this column.OPTIONS (Optional) - [-|option[,option]...]A comma-separated list selected from the following. The order
of the options is not significant but the list may contain no
embedded white-space.autosrcAdded in Shorewall 4.5.17. Causes a host route to the
provider's gateway router to be added to the provider's
routing table. This is the default behavior unless overridden
by a following noautosrc
option.trackIf specified, inbound connections on this interface are
to be tracked so that responses may be routed back out this
same interface.You want to specify if internet
hosts will be connecting to local servers through this
provider.Beginning with Shorewall 4.4.3,
defaults to the setting of the TRACK_PROVIDERS option in
shorewall.conf (5).
If you set TRACK_PROVIDERS=Yes and want to override that
setting for an individual provider, then specify
(see below).balance[=weight]The providers that have
specified will get outbound traffic load-balanced among them.
By default, all interfaces with
specified will have the same weight (1). You can change the
weight of an interface by specifying
weight
where weight is the weight of the
route out of this interface.looseShorewall normally adds a routing rule for each IP
address on an interface which forces traffic whose source is
that IP address to be sent using the routing table for that
interface. Setting prevents creation of
such rules on this interface.noautosrcAdded in Shorewall 4.5.17. Prevents the addition of a
host route to the provider's gateway router from being added
to the provider's routing table. This option must be used with
caution as it can cause start and restart failures.notrackAdded in Shorewall 4.4.3. When specified, turns off
.optional (deprecated for use with
providers that do not share an interface)If the interface named in the INTERFACE column is not up
and configured with an IPv4 address then ignore this provider.
If not specified, the value of the
option for the INTERFACE in shorewall-interfaces(5)
is assumed. Use of that option is preferred to this one,
unless an address is provider in
the INTERFACE column.src=source-addressSpecifies the source address to use when routing to this
provider and none is known (the local client has bound to the
0 address). May not be specified when an
address is given in the INTERFACE
column. If this option is not used, Shorewall substitutes the
primary IP address on the interface named in the INTERFACE
column.mtu=numberSpecifies the MTU when forwarding through this provider.
If not given, the MTU of the interface named in the INTERFACE
column is assumed.fallback[=weight]Indicates that a default route through the provider
should be added to the default routing table (table 253). If a
weight is given, a balanced route
is added with the weight of this provider equal to the
specified weight. If the option is
given without a weight, an separate
default route is added through the provider's gateway; the
route has a metric equal to the provider's NUMBER.Prior to Shorewall 4.4.24, the option is ignored with a
warning message if USE_DEFAULT_RT=Yes in
shorewall.conf.tproxyAdded in Shorewall 4.5.4. Used for supporting the TPROXY
action in shorewall-tcrules(5). See http://www.shorewall.net/Shorewall_Squid_Usage.html.
When specified, the MARK, DUPLICATE and GATEWAY columns should
be empty, INTERFACE should be set to 'lo' and
should be the only OPTION. Only one
provider is allowed.hostrouteAdded in Shorewall 4.5.21. This is the default behavior
that results in a host route to the defined GATEWAY being inserted into the main
routing table and into the provider's routing table. hostroute is required for older
distributions but nohostroute
(below) is appropriate for recent distributions. hostroute may interfere with Zebra's
ability to add routes on some distributions such as Debian
7.nohostrouteAdded in Shorewall 4.5.21. nohostroute inhibits addition
of a host route to the defined GATEWAY being inserted into the main
routing table and into the provider's routing table. nohostroute is not appropriate for
older distributions but is appropriate for recent
distributions. nohostroute
allows Zebra's to correctly add routes on some distributions
such as Debian 7.COPY -
[{|interface[,interface]...}]A comma-separated list of other interfaces on your firewall.
Wildcards specified using an asterisk ("*") are permitted (e.g.,
tun* ). Usually used only when DUPLICATE is .
Only copy routes through INTERFACE and through interfaces listed
here. If you only wish to copy routes through INTERFACE, enter
in this column.Beginning with Shorewall 4.5.17, blackhole, unreachable and
prohibit routes are no longer copied by default but may be copied by
including blackhole,unreachable and prohibit respectively in the COPY
list.ExamplesExample 1:You run squid in your DMZ on IP address 192.168.2.99. Your DMZ
interface is eth2 #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
Squid 1 1 - eth2 192.168.2.99 -Example 2:eth0 connects to ISP 1. The IP address of eth0 is
206.124.146.176 and the ISP's gateway router has IP address
206.124.146.254.eth1 connects to ISP 2. The IP address of eth1 is
130.252.99.27 and the ISP's gateway router has IP address
130.252.99.254.eth2 connects to a local network. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
ISP1 1 1 main eth0 206.124.146.254 track,balance eth2
ISP2 2 2 main eth1 130.252.99.254 track,balance eth2FILES/etc/shorewall/providersSee ALSOhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-rtrules.xml 0000644 0001750 0001750 00000016035 12222401136 023234 0 ustar teastep teastep
shorewall-rtrules5rtrulesShorewall Routing Rules file/etc/shorewall/rtrulesDescriptionEntries in this file cause traffic to be routed to one of the
providers listed in shorewall-providers(5).The columns in the file are as follows.SOURCE (Optional) - {-|[&]interface|address|interface:address}An ip address (network or host) that
matches the source IP address in a packet. May also be specified as
an interface name optionally followed by ":"
and an address. If the device lo is
specified, the packet must originate from the firewall
itself.Beginning with Shorewall 4.5.0, you may specify
&interface in this column to indicate
that the source is the primary IP address of the named
interface.DEST (Optional) - {-|address}An ip address (network or host) that matches the destination
IP address in a packet.If you choose to omit either SOURCE or DEST, place "-" in that column. Note that you
may not omit both SOURCE and
DEST.PROVIDER -
{provider-name|provider-number|main}The provider to route the traffic through. May be expressed
either as the provider name or the provider number. May also be
main or 254 for the main routing
table. This can be used in combination with VPN tunnels, see example
2 below.PRIORITY -
priorityThe rule's numeric priority which
determines the order in which the rules are processed. Rules with
equal priority are applied in the order in which they appear in the
file.1000-1999Before Shorewall-generated 'MARK' rules11000-11999After 'MARK' rules but before Shorewall-generated rules
for ISP interfaces.26000-26999After ISP interface rules but before 'default'
rule.MARK -
{-|mark[/mask]}Optional -- added in Shorewall 4.4.25. For this rule to be
applied to a packet, the packet's mark value must match the
mark when logically anded with the
mask. If a
mask is not supplied, Shorewall supplies
a suitable provider mask.ExamplesExample 1:You want all traffic coming in on eth1 to be routed to the
ISP1 provider. #SOURCE DEST PROVIDER PRIORITY MASK
eth1 - ISP1 1000
Example 2:You use OpenVPN (routed setup /tunX) in combination with
multiple providers. In this case you have to set up a rule to ensure
that the OpenVPN traffic is routed back through the tunX
interface(s) rather than through any of the providers. 10.8.0.0/24
is the subnet chosen in your OpenVPN configuration (server 10.8.0.0
255.255.255.0). #SOURCE DEST PROVIDER PRIORITY MASK
- 10.8.0.0/24 main 1000
FILES/etc/shorewall/rtrulesSee ALSOhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-netmap.xml 0000644 0001750 0001750 00000017733 12222401136 023026 0 ustar teastep teastep
shorewall-netmap5netmapShorewall NETMAP definition file/etc/shorewall/netmapDescriptionThis file is used to map addresses in one network to corresponding
addresses in a second network.To use this file, your kernel and iptables must have NETMAP
support included.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).TYPE - {DNAT|SNAT}[:{P|O|T}]Must be DNAT or SNAT; beginning with Shorewall 4.4.23, may be
optionally followed by :P, :O or :T to perform stateless
NAT. Stateless NAT requires Rawpost Table
support in your kernel and iptables (see the output of
shorewall show capabilities).If DNAT or DNAT:P, traffic entering INTERFACE and addressed to
NET1 has its destination address rewritten to the corresponding
address in NET2.If SNAT or SNAT:T, traffic leaving INTERFACE with a source
address in NET1 has it's source address rewritten to the
corresponding address in NET2.If DNAT:O, traffic originating on the firewall and leaving via
INTERFACE and addressed to NET1 has its destination address
rewritten to the corresponding address in NET2.If DNAT:P, traffic entering via INTERFACE and addressed to
NET1 has its destination address rewritten to the corresponding
address in NET2.If SNAT:P, traffic entering via INTERFACE with a destination
address in NET1 has it's source address rewritten to the
corresponding address in NET2.If SNAT:O, traffic originating on the firewall and leaving via
INTERFACE with a source address in NET1 has it's source address
rewritten to the corresponding address in NET2.NET1 -
network-addressNetwork in CIDR format (e.g., 192.168.1.0/24). Beginning with
Shorewall 4.4.24, exclusion is
supported.INTERFACE -
interfaceThe name of a network interface. The interface must be defined
in shorewall-interfaces(5).
Shorewall allows loose matches to wildcard entries in shorewall-interfaces(5). For
example, ppp0 in this file
will match a shorewall-interfaces(8)
entry that defines ppp+.NET2 -
network-addressNetwork in CIDR formatNET3 (Optional) -
network-addressAdded in Shorewall 4.4.11. If specified, qualifies INTERFACE.
It specifies a SOURCE network for DNAT rules and a DESTINATION
network for SNAT rules.PROTO -
protocol-number-or-nameOptional -- added in Shorewall 4.4.23.2. Only packets
specifying this protocol will have their IP header modified.DEST PORT(S) (dport) -
port-number-or-name-listOptional - added in Shorewall 4.4.23.2. Destination Ports. A
comma-separated list of Port names (from services(5)),
port numbers or port
ranges; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s). ICMP types may be specified as a numeric
type, a numeric type and code separated by a slash (e.g., 3/4), or
a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no PORT is given, ipp2p is
assumed.An entry in this field requires that the PROTO column specify
icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if
any of the following field is supplied.SOURCE PORT(S) (sport) -
port-number-or-name-listOptional -- added in Shorewall 4.4.23.2. Source port(s). If
omitted, any source port is acceptable. Specified as a
comma-separated list of port names, port numbers or port
ranges.An entry in this field requires that the PROTO column specify
tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of
the following fields is supplied.FILES/etc/shorewall/netmapSee ALSOhttp://shorewall.net/netmap.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-nat.xml 0000644 0001750 0001750 00000014032 12222401136 022311 0 ustar teastep teastep
shorewall-nat5natShorewall one-to-one NAT file/etc/shorewall/natDescriptionThis file is used to define one-to-one Network Address Translation
(NAT).If all you want to do is simple port forwarding, do NOT use this
file. See http://www.shorewall.net/FAQ.htm#faq1.
Also, in many cases, Proxy ARP (shorewall-proxyarp(5)) is a better
solution that one-to-one NAT.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).EXTERNAL -
{address|[?]COMMENT}External IP Address - this should NOT be the primary IP
address of the interface named in the next column and must not be a
DNS Name.If you put COMMENT in this column, the rest of the line will
be attached as a comment to the Netfilter rule(s) generated by the
following entries in the file. The comment will appear delimited by
"/* ... */" in the output of "shorewall show nat"To stop the comment from being attached to further rules,
simply include COMMENT on a line by itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for
COMMENT and is preferred.INTERFACE -
interfacelist[:[digit]]Interfaces that have the EXTERNAL address. If ADD_IP_ALIASES=Yes in
shorewall.conf(5),
Shorewall will automatically add the EXTERNAL address to this
interface. Also if ADD_IP_ALIASES=Yes, you may follow the interface
name with ":" and a digit to indicate that you
want Shorewall to add the alias with this name (e.g., "eth0:0").
That allows you to see the alias with ifconfig. That is the only thing that this name is good for -- you
cannot use it anywhere else in your Shorewall configuration.
Each interface must match an entry in shorewall-interfaces(5).
Shorewall allows loose matches to wildcard entries in shorewall-interfaces(5). For
example, ppp0 in this file
will match a shorewall-interfaces(5)
entry that defines ppp+.If you want to override ADD_IP_ALIASES=Yes for a particular
entry, follow the interface name with ":" and no digit (e.g.,
"eth0:").INTERNAL -
addressInternal Address (must not be a DNS Name).ALL INTERFACES (allints) -
[Yes|No]If Yes or yes, NAT will be effective from all hosts. If No or
no (or left empty) then NAT will be effective only through the
interface named in the INTERFACE
column.LOCAL - [Yes|No]If Yes or yes, NAT will be effective from the firewall
systemFILES/etc/shorewall/natSee ALSOhttp://shorewall.net/NAT.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-policy.xml 0000644 0001750 0001750 00000032432 12222401136 023032 0 ustar teastep teastep
shorewall-policy5policyShorewall policy file/etc/shorewall/policyDescriptionThis file defines the high-level policy for connections between
zones defined in shorewall-zones(5).The order of entries in this file is importantThis file determines what to do with a new connection request if
we don't get a match from the /etc/shorewall/rules file . For each
source/destination pair, the file is processed in order until a match is
found ("all" will match any client or server).Intra-zone policies are pre-definedFor $FW and for all of the zones defined in /etc/shorewall/zones,
the POLICY for connections from the zone to itself is ACCEPT (with no
logging or TCP connection rate limiting) but may be overridden by an
entry in this file. The overriding entry must be explicit (specifying
the zone name in both SOURCE and DEST) or it must use "all+" (Shorewall
4.5.17 or later).Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall.conf,
then the implicit policy to/from any sub-zone is CONTINUE. These
implicit CONTINUE policies may also be overridden by an explicit entry
in this file.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).SOURCE -
zone|$FW|all|all+Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or
"all+".Support for "all+" was added in Shorewall 4.5.17. "all" does
not override the implicit intra-zone ACCEPT policy while "all+"
does. DEST -
zone|$FW|all|all+Destination zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or
"all+". If the DEST is a bport zone, then the SOURCE must be "all",
"all+", another bport zone associated with the same bridge, or it
must be an ipv4 zone that is associated with only the same
bridge.Support for "all+" was added in Shorewall 4.5.17. "all" does
not override the implicit intra-zone ACCEPT policy while "all+"
does. POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro[:level]|None}]Policy if no match from the rules file is found.If the policy is neither CONTINUE nor NONE then the policy may
be followed by ":" and one of the following:The word "None" or "none". This causes any default action
defined in shorewall.conf(5) to be
omitted for this policy.The name of an action. The action will be invoked before
the policy is enforced.Actions can have parameters specified.Beginning with Shorewall 4.5.10, the action name can be
followed optionally by a colon and a log level. The level will be
applied to each rule in the action or body that does not already
have a log level.Possible actions are:ACCEPTAccept the connection.DROPIgnore the connection request.REJECTFor TCP, send RST. For all other, send an "unreachable"
ICMP.QUEUEQueue the request for a user-space application such as
Snort-inline.NFQUEUEQueue the request for a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not given, queue
zero (0) is assumed.CONTINUEPass the connection request past any other rules that it
might also match (where the source or destination zone in
those rules is a superset of the SOURCE or DEST in this
policy). See shorewall-nesting(5) for
additional information.NONEAssume that there will never be any packets from this
SOURCE to this DEST. Shorewall will not create any
infrastructure to handle such packets and you may not have any
rules with this SOURCE and DEST in the /etc/shorewall/rules
file. If such a packet is
received, the result is undefined. NONE may not be used if the
SOURCE or DEST columns contain the firewall zone ($FW) or
"all".LOG LEVEL (loglevel) -
[log-level|ULOG|NFLOG]Optional - if supplied, each connection handled under the
default POLICY is logged at that level. If not supplied, no log
message is generated. See syslog.conf(5) for a description of log
levels.You may also specify ULOG or NFLOG (must be in upper case).
This will log to the ULOG or NFLOG target and will send to a
separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html).If you don't want to log but need to specify the following
column, place "-" here.BURST:LIMIT (limit) -
[{s|d}:[[name]:]]]rate/{second|minute}[:burst]If passed, specifies the maximum TCP connection
rate and the size of an acceptable
burst. If not specified, TCP connections are
not limited. If the burst parameter is
omitted, a value of 5 is assumed.When or is specified,
the rate applies per source IP address or per destination IP address
respectively. The name may be chosen by
the user and specifies a hash table to be used to count matching
connections. If not give, the name shorewall is assumed. Where more than one
POLICY specifies the same name, the connections counts for the
policies are aggregated and the individual rates apply to the
aggregated count.CONNLIMIT -
limit[:mask]May be used to limit the number of simultaneous connections
from each individual host to limit
connections. While the limit is only checked on connections to which
this policy could apply, the number of current connections is
calculated over all current connections from the SOURCE host. By
default, the limit is applied to each host individually but can be
made to apply to networks of hosts by specifying a
mask. The mask
specifies the width of a VLSM mask to be applied to the source
address; the number of current connections is then taken over all
hosts in the subnet
source-address/mask.ExampleAll connections from the local network to the internet are
allowedAll connections from the internet are ignored but logged at
syslog level KERNEL.INFO.All other connection requests are rejected and logged at level
KERNEL.INFO. #SOURCE DEST POLICY LOG BURST:LIMIT
# LEVEL
loc net ACCEPT
net all DROP info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT infoFILES/etc/shorewall/policySee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-vardir.xml 0000644 0001750 0001750 00000004127 12222401136 023022 0 ustar teastep teastep
shorewall-vardir5vardirShorewall file/etc/shorewall/vardirDescriptionThis file does not exist by default. You may create the file if you
want to change the directory used by Shorewall to store state information,
including compiled firewall scripts. By default, the directory used is
/var/lib/shorewall/.The file contains a single variable assignment:directorywhere directory is the name of a
directory. If you add this file, you should copy the files from
/var/lib/shorewall to the new directory before
performing a shorewall restart.ExampleVARDIR=/root/shorewallFILES/etc/shorewall/vardirSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-routes.xml 0000644 0001750 0001750 00000007136 12222401136 023057 0 ustar teastep teastep
shorewall-routes5routesShorewall file/etc/shorewall/routesDescriptionThis file was added in Shorewall 4.4.15 and is used to define routes
to be added to provider routing tables.The columns in the file are as follows.PROVIDERThe name or number of a provider defined in shorewall-providers (5).
Beginning with Shorewall 4.5.14, you may also enter
in this column to add routes to the main
routing table.DESTDestination host address or network address.GATEWAY (Optional)If specified, gives the IP address of the gateway to the
DEST.Beginning with Shorewall 4.5.14, you may specify
in this column to create a
blackhole route.Beginning with Shorewall 4.5.15, you may specify
or in this
column to create a prohibit or
unreachable route respectively.DEVICE (Optional)Specifies the device route. If neither DEVICE nor GATEWAY is
given, then the INTERFACE specified for the PROVIDER in shorewall-providers (5). This
column must be omitted if ,
or is
specified in the GATEWAY column.FILES/etc/shorewall/routesSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcclasses(5),
shorewall-tcdevices(5), shorewall-tcrules(5), shorewall-tos(5),
shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-lite-vardir.xml 0000644 0001750 0001750 00000005753 12222401136 023763 0 ustar teastep teastep
shorewall-lite-vardir5vardirShorewall Lite file/etc/shorewall-lite/vardirDescriptionThis file does not exist by default. You may create the file if you
want to change the directory used by Shorewall Lite to store state
information, including compiled firewall scripts. By default, the
directory used is /var/lib/shorewall-lite/.The file contains a single variable assignment:directorywhere directory is the name of a
directory. If you add this file, you should copy the files from
/var/lib/shorewall-lite to the new directory before
performing a shorewall-lite restart.Beginning with Shorewall 4.5.2, use of this file is deprecated in
favor of specifying VARDIR in the shorewallrc file
used during installation of Shorewall Core. While the name of the
variable remains VARDIR, the meaning is slightly different. When set in
shorewallrc, Shorewall Lite, will create a directory under the specified
path name to hold state information.Example:
VARDIR=/opt/var/lib/The state directory for Shorewall Lite will be
/opt/var/lib/shorewall-lite/.
When VARDIR is set in /etc/shorewall-lite/vardir, Shorewall Lite
will save its state in the directory
specified.ExampleVARDIR=/root/shorewallFILES/etc/shorewall-lite/vardirSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall-interfaces(5),
shorewall-ipsec(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-route_rules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcpri.xml 0000644 0001750 0001750 00000015054 12222401136 022655 0 ustar teastep teastep
shorewall-tcpri5tcpriShorewall file/etc/shorewall/tcpriDescriptionThis file is used to specify the priority of traffic for simple
traffic shaping (TC_ENABLED=Simple in shorewall.conf(5)). The priority band of
each packet is determined by the last
entry that the packet matches. If a packet doesn't match any entry in this
file, then its priority will be determined by its TOS field. The default
mapping is as follows but can be changed by setting the TC_PRIOMAP option
in shorewall.conf(5).TOS Bits Means Linux Priority BAND
------------------------------------------------------------
0x0 0 Normal Service 0 Best Effort 2
0x2 1 Minimize Monetary Cost 1 Filler 3
0x4 2 Maximize Reliability 0 Best Effort 2
0x6 3 mmc+mr 0 Best Effort 2
0x8 4 Maximize Throughput 2 Bulk 3
0xa 5 mmc+mt 2 Bulk 3
0xc 6 mr+mt 2 Bulk 3
0xe 7 mmc+mr+mt 2 Bulk 3
0x10 8 Minimize Delay 6 Interactive 1
0x12 9 mmc+md 6 Interactive 1
0x14 10 mr+md 6 Interactive 1
0x16 11 mmc+mr+md 6 Interactive 1
0x18 12 mt+md 4 Int. Bulk 2
0x1a 13 mmc+mt+md 4 Int. Bulk 2
0x1c 14 mr+mt+md 4 Int. Bulk 2
0x1e 15 mmc+mr+mt+md 4 Int. Bulk 2The columns in the file are as follows.BAND - {1|2|3}Classifies matching traffic as High Priority (1), Medium
Priority (2) or Low Priority (3). For those interfaces listed in
shorewall-tcinterfaces(5),
Priority 2 traffic will be deferred so long and there is Priority 1
traffic queued and Priority 3 traffic will be deferred so long as
there is Priority 1 or Priority 2 traffic to send.PROTO -
protocol[,...]Optional. The name or number of an IPv4
protocol.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) - port [,...]Optional. May only be given if the the PROTO is TCP (6), UDP
(17), DCCP (33), SCTP (132) or UDPLITE (136). A list of one or more
port numbers or service names from /etc/services. Port ranges of the
form
lowport:highport
may also be included.ADDRESS - [address]Optional. The IP or MAC address that the traffic originated
from. MAC addresses must be given in Shorewall format. If this
column contains an address, then the PROTO, PORT(S) and INTERFACE
column must be empty ("-").INTERFACE - [interface]Optional. The logical name of an
interface that traffic arrives from. If
given, the PROTO, PORT(S) and ADDRESS columns must be empty
("-").INTERFACE classification of packets occurs before
classification by PROTO/PORT(S)/ADDRESS. So it is highly
recommended to place entries that specify INTERFACE at the top of
the file so that the rule about last entry
matches is preserved.HELPER -
[helper]Optional. Names a Netfilter protocol helper module such as ftp,
sip, amanda, etc. A packet will match if it was accepted by the
named helper module. You can also append "-" and a port number to
the helper module name (e.g., ftp-21) to specify the port number
that the original connection was made on.FILES/etc/shorewall/tcpriSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsprio(8), shorewall(8), shorewall-accounting(5),
shorewall-actions(5), shorewall-blacklist(5), shorewall-hosts(5),
shorewall_interfaces(5), shorewall-ipsets(5), shorewall-maclist(5),
shorewall-masq(5), shorewall-nat(5), shorewall-netmap(5),
shorewall-params(5), shorewall-policy(5), shorewall-providers(5),
shorewall-proxyarp(5), shorewall-rtrules(5), shorewall-routestopped(5),
shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcrules.xml 0000644 0001750 0001750 00000155105 12222401136 023217 0 ustar teastep teastep
shorewall-tcrules5tcrulesShorewall Packet Marking rules file/etc/shorewall/tcrulesDescriptionEntries in this file cause packets to be marked as a means of
classifying them for traffic control or policy routing.Unlike rules in the shorewall-rules(5) file, evaluation
of rules in this file will continue after a match. So the final mark for
each packet will be the one assigned by the LAST tcrule that
matches.If you use multiple internet providers with the 'track' option, in
/etc/shorewall/providers be sure to read the restrictions at http://shorewall.net/MultiISP.html.Beginning with Shorewall 4.5.4, the tcrules file supports two
different formats:FORMAT 1 (default - deprecated)The older limited-function version of TPROXY is
supported.FORMAT 2The newer version of TPROXY is supported.The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is
the preferred form; the form without the '?' is deprecated.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION (mark) -
markWhere mark may assume one of the
following values.A mark value which is an integer in
the range 1-255.Normally will set the mark value. If preceded by a
vertical bar ("|"), the mark value will be logically ORed with
the current mark value to produce a new mark value. If preceded
by an ampersand ("&"), will be logically ANDed with the
current mark value to produce a new mark value.Both "|" and "&" require Extended MARK Target support
in your kernel and iptables; neither may be used with connection
marks (see below).May optionally be followed by :P, :F,:T or
:I where
:P indicates that marking should occur in the
PREROUTING chain, :F indicates
that marking should occur in the FORWARD chain, :I indicates that marking should occur in
the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in
the POSTROUTING chain. If neither :P, :F
nor :T follow the mark value
then the chain is determined as follows:- If the SOURCE is $FW[:address-or-range[,address-or-range]...],
then the rule is inserted into the OUTPUT chain. When
HIGH_ROUTE_MARKS=Yes, only high mark values may be assigned
there. Packet marking rules for traffic shaping of packets
originating on the firewall must be coded in the POSTROUTING
chain (see below).- Otherwise, the chain is determined by the setting of
MARK_IN_FORWARD_CHAIN in shorewall.conf(5).Please note that :I is
included for completeness and affects neither traffic shaping
nor policy routing.If your kernel and iptables include CONNMARK support then
you can also mark the connection rather than the packet.The mark value may be optionally followed by "/" and a
mask value (used to determine those bits of the connection mark
to actually be set). When a mask is specified, the result of
logically ANDing the mark value with the mask must be the same
as the mark value.The mark and optional mask are then followed by one
of:CMark the connection in the chain determined by the
setting of MARK_IN_FORWARD_CHAINCFMark the connection in the FORWARD chainCPMark the connection in the PREROUTING chain.CTMark the connection in the POSTROUTING chainCIMark the connection in the INPUT chain. This option
is included for completeness and has no applicability to
traffic shaping or policy routing.A mark range which is a pair of integers separated by a
dash ("-"). Added in Shorewall 4.5.9.May be optionally followed by a slash ("/") and a mask and
requires the Statistics Match capability
in iptables and kernel. Marks in the specified range are
assigned to packets on a round-robin fashion.When a mask is specified, the result of logically ANDing
each mark value with the mask must be the same as the mark
value. The least significant bit in the mask is used as an
increment. For example, if '0x200-0x400/0xff00' is specified,
then the assigned mark values are 0x200, 0x300 and 0x400 in
equal proportions. If no mask is specified, then ( 2 **
MASK_BITS ) - 1 is assumed (MASK_BITS is set in shorewall.conf(5)).May optionally be followed by :P, :F,:T or
:I where
:P indicates that marking should occur in the
PREROUTING chain, :F indicates
that marking should occur in the FORWARD chain, :I indicates that marking should occur in
the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in
the POSTROUTING chain. If neither :P, :F
nor :T follow the mark value
then the chain is determined as follows:- If the SOURCE is $FW[:address-or-range[,address-or-range]...],
then the rule is inserted into the OUTPUT chain. When
HIGH_ROUTE_MARKS=Yes, only high mark values may be assigned
there. Packet marking rules for traffic shaping of packets
originating on the firewall must be coded in the POSTROUTING
chain (see below).- Otherwise, the chain is determined by the setting of
MARK_IN_FORWARD_CHAIN in shorewall.conf(5).Please note that :I is
included for completeness and affects neither traffic shaping
nor policy routing.If your kernel and iptables include CONNMARK support then
you can also mark the connection rather than the packet.The mark range and optional mask can then followed by one
of:CMark the connection in the chain determined by the
setting of MARK_IN_FORWARD_CHAINCFMark the connection in the FORWARD chainCPMark the connection in the PREROUTING chain.CTMark the connection in the POSTROUTING chainCIMark the connection in the INPUT chain. This option
is included for completeness and has no applicability to
traffic shaping or policy routing.A classification Id (classid) of the form
major:minor where
major and minor are
integers. Corresponds to the 'class' specification in these
traffic shaping modules: atm
cbq
dsmark
pfifo_fast
htb
prioClassification occurs in the POSTROUTING chain except when
the SOURCE is $FW[:address] in
which case classification occurs in the OUTPUT chain.When using Shorewall's built-in traffic shaping tool, the
major class is the device number (the first
device in shorewall-tcdevices(5) is
major class 1, the second device is major class 2, and so on)
and the minor class is the class's MARK
value in shorewall-tcclasses(5)
preceded by the number 1 (MARK 1 corresponds to minor class 11,
MARK 5 corresponds to minor class 15, MARK 22 corresponds to
minor class 122, etc.).Beginning with Shorewall 4.4.27, the classid may be
optionally followed by ':' and a capital letter designating the
chain where classification is to occur.FFORWARD chain.TPOSTROUTING chain (default).CHECKSUMAdded in Shorewall 4.5.9. Compute and fill in the checksum
in a packet that lacks a checksum. This is particularly useful
if you need to work around old applications, such as dhcp
clients, that do not work well with checksum offloads, but you
don't want to disable checksum offload in your device.Requires 'Checksum Target' support in your kernel and
iptables.[?]COMMENT -- the rest of
the line will be attached as a comment to the Netfilter rule(s)
generated by the following entries. The comment will appear
delimited by "/* ... */" in the output of shorewall
show mangleTo stop the comment from being attached to further rules,
simply include COMMENT on a line by itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CONTINUE Don't process
any more marking rules ‒in the table.As in 1) above, may be followed by :P or :F. Currently, CONTINUE may not be used
with exclusion (see the SOURCE and DEST
columns below); that restriction will be removed when
iptables/Netfilter provides the necessary support.DIVERTAdded in Shorewall 4.5.4 and only available when FORMAT is
2. Two DIVERT rule should precede the TPROXY rule and should
select DEST PORT tcp 80 and SOURCE PORT tcp 80 respectively
(assuming that tcp port 80 is being proxied). DIVERT avoids
sending packets to the TPROXY target once a socket connection to
Squid3 has been established by TPROXY. DIVERT marks the packet
with a unique mark and exempts it from any rules that
follow.DSCP(dscp)Added in Shorewall 4.5.1. Sets the
Differentiated Services Code Point field
in the IP header. The dscp value may
be given as an even number (hex or decimal) or as the name of a
DSCP class. Valid class names and their associated hex numeric
values are: CS0 => 0x00
CS1 => 0x08
CS2 => 0x10
CS3 => 0x18
CS4 => 0x20
CS5 => 0x28
CS6 => 0x30
CS7 => 0x38
BE => 0x00
AF11 => 0x0a
AF12 => 0x0c
AF13 => 0x0e
AF21 => 0x12
AF22 => 0x14
AF23 => 0x16
AF31 => 0x1a
AF32 => 0x1c
AF33 => 0x1e
AF41 => 0x22
AF42 => 0x24
AF43 => 0x26
EF => 0x2eTo indicate more than one class, add their hex values
together and specify the result.May be optionally followed by ':' and a capital letter
designating the chain where classification is to occur.FFORWARD chain.TPOSTROUTING chain (default).IMQ(number)Added in Shorewall 4.5.1. Specifies that the packet should
be passed to the IMQ identified by
number. Requires IMQ Target support
in your kernel and iptables.IPMARK ‒ Assigns a mark
to each matching packet based on the either the source or
destination IP address. By default, it assigns a mark value
equal to the low-order 8 bits of the source address. Default
values are:srcmask1 = 0xFFmask2 = 0x00shift = 0'src' and 'dst' specify whether the mark is to be based on
the source or destination address respectively. The selected
address is first shifted to the right by
shift bits. The result is then LANDed with
mask1 then LORed with
mask2.In a sense, the IPMARK target is more like an IPCLASSIFY
target in that the mark value is later interpreted as a class
ID. A packet mark is 32 bits wide; so is a class ID. The
<major> class occupies the high-order 16 bits and the
<minor> class occupies the low-order 16 bits. So the class
ID 1:4ff (remember that class IDs are always in hex) is
equivalent to a mark value of 0x104ff. Remember that Shorewall
uses the interface number as the <major> number where the
first interface in tcdevices has <major> number 1, the
second has <major> number 2, and so on.The IPMARK target assigns a mark to each matching packet
based on the either the source or destination IP address. By
default, it assigns a mark value equal to the low-order 8 bits
of the source address. The syntax is as follows:
[([{|}][,[mask1][,[mask2][,[shift]]]])]
Default values are:mask1 = 0xFFmask2 = 0x00shift = 0 and specify
whether the mark is to be based on the source or destination
address respectively. The selected address is first shifted
right by shift, then LANDed with
mask1 and then LORed with
mask2. The
shift argument is intended to be used
primarily with IPv6 addresses.Example:
IPMARK(src,0xff,0x10100)Suppose that the source IP address is 192.168.4.3 =
0xc0a80403; then0xc0a80403 >> 0 = 0xc0a804030xc0a80403 LAND 0xFF = 0x030x03 LOR 0x0x10100 = 0x10103 or class ID
1:103
It is important to realize that, while class IDs are
composed of a major and a
minor value, the set of values must
be unique. That is, the same numeric value cannot be used as
both a major and a
minor number for the same interface
unless class nesting occurs (which is not currently possible
with Shorewall). You should keep this in mind when deciding how
to map IP addresses to class IDs.For example, suppose that your internal network is
192.168.1.0/29 (host IP addresses 192.168.1.1 - 192.168.1.6).
Your first notion might be to use IPMARK(src,0xFF,0x10000) so as
to produce class IDs 1:1 through 1:6. But 1:1 is an invalid
class ID since the major and
minor classes are equal. So you might
choose instead to use IPMARK(src,0xFF,0x10100) as in the example
above so that all of your minor
classes will have a value > 256.RESTORE[/mask] --
restore the packet's mark from the connection's mark using the
supplied mask if any. Your kernel and iptables must include
CONNMARK support.As in 1) above, may be followed by :P or :FSAME Some websites run
applications that require multiple connections from a client
browser. Where multiple 'balanced' providers are configured,
this can lead to problems when some of the connections are
routed through one provider and some through another. The SAME
target allows you to work around that problem. SAME may be used
in the PREROUTING and OUTPUT chains. When used in PREROUTING, it
causes matching connections from an individual local system to
all use the same provider. For example: #ACTION SOURCE DEST PROTO DEST
# PORT(S)
SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443
If a host in 192.168.1.0/24 attempts a connection on TCP port 80
or 443 and it has sent a packet on either of those ports in the
last five minutes then the new connection will use the same
provider as the connection over which that last packet was
sent.When used in the OUTPUT chain, it causes all matching
connections to an individual remote system to all use the same
provider. For example:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
SAME $FW 0.0.0.0/0 tcp 80,443
If the firewall attempts a connection on TCP port 80 or 443 and
it has sent a packet on either of those ports in the last five
minutes to the same remote system then the new connection will
use the same provider as the connection over which that last
packet was sent.SAVE[/mask] -- save
the packet's mark to the connection's mark using the supplied
mask if any. Your kernel and iptables must include CONNMARK
support.As in 1) above, may be followed by :P or :FSTATE {NEW|RELATED|ESTABLISHED|INVALID} [,...]Added in Shorewall 4.5.9. The rule will only match if the
packet's connection is in one of the listed states.TOS(tos[/mask])Added in Shorewall 4.5.1. Sets the Type of
Service field in the IP header. The
tos value may be given as an number
(hex or decimal) or as the name of a TOS type. Valid type names
and their associated hex numeric values are:Minimize-Delay => 0x10,
Maximize-Throughput => 0x08,
Maximize-Reliability => 0x04,
Minimize-Cost => 0x02,
Normal-Service => 0x00To indicate more than one class, add their hex values
together and specify the result.When tos is given as a number,
it may be optionally followed by '/' and a
mask. When no
mask is given, the value 0xff is
assumed. When tos is given as a type
name, the mask 0x3f is
assumed.The action performed is to zero out the bits specified by
the mask, then set the bits specified
by tos.May be optionally followed by ':' and a capital letter
designating the chain where classification is to occur.FFORWARD chain.TPOSTROUTING chain.TPROXY(mark[,[port][,[address]]])
-- FORMAT 1Transparently redirects a packet without altering the IP
header. Requires a local provider to be defined in shorewall-providers(5).There are three parameters to TPROXY - only the first
(mark) is required:mark - the MARK value
corresponding to the local provider in shorewall-providers(5).port - the port on which
the proxy server is listening. If omitted, the original
destination port.address - a local (to the
firewall) IP address on which the proxy server is listening.
If omitted, the IP address of the interface on which the
request arrives.TPROXY([port][,address])
-- FORMAT 2Transparently redirects a packet without altering the IP
header. Requires a tproxy provider to be defined in shorewall-providers(5).There are three parameters to TPROXY - neither is
required:port - the port on which
the proxy server is listening. If omitted, the original
destination port.address - a local (to the
firewall) IP address on which the proxy server is listening.
If omitted, the IP address of the interface on which the
request arrives.TTL([-|+]number)Added in Shorewall 4.4.24.Prior to Shorewall 4.5.7.2, may be optionally followed by
:F but the resulting rule is
always added to the FORWARD chain. Beginning with Shorewall
4.5.7.s, it may be optionally followed by :P, in which case the rule is added to
the PREROUTING chain.If + is included, packets
matching the rule will have their TTL incremented by
number. Similarly, if - is included, matching packets have
their TTL decremented by number. If
neither + nor - is given, the TTL of matching packets
is set to number. The valid range of
values for number is 1-255.SOURCE - {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion]May be:An interface name - matches traffic entering the firewall
on the specified interface. May not be used in classify rules or
in rules using the :T chain qualifier.A comma-separated list of host or network IP addresses or
MAC addresses. This form will not match
traffic that originates on the firewall itself unless either
<major><minor> or the :T chain qualifier is used in
the ACTION column.Examples:0.0.0.0/0192.168.1.0/24, 172.20.4.0/24An interface name followed by a colon (":") followed by a
comma-separated list of host or network IP addresses or MAC
addresses. May not be used in classify rules or in rules using
the :T chain qualifier.$FW optionally followed by a colon (":") and a
comma-separated list of host or network IP addresses. Matches
packets originating on the firewall. May not be used with a
chain qualifier (:P, :F, etc.) in the ACTION column.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).DEST - {-|{interface|$FW}|[{interface|$FW}:]address-or-range[,address-or-range]...}[exclusion]May be:An interface name. May not be used in the PREROUTING chain
(:P in the mark column or no chain qualifier and
MARK_IN_FORWARD_CHAIN=No in shorewall.conf (5)). The
interface name may be optionally followed by a colon (":") and
an IP address list.A comma-separated list of host or network IP addresses.
The list may include ip address ranges if your kernel and
iptables include iprange support.Beginning with Shorewall 4.4.13, $FW may be specified by
itself or qualified by an address list. This causes marking to
occur in the INPUT chain.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall-exclusion(5)).PROTO - {-|{tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]}Protocol - ipp2p requires
ipp2p match support in your kernel and iptables.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...]Optional destination Ports. A comma-separated list of Port
names (from services(5)), port numbers or
port ranges; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s). ICMP types may be specified as a numeric
type, a numeric type and code separated by a slash (e.g., 3/4), or
a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no PORT is given, ipp2p is
assumed.An entry in this field requires that the PROTO column specify
icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if
any of the following field is supplied.SOURCE PORT(S) (sport) -
[-|port-name-number-or-range[,port-name-number-or-range]...]Optional source port(s). If omitted, any source port is
acceptable. Specified as a comma-separated list of port names, port
numbers or port ranges.An entry in this field requires that the PROTO column specify
tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of
the following fields is supplied.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.USER - [!][user-name-or-number][:group-name-or-number][+program-name]This optional column may only be non-empty if the SOURCE is
the firewall itself.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group+upnpd#program named upnpdThe ability to specify a program name was removed from
Netfilter in kernel version 2.6.14.TEST - [!]value[/mask][:C]Optional - Defines a test on the existing packet or connection
mark. The rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.LENGTH -
[length|[min]:[max]]Optional - packet payload length. This field, if present allow
you to match the length of a packet payload (Layer 4 data ) against
a specific value or range of values. You must have iptables length
support for this to work. A range is specified in the form
min:max where either
min or max (but not both)
may be omitted. If min is omitted, then 0 is
assumed; if max is omitted, than any packet
that is min or longer will match.TOS -
tosType of service. Either a standard name, or a numeric value to
match.Minimize-Delay (16)
Maximize-Throughput (8)
Maximize-Reliability (4)
Minimize-Cost (2)
Normal-Service (0)CONNBYTES -
[!]min:[max[:{O|R|B}[:{B|P|A}]]]Optional connection Bytes; defines a byte or packet range that
the connection must fall within in order for the rule to
match.A packet matches if the the packet/byte count is within the
range defined by min and
max (unless ! is given in which case, a packet
matches if the packet/byte count is not within the range).
min is an integer which defines the beginning
of the byte/packet range. max is an integer
which defines the end of the byte/packet range; if omitted, only the
beginning of the range is checked. The first letter gives the
direction which the range refers to:
O - The original
direction of the connection.- The opposite direction from the original
connection.B - The total of both
directions.
If omitted, B is
assumed.The second letter determines what the range refers
to.
B - BytesP - PacketsA - Average packet
size.
If omitted, B is
assumed.HELPER -
helperNames a Netfilter protocol helper module
such as , ,
, etc. A packet will match if it was accepted
by the named helper module.Example: Mark all FTP data connections with mark
4:#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER
# PORT(S)
4:T 0.0.0.0/0 0.0.0.0/0 TCP - - - - - - - ftpPROBABILITY -
[probability]Added in Shorewall 4.5.0. When non-empty, requires the
Statistics Match capability in your kernel
and ip6tables and causes the rule to match randomly but with the
given probability. The
probability is a number 0 <
probability <= 1 and may be expressed
at up to 8 decimal points of precision.DSCP -
[[!]dscp]Added in Shorewall 4.5.1. When non-empty, match packets whose
Differentiated Service Code Point field
matches the supplied value (when '!' is given, the rule matches
packets whose DSCP field does not match the supplied value). The
dscp value may be given as an even number
(hex or decimal) or as the name of a DSCP class. Valid class names
and their associated hex numeric values are: CS0 => 0x00
CS1 => 0x08
CS2 => 0x10
CS3 => 0x18
CS4 => 0x20
CS5 => 0x28
CS6 => 0x30
CS7 => 0x38
BE => 0x00
AF11 => 0x0a
AF12 => 0x0c
AF13 => 0x0e
AF21 => 0x12
AF22 => 0x14
AF23 => 0x16
AF31 => 0x1a
AF32 => 0x1c
AF33 => 0x1e
AF41 => 0x22
AF42 => 0x24
AF43 => 0x26
EF => 0x2eExampleExample 1:Mark all ICMP echo traffic with packet mark 1. Mark all peer
to peer traffic with packet mark 4.This is a little more complex than otherwise expected. Since
the ipp2p module is unable to determine all packets in a connection
are P2P packets, we mark the entire connection as P2P if any of the
packets are determined to match.We assume packet/connection mark 0 means unclassified. #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST
# PORT(S)
1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:T 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
RESTORE:T 0.0.0.0/0 0.0.0.0/0 all - - - 0
CONTINUE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0
4:T 0.0.0.0/0 0.0.0.0/0 ipp2p:all
SAVE:T 0.0.0.0/0 0.0.0.0/0 all - - - !0If a packet hasn't been classified (packet mark is 0), copy the
connection mark to the packet mark. If the packet mark is set, we're
done. If the packet is P2P, set the packet mark to 4. If the packet
mark has been set, save it to the connection mark.Example 2:SNAT outgoing connections on eth0 from 192.168.1.0/24 in
round-robin fashion between addresses 1.1.1.1, 1.1.1.3, and 1.1.1.9
(Shorewall 4.5.9 and later)./etc/shorewall/tcrules:
#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST
# PORT(S)
1-3:CF 192.168.1.0/24 eth0 ; state=NEW
/etc/shorewall/masq:
#INTERFACE SOURCE ADDRESS ...
eth0 192.168.1.0/24 1.1.1.1 ; mark=1:C
eth0 192.168.1.0/24 1.1.1.3 ; mark=2:C
eth0 192.168.1.0/24 1.1.1.4 ; mark=3:CFILES/etc/shorewall/tcrulesSee ALSOhttp://shorewall.net/traffic_shaping.htmhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/PacketMarking.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-ecn(5), shorewall-exclusion(5),
shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-blrules.xml 0000644 0001750 0001750 00000030434 12222401136 023203 0 ustar teastep teastep
shorewall-blrules5blrulesshorewall Blacklist file/etc/shorewall/blrulesDescriptionThis file is used to perform blacklisting and whitelisting.Rules in this file are applied depending on the setting of
BLACKLISTNEWONLY in shorewall.conf(5). If
BLACKLISTNEWONLY=No, then they are applied regardless of the connection
tracking state of the packet. If BLACKLISTNEWONLY=Yes, they are applied to
connections in the NEW and INVALID states.The format of rules in this file is the same as the format of rules
in shorewall-rules (5). The
difference in the two files lies in the ACTION (first) column.ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]]Specifies the action to be taken if the packet matches the
rule. Must be one of the following.BLACKLISTAdded in Shorewall 4.5.3. This is actually a macro that
expands as follows:If BLACKLIST_LOGLEVEL is specified in shorewall.conf(5), then
the macro expands to blacklog.Otherwise it expands to the action specified for
BLACKLIST_DISPOSITION in shorewall.conf(5).blacklogMay only be used if BLACKLIST_LOGLEVEL is specified in
shorewall.conf (5).
Logs, audits (if specified) and applies the
BLACKLIST_DISPOSITION specified in shorewall.conf (5).ACCEPT|CONTINUE|WHITELISTExempt the packet from the remaining rules in this
file.DROPIgnore the packet.A_DROP and A_DROP!Audited versions of DROP. Requires AUDIT_TARGET support
in the kernel and ip6tables.REJECTdisallow the packet and return an icmp-unreachable or an
RST packet.A_REJECTAudited versions of REJECT. Require AUDIT_TARGET support
in the kernel and ip6tables.LOGSimply log the packet and continue with the next
rule.QUEUEQueue the packet to a user-space application such as
ftwall (http://p2pwall.sf.net). The application may reinsert
the packet for further processing.NFLOG[(nflog-parameters)]queues matching packets to a back end logging daemon via
a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html.NFQUEUEQueues the packet to a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not specified, queue
zero (0) is assumed.[?]COMMENTThe rest of the line will be attached as a comment to
the Netfilter rule(s) generated by the following entries. The
comment will appear delimited by "/* ... */" in the output of
"shorewall show <chain>". To stop the comment from being
attached to further rules, simply include COMMENT on a line by
itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.actionThe name of an action declared in
shorewall-actions(5) or
in /usr/share/shorewall/actions.std.macroThe name of a macro defined in a file named
macro.macro. If the macro accepts an
action parameter (Look at the macro source to see if it has
PARAM in the TARGET column) then the
macro name is followed by the
parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for the
parameter.Example: FTP(ACCEPT).The ACTION may optionally be
followed by ":" and a syslog log level (e.g, REJECT:info or
Web(ACCEPT):debug). This causes the packet to be logged at the
specified level.If the ACTION names an
action declared in shorewall-actions(5) or in
/usr/share/shorewall/actions.std then:If the log level is followed by "!' then all rules in the
action are logged at the log level.If the log level is not followed by "!" then only those
rules in the action that do not specify logging are logged at
the specified level.The special log level none! suppresses logging by the
action.You may also specify NFLOG
(must be in upper case) as a log level.This will log to the NFLOG
target for routing to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html).Actions specifying logging may be followed by a log tag (a
string of alphanumeric characters) which is appended to the string
generated by the LOGPREFIX (in shorewall.conf(5)).For the remaining columns, see shorewall-rules (5).ExampleExample 1:Drop Teredo packets from the net.DROP net:[2001::/32] allExample 2:Don't subject packets from 2001:DB8::/64 to the remaining
rules in the file.WHITELIST net:[2001:DB8::/64] allFILES/etc/shorewall/blrulesSee ALSOhttp://shorewall.net/blacklisting_support.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-hosts(5), shorewall-interfaces(5), shorewall-maclist(5),
shorewall6-netmap(5),shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-rtrules(5), shorewall-routestopped(5),
shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-ecn.xml 0000644 0001750 0001750 00000004616 12222401136 022303 0 ustar teastep teastep
shorewall-ecn5ecnShorewall ECN file/etc/shorewall/ecnDescriptionUse this file to list the destinations for which you want to disable
ECN (Explicit Congestion Notification).The columns in the file are as follows.INTERFACE -
interfaceInterface through which host(s) communicate with the
firewallHOST(S) (Optional) - [-|address-or-address-range[,address-or-address-range]...]Comma-separated list of host and/or network addresses. If left
empty or supplied as "-", 0.0.0.0/0 is assumed. If your kernel and
iptables include iprange match support then IP address ranges are
also permitted.FILES/etc/shorewall/ecnSee ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-proxyarp.xml 0000644 0001750 0001750 00000012475 12222401136 023424 0 ustar teastep teastep
shorewall-proxyarp5proxyarpShorewall Proxy ARP file/etc/shorewall/proxyarpDescriptionThis file is used to define Proxy ARP. There is one entry in this
file for each IP address to be proxied.The columns in the file are as follows.ADDRESS -
addressIP Address.INTERFACE -
interface (Optional as of Shorewall
4.4.16)Local interface where system with the ip address in ADDRESS is
connected. This column is only required when HAVEROUTE is set to
No (no) or is left empty.EXTERNAL -
interfaceExternal Interface to be used to access this system from the
Internet.HAVEROUTE - [-|Yes|No]If there is already a route from the firewall to the host
whose address is given, enter Yes
or yes in this column. Otherwise,
enter no or No or leave the column empty and Shorewall
will add the route for you. If Shorewall adds the route, its
persistence depends on the value of thePERSISTENT column contains Yes; otherwise, shorewall stop or shorewall clear will delete the route.PERSISTENT - [-|Yes|No]If HAVEROUTE is No or
no, then the value of this column
determines if the route added by Shorewall persists after a
shorewall stop or a shorewall clear. If this column contains
Yes or yes then the route persists; If the column is
empty or contains No or no then the route is deleted by
shorewall stop or shorewall
clear.ExampleExample 1:Host with IP 155.186.235.6 is connected to interface eth1 and
we want hosts attached via eth0 to be able to access it using that
address. #ADDRESS INTERFACE EXTERNAL
155.186.235.6 eth1 eth0FILES/etc/shorewall/proxyarpSee ALSOhttp://shorewall.net/ProxyARP.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-tcclasses.xml 0000644 0001750 0001750 00000100712 12222401136 023514 0 ustar teastep teastep
shorewall-tcclasses5tcclassesShorewall file to define HTB and HFSC classes/etc/shorewall/tcclassesDescriptionA note on the rate/bandwidth definitions used
in this file:don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is NOT.you can use one of the following units:kpbsKilobytes per second.mbpsMegabytes per second.kbitKilobits per second.mbitMegabits per second.bps or numberBytes per second.if you want the values to be calculated for you depending on the
output bandwidth setting defined for an interface in tcdevices, you
can use expressions like the following:full/3causes the bandwidth to be calculated as 1/3 of the full
outgoing speed that is defined.full*9/10will set this bandwidth to 9/10 of the full
bandwidthNote that in a sub-class (a class that has a specified parent
class), full refers to the RATE or CEIL of the parent class rather
than to the OUT-BANDWIDTH of the device.DO NOT add a unit to the rate if it is calculated !The columns in the file are as follows.INTERFACE -
interface[[:parent]:class]Name of interface.You may specify the interface number rather than the interface
name. If the classify option is
given for the interface in shorewall-tcdevices(5), then
you must also specify an interface class (an integer that must be
unique within classes associated with this interface). If the
classify option is not given, you may still specify a
class or you may have Shorewall generate a
class number from the MARK value. Interface numbers and class
numbers are always assumed to be specified in hex and class number 1
is reserved as the root class of the queuing discipline.You may NOT specify wildcards here, e.g. if you have multiple
ppp interfaces, you need to put them all in here!Please note that you can only use interface names in here that
have a bandwidth defined in the shorewall-tcdevices(5)
file.Normally, all classes defined here are sub-classes of a root
class that is implicitly defined from the entry in shorewall-tcdevices(5). You
can establish a class hierarchy by specifying a
parent class -- the number of a class that you
have previously defined. The sub-class may borrow unused bandwidth
from its parent.MARK -
{-|value}The mark value which is an integer in the
range 1-255. You set mark values in the shorewall-tcrules(5) file,
marking the traffic you want to fit in the classes defined in here.
Must be specified as '-' if the classify option is given for the interface in
shorewall-tcdevices(5)
and you are running Shorewall 4.5.5 or earlier.You can use the same marks for different interfaces.RATE -
{-|rate[:dmax[:umax]]}The minimum bandwidth this class should get, when the traffic
load rises. If the sum of the rates in this column exceeds the
INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be
honored. Similarly, if the sum of the rates of sub-classes of a
class exceed the CEIL of the parent class, things don't work
well.When using the HFSC queuing discipline, this column specify
the real-time (RT) service curve. leaf classes may specify
dmax, the maximum delay in milliseconds
that the first queued packet for this class should experience. May
be expressed as an integer, optionally followed by 'ms' with no
intervening white-space (e.g., 10ms).HFSC leaf classes may also specify
umax, the largest packet expected in this
class. May be expressed as an integer. The unit of measure is
bytes and the integer may be optionally
followed by 'b' with no intervening white-space (e.g., 800b).
umax may only be given if
dmax is also given.Beginning with Shorewall 4.5.6, HFSC classes may omit this
column (e.g, '-' in the column), provided that an
lsrate is specified (see CEIL below).
These rates are used to arbitrate between classes of the same
priority.CEIL -
[lsrate:]rateThe maximum bandwidth this class is allowed to use when the
link is idle. Useful if you have traffic which can get full speed
when more needed services (e.g. ssh) are not used.You can use the value full in
here for setting the maximum bandwidth to the RATE of the parent
class, or the OUT-BANDWIDTH of the device if there is no parent
class.Beginning with Shorewall 4.5.6, you can also specify an
lsrate (link sharing rate).PRIORITY -
priorityFor HTB:
The priority in which classes will be
serviced by the packet shaping scheduler and also the priority in
which bandwidth in excess of the rate will be given to each
class.Higher priority classes will experience less delay since
they are serviced first. Priority values are serviced in ascending
order (e.g. 0 is higher priority than 1).Classes may be set to the same priority, in which case they
will be serviced as equals.
For both HTB and HFSC, the priority is
used to calculate the priority of following Shorewall-generated
classification filters that refer to the class:Packet MARKtcp-ack and the tos options (see below)The rules for classes with lower numeric priorities will
appear before those with higher numeric priorities.Beginning with Shorewall 4.5.8, the PRIORITY may be omitted
from an HFSC class if you do not use the MARK column or the
tcp-ack or tos options. If you use any of those features
and omit the PRIORITY, then you must specify a
priority along with the MARK or
option.OPTIONS (Optional) -
[option[,option]...]A comma-separated list of options including the
following:defaultThis is the default class for that interface where all
traffic should go, that is not classified otherwise.You must define default for exactly one class per
interface.tos=0xvalue[/0xmask][:priority]
(mask defaults to 0xff)This lets you define a classifier for the given
value/mask
combination of the IP packet's TOS/Precedence/DiffSrv octet
(aka the TOS byte).Beginning with Shorewall 4.5.8, the
value/mask may be followed by a
colon (":") and a priority. This
priority determines the order in which filter rules are
processed during packet classification. If not specified, the
value (class priority << 8) |
10) is used.tos-tosname[:priority]Aliases for the following TOS octet value and mask
encodings. TOS encodings of the "TOS byte" have been
deprecated in favor of diffserve classes, but programs like
ssh, rlogin, and ftp still use them.Beginning with Shorewall 4.5.8, the
tos-name may be followed by a colon
(":") and a priority. This priority
determines the order in which filter rules are processed
during packet classification. If not specified, the value
(class priority << 8) | 10)
is used.tos-minimize-delay 0x10/0x10
tos-maximize-throughput 0x08/0x08
tos-maximize-reliability 0x04/0x04
tos-minimize-cost 0x02/0x02
tos-normal-service 0x00/0x1eEach of these options is only valid for ONE class per
interface.tcp-ack[:priority]If defined, causes a tc filter to be created that puts
all tcp ack packets on that interface that have a size of
<=64 Bytes to go in this class. This is useful for speeding
up downloads. Please note that the size of the ack packets is
limited to 64 bytes because we want only packets WITHOUT
payload to match.Beginning with Shorewall 4.5.8, the tcp-ack may be followed by a colon
(":") and a priority. This priority
determines the order in which filter rules are processed
during packet classification. If not specified, the value
(class priority << 8) | 20)
is used.This option is only valid for ONE class per
interface.occurs=numberTypically used with an IPMARK entry in tcrules. Causes
the rule to be replicated for a total of
number rules. Each rule has a
successively class number and mark value.When 'occurs' is used:The associated device may not have the 'classify'
option.The class may not be the default class.The class may not have any 'tos=' options (including
'tcp-ack').The class should not specify a MARK value. If one is
specified, it will be ignored with a warning
message.The 'RATE' and 'CEIL' parameters apply to each instance
of the class. So the total RATE represented by an entry with
'occurs' will be the listed RATE multiplied by
number. For additional information, see
tcrules
(5).flow=keysShorewall attaches an SFQ queuing discipline to each
leaf HTB class. SFQ ensures that each
flow gets equal access to the
interface. The default definition of a flow corresponds
roughly to a Netfilter connection. So if one internal system
is running BitTorrent, for example, it can have lots of
'flows' and can thus take up a larger share of the bandwidth
than a system having only a single active connection. The
classifier (module cls_flow) works
around this by letting you define what a 'flow' is. The
classifier must be used carefully or it can block off all
traffic on an interface! The flow option can be specified for
an HTB leaf class (one that has no sub-classes). We recommend
that you use the following:Shaping internet-bound traffic:
flow=nfct-srcShaping traffic bound for your local net:
flow=dstThese will cause a 'flow' to consists of the traffic
to/from each internal system.When more than one key is give, they must be enclosed in
parenthesis and separated by commas.To see a list of the possible flow keys, run this
command:
tc filter add flow help
Those that begin with "nfct-" are Netfilter connection
tracking fields. As shown above, we recommend flow=nfct-src;
that means that we want to use the source IP address
before NAT as the key.pfifoWhen specified for a leaf class, the pfifo queuing
discipline is applied to the class rather than the sfq queuing
discipline.limit=numberAdded in Shorewall 4.4.3. When specified for a leaf
class, determines the maximum number of packets that may be
queued within the class. The number must
be > 2 and <=128. If not specified, the value 127 is
assumed.red=(redoption=value,
...)Added in Shorewall 4.5.6. When specified on a leaf
class, causes the class to use the RED (Random Early
Detection) queuing discipline rather than SFQ. See tc-red (8)
for additional information.Allowable redoptions
are:min minAverage queue size at which marking becomes a
possibility.max maxAt this average queue size, the marking
probability is maximal. Must be at least twice
min to prevent synchronous
retransmits, higher for low
min.probability
probabilityMaximum probability for marking, specified as a
floating point number from 0.0 to 1.0. Suggested values
are 0.01 or 0.02 (1 or 2%, respectively).limit limitHard limit on the real (not average) queue size in
bytes. Further packets are dropped. Should be set higher
than
max+burst.
It is advised to set this a few times higher than
max. Shorewall requires that
limit be at least twice
min.burst burstUsed for determining how fast the average queue
size is influenced by the real queue size. Larger values
make the calculation more sluggish, allowing longer
bursts of traffic before marking starts. Real life
experiments support the following guide‐line:
(min+min+max)/(3*avpkt).avpkt avpktOptional. Specified in bytes. Used with burst to
determine the time constant for average queue size
calculations. 1000 is a good value and is the Shorewall
default.bandwidth
bandwidthOptional. This rate is used for calculating the
average queue size after some idle time. Should be set
to the bandwidth of your interface. Does not mean that
RED will shape for you!ecnRED can either 'mark' or 'drop'. Explicit
Congestion Notification allows RED to notify remote
hosts that their rate exceeds the amount of bandwidth
available. Non-ECN capable hosts can only be notified by
dropping a packet. If this parameter is specified,
packets which indicate that their hosts honor ECN will
only be marked and not dropped, unless the queue size
hits limit bytes.
Recommended.fq_codel[=(codeloption=value,
...)]Added in Shorewall 4.5.12. When specified for a leaf
class, causes the class to use the FQ_CODEL (Fair-queuing
Controlled Delay) queuing discipline rather than SFQ. See
tc-fq_codel (8) for additional information.Allowable codeloptions
are:limithard limit on the real queue size. When this limit
is reached, incoming packets are dropped. If the value
is lowered, packets are dropped so that the new limit is
met. Default is 1000 packets.flowsis the number of flows into which the incoming
packets are classified. Due to the stochastic nature of
hashing, multiple flows may end up being hashed into the
same slot. Newer flows have priority over older ones.
This parameter can be set only at load time since memory
has to be allocated for the hash table. Default value is
1024.targetis the acceptable minimum standing/persistent
queue delay. This minimum delay is identified by
tracking the local minimum queue delay that packets
experience. Default and recommended value is 5ms.intervalis used to ensure that the measured minimum delay
does not become too stale. The minimum delay must be
experienced in the last epoch of length interval. It
should be set on the order of the worst-case RTT through
the bottleneck to give endpoints sufficient time to
react. Default value is 100ms.quantumis the number of bytes used as 'deficit' in the
fair queuing algorithm. Default is set to 1514 bytes
which corresponds to the Ethernet MTU plus the hardware
header length of 14 bytes.ecn | noecncan be used to mark packets instead of dropping
them. If ecn has been enabled, noecn can be used to turn
it off and vice-versa. By default, ecn is
enabled.ExamplesExample 1:Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. You have 4 classes here, the first you can use
for voice over IP traffic, the second interactive traffic (e.g.
ssh/telnet but not scp), the third will be for all unclassified
traffic, and the forth is for low priority traffic (e.g.
peer-to-peer).The voice traffic in the first class will be guaranteed a
minimum of 100kbps and always be serviced first (because of the low
priority number, giving less delay) and will be granted excess
bandwidth (up to 180kbps, the class ceiling) first, before any other
traffic. A single VoIP stream, depending upon codecs, after
encapsulation, can take up to 80kbps on a PPPoE/DSL link, so we pad a
little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ
classes EF and AFF3-1 respectively and are often used by VOIP
devices).Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP
echo traffic if you use the example in tcrules) and any packet with
a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may
extend up to full speed of the link.Unclassified traffic and packets marked as 3 will be
guaranteed 1/4th of the link bandwidth, and may extend to the full
speed of the link.Packets marked with 4 will be treated as low priority packets.
(The tcrules example marks p2p traffic as such.) If the link is
congested, they're only guaranteed 1/8th of the speed, and even if
the link is empty, can only expand to 80% of link bandwidth just as
a precaution in case there are upstream queues we didn't account
for. This is the last class to get additional bandwidth and the last
to get serviced by the scheduler because of the low priority. #INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc
ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay
ppp0 3 full/4 full 3 default
ppp0 4 full/8 full*8/10 4FILES/etc/shorewall/tcclassesSee ALSOhttp://shorewall.net/traffic_shaping.htmhttp://shorewall.net/configuration_file_basics.htm#Pairstc-hfsc(7)tc-red(8)shorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-routestopped(5), shorewall-rules(5),
shorewall.conf(5), shorewall-secmarks(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-template.xml 0000644 0001750 0001750 00000003130 12222401136 023337 0 ustar teastep teastep
shorewall-5fileShorewall file/etc/shorewall/DescriptionThe columns in the file are as follows.COLUMN 1ExampleFILES/etc/shorewall/See ALSOshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5), shorewall-ipsets(5),
shorewall-maclist(5), shorewall-masq(5), shorewall-nat(5),
shorewall-netmap(5), shorewall-params(5), shorewall-policy(5),
shorewall-providers(5), shorewall-proxyarp(5), shorewall-rtrules(5),
shorewall-routestopped(5), shorewall-rules(5), shorewall.conf(5), shorewall-secmarks(5),
shorewall-tcclasses(5), shorewall-tcdevices(5), shorewall-tcrules(5),
shorewall-tos(5), shorewall-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages/shorewall-arprules.xml 0000644 0001750 0001750 00000027010 12222401136 023364 0 ustar teastep teastep
shorewall-arprules5arprulesShorewall ARP rules file/etc/shorewall/arprulesDescriptionThis file was added in Shorewall 4.5.12 and is used to describe
low-level rules managed by arptables (8). These rules only affect Address
Resolution Protocol (ARP), Reverse Address Resolution Protocol (RARP) and
Dynamic Reverse Address Resolution Protocol (DRARP) frames.The columns in the file are as shown below. MAC addresses are
specified normally (6 hexadecimal numbers separated by colons).ACTIONDescribes the action to take when a frame matches the criteria
in the other columns. Possible values are:ACCEPTThis is the default action if no rules matches a frame;
it lets the frame go through.DROPCauses the frame to be dropped.SNAT:ip-addressModifies the source IP address to the specified
ip-address.DNAT:ip-addressModifies the destination IP address to the specified
ip-address.SMAT:mac-addressModifies the source MAC address to the specified
mac-address.DMAT:mac-addressModifies the destination MAC address to the specified
mac-address.SNATC:ip-addressLike SNAT except that the frame is then passed to the
next rule.DNATC:ip-addressLike DNAT except that the frame is then passed to the
next rule.SMATC:mac-addressLike SMAT except that the frame is then passed to the
next rule.DMATC:mac-addressLike DMAT except that the frame is then passed to the
next rule.SOURCE - [interface[:[!]ipaddress[/ipmask][:[!]macaddress[/macmask]]]]WhereinterfaceIs an interface defined in
shorewall-interfaces(5).ipaddressis an IPv4 address. DNS names are not allowed.ipmaskspecifies a mask to be applied to
ipaddress.macaddressThe source MAC address.macmaskMask for MAC address; must be specified as 6 hexadecimal
numbers separated by colons.When '!' is specified, the test is inverted.If not specified, matches only frames originating on the
firewall itself.Either SOURCE or DEST must be specified.DEST - [interface[:[!]ipaddress[/ipmask][:[!]macaddress[/macmask]]]]WhereinterfaceIs an interface defined in
shorewall-interfaces(5).ipaddressis an IPv4 address. DNS Names are not allowed.ipmaskspecifies a mask to be applied to frame
addresses.macaddressThe destination MAC address.macmaskMask for MAC address; must be specified as 6 hexadecimal
numbers separated by colons.When '!' is specified, the test is inverted and the rule
matches frames which do not match the specified address/mask.If not specified, matches only frames originating on the
firewall itself.If both SOURCE and DEST are specified, then both interfaces
must be bridge ports on the same bridge.Either SOURCE or DEST must be specified.ARP OPCODE - [[!]opcode]Optional. Describes the type of frame. Possible
opcode values are:1ARP Request2ARP Reply3RARP Request4RARP Reply5Dynamic RARP Request6Dynamic RARP Reply7Dynamic RARP Error8InARP Request9ARP NAKWhen '!' is specified, the test is inverted and the rule
matches frames which do not match the specified
opcode.ExampleThe eth1 interface has both a public IP address and a private
address (10.1.10.11/24). When sending ARP requests to 10.1.10.0/24, use
the private address as the IP source:#ACTION SOURCE DEST ARP OPCODE
SNAT:10.1.10.11 - eth1:10.1.10.0/24 1FILES/etc/shorewall/arprules
shorewall-docs-xml-4.5.21/ports.xml 0000644 0001750 0001750 00000053456 12222401136 017122 0 ustar teastep teastep
Ports Required for Various Services/ApplicationsTomEastepCristian Rodriguez R.2001-Thomas M. EastepPermission 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.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.This article applies to Shorewall 3.0 and
later. If you are running a version of Shorewall earlier than Shorewall
3.0.0 then please see the documentation for that releaseImportant NotesShorewall distribution contains a library of user-defined macros
that allow for easily allowing or blocking a particular application.
ls /usr/share/shorewall/macro.*
for the list of macros in your distribution. If you find what you need,
you simply use the macro in a rule. For example, to allow DNS queries
from the dmz zone to the net zone:#ACTION SOURCE DESTINATION
DNS(ACCEPT) dmz netIn 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)
FTP(ACCEPT) <source><destination>You would code your rule as follows:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
FTP(DNAT) net dmz:192.168.1.4 Auth (identd)It is now the 21st
Century ; don't use identd in production
anymore.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Auth(ACCEPT) <source><destination>BitTorrentThis information is valid only for Shorewall 3.2 or later.This rule assumes that your
BitTorrent client listens on the default
port(s)#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
BitTorrent(ACCEPT)<source><destination>DNS#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
DNS(ACCEPT) <source><destination>Note that if you are setting up a DNS server that supports recursive
resolution, the server is the <destination> for
resolution requests (from clients) and is also the
<source> of recursive resolution requests
(usually to other servers in the 'net' zone). So for example, if you have
a public DNS server in your DMZ that supports recursive resolution for
local clients then you would need:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
DNS(ACCEPT) all dmz
DNS(ACCEPT) dmz net Recursive Resolution means that if the server itself can't resolve
the name presented to it, the server will attempt to resolve the name
with the help of other servers.EmuleThis information is valid only for Shorewall 3.2 or later.In contrast to how the rest of this article is organized, for emule
I will give you the rules necessary to run emule on a single machine in
your loc network (since that's what 99.99% of you want to do). Assume
that:The internal machine running emule has IP address
192.168.1.4.You use Masquerading or SNAT for the local network.The zones are named as they are in the two- and three-interface
QuickStart guides).Your loc->net policy is ACCEPT/etc/shorewall/rules:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Edonkey(DNAT) net loc:192.168.1.4
#if you wish to enable the Emule webserver, add this rule too.
DNAT net loc:192.168.1.4 tcp 4711FTP#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
FTP(ACCEPT) <source><destination>Look here for much more
information.GnutellaThe internal machine running a Gnutella Client has IP address
192.168.1.4.You use Masquerading or SNAT for the local network.The zones are named as they are in the two- and three-interface
QuickStart guides).Your loc->net policy is ACCEPT#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Gnutella(DNAT) net loc:192.168.1.4ICQ/AIM#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ICQ(ACCEPT) <source> netIMAPWhen accessing your mail from the Internet, use onlyIMAP over
SSL.This information is valid only for Shorewall 3.2 or later.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
IMAP(ACCEPT) <source><destination> # Unsecure IMAP
IMAPS(ACCEPT) <source> <destination> # IMAP over SSL.IPSEC#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 500Lots more information here and here.LDAPThis information is valid only for Shorewall 3.2 or later.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
LDAP(ACCEPT) <source> <destination> #Insecure LDAP
LDAPS(ACCEPT) <source> <destination> # LDAP over SSLMy\SQLThis information is valid only for Shorewall 3.2 or later.Allowing access from untrusted hosts to your
MySQL server represents a severe security risk.DO NOT USE THIS if you don't know
how to deal with the consequences, you have been warned.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
MySQL(ACCEPT) <source> <destination>NFS#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <z1>:<list of client IPs> <z2>:a.b.c.d tcp 111
ACCEPT <z1>:<list of client IPs> <z2>:a.b.c.d udpFor more NFS information, see http://lists.shorewall.net/~kb/.NTP (Network Time Protocol)#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
NTP(ACCEPT) <source><destination>PCAnywhere#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
PCA(ACCEPT) <source><destination>POP3If Possible , Avoid this protocol
, use IMAP instead.This information is valid only for Shorewall 3.2 or later#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
POP3(ACCEPT) <source><destination> # Secure
POP3S(ACCEPT) <source> <destination> #Unsecure Pop3PPTP#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <source><destination> 47
ACCEPT <source><destination> tcp 1723Lots more information here and here.rdate#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Rdate(ACCEPT) <source><destination>rsync#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Rsync(ACCEPT) <source><destination>SiproxdThis assumes siproxd is running on the
firewall and is using the default ports.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
REDIRECT loc 5060 udp 5060
ACCEPT net fw udp 5060
ACCEPT net fw udp 7070:7089SSH/SFTP#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
SSH(ACCEPT)<source><destination>SMB/NMB (Samba/Windows Browsing/File
Sharing)#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
SMB(ACCEPT) <source> <destination>
SMB(ACCEPT) <destination><source>Also, see this page.SMTPThis information is valid only for Shorewall 3.2 or later.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
SMTP(ACCEPT) <source><destination> #Insecure SMTP
SMTPS(ACCEPT) <source><destination> #SMTP over SSL (TLS)SNMP#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
SNMP(ACCEPT) <source><destination>SVNThis information is valid only for Shorewall 3.2 or later.This rule is for Subversion running in svnserve mode only.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
SVN(ACCEPT) <source><destination>TelnetThe telnet protocol is very
insecure, don't use it.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Telnet(ACCEPT) <source><destination>TFTPYou must have TFTP connection tracking support in your kernel. If
modularized, the modules are ip_conntrack_tftp (and ip_nat_tftp if any form of NAT is involved) These
modules may be loaded using entries in
/etc/shorewall/modules. The ip_conntrack_tftp module must be loaded first. Note
that the /etc/shorewall/modules file released with
recent Shorewall versions contains entries for these modules.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <source><destination> udp 69Traceroute#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Trcrt(ACCEPT) <source><destination> #Good for 10 hopsUDP traceroute uses ports 33434 through 33434+<max number of
hops>-1. Note that for the firewall to respond with a TTL expired ICMP
reply, you will need to allow ICMP 11 outbound from the firewall. The
standard Shorewall sample configurations all set this up for you
automatically since those sample configurations enable all ICMP packet
types originating on the firewall itself.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT fw net icmp
ACCEPT fw loc icmp
ACCEPT fw ...Usenet (NNTP)#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
NNTP(ACCEPT) <source><destination>
NNTPS(ACCEPT) <source> <destination> # secure NNTPTCP Port 119VNCThis information is valid only for Shorewall 3.2 or later.Vncviewer to Vncserver -- TCP port 5900 + <display
number>.the following rule handles VNC traffic for VNC displays 0 -
9.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
VNC(ACCEPT) <source><destination>Vncserver to Vncviewer in listen mode -- TCP port 5500.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
VNCL(ACCEPT) <source><destination>VonageThe standard Shorewall loc->net ACCEPT policy is all that is
required for Vonage IP phone service to work,
provided that you have loaded the tftp helper modules (add the following
entries to /etc/shorewall/modules if they are not there already):Web AccessThis information is valid for Shorewall 3.2 or later.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
HTTP(ACCEPT) <source><destination> #Insecure HTTP
HTTPS(ACCEPT) <source> <destination> #Secure HTTPWebmin#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Webmin(ACCEPT) <source><destination>Webmin
use TCP port 10000.Whois#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Whois(ACCEPT) <source><destination>X/XDMCPAssume that the Chooser and/or X Server are running at
<chooser> and the Display Manager/X
applications are running at <apps>.#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT <chooser> <apps> udp 177 #XDMCP
ACCEPT <apps> <chooser> tcp 6000:6009 #X Displays 0-9Other Source of Port InformationDidn'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
shorewall-docs-xml-4.5.21/shorewall_quickstart_guide.xml 0000644 0001750 0001750 00000010423 12222401136 023365 0 ustar teastep teastep
Shorewall QuickStart Guides (HOWTOs)TomEastep2001-2005Thomas M. EastepPermission 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.Do not attempt to install Shorewall on a
remote system. You are virtually assured to lock yourself out of that
system.With thanks to Richard who reminded me once again that we must all
first walk before we can run.The French Translations of the single-IP guides are courtesy of
Patrice Vetsel. Updated for Shorewall 2.0 by Fabien Demassieux and for 3.0
by Guy Marcenac.The Russian Translations are courtesy of Alex at tut.by.Before You StartPlease read the short article Introduction to Shorewall to familiarize
yourself with basic Shorewall concepts.The GuidesThese guides provide step-by-step instructions for configuring
Shorewall in common firewall setups.If you want the firewall system to handle a single public IP addressThese guides are designed to get your first firewall up and
running quickly in the three most common Shorewall configurations. If
you want to learn more about Shorewall than is explained in these simple
guides then the Shorewall Setup
Guide (Version
Française) is for you.Standalone Linux System
(Version Française) (Russian Version)Version en EspañolTwo-interface Linux
System acting as a firewall/router for a small local network
(Version Française)
(Russian
Version)Three-interface
Linux System acting as a firewall/router for a small local network
and a DMZ.. (Version
Française) (Russian
Version)If you want the firewall system to handle more than one public IP
addressThe Shorewall Setup
Guide (Version
Française) outlines the steps necessary to set up a firewall
where there are multiple public IP addresses involved or if you want to
learn more about Shorewall than is explained in the single-address
guides above.
shorewall-docs-xml-4.5.21/standalone_fr.xml 0000644 0001750 0001750 00000077562 12222401136 020576 0 ustar teastep teastep
Firewall Monoposte (une interface)Version Française de Standalone
FirewallTomEastepPatriceVetselTraduction française initialeFabienDemassieuxAdaptation française version 2.0GuyMarcenacAdaptation française version 3.0 et version 4.02002-2007Thomas M. EastepPatrice VetselFabien DemassieuxGuy MarcenacPermission est accordée de copier, distribuer et/ou modifier ce
document selon les termes de la Licence de Documentation Libre GNU (GNU
Free Documentation License), version 1.2 ou toute version ultérieure
publiée par la Free Software Foundation ; sans section Invariables, sans
première de Couverture, et sans texte de quatrième de couverture. Une
copie de la présente Licence est incluse dans la section intitulée. Une
traduction française de la licence se trouve dans la section
Licence de
Documentation Libre GNU. Ce paragraphe est une
traduction française pour aider à votre compréhension. Seul le texte
original en anglais présenté ci-dessous fixe les conditions
d'utilisation de cette documentation.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.Notes du traducteur : Le guide
initial a été traduit par VETSEL Patrice et la
révision pour la version 2 de Shorewall a été effectuée par Fabien Demassieux. J'ai assuré la
révision pour l'adapter à la version 3, puis 4 de Shorewall. Si vous
trouvez des erreurs ou des améliorations à y apporter vous pouvez me contacter.Cet article s'applique à Shorewall 4.0 et à
ses versions ultérieures. Si vous utilisez une version plus ancienne de
Shorewall, référez-vous à la documentation s'appliquant à votre
version.Ne tentez pas d'installer Shorewall sur un
système distant. Il est pratiquement certain que vous vous enfermerez à
l'extérieur de ce système.IntroductionConfigurer Shorewall sur un système isolé Linux est très simple si
vous comprenez les bases et suivez la documentation.Ce guide ne prétend pas vous apprendre tous les rouages de
Shorewall. Il se concentre sur ce qui est nécessaire pour configurer
Shorewall dans son utilisation la plus courante :Un système LinuxUne seule adresse IP externeUne connexion passant par un modem câble,
ADSL, ISDN-RNIS, Frame Relay,
RTC... ou bien une connexion à un réseau local
(LAN) et vous souhaitez simplement protéger votre
système Linux des autres systèmes sur ce réseau local.Pré-requis systèmeShorewall a besoin que le package
iproute/iproute2
soit installé (avec la distribution RedHat, le
package s'appelle iproute). Vous pouvez vérifier que
le package est installé en contrôlant la présence du programme
ip sur votre firewall. En tant que
root, vous pouvez utiliser la
commande which pour cela:[root@gateway root]# which ip
/sbin/ip
[root@gateway root]#Avant de commencerJe vous recommande de commencer par une lecture complète du guide
afin de vous familiariser avec les concepts mis en oeuvre, puis de
recommencer la lecture et seulement alors d'appliquer vos modifications
de configuration.Si vous éditez vos fichiers de configuration sur un système
Windows, vous devez les enregistrer comme des
fichiers Unix si votre éditeur supporte cette
option, sinon vous devez les convertir avec
dos2unix avant d'essayer de les utiliser. De la
même manière, si vous copiez un fichier de configuration depuis votre
disque dur Windows vers une disquette, vous
devez lancer dos2unix sur la copie avant de
l'utiliser avec Shorewall.Version
Windows de dos2unixVersion Linux de
dos2unixConventionsLes points ou les modifications qui s'imposent sont indiqués par
.PPTP/ADSLSi vous êtes équipé d'un modem
ADSL et que vous utilisez
PPTP pour communiquer avec un
serveur à travers ce modem, vous devez faire les changements suivants en plus de ceux décrits
ci-dessous. ADSL avec
PPTP est répandu en Europe,
notamment en Autriche.Les Concepts de ShorewallLes fichiers de configuration pour Shorewall sont situés dans le
répertoire /etc/shorewall -- pour
de simples paramétrages, vous n'aurez à faire qu'avec quelques-uns d'entre
eux comme décrit dans ce guide. Après avoir installé Shorewall,vous pourrez trouver les
exemples de la manière suivante:Si vous avez installé shorewall en utilisant un
RPM, les exemples seront dans le sous-répertoire
Samples/one-interface/ du
répertoire de la documentation de Shorewall. Si vous ne savez pas où
se trouve le répertoire de la documentation de Shorewall, vous
pouvez trouver les exemples en utilisant cette commande:~# rpm -ql shorewall | fgrep one-interface
/usr/share/doc/packages/shorewall/Samples/one-interface
/usr/share/doc/packages/shorewall/Samples/one-interface/interfaces
/usr/share/doc/packages/shorewall/Samples/one-interface/policy
/usr/share/doc/packages/shorewall/Samples/one-interface/rules
/usr/share/doc/packages/shorewall/Samples/one-interface/zones
~#Si vous avez installé depuis le tarball, les exemples sont
dans le répertoire Samples/one-interface du
tarball.Si vous avez installé en utilisant un .deb de Shorewall 3.x,
les exemples sont dans
/usr/share/doc/shorewall/examples/one-interface.
Il vous faut installer le paquetage shorewall-doc.Si vous avez installé en utilisant un .deb de Shorewall 4.x,
les exemples sont dans /usr/share/doc/shorewall/examples/one-interface.
Vous n'avez pas besoin d'installer le paquetage shorewall-doc pour
pouvoir accéder aux exemples.Note aux utilisateurs de Debian et de
UbuntuSi vous vous servez du .deb pour installer, vous vous rendrez
compte que votre répertoire /etc/shorewall est
vide. Ceci est voulu. Les squelettes des fichiers de configuration se
trouvent sur votre système dans le répertoire /usr/share/doc/shorewall/default-config.
Copiez simplement les fichiers dont vous avez besoin depuis ce
répertoire dans /etc/shorewall,
puis modifiez ces copies.Si vous installez la version 3.4.0 de Shorewall ou une version
ultérieure, au fur et à mesure de la présentation de chaque fichier, je
vous suggère de jeter un oeil à ceux qui sont physiquement présents sur
votre système et que vous voyez la page de manuel (man
page) pour ce fichier. Par exemple, tapez man
shorewall-zones à l'invite du système pour voir la page de
manuel du fichier /etc/shorewall/zones.Si vous installez une version antérieure à shorewall 3.4.0, au fur
et à mesure de la présentation de chaque fichier, je vous suggère de jeter
un oeil à ceux qui sont physiquement présents sur votre système -- chacun
de ces fichiers contient des instructions de configuration détaillées et
des entrées par défaut.Shorewall voit le réseau où il fonctionne, comme étant composé d'un
ensemble de zones. Dans les fichiers de configuration
fournis dans l'archive d'exemples pour une seule interface, deux zones
seulement sont définies :#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4Les zones de Shorewall sont définies dans /etc/shorewall/zones.Remarquez que Shorewall reconnaît le système de firewall comme étant
sa propre zone. Le nom de la zone firewall (fw dans l'exemple plus haut) est stocké dans la
variable d'environnement $FW, qui peut être utilisée
depuis l'ensemble des autres fichiers de configuration de Shorewall pour
faire référence au firewall lui-même.Les règles concernant le trafic à autoriser ou à interdire sont
exprimées en utilisant les termes de zones.Vous exprimez votre politique par défaut pour les connexions
d'une zone vers une autre zone dans le fichier /etc/shorewall/policy.Vous définissez les exceptions à ces politiques pas défaut dans
le fichier /etc/shorewall/rules.Pour chaque connexion demandant à entrer dans le firewall, la
requête est en premier lieu vérifiée par rapport au contenu du fichier
/etc/shorewall/rules. Si aucune
règle dans ce fichier ne correspond à la demande de connexion alors la
première politique dans le fichier
/etc/shorewall/policy qui y correspond sera
appliquée. S'il y a une action commune définie pour
cette politique dans /etc/shorewall/actions ou dans
/usr/share/shorewall/actions.std cette action commune
sera exécutée avant que la politique ne soit appliquée. Le but de l'action
commune est double:Elle ignore (DROP) ou rejette (REJECT) silencieusement le trafic
courant qui n'est pas dangereux qui sans cela encombrerait votre
fichier journal - les messages de broadcast, par exemple.Elle garantit que le trafic nécessaire à un fonctionnement
normal est autorisé à traverser le firewall — ICMP
fragmentation-needed par exempleLe fichier /etc/shorewall/policy inclus dans
l'archive d'exemple (one-interface) contient les politiques
suivantes:#SOURCE ZONE DESTINATION ZONE POLICY LOG LEVEL LIMIT:BURST
$FW net ACCEPT
net all DROP info
all all REJECT infoCes politiques vont :Autoriser (ACCEPT) toute demande de connexion depuis le firewall
vers internetIgnorer (DROP) toutes les demandes de connexion depuis internet
vers votre firewallRejeter (REJECT) toutes les autres requêtes de connexion.
Shorewall à toujours besoin de cette dernière politique. A ce point, éditez
votre /etc/shorewall/policy et faites y les
changements que vous désirez.Interface ExterneLe firewall possède une seule interface réseau. Lorsque la connexion
internet passe par un "modem" câble ou
ADSL, l'Interface
Externe sera l'adaptateur ethernet qui est connecté à ce
Modem (par exemple eth0). Par contre, si vous vous connectez
par PPPoE
(Point-to-Point Protocol over Ethernet) ou par
PPTP(Point-to-Point Tunneling Protocol), l'interface
externe sera une interface ppp (par exemple ppp0). Si vous vous connectez par un simple
modem RTC, votre interface externe
sera aussi ppp0. Si vous vous
connectez en utilisant l'ISDN, votre
interface externe sera ippp0.Assurez-vous de savoir laquelle de vos interfaces est l'interface
externe. Certains utilisateurs qui avaient configuré la mauvaise
interface ont passé des heures avant de comprendre leur erreur. Si vous
n'êtes pas sûr, tapez la commande ip route ls en tant
que root. L'interface listée à la fin (default) devrait être votre
interface externe.Exemple:root@lists:~# ip route ls
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
10.13.10.0/24 dev tun1 scope link
192.168.2.0/24 via 192.168.2.2 dev tun0
206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176
10.10.10.0/24 dev tun1 scope link
default via 206.124.146.254 dev eth0
root@lists:~# Dans cette exemple, l'interface externe est eth0.Les fichiers de configuration d'exemple pour le firewall monoposte
(one-interface) supposent que votre interface externe est eth0. Si votre configuration est différente,
vous devrez modifier le
fichier/etc/shorewall/interfaces en conséquence. Tant
que vous y êtes, vous pourriez parcourir la liste des options qui sont
spécifiées pour les interfaces. Quelques astuces:Si votre interface vers l'extérieur est ppp0
ouippp0, vous pouvez remplacer le
detect dans la seconde colonne par un -
(sans guillemets).Si votre interface vers l'extérieur est ppp0 or
ippp0 ou si vous avez une
adresse IP statique, vous pouvez enlever
dhcp de la liste des options .Adresses IPAvant d'aller plus loin, nous devons dire quelques mots au sujet des
adresses IP. Normalement, votre Fournisseur d' Accès Internet
(FAI) ne vous allouera qu'une seule adresse IP. Cette
adresse peut vous être allouée par DHCP (Dynamic Host
Configuration Protocol), lors de l'établissement de votre connexion (modem
standard) ou bien lorsque vous établissez un autre type de connexion
PPP (PPPoA,
PPPoE, etc.). Dans certains cas , votre fournisseur
peut vous allouer une adresse statique IP. Dans ce cas vous devez
configurer l'interface externe de votre firewall afin d'utiliser cette
adresse de manière permanente.La RFC 1918 réserve des plages d'adresses IP pour utilisation dans
les réseau privés:10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255Ces adresses sont parfois nommées non-routables
car les routeurs centraux d'internet ne transfèrent pas un paquet dont la
destination est une adresse réservée par la RFC 1918. Dans certain cas
cependant, les FAI (fournisseurs d'accès Internet)
peuvent vous affecter une de ces adresses et utiliser la Traduction
d'Adresses Réseau (NAT Network Address
Translation) pour réécrire les en-têtes des paquets transmis en
provenance ou à destination d'internet.Avant de lancer Shorewall, il faut
impérativement regarder l'adresse IP de votre interface externe, et, si
elle est dans l'une des plages précédentes, vous devez enlever l'option
"norfc1918" dans la ligne concernant l'interface externe dans le fichier
/etc/shorewall/interfacesPour déterminer l'adresse IP de votre interface externe, en tant
que root tapez ip addr ls dev <interface> à
l'invite du système. <interface> étant
votre interface externe. La ligne qui commence par
inet vous donne votre adresse IP.Exemple:root@lists:~# ip addr ls dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc htb qlen 1000
link/ether 00:02:e3:08:48:4c brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet6 fe80::202:e3ff:fe08:484c/64 scope link
valid_lft forever preferred_lft forever
root@lists:~# Dans cet exemple, l'adresse IP de votre interface externe est
206.124.146.176.Journalisation (log)Shorewall ne produit pas un fichier journal lui-même, mais il
s'appuie sur votre configuration de la
journalisation système. Les commandes suivantes nécessitent un
bonne configuration de la journalisation, car elles ont besoin de
connaitre le fichier dans lequel netfilter enregistre ses messages.shorewall show log (Affiche les 20 derniers
messages enregistrés par netfilter)shorewall logwatch (Consulte le fichier
journal à un intervalle régulier paramétrable)shorewall dump (Produit un état très détaillé
à inclure à vos rapports d'anomalie)Il est important que ces commandes fonctionnent correctement. En
effet, lorsque vous rencontrez des problèmes de connexion alors que
shorewall est actif, la première chose que vous devriez faire est de
regarder le journal netfilter, et vous pourrez généralement résoudre
rapidement votre problème en vous aidant de la FAQ 17 de Shorewall.La plupart du temps, les messages de Netfilter sont journalisés dans
le fichier /var/log/messages. Certaines version
récentes de SuSE/OpenSuSE sont pré configurées pour
utiliser syslog-ng et journalisent les messages de netfilter dans le
fichier /var/log/firewall.Si votre distribution enregistre les message de netfilter dans un
autre fichier que /var/log/messages, il faut modifier
le paramètre LOGFILE dans le fichier
/etc/shorewall/shorewall.conf et y spécifier le nom de votre
fichier journal.Le paramètre LOGFILE ne contrôle pas le fichier dans lequel
netfilter va enregistrer ses messages -- Il indique simplement à
/sbin/shorewalloù trouver le fichier
journal.Permettre d'autres connexionsShorewall inclue une collection de macros
qui peuvent être utilisées pour rapidement autoriser ou refuser des
services. Vous pouvez trouver une liste des macros comprises dans votre
version de Shorewall en utilisant la commande ls
/usr/share/shorewall/macro.* ou bien la
commande shorewall show macros si vous utilisez une
version 3.0.3 ou ultérieure de shorewall.Si vous souhaitez autoriser des connexions depuis internet vers
votre firewall et que vous avez trouvé une macro appropriée dans
/etc/shorewall/macro.*, le
format général d'une règle dans /etc/shorewall/rules
est le suivant:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
<macro>/ACCEPT net $FWAssurez-vous d'ajouter vos règles après la ligne contenant
SECTION NEW.Un serveur Web et un serveur IMAP sur votre firewall, accessibles
depuis l'extérieur:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
Web/ACCEPT net $FW
IMAP/ACCEPT net $FWVous pouvez aussi choisir de coder vos règles directement, sans
utiliser de macro pré-définie. Ceci sera nécessaire quand aucune macro
pré-définie ne répond à vos besoins. Dans ce cas, le format général d'une
règle dans /etc/shorewall/rules est:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT net $FW <protocol><port>Un serveur Web et un serveur IMAP sur votre firewall, accessibles
depuis l'extérieur:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
ACCEPT net $FW tcp 80
ACCEPT net $FW tcp 143Si vous ne savez pas quel port ou protocole utilise une application
donnée, allez voir ici.Je ne recommande pas d'activer telnet
depuis/vers internet car il utilise du texte en clair (y compris pour le
login !). Si vous voulez un accès shell à votre firewall, utilisez
SSH:#ACTION SOURCE DESTINATION PROTO DEST PORT(S)
SSH/ACCEPT net $FW Maintenant, éditez votre fichier de configuration /etc/shorewall/rules
pour ajouter, modifier ou supprimer d'autres connexions suivant vos
besoins.Démarrer et Arrêter Votre FirewallLa procédure d'installation
configure votre système pour lancer Shorewall dès le boot du système, mais
le lancement est désactivé, de façon à ce que votre système ne tente pas
de lancer Shorewall avant que la configuration ne soit terminée. Une fois
que vous en avez fini avec la configuration du firewall, vous devez éditer
/etc/shorewall/shorewall.conf et y mettre STARTUP_ENABLED=Yes.Les utilisateurs des paquets .deb doivent
éditer /etc/default/shorewall et mettre
startup=1.Vous devez activer le lancement de Shorewall
en éditant /etc/shorewall/shorewall.conf et en y
mettant STARTUP_ENABLED=Yes.Le firewall est activé en utilisant la commande
shorewall start et arrêté avec la
commande shorewall stop. Lorsque le
firewall est arrêté, le routage est autorisé sur les hôtes qui possèdent
une entrée dans /etc/shorewall/routestopped.
Un firewall qui tourne peut être relancé en utilisant la commande
shorewall restart. Si vous voulez
enlever toute trace de Shorewall sur votre configuration de Netfilter,
utilisez shorewall
clearSi vous êtes connecté à votre firewall depuis internet, n'essayez
pas d'exécuter une commande shorewall
stop tant que vous n'avez pas ajouté une entrée dans
/etc/shorewall/routestopped
pour l'adresse IP à partir de laquelle vous êtes connecté . De la même
manière, je vous déconseille d'utiliser shorewall
restart; il est plus intéressant de créer une configuration
alternative et de la tester en utilisant la commande
shorewall
trySi cela ne marche pasVérifiez à nouveau chacun des points repérés par un flèche
rouge.Vérifiez vos journaux.Vérifiez le Troubleshooting
Guide.Vérifiez la FAQ.Autres Lectures RecommandéesJe vous recommande vivement de lire la page des fonctionnalités générales des
fichiers de configuration -- elle contient des astuces sur des
possibilités de Shorewall qui peuvent rendre plus aisée l'administration
de votre firewall Shorewall.
shorewall-docs-xml-4.5.21/two-interface.xml 0000644 0001750 0001750 00000167442 12222401136 020523 0 ustar teastep teastep
Basic Two-Interface FirewallTomEastep2002-2009Thomas M. EastepPermission 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.This article applies to Shorewall 4.4 and
later. If you are running a version of Shorewall earlier than Shorewall
4.4.0 then please see the documentation for that
release.IntroductionSetting up a Linux system as a firewall for a small network 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 its most common configuration:Linux system used as a firewall/router for a small local
network.Single public IP address. If
you have more than one public IP address, this is not the guide you
want -- see the Shorewall Setup
Guide instead.Internet connection through cable modem, DSL, ISDN, Frame Relay,
dial-up ...Here is a schematic of a typical installation: Common two interface firewall configurationIf 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. Windows
Version of dos2unixLinux
Version of dos2unixSystem RequirementsShorewall 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.ConventionsPoints at which configuration changes are recommended are flagged
with .Configuration notes that are unique to Debian and it's derivatives
are marked with .PPTP/ADSLIf 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.Shorewall ConceptsThe 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, locate the two-interfaces samples:If you installed using an RPM, the samples will be in the
Samples/two-interfaces/ subdirectory of the Shorewall
documentation directory. If you don't know where the Shorewall
documentation directory is, you can find the samples using this
command:~# rpm -ql shorewall | fgrep two-interfaces
/usr/share/doc/packages/shorewall/Samples/two-interfaces
/usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces
/usr/share/doc/packages/shorewall/Samples/two-interfaces/masq
/usr/share/doc/packages/shorewall/Samples/two-interfaces/policy
/usr/share/doc/packages/shorewall/Samples/two-interfaces/routestopped
/usr/share/doc/packages/shorewall/Samples/two-interfaces/rules
/usr/share/doc/packages/shorewall/Samples/two-interfaces/zones
~#If you installed using the tarball, the samples are in the
Samples/two-interfaces directory in the tarball.If you installed using a Shorewall 3.x .deb, the samples are
in /usr/share/doc/shorewall/examples/two-interfaces. You must
install the shorewall-doc package.If you installed using a
Shorewall 4.x .deb, the samples are in /usr/share/doc/shorewall-common/examples/two-interfaces.
You do not need the shorewall-doc package to have access to the
samples.Note to Debian and Ubuntu
UsersIf you install using the .deb, you will find that your
/etc/shorewall directory
is empty. This is intentional. The released configuration file
skeletons may be found on your system in the directory /usr/share/doc/shorewall/default-config.
Simply copy the files you need from that directory to /etc/shorewall and modify the
copies.As each file is introduced, I suggest that you look at the actual
file on your system and that you look at the man page for that
file. For example, to look at the man page for the
/etc/shorewall/zones file, type man
shorewall-zones at a shell prompt.Note: Beginning with Shorewall 4.4.20.1, there are versions of the
sample files that are annotated with the corresponding manpage contents.
These files have names ending in '.annotated'. You might choose to look at
those files instead.Shorewall views the network where it is running as being composed of
a set of zones. In the two-interface sample configuration, the following
zone names are used:#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
loc ipv4Zones are defined in the /etc/shorewall/zones
file.Note that Shorewall recognizes the firewall system as its own zone -
when the /etc/shorewall/zones file is processed, the name of the firewall
zone is stored in the shell variable $FW which may be used to refer to the
firewall zone throughout the Shorewall configuration.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 there is a common action defined for
the policy in /etc/shorewall/actions or
/usr/share/shorewall/actions.std then that action is
performed before the action is applied. The purpose of the common action
is two-fold:It silently drops or rejects harmless common traffic that would
otherwise clutter up your log — Broadcasts for example.If ensures that traffic critical to correct operation is allowed
through the firewall — ICMP fragmentation-needed
for example.The /etc/shorewall/policy
file included with the two-interface sample has the following policies:
#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT infoIn the two-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
InternetDrop (ignore) all connection requests from the Internet to
your firewall or local networkOptionally accept all connection requests from the firewall to
the Internet (if you uncomment the additional policy)reject all other connection requests. The word info in the LOG LEVEL
column for the DROP and REJECT policies indicates that packets dropped or
rejected under those policies should be logged at that level.It is important to note that Shorewall policies (and rules) refer to
connections and not packet flow. With the
policies defined in the /etc/shorewall/policy file shown above,
connections are allowed from the loc zone to the
net zone even though connections are not allowed from
the loc zone to the firewall itself.Some people want to consider their firewall to be part of their
local network from a security perspective. If you want to do this, add
these two policies:#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc $FW ACCEPT
$FW loc ACCEPTAt this point, edit your /etc/shorewall/policy
and make any changes that you wish.Network InterfacesThe firewall has two 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 via
ISDN, your external interface will be ippp0.Be sure you know which interface is your external interface. Many
hours have been spent floundering by users who have configured the wrong
interface. If you are unsure, then as root type ip route
ls at the command line. The device listed in the last
(default) route should be your external interface.Example:root@lists:~# ip route ls
192.168.1.1 dev eth0 scope link
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
192.168.3.0/24 dev br0 proto kernel scope link src 192.168.3.254
10.13.10.0/24 dev tun1 scope link
192.168.2.0/24 via 192.168.2.2 dev tun0
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.254
206.124.146.0/24 dev eth0 proto kernel scope link src 206.124.146.176
10.10.10.0/24 dev tun1 scope link
default via 206.124.146.254 dev eth0
root@lists:~# In that example, eth0 is
the external interface.If your external interface is ppp0 or ippp0 then you will want to set
CLAMPMSS=yes in /etc/shorewall/shorewall.conf.Your Internal Interface will be an Ethernet
adapter (eth1 or eth0) and will be connected to a hub or
switch. Your other computers will be connected to the same hub/switch
(note: If you have only a single internal system, you can connect the
firewall directly to the computer using a cross-over cable). Do not connect the internal and external
interface to the same hub or switch except for testing.You
can test using this kind of configuration if you specify the arp_filter option or the arp_ignore 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.Do not configure a default route on your
internal interface. Your firewall should have exactly one
default route via your ISP's Router.The Shorewall two-interface sample configuration assumes that the
external interface is eth0 and the
internal interface is eth1. 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:If your external interface is ppp0 or ippp0, you can replace the
detect in the second column with a -
(minus the quotes).If your external interface is ppp0 or ippp0 or if you have a static
IP address, you can remove dhcp
from the option list.If your internal interface is a bridge create using the
brctl utility then you must
add the routeback option to the option
list.IP AddressesBefore 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. However
your external 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 in your internal network (the Internal Interface 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.255You will want to assign your
addresses from the same sub-network (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 leading 1 bits from the left
of the subnet mask. Range:10.10.10.0 -
10.10.10.255Subnet
Address:10.10.10.0Broadcast
Address:10.10.10.255CIDR
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 (computer 1 and computer 2 in the above
diagram) should be configured with their default gateway to be the
IP address of the firewall's internal 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
(link).The remainder of this guide will assume that you have
configured your network as shown here: The default gateway for computer's 1 & 2 would be
10.10.10.254. 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.IP Masquerading (SNAT)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 computer 1 in the above diagram) 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 appear to the destination
Internet host 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 across the Internet so the
remote host can't address its response to computer 1). When the firewall
receives a return packet, it rewrites the destination address back to
10.10.10.1 and forwards the
packet on to computer 1.On Linux systems, the above process is often referred to as
IP Masquerading but 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. You will normally use Masquerading if your external
IP is dynamic and SNAT if the
IP is static.If your external firewall interface is eth0, you do not need to modify the file
provided with the sample. Otherwise, edit
/etc/shorewall/masq and
change the first column to the name of your external interface.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 (Masquerade). Entering your static IP in
column 3 (SNAT) makes the processing of outgoing packets a little more
efficient.If you are using the Debian package, please
check your shorewall.conf file to ensure that the
following is set correctly; if it is not, change it
appropriately:IP_FORWARDING=OnLoggingShorewall does not maintain a log itself but rather relies on your
system's logging configuration.
The following commands rely
on knowing where Netfilter messages are logged:shorewall show log (Displays the last 20
netfilter log messages)shorewall logwatch (Polls the log at a
settable intervalshorewall dump (Produces an extensive report
for inclusion in Shorewall problem reports)It is important that these commands work properly because when you
encounter connection problems when Shorewall is running, the first thing
that you should do is to look at the Netfilter log; with the help of
Shorewall FAQ 17, you can usually
resolve the problem quickly.The Netfilter log location is distribution-dependent:Debian and its derivatives log Netfilter messages to
/var/log/kern.log.Recent SuSE/OpenSuSE releases come
preconfigured with syslog-ng and log netfilter messages to
/var/log/firewall.For other distributions, Netfilter messages are most commonly
logged to /var/log/messages.If you are running a distribution that logs netfilter messages to a
log other than /var/log/messages, then modify the
LOGFILE setting in /etc/shorewall/shorewall.conf to
specify the name of your log.The LOGFILE setting does not control where the Netfilter log is
maintained -- it simply tells the /sbin/shorewall
utility where to find the log.Kernel Module LoadingBeginning in Shorewall 4.4.7,
/etc/shorewall/shorewall.conf contains a
LOAD_HELPERS_ONLY option which is set to in the
samples. This causes Shorewall to attempt to load the modules listed in
/usr/share/shorewall/helpers. In addition, it sets
sip_direct_media=0 when loading the
nf_conntrack_sip module. That setting is somewhat less secure than
sip_direct_media=1, but it generally
makes VOIP through the firewall work much better.The modules in /usr/share/shorewall/helpers are
those that are not autoloaded. If your kernel does not support module
autoloading and you want Shorewall to attempt to load all netfilter
modules that it might require, then set LOAD_HELPERS_ONLY=No. That will
cause Shorewall to try to load the modules listed in
/usr/share/shorewall/modules. That file does not set
sip_direct_media=0.If you need to modify either
/usr/share/shorewall/helpers or
/usr/share/shorewall/modules then copy the file to
/etc/shorewall and modify the copy.Modify the setting of LOAD_HELPER_ONLY as necessary.Port Forwarding (DNAT)One of your goals may be to run one or more servers on your local
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
the 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.For forwarding connections from the net zone to
a server in the loc zone, the general form of a
simple port forwarding rule in /etc/shorewall/rules is:
#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net loc:<server local ip address>[:<server port>] <protocol><port>If you want to forward traffic from the
loc zone to a server in the
loc zone, see Shorewall
FAQ 2.Be sure to add your rules after the line that reads SECTION NEW.The server must have a static IP address. If you assign IP
addresses to your local system using DHCP, you need to configure your
DHCP server to always assign the same IP address to systems that are
the target of a DNAT rule.Shorewall has macros for
many popular applications. Look at the output of shorewall show
macros to see what is available in your release. Macros simplify
creating DNAT rules by supplying the protocol and port(s) as shown in the
following examples.Web ServerYou run a Web Server on computer 2 in the above diagram and you want to forward
incoming TCP port 80 to that system:
#ACTION SOURCE DEST PROTO DEST PORT(S)
Web(DNAT) net loc:10.10.10.2FTP ServerYou run an FTP Server on computer 1 so you want to forward incoming
TCP port 21 to that system: #ACTION SOURCE DEST PROTO DEST PORT(S)
FTP(DNAT) net loc:10.10.10.1 For
FTP, you will also need to have
FTP connection tracking and NAT
support in your kernel. For vendor-supplied kernels, this means that
the ip_conntrack_ftp and
ip_nat_ftp modules
(nf_conntrack_ftp and
nf_nat_ftp in later 2.6 kernels) must be loaded.
Shorewall will automatically load these modules if they are available
and located in the standard place under /lib/modules/<kernel
version>/kernel/net/ipv4/netfilter. See the Shorewall FTP documentation for more
information. A couple of important points to keep in mind: You must test the above rule from a client outside of your
local network (i.e., don't test from a browser running on computers
1 or 2 or on the firewall). If you want to be able to access your
web server and/or FTP server from inside your
firewall using the IP address of your external
interface, see Shorewall FAQ
#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.#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net loc:10.10.10.2:80 tcp 5000At this point, modify /etc/shorewall/rules to
add any DNAT rules that you require.When testing DNAT rules like those shown above, you must test from
a client OUTSIDE YOUR FIREWALL (in the 'net' zone). You cannot test
these rules from inside the firewall!For DNAT troubleshooting tips, see FAQs
1a and 1b.For information about DNAT when there are multiple external IP
addresses, see the Shorewall Aliased Interface
documentation and the Shorewall Setup Guide.Domain Name Server (DNS)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. Regardless of how DNS gets configured on your
firewall, 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 your 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.
Red Hat has an RPM for a
caching name server (the RPM also requires the
bindRPM) and for Bering users,
there is dnscache.lrp. If you take this approach,
you configure your internal systems to use the firewall itself 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. 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 firewall; you do that by adding the following rules
in /etc/shorewall/rules.
#ACTION SOURCE DEST PROTO DEST PORT(S)
DNS(ACCEPT)loc $FWOther ConnectionsThe two-interface sample includes the following rules:
#ACTION SOURCE DEST PROTO DEST PORT(S)
DNS(ACCEPT) $FW netThis rule allows
DNS access from your firewall and may be removed if you
uncommented the line in /etc/shorewall/policy
allowing all connections from the firewall to the Internet.In the rule shown above, DNS(ACCEPT)is an example of
a macro invocation. Shorewall includes a number of
macros (see /usr/share/shorewall/macro.*) and you can add your own.You don't have to use defined macros when coding a rule in
/etc/shorewall/rules; Shorewall will start slightly
faster if you code your rules directly rather than using macros. The the
rule shown above could also have been coded as follows:#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT $FW net udp 53
ACCEPT $FW net tcp 53In cases where Shorewall doesn't include a defined macro to meet
your needs, you can either define the macro yourself or you can simply
code the appropriate rules directly.The sample also includes: #ACTION SOURCE DEST PROTO DEST PORT(S)
SSH(ACCEPT) loc $FW That rule allows you to run an
SSH server on your firewall and connect to that server
from your local systems.If you wish to enable other connections from your firewall to other
systems, the general format using a macro is: #ACTION SOURCE DEST PROTO DEST PORT(S)
<macro>(ACCEPT) $FW <destination zone>The
general format when not using defined macros is:#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT $FW <destination zone> <protocol> <port>Web Server on FirewallYou want to run a Web Server on your firewall system:
#ACTION SOURCE DEST PROTO DEST PORT(S)
Web(ACCEPT) net $FW
Web(ACCEPT) loc $FW Those two rules would of
course be in addition to the rules listed above under You can configure a Caching Name Server on your
firewall. If you don't know what port and protocol a particular
application uses, look here. 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)
SSH(ACCEPT) net $FWBering 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 #Allow DNS Cache to work
ACCEPT loc $FW tcp 80 #Allow Weblet to workNow edit your /etc/shorewall/rules
file to add or delete other connections as required.Some Things to Keep in MindYou cannot test your firewall from the
inside. Just because you send requests to your firewall
external IP address does not mean that the request will be associated
with the external interface or the net zone. Any
traffic that you generate from the local network will be associated
with your local interface and will be treated as loc->fw
traffic.IP addresses are properties of systems,
not of interfaces. It is a mistake to believe that your
firewall is able to forward packets just because you can ping the IP
address of all of the firewall's interfaces from the local network.
The only conclusion you can draw from such pinging success is that the
link between the local system and the firewall works and that you
probably have the local system's default gateway set correctly.All IP addresses configured on firewall
interfaces are in the $FW (fw) zone. If 192.168.1.254 is
the IP address of your internal interface then you can write
$FW:192.168.1.254 in a
rule but you may not write loc:192.168.1.254. Similarly, it is
nonsensical to add 192.168.1.254 to the loc zone using an entry in
/etc/shorewall/hosts.Reply packets do NOT automatically follow
the reverse path of the one taken by the original request.
All packets are routed according to the routing table of the host at
each step of the way. This issue commonly comes up when people install
a Shorewall firewall parallel to an existing gateway and try to use
DNAT through Shorewall without changing the default gateway of the
system receiving the forwarded requests. Requests come in through the
Shorewall firewall where the destination IP address gets rewritten but
replies go out unmodified through the old gateway.Shorewall itself has no notion of inside
or outside. These concepts are embodied in how Shorewall is
configured.Starting and Stopping Your FirewallThe installation procedure
configures your system to start Shorewall at system boot but 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 must edit /etc/shorewall/shorewall.conf and set
STARTUP_ENABLED=Yes.Users of the .deb package must edit /etc/default/shorewall
and set startup=1. While you are editing shorewall.conf,
it is a good idea to check the value of the SUBSYSLOCK option. You can
find a description of this option by typing 'man shorewall.conf' at a
shell prompt and searching for SUBSYSLOCK.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 two-interface sample assumes that you want to enable routing
to/from eth1 (the local network)
when Shorewall is stopped. If your local network isn't connected to
eth1 or if you wish to enable
access to/from other hosts, change /etc/shorewall/routestopped
accordingly. 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.The firewall will start after your network interfaces have been
brought up. This leaves a small window between the time that the network
interfaces are working and when the firewall is controlling connections
through those interfaces. If this is a concern, you can close that window
by installing the Shorewall Init
Package.If it Doesn't WorkRe-check each of the items flagged with a red arrow
above.Check your log.Check the Troubleshooting
Guide.Check the FAQ.Disabling your existing FirewallBefore starting Shorewall for the first time, it's a good idea to
stop your existing firewall. On older Redhat/CentOS/Fedora:service iptables stopOn recent Fedora systems that run systemd, the command is:systemctl stop iptables.serviceIf you are running SuSE, use Yast or Yast2 to stop
SuSEFirewall.On other systems that use a classic SysV init system:/etc/init.d/iptables stopOnce you have Shorewall running to your satisfaction, you should
totally disable your existing firewall. On older
Redhat/CentOS/Fedora:chkconfig --del iptablesOn Debian systems:update-rc.d iptables disableOn recent Fedora system running systemd:systemctl disable iptables.serviceAt this point, disable your existing firewall service.Additional Recommended ReadingI highly recommend that you review the Common Configuration File Features
page -- it contains helpful tips about Shorewall features than
make administering your firewall easier. Also, Operating Shorewall and
Shorewall Lite contains a lot of useful operational hints.Adding a Wireless Segment to your Two-Interface FirewallOnce you have the two-interface setup working, the next logical step
is to add a Wireless Network. The first step involves adding an additional
network card to your firewall, either a Wireless card or an Ethernet card
that is connected to a Wireless Access Point.When you add a network card, it won't necessarily be detected as
the next highest Ethernet interface. For example, if you have two
Ethernet cards in your system (eth0 and eth1) and you add a third card that uses
the same driver as one of the other two, that third card won't
necessarily be detected as eth2; it could rather be detected as
eth0 or eth1! You can either live with that or
you can shuffle the cards around in the slots until the new card is
detected as eth2.Update: Distributions are
getting better about this. SuSE now associates
a unique interface name with each MAC address. Other distributions
have add-on packages to manage the relationship between MAC addresses
and device names.Your new network will look similar to what is shown in the following
figure.The first thing to note is that the computers in your wireless
network will be in a different subnet from those on your wired local LAN.
In the above example, we have chosen to use the network 10.10.11.0/24.
Computers 3 and 4 would be configured with a default gateway IP address of
10.10.11.254.Second, we have chosen to include the wireless network as part of
the local zone. Since Shorewall allows intra-zone traffic by default,
traffic may flow freely between the local wired network and the wireless
network.There are only two changes that need to be made to the Shorewall
configuration:An entry needs to be added to
/etc/shorewall/interfaces for the wireless
network interface. If the wireless interface is wlan0, the entry might look like:#ZONE INTERFACE BROADCAST OPTIONS
loc wlan0 detect maclistAs shown in the above entry, I recommend using the maclist option for the wireless
segment. By adding entries for computers 3 and 4 in
/etc/shorewall/maclist, you help ensure that your
neighbors aren't getting a free ride on your Internet connection.
Start by omitting that option; when you have everything working, then
add the option and configure your
/etc/shorewall/maclist file.You may need to add an entry to the
/etc/shorewall/masq file to masquerade traffic
from the wireless network to the Internet. If you file looks like
this:#INTERFACE SOURCE ADDRESS PROTO PORT(S) IPSEC MARK
eth0 10.0.0.0/8,\
169.254.0.0/16,\
172.16.0.0/12,\
192.168.0.0/16
then you do not need to change
the contents.Otherwise, if your Internet interface is eth0 and your wireless interface is
wlan0, the entry would
be:#INTERFACE SOURCE ADDRESS
eth0 10.10.11.0/24One other thing to note. To get Microsoft
networking working between the wireless and wired networks, you will need
either a WINS server or a PDC. I personally use Samba configured as a WINS
server running on my firewall. Running a WINS server on your firewall
requires the rules listed in the Shorewall/Samba
documentation.
shorewall-docs-xml-4.5.21/ipsets.xml 0000644 0001750 0001750 00000015673 12222401136 017261 0 ustar teastep teastep
Shorewall and IpsetsTomEastep200520082010Thomas M. EastepPermission 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.This article applies to Shorewall 4.4 and
later. If you are running a version of Shorewall earlier than Shorewall
4.4.0 then please see the documentation appropriate for your
version.What are Ipsets?Ipsets are an extension to Netfilter/iptables that are available in
xtables-addons
if they are not available in your current distribution. Instructions for
installing xtables-addons may be found in the Dynamic Zones article.Ipset allows you to create one or more named sets of addresses then
use those sets to define Netfilter/iptables rules. Possible uses of ipsets
include:Blacklists. Ipsets provide an efficient way to represent large
sets of addresses and you can maintain the lists without the need to
restart or even refresh your Shorewall configuration.Zone definition. Using the /etc/shorewall/hosts file, you can
define a zone based on the (dynamic)
contents of an ipset. Again, you can then add or delete
addresses to the ipset without restarting Shorewall.See the ipsets site (URL above) for additional information about
ipsets.Shorewall Support for IpsetsSupport for ipsets was introduced in Shorewall version 2.3.0. In
most places where a host or network address may be used, you may also use
the name of an ipset prefaced by "+".Example: "+Mirrors"When using Shorewall, the names of ipsets are restricted as
follows:They must begin with a letter (after the '+').They must be composed of letters, digits, dashes ("-") or
underscores ("_").To generate a negative match, prefix the "+" with "!" as in
"!+Mirrors".Example 1: Blacklist all hosts in an ipset named "blacklist"/etc/shorewall/blacklist#ADDRESS/SUBNET PROTOCOL PORT
+blacklistExample 2: Allow SSH from all hosts in an ipset named "sshok:/etc/shorewall/rules#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net:+sshok $FW tcp 22The name of the ipset can be optionally followed by a
comma-separated list of flags enclosed in square brackets ([...]). Each
flag is either src or dst and specifies whether it is the SOURCE address
or port number or the DESTINATION address or port number that should be
matched. The number of flags must be appropriate for the type of ipset. If
no flags are given, Shorewall assumes that the set takes a single flag and
will select the flag based on the context. For example, in the blacklist
file and when the ipset appears in the SOURCE column of the rules file,
src is assumed. If the ipset appears in
the DEST column of the rules file, dst is
assumed. Note that by using [dst] in the
blacklist file, you can coerce the rule into matching the destination IP
address rather than the source.Beginning with Shorewall 4.4.14, multiple source or destination
matches may be specified by placing multiple set names in '+[...]' (e.g.,
+[myset,myotherset]). When so inclosed, the set names need not be prefixed
with a plus sign.Shorewall can save/restore your ipset contents with certain
restrictions:You must set SAVE_IPSETS=Yes in shorewall.conf (5).You cannot use an ipset in shorewall-routestopped
(5).The restore command cannot restore ipset
contents saved by the save command unless the
firewall is first stopped.Shorewall6 and Shorewall-init Support for IpsetsIpset support in Shorewall6 was added in Shorewall 4.4.21.Unlike iptables, which has separate configurations for IPv4 and
IPv6, ipset has a single configuration that handles both. This means the
SAVE_IPSETS=Yes in shorewall.conf or shorewall6.conf won't work correctly
because . To work around this issue, Shorewall-init is now capable
restoring ipset contents during 'start' and saving them during 'stop'. To
direct Shorewall-init to save/restore ipset contents, set the SAVE_IPSETS
option in /etc/sysconfig/shorewall-init (/etc/default/shorewall-init on
Debian and derivatives). The value of the option is a file name where the
contents of the ipsets will be save to and restored from. Shorewall-init
will create any necessary directories during the first 'save' operation.
If you configure Shorewall-init to save/restore ipsets, be sure to set
SAVE_IPSETS=No in shorewall.conf and shorewall6.conf.
shorewall-docs-xml-4.5.21/manpages6/ 0000755 0001750 0001750 00000000000 12223303501 017073 5 ustar teastep teastep shorewall-docs-xml-4.5.21/manpages6/shorewall6-netmap.xml 0000644 0001750 0001750 00000016424 12222401136 023176 0 ustar teastep teastep
shorewall6-netmap5netmapShorewall6 NETMAP definition file/etc/shorewall/netmapDescriptionThis file is used to map addresses in one network to corresponding
addresses in a second network. It was added in Shorewall6
4.4.23.3.To use this file, your kernel and ip6tables must have RAWPOST
table support included.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).TYPE - {DNAT|SNAT}:{P|O|T}Must be DNAT or SNAT followed by :P, :O or :T to perform
stateless NAT. Stateless NAT requires
Rawpost Table support in your kernel and
iptables (see the output of shorewall6 show
capabilities).If DNAT:P, traffic entering INTERFACE and addressed to NET1
has its destination address rewritten to the corresponding address
in NET2.If SNAT:T, traffic leaving INTERFACE with a source address in
NET1 has it's source address rewritten to the corresponding address
in NET2.If DNAT:O, traffic originating on the firewall and leaving via
INTERFACE and addressed to NET1 has its destination address
rewritten to the corresponding address in NET2.If DNAT:P, traffic entering via INTERFACE and addressed to
NET1 has its destination address rewritten to the corresponding
address in NET2.If SNAT:P, traffic entering via INTERFACE with a destination
address in NET1 has it's source address rewritten to the
corresponding address in NET2.If SNAT:O, traffic originating on the firewall and leaving via
INTERFACE with a source address in NET1 has it's source address
rewritten to the corresponding address in NET2.NET1 -
network-addressNetwork in CIDR format (e.g., 2001:470:b:227/64). Beginning in
Shorewall6 4.4.24, exclusion is
supported.INTERFACE -
interfaceThe name of a network interface. The interface must be defined
in shorewall6-interfaces(5).
Shorewall allows loose matches to wildcard entries in shorewall6-interfaces(5).
For example, ppp0 in this
file will match a shorewall6-interfaces(8)
entry that defines ppp+.NET2 -
network-addressNetwork in CIDR formatNET3 -
network-addressOptional - added in Shorewall 4.4.11. If specified, qualifies
INTERFACE. It specifies a SOURCE network for DNAT rules and a
DESTINATION network for SNAT rules.PROTO (Optional -
protocol-number-or-nameOnly packets specifying this protocol will have their IP
header modified.DEST PORT(S) (dport) -
port-number-or-name-listDestination Ports. An optional comma-separated list of Port
names (from services(5)), port numbers or
port ranges; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s). ICMP types may be specified as a numeric
type, a numeric type and code separated by a slash (e.g., 3/4), or
a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no PORT is given, ipp2p is
assumed.An entry in this field requires that the PROTO column specify
icmp (1), tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if
any of the following field is supplied.SOURCE PORT(S) (sport) -
port-number-or-name-listOptional source port(s). If omitted, any source port is
acceptable. Specified as a comma-separated list of port names, port
numbers or port ranges.An entry in this field requires that the PROTO column specify
tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of
the following fields is supplied.FILES/etc/shorewall/netmapSee ALSOhttp://shorewall.net/netmap.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairs
shorewall-docs-xml-4.5.21/manpages6/shorewall6-proxyndp.xml 0000644 0001750 0001750 00000012407 12222401136 023572 0 ustar teastep teastep
shorewall6-proxyndp5proxyndpShorewall6 Proxy NDP file/etc/shorewall6/proxyndpDescriptionThis file was added in Shorewall 4.4.16 and is used to define Proxy
NDP. There is one entry in this file for each IPv6 address to be
proxied.The columns in the file are as follows.ADDRESS -
addressIPv6 Address.INTERFACE -
interface (Optional)Local interface where system with the ip address in ADDRESS is
connected. Only required when the HAVEROUTE column is left empty or
is set to no or No.EXTERNAL -
interfaceExternal Interface to be used to access this system from the
Internet.HAVEROUTE - [-|Yes|No]If there is already a route from the firewall to the host
whose address is given, enter Yes
or yes in this column. Otherwise,
enter no or No or leave the column empty and Shorewall
will add the route for you. If Shorewall6 adds the route, its
persistence depends on the value of thePERSISTENT column contains Yes; otherwise, shorewall6 stop or shorewall clear6 will delete the
route.PERSISTENT - [-|Yes|No]If HAVEROUTE is No or
no, then the value of this column
determines if the route added by Shorewall persists after a
shorewall6 stop or a shorewall6 clear. If this column contains
Yes or yes then the route persists; If the column is
empty or contains No or no then the route is deleted by
shorewall6 stop or shorewall6
clear.ExampleExample 1:Host with IPv6 2001:470:b:227::44 is connected to interface
eth1 and we want hosts attached via eth0 to be able to access it
using that address. #ADDRESS INTERFACE EXTERNAL
2001:470:b:227::44 eth1 eth0FILES/etc/shorewall6/proxyndpSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-exclusion(5), shorewall6-hosts(5),
shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-nesting(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6.conf.xml 0000644 0001750 0001750 00000320043 12222401136 022633 0 ustar teastep teastep
shorewall6.conf5shorewall6.confShorewall6 global configuration file/etc/shorewall6/shorewall6.confDescriptionThis file sets options that apply to Shorewall6 as a whole.The file consists of Shell comments (lines beginning with '#'),
blank lines and assignment statements
(variable=value). If the
value contains shell meta characters or white-space,
then it must be enclosed in quotes. Example:
LOG_LEVEL="NFLOG(1,0,1)".OPTIONSMany options have as their value a log-level.
Log levels are a method of describing to syslog (8) the importance of a
message and a number of parameters in this file have log levels as their
value.These levels are defined by syslog and are used to determine the
destination of the messages through entries in /etc/syslog.conf (5). The
syslog documentation refers to these as "priorities"; Netfilter calls them
"levels" and Shorewall6 also uses that term.Valid levels are: 7 debug
6 info
5 notice
4 warning
3 err
2 crit
1 alert
0 emergFor most Shorewall6 logging, a level of 6 (info) is appropriate.
Shorewall6 log messages are generated by NetFilter and are logged using
facility 'kern' and the level that you specify. If you are unsure of the
level to choose, 6 (info) is a safe bet. You may specify levels by name or
by number.If you have built your kernel with NFLOG target support, you may
also specify a log level of NFLOG (must be all caps). Rather than log its
messages to syslogd, Shorewall6 will direct netfilter to log the messages
via the NFLOG target which will send them to a process called 'ulogd'.
ulogd is available with most Linux distributions (although it probably
isn't installed by default). Ulogd is also available from http://www.netfilter.org/projects/ulogd/index.html
and can be configured to log all Shorewall6 message to their own log
fileThe following options may be set in shorewall6.conf.ACCEPT_DEFAULT={action[(parameters)][:level]|none}DROP_DEFAULT={action[(parameters)][:level]|none}NFQUEUE_DEFAULT={action[(parameters)][:level]|none}QUEUE_DEFAULT={action[(parameters)][:level]|none}REJECT_DEFAULT={action[(parameters)][:level]|none}DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other three are similar for ACCEPT,
QUEUE and NFQUEUE policies.The value applied to these may be:a) The name of an action. The
name may optionally be followed by a comma-separated list of
parameters enclosed in parentheses if the specified action accepts
parameters (e.g., 'Drop(audit)').c) None or noneThe default values are:DROP_DEFAULT="Drop"REJECT_DEFAULT="Reject"ACCEPT_DEFAULT="none"QUEUE_DEFAULT="none"NFQUEUE_DEFAULT="None"If you set the value of either option to "None" then no
default action will be used and the default action or macro must be
specified in shorewall6-policy(5).You can pass parameters to the
specified action or macro (e.g.,
myaction(audit,DROP)).Beginning with Shorewall 4.5.10, the action name can be
followed optionally by a colon and a log
level. The level will be applied to each
rule in the action or macro body that does not already have a log
level.ACCOUNTING=[Yes|No]Added in Shorewall 4.4.7. If set to Yes, Shorewall6 accounting
is enabled (see shorewall6-accounting(5)).
If not specified or set to the empty value, ACCOUNTING=Yes is
assumed.ACCOUNTING_TABLE=[filter|mangle]Added in Shorewall 4.4.20. This setting determines which
Netfilter table the accounting rules are added in. By default,
ACCOUNTING_TABLE=filter is assumed. See also shorewall-accounting(5).ADMINISABSENTMINDED=[Yes|No]The value of this variable affects Shorewall6's stopped state.
When ADMINISABSENTMINDED=No, only traffic to/from those addresses
listed in shorewall6-routestopped(5)
is accepted when Shorewall6 is stopped. When
ADMINISABSENTMINDED=Yes, in addition to traffic to/from addresses in
shorewall6-routestopped(5),
connections that were active when Shorewall6 stopped continue to
work and all new connections from the firewall system itself are
allowed. If this variable is not set or is given the empty value
then ADMINISABSENTMINDED=No is assumed.IGNOREUNKNOWNVARIABLES=[Yes|No]Added in Shorewall 4.5.11. Normally, if an unknown shell
variable is encountered in a configuration file (except in ?IF and
?ELSIF directives), the compiler raises a fatal error. If
IGNOREUNKNOWNVARIABLES is set to Yes, then such variables simply expand to an
empty string. Default is No.AUTOCOMMENT=[Yes|No]Formerly named AUTO_COMMENT. If set, if there is not a current
comment when a macro is invoked, the behavior is as if the first
line of the macro file was "COMMENT <macro name>". The
AUTO_COMMENT option has a default value of 'Yes'.AUTOHELPERS=[Yes|No]Added in Shorewall 4.5.7. When set to
(the default), the generated ruleset will automatically associate
helpers with applications that require them (FTP, IRC, etc.). When
configuring your firewall on systems running kernel 3.5 or later, it
is recommended that you:Set AUTOHELPERS=No.Either:Modify shorewall6-conntrack
(5) to only apply helpers where they are required; orSpecify the appropriate helper in the HELPER column in
shorewall6-rules
(5).The macros for those applications requiring a helper
automatically specify the appropriate HELPER where
required.AUTOMAKE=[Yes|No]If set, the behavior of the start and
restart commands is change; if no files in
/etc/shorewall have been
changed since the last successful start or
restart command, then the compilation step is
skipped and the compiled script that executed the last
start or restart command is
used. The default is AUTOMAKE=No.The setting of the AUTOMAKE option is ignored if the
start or restart command
includes a directory name (e.g., shorewall6 restart
/etc/shorewall.new).BLACKLIST=[{ALL|state[,...]}]where state is one of NEW, ESTABLISHED, RELATED, INVALID,or
UNTRACKED.Added in Shorewall 4.5.13 to replace the BLACKLISTNEWONLY
option below. Specifies the connection tracking states that are to
be subject to blacklist screening. If neither BLACKLIST nor
BLACKLISTNEWONLY are specified then the states subject to
blacklisting are NEW,ESTABLISHED,INVALID,UNTRACKED.Note: The ESTABLISHED state may not be specified if FASTACCEPT
is specified.BLACKLIST_DISPOSITION=[DROP|A_DROP|REJECT|A_REJECT]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. The
setting determines the disposition of packets sent to the blacklog target of shorewall6-blrules(5).BLACKLIST_LOG_LEVEL=[log-level]Formerly named BLACKLIST_LOGLEVEL. This parameter 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_LOG_LEVEL=debug). If you do not assign a
value or if you assign an empty value then packets from blacklisted
hosts are not logged. The setting determines the log level of
packets sent to the blacklog target
of shorewall6-blrules(5).BLACKLISTNEWONLY={Yes|No}Deprecated in Shorewall 4.5.13 in favor of BLACKLIST
above.When set to Yes or yes, blacklists are only consulted for new
connections, for packets in the INVALID connection state (such as a
TCP SYN,ACK when there has been no corresponding SYN), and for
packets that are UNTRACKED due to entries in shorewall6-conntrack(5).
This includes entries in the shorewall6-blrules (5) file
and in the BLACKLIST section of shorewall6-rules (5).When set to No or no, blacklists are consulted for every packet
(will slow down your firewall noticeably if you have large
blacklists). If the BLACKLISTNEWONLY option is not set or is set to
the empty value then BLACKLISTNEWONLY=No is assumed.BLACKLISTNEWONLY=No is incompatible with
FASTACCEPT=Yes.CHAIN_SCRIPTS={Yes|No}Added in Shorewall 4.5.16. Prior to the availability of BEGIN
PERL....END PERL in configuration files, the only way to execute a
chain-specific script was to create a script file with the same name
as the chain and place it in a directory on the CONFIG_PATH. That
facility has the drawback that the compiler will attempt to run a
non-script file just because it has the same name as a chain. To
disable this facility, set CHAIN_SCRIPTS=No. If not specified or
specified as the empty value, CHAIN_SCRIPTS=Yes is assumed.CLAMPMSS=[Yes|No|value]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.Important: This option
requires CONFIG_IP_NF_TARGET_TCPMSS in your kernel.You may also set CLAMPMSS to a numeric
value (e.g., CLAMPMSS=1400). This will set the
MSS field in TCP SYN packets going through the firewall to the
value that you specify.CLEAR_TC=[Yes|No]If this option is set to No
then Shorewall6 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/shorewall6/tcstart file. That way, your traffic shaping rules
can still use the “fwmark” classifier based on packet marking
defined in shorewall6-tcrules(5). If not
specified, CLEAR_TC=No is assumed.If you also run Shorewall and if you have
TC_ENABLED=Internal in your shorewall-conf(5),
then you will want CLEAR_TC=No in this file.COMPLETE=[Yes|No]Added in Shorewall6 4.4.12. When you set this option to Yes,
you are asserting that the configuration is complete so that your
set of zones encompasses any hosts that can send or receive traffic
to/from/through the firewall. This causes Shorewall6 to omit the
rules that catch packets in which the source or destination IP
address is outside of any of your zones. Default is No. It is
recommended that this option only be set to Yes if:You have defined an interface whose effective physical
setting is '+'.That interface is assigned to a zone.You have no CONTINUE policies or rules.CONFIG_PATH=[directory[:directory]...]Specifies where configuration files other than shorewall6.conf
may be found. CONFIG_PATH is specifies as a list of directory names
separated by colons (":"). When looking for a configuration file
other than shorewall6.conf:If the command is "try" or a "<configuration
directory>" was specified in the command (e.g.,
shorewall6 check ./gateway) then the
directory given in the command is searched first.Next, each directory in the CONFIG_PATH setting is
searched in sequence.If CONFIG_PATH is not given or if it is set to the empty value
then the contents of /usr/share/shorewall6/configpath are used. As
released from shorewall.net, that file sets the CONFIG_PATH to
/etc/shorewall6:/usr/share/shorewall6:/usr/share/shorewall but your
particular distribution may set it differently. See the output of
shorewall6 show config for the default on your system.DEFER_DNS_RESOLUTION=[Yes|No]Added in Shorewall 4.5.12. When set to 'Yes' (the default),
DNS names are validated in the compiler and then passed on to the
generated script where they are resolved by ip6tables-restore. This
is an advantage if you use AUTOMAKE=Yes and the IP address
associated with the DNS name is subject to change. When
DEFER_DNS_RESOLUTION=No, DNS names are converted into IP addresses
by the compiler. This has the advantage that when AUTOMAKE=Yes the
start and restart commands
will succeed even if no DNS server is reachable (assuming that the
configuration hasn't changed since the compiled script was last
generated).DELETE_THEN_ADD={Yes|No}If set to Yes (the default value), entries in the
/etc/shorewall6/route_stopped files cause an 'ip rule del' command
to be generated in addition to an 'ip rule add' command. Setting
this option to No, causes the 'ip rule del' command to be
omitted.DONT_LOAD=[module[,module]...]Causes Shorewall6 to not load the listed kernel
modules.DYNAMIC_BLACKLIST={Yes|No}Added in Shorewall 4.4.7. When set to No or no,
dynamic blacklisting using the shorewall6 drop,
shorewall6 reject, shorewall6
logdrop and shorewall6 logreject is
disabled. Default is Yes.EXPAND_POLICIES={Yes|No}Normally, when the SOURCE or DEST columns in
shorewall-policy(5) contains 'all', a single policy chain is created
and the policy is enforced in that chain. For example, if the policy
entry is#SOURCE DEST POLICY LOG
# LEVEL
net all DROP infothen the chain name is 'net2all'
which is also the chain named in Shorewall log messages generated as
a result of the policy. If EXPAND_POLICIES=Yes, then Shorewall will
create a separate chain for each pair of zones covered by the
policy. This makes the resulting log messages easier to interpret
since the chain in the messages will have a name of the form 'a2b'
where 'a' is the SOURCE zone and 'b' is the DEST zone.EXPORTMODULES=[Yes|No]Added in Shorewall 4.4.17. When set to Yes when compiling for
use by Shorewall6 Lite (shorewall6 load,
shorewall6 reload or shorewall6
export commands), the compiler will copy the modules or
helpers file from the administrative system into the script. When
set to No or not specified, the compiler will not copy the modules
or helpers file from /usr/share/shorewall6 but
will copy the found in another location on the CONFIG_PATH.When compiling for direct use by Shorewall6, causes the
contents of the local module or helpers file to be copied into the
compiled script. When set to No or not set, the compiled script
reads the file itself.EXPORTPARAMS={Yes|No}Deprecated beginning with Shorewall 4.4.17.Beginning with Shorewall 4.4.17, the variables set in the
'params' file at compile time are available at run time with
EXPORTPARAMS=No. As a consequence, beginning with that version the
recommended setting is EXPORTPARAMS=No.It is quite difficult to code a 'params' file that assigns
other than constant values such that it works correctly with
Shorewall6 Lite. The EXPORTPARAMS option works around this problem.
When EXPORTPARAMS=No, the 'params' file is not copied to the
compiler output.With EXPORTPARAMS=No, if you need to set environmental
variables on the firewall system for use by your extension scripts,
then do so in the init extension script.The default is EXPORTPARAMS=Yes which is the recommended
setting unless you are running Shorewall6 Lite.FASTACCEPT={Yes|No}Normally, Shorewall6 defers accepting ESTABLISHED/RELATED
packets until these packets reach the chain in which the original
connection was accepted. So for packets going from the 'loc' zone to
the 'net' zone, ESTABLISHED/RELATED packets are ACCEPTED in the
'loc2net' chain.If you set FASTACCEPT=Yes, then ESTABLISHED/RELATED packets
are accepted early in the INPUT, FORWARD and OUTPUT chains. If you
set FASTACCEPT=Yes then you may not include rules in the ESTABLISHED
or RELATED sections of shorewall6-rules(5).FASTACCEPT=Yes is incompatible with
BLACKLISTNEWONLY=No.FORWARD_CLEAR_MARK={Yes|No}Added in Shorewall 4.4.11 Beta 3. Traditionally, Shorewall has
cleared the packet mark in the first rule in the mangle FORWARD
chain. This behavior is maintained with the default setting of this
option (FORWARD_CLEAR_MARK=Yes). If FORWARD_CLEAR_MARK is set to
'No', packet marks set in the mangle PREROUTING chain are retained
in the FORWARD chains.GEOIPDIR=[pathname]Added in Shorewall 4.5.4. Specifies the pathname of the
directory containing the GeoIP Match
database. See http://www.shorewall.net/ISO-3661.html.
If not specified, the default value is
/usr/share/xt_geoip/LE which is the default
location of the little-endian database.HELPERS=[helper[,helper...]]Added in Shorewall 4.5.7. This option lists the Netfilter
application helps that are to be enabled. If not specified, the
default is to enable all helpers.Possible values for helper
are:amandaftph323ircnetbios-nsnone - This special value
was added in Shorewall 4.5.16 and indicates that no helpers are
to be enabled. It also prevents the compiler for probing for
helper support; such probing generates messages on the system
log of the form "xt_CT: No such helper XXX" where XXX is the
helper name. When used, none
must be the only helper specified.pptpsanesipsnmptftpWhen HELPERS is specified on a system running Kernel 3.5.0 or
later, automatic association of helpers to connections is
disabled.HIGH_ROUTE_MARKS={Yes|No}Deprecated in Shorewall 4.4.26 in favor of
PROVIDER_OFFSET.You may set HIGH_ROUTE_MARKS=Yes in to effectively divide the
packet mark and connection mark into two mark fields.The width of the fields are determined by the setting of the
WIDE_TC_MARKS option.When WIDE_TC_MARKS=No (the default):The MARK field in the providers file must have a value
that is less than 65536 and that is a multiple of 256 (using hex
representation, the values are 0x0100-0xFF00 with the low-order
8 bits being zero).You may only set those mark values in the PREROUTING
chain.Marks used for traffic shaping must still be in the range
of 1-255 and may still not be set in the PREROUTING
chain.When WIDE_TC_MARKS=Yes:The MARK field in the providers file must have a value
that is a multiple of 65536 (using hex representation, the
values are 0x010000-0xFF0000 with the low-order 16 bits being
zero).You may only set those mark values in the PREROUTING
chain.Marks used for traffic shaping must be in the range of
1-16383 and may still not be set in the PREROUTING chain.Regardless of the setting of WIDE_TC_MARKS, when you SAVE or
RESTORE in tcrules, only the TC mark value is saved or restored.
Shorewall handles saving and restoring the routing (provider)
marks.IMPLICIT_CONTINUE={Yes|No}When this option is set to Yes, it causes subzones to be treated
differently with respect to policies.Subzones are defined by following their name with ":" and a
list of parent zones (in shorewall6-zones(5)). Normally,
you want to have a set of special rules for the subzone and if a
connection doesn't match any of those subzone-specific rules then
you want the parent zone rules and policies to be applied; see
shorewall6-nesting(5).
With IMPLICIT_CONTINUE=Yes, that happens automatically.If IMPLICIT_CONTINUE=No or if IMPLICIT_CONTINUE is not set,
then subzones are not subject to this special treatment. With
IMPLICIT_CONTINUE=Yes, an implicit CONTINUE policy may be overridden
by including an explicit policy (one that does not specify "all" in
either the SOURCE or the DEST columns).INVALID_DISPOSITION=[A_DROP|A_REJECT|DROP|REJECT|CONTINUE]Added in Shorewall 4.5.13. Shorewall has traditionally passed
INVALID packets through the NEW section of shorewall-rules (5). When a
packet in INVALID state fails to match any rule in the INVALID
section, the packet is disposed of based on this setting. The
default value is CONTINUE for compatibility with earlier
versions.INVALID_LOG_LEVEL=log-levelAdded in Shorewall 4.5.13. Packets in the INVALID state that
do not match any rule in the INVALID section of shorewall-rules (5) are
logged at this level. The default value is empty which means no
logging is performed.IP=[pathname]If specified, gives the pathname of the 'ip' executable. If
not specified, 'ip' is assumed and the utility will be located using
the current PATH setting.IP_FORWARDING=[On|Off|Keep]This rather useless parameter determines whether Shorewall6
enables or disables IPV6 Packet Forwarding on all interfaces
(/proc/sys/net/ipv6/config/all/forwarding). Possible values
are:On or onpacket forwarding will be enabled.Off or offpacket forwarding will be disabled.Keep or keepShorewall6 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.
IP6TABLES=[pathname]This parameter names the ip6tables executable to be used by
Shorewall6. If not specified or if specified as a null value, then
the ip6tables executable located using the PATH option is
used.Regardless of how the ip6tables utility is located (specified
via IP6TABLES= or located via PATH), Shorewall6 uses the
ip6tables-restore and ip6tables-save utilities from that same
directory.IPSET=[pathname]If specified, gives the pathname of the 'ipset' executable. If
not specified, 'ipset' is assumed and the utility will be located
using the current PATH setting.IPSET_WARNINGS={Yes|No}Added in Shorewall 4.5.2. Default is Yes. When set, causes the
rules compiler to issue a warning when:The compiler is being run by root and an ipset specified
in the configuration does not exists. Only one warning is issued
for each missing ipset.When [src] is specified in a destination column and when
[dst] is specified in a source column.KEEP_RT_TABLES={Yes|No}When set to , this option prevents scripts
generated by Shorewall6 from altering the /etc/iproute2/rt_tables
database when there are entries in
/etc/shorewall6/providers. If you set this
option to while Shorewall6 (Shorewall6-lite) is
running, you should remove the file
/var/lib/shorewall6/rt_tables
(/var/lib/shorewall6-lite/rt_tables) before
your next stop, refresh,
restore on restart
command.The default is KEEP_RT_TABLES=No.LEGACY_FASTSTART={Yes|No}Added in Shorewall6 4.4.20. If not specified, the default is
Yes which preserves the legacy behavior of start
-f (the modification times of the files in
/etc/shorewall6 are compare with that of
/var/lib/shorewall6/restore). If set to No,
then the times are compared with that of
/var/lib/shorewall6/firewall, which is consistent with the way that
restart -f works.LOAD_HELPERS_ONLY={Yes|No}Added in Shorewall 4.4.7. When set to Yes, restricts the set
of modules loaded by shorewall to those listed in
/var/lib/shorewall6/helpers and those that are actually used. When
not set, or set to the empty value, LOAD_HELPERS_ONLY=No is
assumed.LOCKFILE=[pathname]Specifies the name of the Shorewall6 lock file, used to
prevent simultaneous state-changing commands. If not specified,
${VARDIR}/shorewall6/lock is assumed (${VARDIR} is normally /var/lib
but can be changed when Shorewall-core is installed -- see the
output of shorewall6 show vardir).LOG_VERBOSITY=[number]This option controls the amount of information logged to the
file specified in the STARTUP_LOG option.Values are:-1 - Logging is disabled0 - Silent. Only error messages are logged.1 - Major progress messages logged.2 - All progress messages loggedIf not specified, then -1 is assumed.LOGALLNEW=[log-level]This option is intended for use as a debugging aid. When set
to a log level, this option causes Shorewall6 to generate a logging
rule as the first rule in each builtin chain.The table name is used as the chain name in the log
prefix.The chain name is used as the target in the log
prefix.
For example, using the default LOGFORMAT, the log prefix for
logging from the nat table's PREROUTING chain is: Shorewall:nat:PREROUTING
To help insure that all packets in the NEW state are
logged, rate limiting (LOGBURST and LOGRATE) should be disabled
when using LOGALLNEW. Use LOGALLNEW at your own risk; it may
cause high CPU and disk utilization and you may not be able to
control your firewall after you enable this option.Do not use this option if the resulting log messages will
be sent to another system.
LOGFILE=[pathname]This parameter tells the /sbin/shorewall6 program where to
look for Shorewall6 messages when processing the dump, logwatch, show
log, and hits commands.
If not assigned or if assigned an empty value, /var/log/messages is
assumed.LOGFORMAT=["formattemplate"]The value of this variable generate the --log-prefix setting
for Shorewall6 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, 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
“Shorewall6:%s:%s:” is assumed.The setting of LOGFORMAT has an effect of the permitted
length of zone names. See shorewall6-zones (5).LOGLIMIT=[[{s|d}:]rate/{sec|min|hour|day}[:burst]]Added in Shorewall 4.4.12. Limits the logging rate, either
overall, or by source or destination IP address.If the value starts with 's:' then logging is limited per
source IP. If the value starts with 'd:', then logging is limited
per destination IP. Otherwise, the overall logging rate is
limited.If burst is not specified, then a
value of 5 is assumed.LOGBURST=[burst]Deprecated in Shorewall 4.4.12.LOGRATE=[rate/{minute|second}]As of Shorewall 4.4.12, these parameters are
Deprecated.These parameters set the match rate and initial burst size for
logged packets. Please see ip6tables(8) for a description of the
behavior of these parameters (the ip6tables option --limit is set by
LOGRATE and --limit-burst is set by LOGBURST). If both parameters
are set empty, no rate-limiting will occur. If you supply one of
these, then you should also supply the other.Example: LOGRATE=10/minute
LOGBURST=5For each logging rule, the first time the rule is reached, the
packet will be logged; in fact, since the burst is 5, the first five
packets will be logged. After this, it will be 6 seconds (1 minute
divided by the rate of 10) before a message will be logged from the
rule, regardless of how many packets reach it. Also, every 6
seconds, one of the bursts will be regained; if no packets hit the
rule for 30 seconds, the burst will be fully recharged; back where
we started.LOGTAGONLY=[Yes|No]Using the default LOGFORMAT, chain names may not exceed 11
characters or truncation of the log prefix may occur. Longer chain
names may be used with log tags if you set LOGTAGONLY=Yes. With
LOGTAGONLY=Yes, if a log tag is specified then the tag is included
in the log prefix in place of the chain name.Beginning with Shorewall 4.5.12, when LOGTAGONLY=Yes, you have
more control over the generated log prefix. Beginning with that
release, the tag is interpreted as a chain
name and a disposition
separated by a comma. So this rule:#ACTION SOURCE DEST
LOG:info:foo,bar net fwwould generate the following log prefix when using the default
LOGFORMAT setting:Shorewall:foo:bar:Similarly,#ACTION SOURCE DEST
LOG:info:,bar net fwwould generateShorewall:net2fw:bar:MACLIST_DISPOSITION=[ACCEPT|DROP|REJECT|A_DROP|A_REJECT]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.A_DROP and A_REJECT are audited versions of DROP and REJECT
respectively and were added in Shorewall 4.4.20. They require
AUDIT_TARGET in the kernel and ip6tables.MACLIST_LOG_LEVEL=[log-level]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="").MACLIST_TABLE=[filter|mangle]Normally, MAC verification occurs in the filter table (INPUT
and FORWARD) chains. When forwarding a packet from an interface with
MAC verification to a bridge interface, that doesn't work.This problem can be worked around by setting
MACLIST_TABLE=mangle which will cause Mac verification to occur out
of the PREROUTING chain. Because REJECT isn't available in that
environment, you may not specify MACLIST_DISPOSITION=REJECT with
MACLIST_TABLE=mangle.MACLIST_TTL=[number]The performance of configurations with a large numbers of
entries in shorewall-maclist(5) can be
improved by setting the MACLIST_TTL variable in shorewall.conf(5).If your iptables and kernel support the "Recent Match" (see
the output of "shorewall check" near the top), you can cache the
results of a 'maclist' file lookup and thus reduce the overhead
associated with MAC Verification.When a new connection arrives from a 'maclist' interface, the
packet passes through then list of entries for that interface in
shorewall-maclist(5). If
there is a match then the source IP address is added to the 'Recent'
set for that interface. Subsequent connection attempts from that IP
address occurring within $MACLIST_TTL seconds will be accepted
without having to scan all of the entries. After $MACLIST_TTL from
the first accepted connection request from an IP address, the next
connection request from that IP address will be checked against the
entire list.If MACLIST_TTL is not specified or is specified as empty (e.g,
MACLIST_TTL="" or is specified as zero then 'maclist' lookups will
not be cached).MANGLE_ENABLED=[Yes|No]Determines whether Shorewall will generate rules in the
Netfilter mangle table. Setting MANGLE_ENABLED=No disables all
Shorewall features that require the mangle table. The default is
MANGLE_ENABLED=Yes.MARK_IN_FORWARD_CHAIN=[Yes|No]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 DNAT is in use. To determine if your
kernel has a FORWARD chain in the mangle table, use the /sbin/shorewall6 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.MASK_BITS=[number]Added in Shorewall 4.4.26. Number of bits on the right of the
32-bit packet mark to be masked when clearing the traffic shaping
mark. Must be >= TC_BITS and <= PROVIDER_OFFSET (if
PROVIDER_OFFSET > 0). Default value and the default values of the
other mark layout options is determined as follows:
MODULE_SUFFIX=["extension ..."]The value of this option determines the possible file
extensions of kernel modules. The default value is "ko ko.gz o o.gz
gz".MODULESDIR=[pathname[:pathname]...]This parameter specifies the directory/directories where your
kernel netfilter modules may be found. If you leave the variable
empty, Shorewall6 will supply "/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter:/lib/modules/`uname
-r`/kernel/net/ipv4/netfilter".MUTEX_TIMEOUT=[seconds]The value of this variable determines the number of seconds
that programs will wait for exclusive access to the Shorewall6 lock
file. After the number of seconds corresponding to the value of this
variable, programs will assume that the last program to hold the
lock died without releasing the lock.If not set or set to the empty value, a value of 60 (60
seconds) is assumed.An appropriate value for this parameter would be twice the
length of time that it takes your firewall system to process a
shorewall6 restart command.NFACCT=[pathname]Added in Shorewall 4.5.7. Specifies the pathname of the nfacct
utility. If not specified, Shorewall will use the PATH setting to
find the program.OPTIMIZE=[value]The specified value enables certain
optimizations. Each optimization category is associated with a power
of two. To enable multiple optimization categories, simply add their
corresponding numbers together.Beginning with Shorewall 4.5.20, you may specify OPTIMIZE=All
to enable all optimization categories, and you may also specify
OPTIMIZE=None to disable optimization.Optimization category 1 - Traditionally, Shorewall has
created rules for the complete matrix of
host groups defined by the zones, interfaces and hosts
files. Any traffic that didn't correspond to an element
of that matrix was rejected in one of the built-in chains. When
the matrix is sparse, this results in lots of largely useless
rules.These extra rules can be eliminated by setting the 1 bit
in OPTIMIZE.The 1 bit setting also controls the suppression of
redundant wildcard rules (those specifying "all" in the SOURCE
or DEST column). A wildcard rule is considered to be redundant
when it has the same ACTION and Log Level as the applicable
policy.Optimization level 1 is ignored when optimization level
4 is also selected, since level 4 performs similar
optimizations in a more robust way.Optimization category 2 - Added in Shorewall 4.4.7. When
set, suppresses superfluous ACCEPT rules in a policy chain that
implements an ACCEPT policy. Any ACCEPT rules that immediately
precede the final blanket ACCEPT rule in the chain are now
omitted.Optimization category 4 - Added in Shorewall 4.4.7. When
set, causes short chains (those with less than 2 rules) to be
optimized away. The following chains are excluded from
optimization:accounting chains (unless
OPTIMIZE_ACCOUNTING=Yes)action chains (user-defined)'blacklst' chaindynamicAdditionally:If a built-in chain has a single rule that branches to
a second chain, then the rules from the second chain are
moved to the built-in chain and the target chain is
omitted.Chains with no references are deleted.Accounting chains are subject to optimization if the
OPTIMIZE_ACCOUNTING option is set to 'Yes'.If a chain ends with an unconditional branch to a
second chain (other than to 'reject'), then the branch is
deleted from the first chain and the rules from the second
chain are appended to it.An additional optimization was added in Shorewall 4.5.4.
If the last rule in a chain is an unqualified jump to a simple
target, then all immediately preceding rules with the same
simple target are omitted.For example, consider this chain: -A fw-net -p udp --dport 67:68 -j ACCEPT
-A fw-net -p udp --sport 1194 -j ACCEPT
-A fw-net -p 41 -j ACCEPT
-A fw-net -j ACCEPT
Since all of the rules are jumps to the simple target
ACCEPT, this chain is totally optimized away and jumps to the
chain are replace with jumps to ACCEPT.Optimization category 8 - Added in Shorewall 4.4.9. When
set, causes chains with identical rules to be collapsed into a
single chain.Optimization category 16 - Added in Shorewall 4.4.26. When
set, causes sequences of compatible rules
to be combined into a single rule. Rules are considered
compatible if they differ only in their destination ports and
comments.A sequence of compatible rules is often generated when
macros are invoked in sequence.The ability to combine adjacent rules is limited by two
factors:Destination port lists may only be combined up to a
maximum of 15 ports, where a port-pair counts as two
ports.Rules may only be combined until the length of their
concatenated comment reaches 255 characters.When either of these limits would be exceeded, the current
combined rule is emitted and the compiler attempts to combine
rules beginning with the one that would have exceeded the limit.
Adjacent combined comments are separated by ', '. Empty comments
at the front of a group of combined comments are replaced by
'Others and'. Empty comments at the end of a group of combined
comments are replaced by 'and others'.Beginning in Shorewall 4.5.10, this option also suppresses
duplicate adjacent rules and duplicate non-adjacent rules that
don't include mark, connmark, dscp, ecn, set, tos
or u32 matches.Example 1:Rules with comments "FOO", <empty> and "BAR"
would result in the combined comment "FOO and others,
BAR".Example 2:Rules with comments <empty>, "FOO" and "BAR"
would result in the combined comment "Others and FOO,
BAR". Note: Optimize level 16 requires "Extended
Multi-port Match" in your iptables and kernel.The default value is zero which disables all
optimizations.OPTIMIZE_ACCOUNTING=[Yes|No]Added in Shorewall 4.4.7. If set to Yes, Shorewall accounting
changes are subject to optimization (OPTIMIZE=4,5,6 or 7). If not
specified or set to the empty value, OPTIMIZE_ACCOUNTING=No is
assumed.PATH=pathname[:pathname]...Determines the order in which Shorewall6 searches directories
for executable files.PERL=pathnameAdded in Shorewall 4.4.11 RC1. Specifies the path name of the
Perl executable. Default is /usr/bin/perl. If
the pathname specified by this option does not exist or the named
file is not executable, then Shorewall6 falls back to
/usr/bin/perl/PROVIDER_BITS=[number]Added in Shorewall 4.4.26. The number of bits in the 32-bit
packet mark to be used for provider numbers. May be zero. See MASK_BITS above for default value.PROVIDER_OFFSET=[number]Added in Shorewall 4.4.26. The offset from the right
(low-order end) of the provider number field in the 32-bit packet
mark. If non-zero, must be >= TC_BITS (Shorewall automatically
adjusts PROVIDER_OFFSET's value). PROVIDER_OFFSET + PROVIDER_BITS +
ZONE_BITS must be < 32. See MASK_BITS above for default value.RCP_COMMAND="command"RSH_COMMAND="command"Earlier generations of Shorewall6 Lite required that remote
root login via ssh be enabled in order to use the
load and reload commands.
Beginning with release 3.9.5, you may define an alternative means
for accessing the remote firewall system. In that release, two new
options were added to shorewall6.conf:RSH_COMMANDRCP_COMMANDThe default values for these are as
follows:RSH_COMMAND: ssh ${root}@${system} ${command}RCP_COMMAND: scp ${files}
${root}@${system}:${destination}Shell variables that will be set when the commands
are invoked are as follows:root - root user. Normally
but may be overridden using the '-r'
option.system - The name/IP address
of the remote firewall system.command - For RSH_COMMAND,
the command to be executed on the firewall system.files - For RCP_COMMAND, a
space-separated list of files to be copied to the remote
firewall system.destination - The directory
on the remote system that the files are to be copied
into.RELATED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]Added in Shorewall 4.4.27. Shorewall has traditionally
ACCEPTed RELATED packets that don't match any rule in the RELATED
section of shorewall6-rules (5). Concern
about the safety of this practice resulted in the addition of this
option. When a packet in RELATED state fails to match any rule in
the RELATED section, the packet is disposed of based on this
setting. The default value is ACCEPT for compatibility with earlier
versions.RELATED_LOG_LEVEL=log-levelAdded in Shorewall 4.4.27. Packets in the related state that
do not match any rule in the RELATED section of shorewall6-rules (5) are
logged at this level. The default value is empty which means no
logging is performed.REJECT_ACTION=actionAdded in Shorewall 4.5.21. When a REJECT target is specified,
Shorewall normally handles the response as follows:If the destination address of the packet is a broadcast or
multicast address, the packet is dropped.if the protocol is ICMP (58) then the packet is
dropped.if the protocol is TCP (6) then the packet is rejected
with an RST.if the protocol is UDP (17) then the packet is rejected
with an 'port-unreachable' ICMP (ICMP6).if the protocol is ICMP (1) then the packet is rejected
with a 'addr-unreachable' ICMP.otherwise, the packet is rejected with a 'adm-prohibited'
ICMP.You can modify this behavior by implementing your own
action that handles REJECT and specifying
it's name in this option. The nolog
and inline options will
automatically be assumed for the specified
action.The following action implements the standard behavior:?format 2
#TARGET SOURCE DEST PROTO
Broadcast(DROP) - - -
DROP - - 2
INLINE - - 6 ; -j REJECT --reject-with tcp-reset
?if __ENHANCED_REJECT
INLINE - - 17 ; -j REJECT
?if __IPV4
INLINE - - 1 ; -j REJECT --reject-with icmp-host-unreachable
INLINE - - - ; -j REJECT --reject-with icmp-host-prohibited
?else
INLINE - - 58 ; -j REJECT --reject-with icmp6-addr-unreachable
INLINE - - - ; -j REJECT --reject-with icmp6-adm-prohibited
?endif
?else
INLINE - - - ; -j REJECT
?endifREQUIRE_INTERFACE=[Yes|No]Added in Shorewall 4.4.10. The default is No. If set to Yes,
at least one optional interface must be up in order for the firewall
to be in the started state. Intended to be used with the Shorewall Init
Package.RESTORE_ROUTEMARKS=[Yes|No]Added in Shorewall 4.5.9. When set to Yes (the default), provider marks are
restored unconditionally at the top of the mangle OUTPUT and
PREROUTING chains, even if the saved mark is zero. When this option
is set to No, the mark is restored
even when it is zero. If you have problems with IPSEC ESP packets
not being routed correctly on output, try setting this option to
No.RESTOREFILE=filenameSpecifies the simple name of a file in /var/lib/shorewall6 to
be used as the default restore script in the shorewall6 save, shorewall6 restore, shorewall6 forget and shorewall6 -f start commands.RPFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]Added in Shorewall 4.5.7. Determines the disposition of
packets entering from interfaces with the
option (see shorewall-interfaces(5)).
Packets disposed of by this option are those whose response packets
would not be sent through the same interface receiving the
packet.RPFILTER_LOG_LEVEL=log-levelAdded in shorewall 4.5.7. Determines the logging of packets
disposed via the RPFILTER_DISPOSITION. The default value is
.SHOREWALL_SHELL=[pathname]This option is used to specify the shell program to be used to
interpret the compiled script. If not specified or specified as a
null value, /bin/sh is assumed. Using a light-weight shell such as
ash or dash can significantly improve performance.SMURF_DISPOSITION=[DROP|A_DROP]Added in Shorewall 4.4.20. The default setting is DROP which
causes smurf packets (see the nosmurfs option in shorewall-interfaces(5)) to
be dropped. A_DROP causes the packets to be audited prior to being
dropped and requires AUDIT_TARGET support in the kernel and
ip6tables.SMURF_LOG_LEVEL=[log-level]Specifies the logging level for smurf packets (see the
nosmurfs option in shorewall6-interfaces(5)).
If set to the empty value ( SMURF_LOG_LEVEL="" ) then smurfs are not
logged.SFILTER_DISPOSITION=[DROP|REJECT|A_DROP|A_REJECT]Added in Shorewall 4.4.20. Determines the disposition of
packets matching the option (see shorewall6-interfaces(5))
and of hairpin packets on interfaces without
the option.Hairpin packets are packets that are routed out of the
same interface that they arrived on. interfaces without the routeback option.SFILTER_LOG_LEVEL=log-levelAdded on Shorewall 4.4.20. Determines the logging of packets
matching the option (see shorewall6-interfaces(5))
and of hairpin packets on interfaces without
the option.Hairpin packets are packets that are routed out of the
same interface that they arrived on. interfaces without the routeback option. The default
is . If you don't wish for these packets to be
logged, use SFILTER_LOG_LEVEL=none.STARTUP_ENABLED={Yes|No}Determines if Shorewall6 is allowed to start. As released from
shorewall.net, this option is set to No. When set to Yes or yes,
Shorewall6 may be started. Used as a guard against Shorewall6 being
accidentally started before it has been configured.STARTUP_LOG=[pathname]If specified, determines where Shorewall6 will log the details
of each start, restart and refresh command. Logging verbosity is
determined by the setting of LOG_VERBOSITY above.SUBSYSLOCK=[pathname]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 Shorewall6 to work
with your distribution's initscripts. For RedHat, this should be set
to /var/lock/subsys/shorewall6. For Debian, the value is
/var/lock/shorewall6 and in LEAF it is /var/run/shorewall.TC=[pathname]If specified, gives the pathname of the 'tc' executable. If
not specified, 'tc' is assumed and the utility will be located using
the current PATH setting.TC_BITS=[number]Added in Shorewall 4.4.26. The number of bits at the low end
of the 32-bit packet mark to be used for traffic shaping marking.
May be zero. See MASK_BITS above
for default value.TC_ENABLED=[Yes|No|Internal|Shared]If you say Yes or yes here, Shorewall6 will use a script that
you supply to configure traffic shaping. The script must be named
'tcstart' and must be placed in a directory on your
CONFIG_PATH.If you say No or no then traffic shaping is not
enabled.If you set TC_ENABLED=Internal or internal or leave the option
empty then Shorewall6 will use its builtin traffic shaper
(tc4shorewall6 written by Arne Bernin.Beginning with Shorewall 4.4.15, if you set TC_ENABLED=Shared
or shared, then you should create symbolic links from your
Shorewall6 configuration directory (normally
/etc/shorewall6/) to your Shorewall
tcdevices and tcclasses
files. This allows the compiler to have access to your Shorewall
traffic shaping configuration so that it can validate CLASSIFY rules
in shorewall6-tcrules
(5).If you also run Shorewall and if you have
TC_ENABLED=Internal in your shorewall-conf(5),
then you will want TC_ENABLED=No or TC_ENABLED=Shared in this
file.TC_EXPERT={Yes|No}Normally, Shorewall6 tries to protect users from themselves by
preventing PREROUTING and OUTPUT tcrules from being applied to
packets that have been marked by the 'track' option in shorewall6-providers(5).If you know what you are doing, you can set TC_EXPERT=Yes and
Shorewall6 will not include these cautionary checks.TC_PRIOMAP=mapAdded in Shorewall 4.4.6. Determines the mapping of a packet's
TOS field to priority bands. See shorewall6-tcpri(5). The
map consists of 16 space-separated digits with
values 1, 2 or 3. A value of 1 corresponds to Linux priority 0, 2 to
Linux priority 1, and 3 to Linux Priority 2. The first entry gives
the priority of TOS value 0, the second of TOS value 1, and so on.
See tc-prio(8) for additional information.The default setting is TC_PRIOMAP="2 3 3 3 2 3 1 1 2 2 2 2 2 2
2 2".TCP_FLAGS_DISPOSITION=[ACCEPT|DROP|REJECT]Determines the disposition of TCP packets that fail the checks
enabled by the tcpflags interface
option (see shorewall6-interfaces(5))
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=[log-level]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="").TRACK_PROVIDERS={Yes|No}Added in Shorewall 4.4.3. When set to Yes, causes the
option to be assumed on all providers defined
in shorewall6-providers(5). May
be overridden on an individual provider through use of the
option. The default value is 'No'.Beginning in Shorewall 4.4.6, setting this option to 'Yes'
also simplifies PREROUTING rules in shorewall6-tcrules(5).
Previously, when TC_EXPERT=No, packets arriving through 'tracked'
provider interfaces were unconditionally passed to the PREROUTING
tcrules. This was done so that tcrules could reset the packet mark
to zero, thus allowing the packet to be routed using the 'main'
routing table. Using the main table allowed dynamic routes (such as
those added for VPNs) to be effective. The shorewall6-rtrules(5) file was
created to provide a better alternative to clearing the packet mark.
As a consequence, passing these packets to PREROUTING complicates
things without providing any real benefit. Beginning with Shorewall
4.4.6, when TRACK_PROVIDERS=Yes and TC_EXPERT=No, packets arriving
through 'tracked' interfaces will not be passed to the PREROUTING
rules. Since TRACK_PROVIDERS was just introduced in 4.4.3, this
change should be transparent to most, if not all, users.TRACK_RULES={Yes|No}Added in Shorewall 4.5.20. If set to Yes, causes the compiler to add a comment to
iptables rules to indicate the file name and line number of the
configuration entry that generated the rule. If set to No (the default), then no such comments are
added.Setting this option to Yes
requires the Comments capability in ip6tables
and kernel.UNTRACKED_DISPOSITION=[ACCEPT|A_ACCEPT|A_DROP|A_REJECT|DROP|REJECT|CONTINUE]Added in Shorewall 4.5.13. Shorewall has traditionally passed
UNTRACKED packets through the NEW section of shorewall6-rules (5). When a
packet in UNTRACKED state fails to match any rule in the UNTRACKED
section, the packet is disposed of based on this setting. The
default value is CONTINUE for compatibility with earlier
versions.UNTRACKED_LOG_LEVEL=log-levelAdded in Shorewall 4.5.13. Packets in the UNTRACKED state that
do not match any rule in the UNTRACKED section of shorewall-rules (5) are
logged at this level. The default value is empty which means no
logging is performed.USE_DEFAULT_RT=[Yes|No]Added in Shorewall6 4.4.25. When set to 'Yes', this option
causes the Shorewall6 multi-ISP feature to create a different set of
routing rules which are resilient to changes in the main routing
table. Such changes can occur for a number of reasons, VPNs going up
and down being an example. The idea is to send packets through the
main table prior to applying any of the Shorewall6-generated routing
rules. So changes to the main table will affect the routing of
packets by default.When USE_DEFAULT_RT=Yes:Both the DUPLICATE and the COPY columns in shorewall6-providers(5)
file must remain empty (or contain "-").The default route is added to the the 'default' table
rather than to the main table.balance is assumed unless
loose is specified.Packets are sent through the main routing table by a rule
with priority 999. In shorewall6-routing_rules(5),
the range 1-998 may be used for inserting rules that bypass the
main table.All provider gateways must be specified explicitly in the
GATEWAY column. detect may not
be specified.You should disable all default route management outside of
Shorewall6. If a default route is added to the main table while
Shorewall is started, then all policy routing will stop working
(except for those routing rules in the priority range
1-998).If USE_DEFAULT_RT is not set or if it is set to the empty
string then USE_DEFAULT_RT=No is assumed.USE_PHYSICAL_NAMES=[Yes|No]Added in Shorewall 4.4.27. Normally, when Shorewall creates a
Netfilter chain that relates to an interface, it uses the
interface's logical name as the base of the chain name. For example,
if the logical name for an interface is OAKLAND, then the input
chain for traffic arriving on that interface would be 'OAKLAND_in'.
If this option is set to Yes, then the physical name of the
interface will be used the base of the chain name.USE_RT_NAMES=[Yes|No]Added in Shorewall 4.5.15. When set to 'Yes', Shorewall will
use routing table (provider) names in the generated script rather
than table numbers. When set to 'No' (the default), routing table
numbers will be used.If you set USE_RT_NAMES=Yes and KEEP_RT_TABLES=Yes, then you
must insure that all of your providers have entries in
/etc/iproute2/rt_tables as well as the following entries:255 local254 main253 default250 balance0 unspecWithout these entries, the firewall will fail to
start.VERBOSITY=[number]Shorewall6 has traditionally been very noisy (produced lots of
output). You may set the default level of verbosity using the
VERBOSITY OPTION.Values are:0 - Silent. You may make it more verbose using the -v
option1 - Major progress messages displayed2 - All progress messages displayed (pre Shorewall6-3.2.0
behavior)If not specified, then 2 is assumed.WARNOLDCAPVERSION=[Yes|No]Added in Shorewall 4.5.12. When set to Yes (the default), the compiler issues a
warning when it finds a capabilities file that doesn't specify all
of the capabilities supported by the compiler. When
WARNOLDCAPVERSION is set to No, no
warning is issued.WIDE_TC_MARKS={Yes|No}Deprecated in Shorewall 4.4.26 in favor of TC_BITS and
MASK_BITS.When set to No (the default), traffic shaping marks are 8
bytes wide (possible values are 1-255). When WIDE_TC_MARKS=Yes,
traffic shaping marks are 14 bytes wide (values 1-16383). The
setting of WIDE_TC_MARKS also has an effect on the HIGH_ROUTE_MARKS
option (see above).ZONE_BITS=[number]Added in Shorewall 4.4.26. When non-zero, enables automatic
packet marking by source zone and determines the number of bits in
the 32-bit packet mark to be used for the zone mark. Default value
is 0.ZONE2ZONE={|}Added in Shorewall 4.4.4. This option determines how Shorewall
constructs chain names involving zone names and/or 'all'. The
default is '2' (e.g., fw2net).FILES/etc/shorewall6/shorewall6.confSee ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5),
shorewall6-nat(5), shorewall6-netmap(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6-tcclasses(5),
shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5),
shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-rules.xml 0000644 0001750 0001750 00000212361 12222401136 023042 0 ustar teastep teastep
shorewall6-rules5rulesShorewall6 rules file/etc/shorewall6/rulesDescriptionEntries in this file govern connection establishment by defining
exceptions to the policies laid out in shorewall6-policy(5). By default,
subsequent requests and responses are automatically allowed using
connection tracking. For any particular (source,dest) pair of zones, the
rules are evaluated in the order in which they appear in this file and the
first terminating match is the one that determines the disposition of the
request. All rules are terminating except LOG and QUEUE rules.The rules file is divided into sections. Each section is introduced
by a "Section Header" which is a line beginning with SECTION and followed
by the section name.Sections are as follows and must appear in the order listed:ALLThis section was added in Shorewall 4.4.23. rules in this
section are applied, regardless of the connection tracking state of
the packet.ESTABLISHEDPackets in the ESTABLISHED state are processed by rules in
this section.The only ACTIONs allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUEThere is an implicit ACCEPT rule inserted at the end of this
section.RELATEDPackets in the RELATED state are processed by rules in this
section.The only ACTIONs allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUEThere is an implicit rule added at the end of this section
that invokes the RELATED_DISPOSITION (shorewall6.conf(5)).INVALIDAdded in Shorewall 4.5.13. Packets in the INVALID state are
processed by rules in this section.The only Actions allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUE.There is an implicit rule added at the end of this section
that invokes the INVALID_DISPOSITION (shorewall6.conf(5)).UNTRACKEDAdded in Shorewall 4.5.13. Packets in the UNTRACKED state are
processed by rules in this section.The only Actions allowed in this section are ACCEPT, DROP,
REJECT, LOG and QUEUE.There is an implicit rule added at the end of this section
that invokes the UNTRACKED_DISPOSITION (shorewall6.conf(5)).NEWPackets in the NEW, INVALID and UNTRACKED states are processed
by rules in this section.If you are not familiar with Netfilter to the point where you are
comfortable with the differences between the various connection tracking
states, then it is suggested that you omit the ESTABLISHED and RELATED sections and place all of your rules in
the NEW section (That's after the line that reads SECTION NEW').If you specify FASTACCEPT=Yes in shorewall6.conf(5) then the ESTABLISHED and RELATED sections must be empty.An except is made if you are running Shorewall 4.4.27 or later and
you have specified a non-default value for RELATED_DISPOSITION or
RELATED_LOG_LEVEL. In that case, you may have rules in the RELATED
section of this file.You may omit any section that you don't need. If no Section Headers
appear in the file then all rules are assumed to be in the NEW
section.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION - target[:{log-level|none}[!][:tag]]Specifies the action to be taken if the connection request
matches the rule. target must be one of
the following.ACCEPTAllow the connection request.ACCEPT+like ACCEPT but also excludes the connection from any
subsequent matching DNAT[-] or REDIRECT[-] rules. Requires Shorewall 4.5.14 or
later.ACCEPT!like ACCEPT but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall6.conf(5).actionThe name of an action declared in
shorewall6-actions(5) or
in /usr/share/shorewall/actions.std.ADD(ipset:flags)Added in Shorewall 4.4.12. Causes addresses and/or port
numbers to be added to the named
ipset. The
flags specify the address or tuple
to be added to the set and must match the type of ipset
involved. For example, for an iphash ipset, either the SOURCE
or DESTINATION address can be added using
flagssrc or dst respectively (see the -A command in
ipset (8)).ADD is non-terminating. Even if a packet matches the
rule, it is passed on to the next rule.AUDIT[(accept|drop|reject)]Added in Shorewall 4.5.10. Audits the packet with the
specified type; if the type is omitted, then
is assumed. Require AUDIT_TARGET support
in the kernel and iptables.A_ACCEPT, and A_ACCEPT!Added in Shorewall 4.4.20. Audited versions of ACCEPT
and ACCEPT! respectively. Require AUDIT_TARGET support in the
kernel and iptables.A_DROP and A_DROP!Added in Shorewall 4.4.20. Audited versions of DROP and
DROP! respectively. Require AUDIT_TARGET support in the kernel
and iptables.A_REJECT AND A_REJECT!Added in Shorewall 4.4.20. Audited versions of REJECT
and REJECT! respectively. Require AUDIT_TARGET support in the
kernel and iptables.[?]COMMENTthe rest of the line will be attached as a comment to
the Netfilter rule(s) generated by the following entries. The
comment will appear delimited by "/* ... */" in the output of
"shorewall show <chain>". To stop the comment from being
attached to further rules, simply include COMMENT on a line by
itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CONTINUEFor experts only.Do not process any of the following rules for this
(source zone,destination zone). If the source and/or
destination IP address falls into a zone defined later in
shorewall6-zones(5)
or in a parent zone of the source or destination zones, then
this connection request will be passed to the rules defined
for that (those) zone(s). See shorewall6-nesting(5)
for additional information.CONTINUE!like CONTINUE but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall6.conf(5).COUNTSimply increment the rule's packet and byte count and
pass the packet to the next rule.DEL(ipset:flags)Added in Shorewall 4.4.12. Causes an entry to be deleted
from the named ipset. The
flags specify the address or tuple
to be deleted from the set and must match the type of ipset
involved. For example, for an iphash ipset, either the SOURCE
or DESTINATION address can be deleted using
flagssrc or dst respectively (see the -D command in
ipset (8)).DEL is non-terminating. Even if a packet matches the
rule, it is passed on to the next rule.DNATForward the request to another system (and optionally
another port). Requires Shorewall 4.5.14 or later.DNAT-Advanced users only.Like DNAT but only
generates the DNAT iptables
rule and not the companion ACCEPT rule. Requires Shorewall 4.5.14
or later.DROPIgnore the request.DROP!like DROP but exempts the rule from being suppressed by
OPTIMIZE=1 in shorewall6.conf(5).HELPERAdded in Shorewall 4.5.7. This action requires that the
HELPER column contains the name of the Netfilter helper to be
associated with connections matching this connection. May only
be specified in the NEW section and is useful for being able
to specify a helper when the applicable policy is ACCEPT. No
destination zone should be specified in HELPER rules.INLINE[(action)]Added in Shorewall 4.5.16. This action allows you to
construct most of the rule yourself using ip6tables syntax.
The part that you specify must follow a semicolon (';') and is
completely free-form. If the target of the rule (the part
following 'j') is something that Shorewall supports in the
ACTION column, then you may enclose it in parentheses (e.g.,
INLINE(ACCEPT)). Otherwise, you can include it after the
semicolon. In this case, you must declare the target as a
builtin action in shorewall6-actions(5).Some considerations when using INLINE:The , ,
, ,
, , and state
match ( or ) matches will always appear in the
front of the rule in that order.When multiple matches are specified, the compiler
will keep them in the order in which they appear
(excluding the above listed ones), but they will not
necessarily be at the end of the generated rule. For
example, if addresses are specified in the SOURCE and/or
DEST columns, their generated matches will appear after
those specified using ';'.LOG:levelSimply log the packet and continue with the next
rule.macro[(macrotarget)]The name of a macro defined in a file named
macro.macro. If the macro accepts an
action parameter (Look at the macro source to see if it has
PARAM in the TARGET column) then the
macro name is followed by the
parenthesized macrotarget (ACCEPT, DROP, REJECT, ...) to be substituted for the
parameter.Example: FTP(ACCEPT).The older syntax where the macro name and the target are
separated by a slash (e.g. FTP/ACCEPT) is still allowed but is
deprecated.NFLOG[(nflog-parameters)]Added in Shorewall 4.5.9.3. Queues matching packets to a
back end logging daemon via a netlink socket then continues to
the next rule. See http://www.shorewall.net/shorewall_logging.html.Similar to
LOG:NFLOG[(nflog-parameters)],
except that the log level is not changed when this ACTION is
used in an action or macro and the invocation of that action
or macro specifies a log level.NFQUEUE[(queuenumber)]Queues the packet to a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not specified, queue
zero (0) is assumed.NFQUEUE![(queuenumber)]like NFQUEUE but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall6.conf(5).NONATExcludes the connection from any subsequent DNAT[-] or REDIRECT[-] rules but doesn't generate
a rule to accept the traffic. Requires Shorewall 4.5.14 or
later.QUEUEQueue the packet to a user-space application such as
ftwall (http://p2pwall.sf.net). The application may reinsert
the packet for further processing.QUEUE!like QUEUE but exempts the rule from being suppressed by
OPTIMIZE=1 in shorewall6.conf(5).REDIRECTRedirect the request to a server running on the
firewall. Requires Shorewall 4.5.14 or later.REDIRECT-Advanced users only.Like REDIRECT but only
generates the REDIRECT
iptables rule and not the companion ACCEPT rule. Requires Shorewall 4.5.14
or later.REJECTdisallow the request and return an icmp-unreachable or
an RST packet.REJECT!like REJECT but exempts the rule from being suppressed
by OPTIMIZE=1 in shorewall6.conf(5).The target may optionally be
followed by ":" and a syslog log level (e.g, REJECT:info or
Web(ACCEPT):debug). This causes the packet to be logged at the
specified level. Note that if the ACTION involves destination network address
translation (DNAT, REDIRECT, etc.) then the packet is logged
before the destination address is
rewritten.If the ACTION names an
action declared in shorewall-actions(5) or in
/usr/share/shorewall/actions.std then:If the log level is followed by "!' then all rules in the
action are logged at the log level.If the log level is not followed by "!" then only those
rules in the action that do not specify logging are logged at
the specified level.The special log level none! suppresses logging by the
action.You may also specify ULOG or
NFLOG (must be in upper case) as a
log level.This will log to the ULOG or NFLOG target for routing to a
separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html).Actions specifying logging may be followed by a log tag (a
string of alphanumeric characters) which is appended to the string
generated by the LOGPREFIX (in shorewall.conf(5)).Example: ACCEPT:info:ftp would include 'ftp ' at the end of
the log prefix generated by the LOGPREFIX setting.SOURCE -
{zone|zone-list[+]|{all|any}[+][-]}[:interface][:{address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list}Source hosts to which the rule applies. May be a zone declared
in /etc/shorewall6/zones, $FW to
indicate the firewall itself, all,
all+, all-, all+-
or none.Beginning with Shorewall 4.4.13, you may use a
zone-list which consists of a
comma-separated list of zones declared in shorewall-zones (5). This
zone-list may be optionally followed by
"+" to indicate that the rule is to apply to intra-zone traffic as
well as inter-zone traffic.When none is used either in
the SOURCE or DEST column, the rule is ignored.all means "All Zones",
including the firewall itself. all-
means "All Zones, except the firewall itself". When all[-] is
used either in the SOURCE or
DEST column intra-zone traffic is
not affected. When all+[-] is "used, intra-zone traffic is affected.
Beginning with Shorewall 4.4.13, exclusion is supported -- see see
shorewall6-exclusion(5).Except when all[+][-] or
any[+][-] is
specified, clients may be further restricted to a list of networks
and/or hosts by appending ":" and a comma-separated list of network
and/or host addresses. Hosts may be specified by IP or MAC address;
mac addresses must begin with "~" and must use "-" as a
separator.any is equivalent to
all when there are no nested zones.
When there are nested zones, any
only refers to top-level zones (those with no parent zones). Note
that any excludes all vserver
zones, since those zones are nested within the firewall zone.Hosts may also be specified as an IP address range using the
syntax
lowaddress-highaddress.
This requires that your kernel and ip6tables contain iprange match
support. If your kernel and ip6tables have ipset match support then
you may give the name of an ipset prefaced by "+". The ipset name
may be optionally followed by a number from 1 to 6 enclosed in
square brackets ([]) to indicate the number of levels of source
bindings to be matched.Beginning with Shorewall6 4.4.17, the primary IP address of a
firewall interface can be specified by an ampersand ('&')
followed by the logical name of the interface as found in the
INTERFACE column of shorewall6-interfaces
(5).Beginning with Shorewall 4.5.4, A
countrycode-list may be specified. A
countrycode-list is a comma-separated list of up to 15 two-character
ISO-3661 country codes enclosed in square brackets ('[...]') and
preceded by a caret ('^'). When a single country code is given, the
square brackets may be omitted. A list of country codes supported by
Shorewall may be found at http://www.shorewall.net/ISO-3661.html.
Specifying a countrycode-list requires
GeoIP Match support in your ip6tables and
Kernel.When an interface is not specified,
you may omit the angled brackets ('<' and '>') around the
address(es) or you may supply them to improve readability.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall6-exclusion(5)).Examples:dmz:2002:ce7c::92b4:1::2Host 2002:ce7c:92b4:1::2 in the DMZnet:2001:4d48:ad51:24::/64Subnet 2001:4d48:ad51:24::/64 on the Internetloc:<2002:cec792b4:1::2,2002:cec792b4:1::44>Hosts 2002:cec792b4:1::2 and 2002:cec792b4:1::44 in the
local zone.loc:~00-A0-C9-15-39-78Host in the local zone with MAC address
00:A0:C9:15:39:78.net:2001:4d48:ad51:24::/64!2001:4d48:ad51:24:6:/80!2001:4d48:ad51:24:6:/80Subnet 2001:4d48:ad51:24::/64 on the Internet except for
2001:4d48:ad51:24:6:/80.$FW:ð0The primary IP address of eth0 in the firewall zone
(Shorewall6 4.4.17 and later).Alternatively, clients may be specified by interface by
appending ":" to the zone name followed by the interface name. For
example, loc:eth1 specifies a
client that communicates with the firewall system through eth1. This
may be optionally followed by another colon (":") and an
IP/MAC/subnet address as described above (e.g., loc:eth1:<2002:ce7c::92b4:1::2>).Examples:loc:eth1:<2002:cec792b4:1::2,2002:cec792b4:1::44>Hosts 2002:cec792b4:1::2 and 2002:cec792b4:1::44 in the
Local zone, with both
originating from eth1DEST -
{zone|zone-list[+]|all[+][-]}[:interface][:{address-or-range[,address-or-range]...[exclusion]|exclusion|+ipset|^countrycode-list}[port[:random]]Location of Server. May be a zone declared in shorewall6-zones(5), $FW to indicate the firewall itself, all. all+ or
none.Beginning with Shorewall 4.4.13, you may use a
zone-list which consists of a
comma-separated list of zones declared in shorewall-zones (5). Ths
zone-list may be optionally followed by
"+" to indicate that the rule is to apply to intra-zone traffic as
well as inter-zone traffic. Beginning with Shorewall-4.4.13,
exclusion is supported -- see see shorewall6-exclusion(5).Beginning with Shorewall6 4.4.17, the primary IP address of a
firewall interface can be specified by an ampersand ('&')
followed by the logical name of the interface as found in the
INTERFACE column of shorewall6-interfaces
(5).Beginning with Shorewall 4.5.4, A
countrycode-list may be specified. A
countrycode-list is a comma-separated list of up to 15 two-character
ISO-3661 country codes enclosed in square brackets ('[...]') and
preceded by a caret ('^'). When a single country code is given, the
square brackets may be omitted. A list of country codes supported by
Shorewall may be found at http://www.shorewall.net/ISO-3661.html.
Specifying a countrycode-list requires
GeoIP Match support in your ip6tables and
Kernel.When none is used either in
the SOURCE or DEST column, the rule is ignored.When all is used either in
the SOURCE or DEST column intra-zone traffic is not
affected. When all+ is used,
intra-zone traffic is affected.If the DEST zone is a bport zone,
then either:the SOURCE must be , orthe SOURCE zone must be
another bport zone associated with the same bridge, orthe SOURCE zone must be an
ipv4 zone that is associated with only the same bridge.Except when all[+]|[-] is specified, the server may be
further restricted to a particular network, host or interface by
appending ":" and the network, host or interface. See SOURCE above.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall6-exclusion(5)).Restriction: MAC addresses are not allowed (this is a
Netfilter restriction).If you kernel and ip6tables have ipset match support then you
may give the name of an ipset prefaced by "+". The ipset name may be
optionally followed by a number from 1 to 6 enclosed in square
brackets ([]) to indicate the number of levels of destination
bindings to be matched. Only one of the SOURCE and DEST columns may specify an ipset
name.The port that the server is
listening on may be included and separated from the server's IP
address by ":". If omitted, the firewall will not modify the
destination port. A destination port may only be included if the
ACTION is DNAT or REDIRECT.Example 1:loc:[2001:470:b:227::44]:3128 specifies
a local server at IP address 2001:470:b:227::44 and listening
on port 3128.Example 2:loc:[]:3128 specifies
that the destination port should be changed to 3128 but the IP
address should remain the same.The port may be specified as a service
name. You may specify a port range in the form
lowport-highport to cause connections to be
assigned to ports in the range in round-robin fashion. When a port
range is specified, lowport and
highport must be given as integers; service
names are not permitted. Additionally, the port range may be
optionally followed by :random
which causes assignment to ports in the list to be random.If the ACTION is REDIRECT or REDIRECT-, this column needs only to contain
the port number on the firewall that the request should be
redirected to. That is equivalent to specifying
::port.PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}Optional protocol - ipp2p*
requires ipp2p match support in your kernel and ip6tables. tcp:syn implies tcp plus the SYN flag must be set and the
RST,ACK and FIN flags must be reset.Beginning with Shorewall6 4.4.19, this column can contain a
comma-separated list of protocol-numbers and/or protocol names
(e.g., tcp,udp).DEST PORT(S) (dport) -
{-|port-name-number-or-range[,port-name-number-or-range]...}Optional destination Ports. A comma-separated list of Port
names (from services(5)), port numbers or port ranges; if the
protocol is icmp, this column is
interpreted as the destination icmp-type(s). ICMP types may be
specified as a numeric type, a numeric type and code separated by a
slash (e.g., 3/4), or a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.
Note that prior to Shorewall6 4.4.19, only a single ICMP type may be
listed.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no port is given, ipp2p is
assumed.A port range is expressed as
lowport:highport.This column is ignored if PROTO = all
but must be entered if any of the following columns are supplied. In
that case, it is suggested that this field contain a dash (-).If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and the
CLIENT PORT(S) list below:1. There are 15 or less ports listed.2. No port ranges are included or your kernel and ip6tables
contain extended multi-port match support.SOURCE PORT(S) (sport) -
{-|port-name-number-or-range[,port-name-number-or-range]...}Optional source port(s). If omitted, any source port is
acceptable. Specified as a comma- separated list of port names, port
numbers or port ranges.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.Unless you really understand IP, you should leave this
column empty or place a dash (-)
in the column. Most people who try to use this column get it
wrong.If you don't want to restrict client ports but need to specify
a later column, then place "-" in this column.If your kernel contains multi-port match support, then only a
single Netfilter rule will be generated if in this list and the
DEST PORT(S) list above:1. There are 15 or less ports listed.2. No port ranges are included or your kernel and ip6tables
contain extended multi-port match support.ORIGINAL DEST (origdest) -
[-]Included for compatibility with Shorewall. Enter '-' in this
column if you need to specify one of the later columns.RATE LIMIT (rate) - [-|[{s|d}:[[name]:]]]rate/{sec|min|hour|day}[:burst]You may optionally rate-limit the rule by placing a value in
this column:rate is the number of connections per
interval (sec or min) and burst is the
largest burst permitted. If no burst is given,
a value of 5 is assumed. There may be no no white-space embedded in
the specification.Example: 10/sec:20When or is specified,
the rate applies per source IP address or per destination IP address
respectively. The name may be chosen by
the user and specifies a hash table to be used to count matching
connections. If not given, the name shorewallN (where N is a unique integer) is
assumed. Where more than one POLICY specifies the same name, the
connections counts for the rules are aggregated and the individual
rates apply to the aggregated count.USER/GROUP (user) - [!][user-name-or-number-or-range][:group-name-or-number-or-range]This optional column may only be non-empty if the SOURCE is
the firewall itself.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Beginning with Shorewall 4.5.8, multiple user or group
names/ids separated by commas may be specified.Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group2001-2099UIDs 2001 through 2099 (Shorewall 4.5.6 and
later)MARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.CONNLIMIT - [!]limit[:mask]May be used to limit the number of simultaneous connections
from each individual host to limit
connections. Requires connlimit match in your kernel and ip6tables.
While the limit is only checked on rules specifying CONNLIMIT, the
number of current connections is calculated over all current
connections from the SOURCE host. By default, the limit is applied
to each host but can be made to apply to networks of hosts by
specifying a mask. The
mask specifies the width of a VLSM mask
to be applied to the source address; the number of current
connections is then taken over all hosts in the subnet
source-address/mask.
When is specified, the rule matches when the
number of connection exceeds the
limit.TIME -
timeelement[&timeelement...]May be used to limit the rule to a particular time period each
day, to particular days of the week or month, or to a range defined
by dates and times. Requires time match support in your kernel and
ip6tables.timeelement may be:timestart=hh:mm[:ss]Defines the starting time of day.timestop=hh:mm[:ss]Defines the ending time of day.utcTimes are expressed in Greenwich Mean Time.localtzDeprecated by the Netfilter team in favor of kerneltz. Times are expressed in Local
Civil Time (default).kerneltzAdded in Shorewall 4.5.2. Times are expressed in Local
Kernel Time (requires iptables 1.4.12 or later).weekdays=ddd[,ddd]...where ddd is one of
, ,
, ,
, or
monthdays=dd[,dd],...where dd is an ordinal day of
the monthdatestart=yyyy[-mm[-dd[hh[:mm[:ss]]]]]Defines the starting date and time.datestop=yyyy[-mm[-dd[hh[:mm[:ss]]]]]Defines the ending date and time.HEADERS -
[!][any:|exactly:]header-list
(Optional - Added in Shorewall 4.4.15)The header-list consists of a
comma-separated list of headers from the following list.auth, ah, or 51Authentication Headers extension
header.esp, or 50Encrypted Security Payload
extension header.hop, hop-by-hop or 0Hop-by-hop options extension header.route, ipv6-route or 41IPv6 Route extension header.frag, ipv6-frag or 44IPv6 fragmentation extension header.none, ipv6-nonxt or 59No next headerproto, protocol or 255Any protocol header.If any: is specified, the
rule will match if any of the listed headers are present. If
exactly: is specified, the will
match packets that exactly include all specified headers. If neither
is given, any: is assumed.If ! is entered, the rule
will match those packets which would not be matched when ! is omitted.SWITCH -
[!]switch-name[={0|1}]Added in Shorewall6 4.4.24 and allows enabling and disabling
the rule without requiring shorewall6
restart.Enables the rule if the value stored in
/proc/net/nf_condition/switch-name
is 1. Disables the rule if that file contains 0 (the default). If
'!' is supplied, the test is inverted such that the rule is enabled
if the file contains 0.Within the switch-name, '@0' and
'@{0}' are replaced by the name of the chain to which the rule is a
added. The switch-name (after '@...'
expansion) must begin with a letter and be composed of letters,
decimal digits, underscores or hyphens. Switch names must be 30
characters or less in length.Switches are normally off. To
turn a switch on:echo 1 >
/proc/net/nf_condition/switch-nameTo turn it off again:echo 0 >
/proc/net/nf_condition/switch-nameSwitch settings are retained over shorewall6
restart.Beginning with Shorewall 4.5.10, when the
switch-name is followed by
or , then the switch is
initialized to off or on respectively by the
start command. Other commands do not affect the
switch setting.HELPER - [helper]Added in Shorewall 4.5.7.In the NEW section, causes the named conntrack
helper to be associated with this
connection; the contents of this column are ignored unless ACTION is
ACCEPT*, DNAT* or REDIRECT*.In the RELATED section, will only match if the related
connection has the named helper
associated with it.The helper may be one of:If the HELPERS option is specified in shorewall.conf(5), then any module
specified in this column must be listed in the HELPERS
setting.ExampleExample 1:Accept SMTP requests from the DMZ to the internet #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
ACCEPT dmz net tcp smtpExample 4:You want to accept SSH connections to your firewall only from
internet IP addresses 2002:ce7c::92b4:1::2 and
2002:ce7c::92b4:1::22 #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL
# PORT PORT(S) DEST
ACCEPT net:<2002:ce7c::92b4:1::2,2002:ce7c::92b4:1::22> \
$FW tcp 22Example 5:You wish to limit SSH connections from remote systems to 1/min
with a burst of three (to allow for limited retry): #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE
# PORT(S) PORT(S) DEST LIMIT
SSH(ACCEPT) net all - - - - s:1/min:3Example 6:Forward port 80 to dmz host $BACKUP if switch 'primary_down'
is set. #ACTION SOURCE DEST PROTO DEST SOURCE ORIGINAL RATE USER/ MARK CONNLIMIT TIME HEADERS SWITCH
# PORT(S) PORT(S) DEST LIMIT GROUP
DNAT net dmz:$BACKUP tcp 80 - - - - - - - - primary_downExample 7:Drop all email from IP addresses in the country whose ISO-3661
country code is ZZ. #ACTION SOURCE DEST PROTO DEST
# PORT(S)
DROP net:^ZZ fw tcp 25Example 8:You want to generate your own rule involving ip6tables targets
and matches not supported by Shorewall. #ACTION SOURCE DEST PROTO DEST
# PORT(S)
INLINE $FW net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3The above will generate the following ip6tables-restore
input: -A fw2net -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3Note that SECCTX must be defined as a builtin action in shorewall6-actions(5): #ACTION OPTIONS
SECCTX builtinFILES/etc/shorewall6/rulesSee ALSOhttp://www.shorewall.net/shorewall_logging.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-blrules(5), shorewall6-hosts(5),
shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/manpages/ 0000755 0001750 0001750 00000000000 12222401136 020670 5 ustar teastep teastep shorewall-docs-xml-4.5.21/manpages6/manpages/shorewall6-lite-vardir.xml 0000644 0001750 0001750 00000005666 12222401136 025735 0 ustar teastep teastep
shorewall6-lite-vardir5vardirShorewall6 Lite file/etc/shorewall6-lite/vardirDescriptionThis file does not exist by default. You may create the file if you
want to change the directory used by Shorewall6 Lite to store state
information, including compiled firewall scripts. By default, the
directory used is /var/lib/shorewall6-lite/.The file contains a single variable assignment:directorywhere directory is the name of a
directory. If you add this file, you should copy the files from
/var/lib/shorewall6-lite to the new directory before
performing a shorewall6-lite restart.Beginning with Shorewall 4.5.2, use of this file is deprecated in
favor of specifying VARDIR in the shorewallrc file
used during installation of Shorewall Core. While the name of the
variable remains VARDIR, the meaning is slightly different. When set in
shorewallrc, Shorewall6 Lite will create a directory under the specified
path name to hold state information.Example:
VARDIR=/opt/var/lib/The state directory for Shorewall Lite will be
/opt/var/lib/shorewall6-lite.
When VARDIR is set in
/etc/shorewall6-lite/vardir, Shorewall Lite will
save its state in the directory
specified.ExampleVARDIR=/root/shorewall6FILES/etc/shorewall6-lite/vardirSee ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-route_rules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/manpages/shorewall6-lite.xml 0000644 0001750 0001750 00000114606 12222401136 024443 0 ustar teastep teastep
shorewall6-lite8shorewall6-liteAdministration tool for Shoreline 6 Firewall Lite (Shorewall6
Lite)shorewall6-lite|-optionsinterface[:host-list]zoneshorewall6-lite|-optionsaddressshorewall6-lite|-optionsshorewall6-lite|-optionsinterface[:host-list]zoneshorewall6-lite|-options{ interface |
provider }shorewall6-lite|-optionsaddressshorewall6-lite|-optionsshorewall6-lite|-options{ interface |
provider }shorewall6-lite|-optionsfilenameshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionsaddressmaskaddress/vlsmshorewall6-lite|-optionsaddress1address2shorewall6-lite|-optionsiptables match
expressionshorewall6-lite|-optionsaddressshorewall6-lite|-optionsrefresh-intervalshorewall6-lite|-optionsaddressshorewall6-lite|-optionsiptables match
expressionshorewall6-lite|-optionsaddressshorewall6-lite|-optionsshorewall6-lite|-optionsdirectoryshorewall6-lite|-optionsfilenameshorewall6-lite|-optionsfilenameshorewall6-lite|-options
{|||}chainshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionseventshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionsshorewall6-lite|-optionsDescriptionThe shorewall6-lite utility is used to control the Shoreline
Firewall Lite (Shorewall Lite).OptionsThe and options are
used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace.The nolock prevents the command from
attempting to acquire the shorewall6-lite lockfile. It is useful if you
need to include shorewall commands in
/etc/shorewall/started.The options control the amount of output that
the command produces. They consist of a sequence of the letters v and q. If the
options are omitted, the amount of output is determined by the setting of
the VERBOSITY parameter in shorewall6.conf(5). Each v adds one to the effective verbosity and each
q subtracts one from the effective
VERBOSITY. Alternately, v may be followed
immediately with one of -1,0,1,2 to specify a specify VERBOSITY. There may
be no white-space between v and the
VERBOSITY.The options may also include the letter
which causes all progress messages to be
timestamped.CommandsThe available commands are listed below.addAdds a list of hosts or subnets to a dynamic zone usually used
with VPN's.The interface argument names an interface
defined in the shorewall-interfaces(5)
file. A host-list is comma-separated list whose
elements are host or network addresses.The add command is not very robust. If
there are errors in the host-list,
you may see a large number of error messages yet a subsequent
shorewall6-lite show zones command will
indicate that all hosts were added. If this happens, replace
add by delete and run the
same command again. Then enter the correct command.allowRe-enables receipt of packets from hosts previously
blacklisted by a drop, logdrop, reject, or logreject command.clearClear will remove all rules and chains installed by
shorewall6-lite. The firewall is then wide open and unprotected.
Existing connections are untouched. Clear is often used to see if
the firewall is causing connection problems.If is given, the command will be processed
by the compiled script that executed the last successful start, restart or refresh command if that script exists.deleteThe delete command reverses the effect of an earlier add command.The interface argument names an interface
defined in the shorewall-interfaces(5)
file. A host-list is comma-separated list whose
elements are a host or network address.disableAdded in Shorewall 4.4.26. Disables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.dropCauses traffic from the listed addresses
to be silently dropped.dumpProduces a verbose report about the firewall configuration for
the purpose of problem analysis.The -x option causes actual
packet and byte counts to be displayed. Without that option, these
counts are abbreviated. The -m
option causes any MAC addresses included in shorewall6-lite log
messages to be displayed.The -l option causes the rule
number for each Netfilter rule to be displayed.enableAdded in Shorewall 4.4.26. Enables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.forgetDeletes /var/lib/shorewall6-lite/filename
and /var/lib/shorewall6-lite/save. If no
filename is given then the file specified by
RESTOREFILE in shorewall6.conf(5) is
assumed.helpDisplays a syntax summary.hitsGenerates several reports from shorewall6-lite log messages in
the current log file. If the option is included,
the reports are restricted to log messages generated today.ipcalcIpcalc displays the network address, broadcast address,
network in CIDR notation and netmask corresponding to the
input[s].iprangeIprange decomposes the specified range of IP addresses into
the equivalent list of network/host addresses.iptraceThis is a low-level debugging command that causes iptables
TRACE log records to be created. See iptables(8) for details.The iptables match expression must
be one or more matches that may appear in both the raw table OUTPUT
and raw table PREROUTING chains.The trace records are written to the kernel's log buffer with
facility = kernel and priority = warning, and they are routed from
there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) --
shorewall6-lite has no control over where the messages go; consult
your logging daemon's documentation.logdropCauses traffic from the listed addresses
to be logged then discarded. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5).logwatchMonitors the log file specified by the LOGFILE option in
shorewall6.conf(5) and
produces an audible alarm when new shorewall6-lite messages are
logged. The -m option causes the
MAC address of each packet source to be displayed if that
information is available. The
refresh-interval specifies the time in
seconds between screen refreshes. You can enter a negative number by
preceding the number with "--" (e.g., shorewall6-lite
logwatch -- -30). In this case, when a packet count
changes, you will be prompted to hit any key to resume screen
refreshes.logrejectCauses traffic from the listed addresses
to be logged then rejected. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5).noiptraceThis is a low-level debugging command that cancels a trace
started by a preceding iptrace command.The iptables match expression must
be one given in the iptrace command being
canceled.resetAll the packet and byte counters in the firewall are
reset.restartRestart is similar to shorewall6-lite
start except that it assumes that the firewall is already
started. Existing connections are maintained.The option causes shorewall6-lite to avoid
updating the routing table(s).The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.restoreRestore shorewall6-lite to a state saved using the shorewall6-lite save command. Existing
connections are maintained. The filename names
a restore file in /var/lib/shorewall6-lite created using shorewall6-lite save; if no
filename is given then shorewall6-lite will be
restored from the file specified by the RESTOREFILE option in shorewall6.conf(5).saveThe dynamic blacklist is stored in
/var/lib/shorewall6-lite/save. The state of the firewall is stored
in /var/lib/shorewall6-lite/filename for use by
the shorewall6-lite restore. If
filename is not given then the state is saved
in the file specified by the RESTOREFILE option in shorewall6.conf(5).showThe show command can have a number of different
arguments:capabilitiesDisplays your kernel/iptables capabilities. The
-f option causes the display
to be formatted as a capabilities file for use with compile -e.[ [ ] chain...
]The rules in each chain are
displayed using the iptables
-Lchain-n -v command. If no
chain is given, all of the chains in the
filter table are displayed. The -x option is passed directly through to
iptables and causes actual packet and byte counts to be
displayed. Without this option, those counts are abbreviated.
The -t option specifies the
Netfilter table to display. The default is filter.The -b ('brief') option
causes rules which have not been used (i.e. which have zero
packet and byte counts) to be omitted from the output. Chains
with no rules displayed are also omitted from the
output.The -l option causes
the rule number for each Netfilter rule to be
displayed.If the t option and the
keyword are both omitted and any of the
listed chains do not exist, a usage
message is displayed.classifiers|filtersDisplays information about the packet classifiers
defined on the system as a result of traffic shaping
configuration.configDisplays distribution-specific defaults.connectionsDisplays the IP connections currently being tracked by
the firewall.event
eventAdded in Shorewall 4.5.19. Displays the named
event.eventsAdded in Shorewall 4.5.19. Displays all events.ipDisplays the system's IPv4 configuration.ipaAdded in Shorewall 4.4.17. Displays the per-IP
accounting counters (shorewall-accounting
(5)).logDisplays the last 20 shorewall6-lite messages from the
log file specified by the LOGFILE option in shorewall6.conf(5). The
-m option causes the MAC
address of each packet source to be displayed if that
information is available.marksAdded in Shorewall 4.4.26. Displays the various fields
in packet marks giving the min and max value (in both decimal
and hex) and the applicable mask (in hex).natDisplays the Netfilter nat table using the command
iptables -t nat -L -n -v.The
-x option is passed directly
through to iptables and causes actual packet and byte counts
to be displayed. Without this option, those counts are
abbreviated.policiesAdded in Shorewall 4.4.4. Displays the applicable policy
between each pair of zones. Note that implicit intrazone
ACCEPT policies are not displayed for zones associated with a
single network where that network doesn't specify
.routingDisplays the system's IPv4 routing configuration.rawDisplays the Netfilter raw table using the command
iptables -t raw -L -n -v.The
-x option is passed directly
through to iptables and causes actual packet and byte counts
to be displayed. Without this option, those counts are
abbreviated.tcDisplays information about queuing disciplines, classes
and filters.zonesDisplays the current composition of the Shorewall zones
on the system.startStart Shorewall Lite. Existing connections through
shorewall6-lite managed interfaces are untouched. New connections
will be allowed only if they are allowed by the firewall rules or
policies.The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.stopStops the firewall. All existing connections, except those
listed in shorewall-routestopped(5)
or permitted by the ADMINISABSENTMINDED option in shorewall6.conf(5), are taken
down. The only new traffic permitted through the firewall is from
systems listed in shorewall-routestopped(5)
or by ADMINISABSENTMINDED.If is given, the command will be processed
by the compiled script that executed the last successful start, restart or refresh command if that script exists.statusProduces a short report about the state of the
Shorewall-configured firewall.versionDisplays Shorewall's version. The option
is included for compatibility with earlier Shorewall releases and is
ignored.EXIT STATUSIn general, when a command succeeds, status 0 is returned; when the
command fails, a non-zero status is returned.The status command returns exit status as
follows:0 - Firewall is started.3 - Firewall is stopped or cleared4 - Unknown state; usually means that the firewall has never been
started.See ALSOhttp://www.shorewall.net/starting_and_stopping_shorewall.htmshorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall_interfaces(5),
shorewall6-ipsets(5), shorewall6-maclist(5), shorewall6-masq(5),
shorewall6-netmap(5), shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/manpages/shorewall6-lite.conf.xml 0000644 0001750 0001750 00000016436 12222401136 025371 0 ustar teastep teastep
shorewall6-lite.conf5shorewall6-lite.confShorewall6 Lite global configuration file/etc/shorewall6-lite/shorewall6-lite.confDescriptionThis file sets options that apply to Shorewall6 Lite as a
whole.The file consists of Shell comments (lines beginning with '#'),
blank lines and assignment statements
(variable=value). Each
variable's setting is preceded by comments that describe the variable and
it's effect.Any option not specified in this file gets its value from the
shorewall6.conf file used during compilation of
/var/lib/shorewall6-lite/firewall. Those settings may be found in the file
/var/lib/shorewall6-lite/firewall.conf.OPTIONSThe following options may be set in shorewall6.conf.IP6TABLES=[pathname]This parameter names the ip6tables executable to be used by
Shorewall6. If not specified or if specified as a null value, then
the ip6tables executable located using the PATH option is
used.LOGFILE=[pathname]This parameter tells the /sbin/shorewall6 program where to
look for Shorewall6 messages when processing the dump, logwatch, show
log, and hits commands.
If not assigned or if assigned an empty value, /var/log/messages is
assumed.LOGFORMAT=["formattemplate"]The value of this variable generate the --log-prefix setting
for Shorewall6 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, 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
“Shorewall6:%s:%s:” is assumed.PATH=pathname[:pathname]...Determines the order in which Shorewall6 searches directories
for executable files.RESTOREFILE=[filename]Specifies the simple name of a file in /var/lib/shorewall6 to
be used as the default restore script in the shorewall6 save, shorewall6 restore, shorewall6 forget and shorewall6 -f start commands.SHOREWALL_SHELL=[pathname]This option is used to specify the shell program to be used to
interpret the compiled script. If not specified or specified as a
null value, /bin/sh is assumed. Using a light-weight shell such as
ash or dash can significantly improve performance.SUBSYSLOCK=[pathname]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 Shorewall6 to work
with your distribution's initscripts. For RedHat, this should be set
to /var/lock/subsys/shorewall6. For Debian, the value is
/var/state/shorewall6 and in LEAF it is /var/run/shorewall.VERBOSITY=[number]Shorewall6 has traditionally been very noisy (produced lots of
output). You may set the default level of verbosity using the
VERBOSITY OPTION.Values are:0 - Silent. You may make it more verbose using the -v
option1 - Major progress messages displayed2 - All progress messages displayed (old default
behavior)If not specified, then 2 is assumed.FILES/etc/shorewall6-lite/shorewall6.confSee ALSOhttp://www.shorewall.net/Documentation_Index.htmlshorewall6-lite(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5),
shorewall6-nat(5), shorewall6-netmap(5), shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5),
shorewall6-route_rules(5), shorewall6-routestopped(5),
shorewall6-rules(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tos.xml 0000644 0001750 0001750 00000013612 12222401136 022513 0 ustar teastep teastep
shorewall6-tos5tosShorewall6 Type of Service rules file/etc/shorewall6/tosDescriptionThis file defines rules for setting Type Of Service (TOS). Its use
is deprecated, beginning in Shorewall 4.5.1, in favor of the TOS target in
shorewall6-tcrules
(5).The columns in the file are as follows.SOURCE - {all|address]|all:address|$FW}If all, may optionally be
followed by ":" and an IP address, a MAC address, a subnet
specification or the name of an interface.Example: all:2002:ce7c::92b4:1::2MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78DEST - {all|address]|all:address}Example: 2002:ce7c::92b4:1::2PROTOCOL -
proto-name-or-numberProtocol name or number.SOURCE PORT(S) -
{-|port|lowport:highport}Source port or port range. If all ports, use "-".DEST PORT(S) -
{-|port|lowport:highport}Destination port or port range. If all ports, use "-"TOS -
tosMust be one of the following;tos-minimize-delay (16)
tos-maximize-throughput (8)
tos-maximize-reliability (4)
tos-minimize-cost (2)
tos-normal-service (0)To specify more than one flag, add their values together and
specify the numeric result.MARK - [!]value[/mask][:C]If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.FILES/etc/shorewall6/tosSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-actions.xml 0000644 0001750 0001750 00000011762 12222401136 023352 0 ustar teastep teastep
shorewall6-actions5actionsshorewall6 action declaration file/etc/shorewall6/actionsDescriptionThis file allows you to define new ACTIONS for use in rules (see
shorewall6-rules(5)). You define
the ip6tables rules to be performed in an ACTION in
/etc/shorewall6/action.action-name.Columns are:NAMEThe name of the action. ACTION names should begin with an
upper-case letter to distinguish them from Shorewall-generated chain
names and be composed of letters, digits or numbers. If you intend
to log from the action then the name must be no longer than 11
characters in length if you use the standard LOGFORMAT.OPTIONSAdded in Shorewall 4.5.10. Available options are:builtinAdded in Shorewall 4.5.16. Defines the action as a rule
target that is supported by your ip6tables but is not directly
supported by Shorewall. The action may be used as the rule
target in an INLINE rule in shorewall6-rules(5).inlineCauses the action body (defined in
action.action-name) to be expanded
in-line like a macro rather than in its own chain. You can
list Shorewall Standard Actions in this file to specify the
option.Some of the Shorewall standard actions cannot be used
in-line and will generate a warning and the compiler will
ignore if you try to use them that
way:BroadcastDropSmurfsInvalid (Prior to Shorewall 4.5.13)NotSyn (Prior to Shorewall 4.5.13)RST (Prior to Shorewall 4.5.13)TCPFlagsnoinlineCauses any later option for the
same action to be ignored with a warning.nologAdded in Shorewall 4.5.11. When this option is
specified, the compiler does not automatically apply the log
level and/or tag from the invocation of the action to all
rules inside of the action. Rather, it simply sets the
$_loglevel and $_logtag shell variables which can be used
within the action body to apply those logging options only to
a subset of the rules.FILES/etc/shorewall6/actionsSee ALSOhttp://shorewall.net/Actions.htmlshorewall6(8), shorewall6-accounting(5), shorewall6-blacklist(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcrules.xml 0000644 0001750 0001750 00000144635 12222401136 023401 0 ustar teastep teastep
shorewall6-tcrules5tcrulesShorewall6 Packet Marking rules file/etc/shorewall6/tcrulesDescriptionEntries in this file cause packets to be marked as a means of
classifying them for traffic control or policy routing.Unlike rules in the shorewall6-rules(5) file, evaluation
of rules in this file will continue after a match. So the final mark for
each packet will be the one assigned by the LAST tcrule that
matches.If you use multiple internet providers with the 'track' option, in
/etc/shorewall6/providers be sure to read the restrictions at http://shorewall.net/MultiISP.html.Beginning with Shorewall 4.5.4, the tcrules file supports two
different formats:FORMAT 1 (default - deprecated)The older limited-function version of TPROXY is
supported.FORMAT 2The newer version of TPROXY is supported.The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is
the preferred form; the form without the '?' is deprecated.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION -
actionaction may assume one of the
following values.A mark value which is an integer in
the range 1-255.Normally will set the mark value. If preceded by a
vertical bar ("|"), the mark value will be logically ORed with
the current mark value to produce a new mark value. If preceded
by an ampersand ("&"), will be logically ANDed with the
current mark value to produce a new mark value.Both "|" and "&" require Extended MARK Target support
in your kernel and ip6tables; neither may be used with
connection marks (see below).May optionally be followed by :P, :F
or :T, :I
where :P indicates
that marking should occur in the PREROUTING chain, :F indicates that marking should occur in
the FORWARD chain, :I indicates
that marking should occur in the INPUT chain (added in Shorewall
4.4.13) and :T indicates that
marking should occur in the POSTROUTING chain. If neither
:P, :F nor :T follow the mark value then the chain
is determined as follows:- If the SOURCE is $FW[:address-or-range[,address-or-range]...],
then the rule is inserted into the OUTPUT chain. The behavior
changed in Shorewall6-perl 4.1. Only high mark values may be
assigned in this case. Packet marking rules for traffic shaping
of packets originating on the firewall must be coded in the
POSTROUTING chain (see below).- Otherwise, the chain is determined by the setting of
MARK_IN_FORWARD_CHAIN in shorewall6.conf(5).Please note that :I is
included for completeness and affects neither traffic shaping
nor policy routing.If your kernel and ip6tables include CONNMARK support then
you can also mark the connection rather than the packet.The mark value may be optionally followed by "/" and a
mask value (used to determine those bits of the connection mark
to actually be set). When a mask is specified, the result of
logically ANDing the mark value with the mask must be the same
as the mark value.The mark and optional mask are then followed by one
of:+CMark the connection in the chain determined by the
setting of MARK_IN_FORWARD_CHAINCFMark the connection in the FORWARD chainCPMark the connection in the PREROUTING chain.CTMark the connection in the POSTROUTING chainCIMark the connection in the INPUT chain. This option
is included for completeness and has no applicability to
traffic shaping or policy routing.A mark range which is a pair of integers separated by a
dash ("-"). Added in Shorewall 4.5.9.May be optionally followed by a slash ("/") and a mask and
requires the Statistics Match capability
in iptables and kernel. Marks in the specified range are
assigned to packets on a round-robin fashion.When a mask is specified, the result of logically ANDing
each mark value with the mask must be the same as the mark
value. The least significant bit in the mask is used as an
increment. For example, if '0x200-0x400/0xff00' is specified,
then the assigned mark values are 0x200, 0x300 and 0x400 in
equal proportions. If no mask is specified, then ( 2 **
MASK_BITS ) - 1 is assumed (MASK_BITS is set in shorewall6.conf(5)).May optionally be followed by :P, :F,:T or
:I where
:P indicates that marking should occur in the
PREROUTING chain, :F indicates
that marking should occur in the FORWARD chain, :I indicates that marking should occur in
the INPUT chain (added in Shorewall 4.4.13), and :T indicates that marking should occur in
the POSTROUTING chain. If neither :P, :F
nor :T follow the mark value
then the chain is determined as follows:- If the SOURCE is $FW[:address-or-range[,address-or-range]...],
then the rule is inserted into the OUTPUT chain. When
HIGH_ROUTE_MARKS=Yes, only high mark values may be assigned
there. Packet marking rules for traffic shaping of packets
originating on the firewall must be coded in the POSTROUTING
chain (see below).- Otherwise, the chain is determined by the setting of
MARK_IN_FORWARD_CHAIN in shorewall.conf(5).Please note that :I is
included for completeness and affects neither traffic shaping
nor policy routing.If your kernel and iptables include CONNMARK support then
you can also mark the connection rather than the packet.The mark range may be optionally followed by "/" and a
mask value (used to determine those bits of the connection mark
to actually be set). When a mask is specified, the result of
logically ANDing the mark value with each of the masks must be
the same as the mark value.The mark range and optional mask may followed by one
of:CMark the connection in the chain determined by the
setting of MARK_IN_FORWARD_CHAINCFMark the connection in the FORWARD chainCPMark the connection in the PREROUTING chain.CTMark the connection in the POSTROUTING chainCIMark the connection in the INPUT chain. This option
is included for completeness and has no applicability to
traffic shaping or policy routing.A classification Id (classid) of the form
major:minor where
major and minor are
integers. Corresponds to the 'class' specification in these
traffic shaping modules: atm
cbq
dsmark
pfifo_fast
htb
prioClassification occurs in the POSTROUTING chain except when
the SOURCE is $FW[:address] in
which case classification occurs in the OUTPUT chain.When using Shorewall6's built-in traffic shaping tool, the
major class is the device number (the first
device in shorewall6-tcdevices(5)
is major class 1, the second device is major class 2, and so on)
and the minor class is the class's MARK
value in shorewall6-tcclasses(5)
preceded by the number 1 (MARK 1 corresponds to minor class 11,
MARK 5 corresponds to minor class 15, MARK 22 corresponds to
minor class 122, etc.).Beginning with Shorewall 4.4.27, the classid may be
optionally followed by ':' and a capital letter designating the
chain where classification is to occur.FFORWARD chain.TPOSTROUTING chain (default).CHECKSUMAdded in Shorewall 4.5.9. Compute and fill in the checksum
in a packet that lacks a checksum. This is particularly useful
if you need to work around old applications, such as dhcp
clients, that do not work well with checksum offloads, but you
don't want to disable checksum offload in your device.Requires 'Checksum Target' support in your kernel and
ip6tables.[?]COMMENT -- the rest of
the line will be attached as a comment to the Netfilter rule(s)
generated by the following entries. The comment will appear
delimited by "/* ... */" in the output of shorewall6
show mangleTo stop the comment from being attached to further rules,
simply include COMMENT on a line by itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CONTINUE Don't process
any more marking rules in the table.As in 1) above, may be followed by :P or :F. Currently, CONTINUE may not be used
with exclusion (see the SOURCE and DEST
columns below); that restriction will be removed when
ip6tables/Netfilter provides the necessary support.DIVERTAdded in Shorewall 4.5.3. Two DIVERT rule should precede
the TPROXY rule and should select DEST PORT tcp 80 and SOURCE
PORT tcp 80 respectively (assuming that tcp port 80 is being
proxied). DIVERT avoids sending packets to the TPROXY target
once a socket connection to Squid3 has been established by
TPROXY. DIVERT marks the packet with a unique mark and exempts
it from any rules that follow.DSCP(dscp)Added in Shorewall 4.5.1. Sets the
Differentiated Services Code Point field
in the IP header. The dscp value may
be given as an even number (hex or decimal) or as the name of a
DSCP class. Valid class names and their associated hex numeric
values are: CS0 => 0x00
CS1 => 0x08
CS2 => 0x10
CS3 => 0x18
CS4 => 0x20
CS5 => 0x28
CS6 => 0x30
CS7 => 0x38
BE => 0x00
AF11 => 0x0a
AF12 => 0x0c
AF13 => 0x0e
AF21 => 0x12
AF22 => 0x14
AF23 => 0x16
AF31 => 0x1a
AF32 => 0x1c
AF33 => 0x1e
AF41 => 0x22
AF42 => 0x24
AF43 => 0x26
EF => 0x2eTo indicate more than one class, add their hex values
together and specify the result.May be optionally followed by ':' and a capital letter
designating the chain where classification is to occur.FFORWARD chain.TPOSTROUTING chain.HL([-|+]number)Added in Shorewall 4.4.24.Prior to Shorewall 4.5.7.2, may be optionally followed by
:F but the resulting rule is
always added to the FORWARD chain. Beginning with Shorewall
4.5.7.s, it may be optionally followed by :P, in which case the rule is added to
the PREROUTING chain.If + is included, packets
matching the rule will have their HL (hop limit) incremented by
number. Similarly, if - is included, matching packets have
their HL decremented by number. If
neither + nor - is given, the HL of matching packets is
set to number. The valid range of
values for number is 1-255.IMQ(number)Added in Shorewall 4.5.1. Specifies that the packet should
be passed to the IMQ identified by
number. Requires IMQ Target support
in your kernel and ip6tables.RESTORE[/mask] --
restore the packet's mark from the connection's mark using the
supplied mask if any. Your kernel and ip6tables must include
CONNMARK support.As in 1) above, may be followed by :P or :FSAME (Added in Shorewall
4.3.5) -- Some websites run applications that require multiple
connections from a client browser. Where multiple 'balanced'
providers are configured, this can lead to problems when some of
the connections are routed through one provider and some through
another. The SAME target allows you to work around that problem.
SAME may be used in the PREROUTING and OUTPUT chains. When used
in PREROUTING, it causes matching connections from an individual
local system to all use the same provider. For example:
#ACTION SOURCE DEST PROTO DEST
# PORT(S)
SAME:P 192.168.1.0/24 0.0.0.0/0 tcp 80,443
If a host in 192.168.1.0/24 attempts a connection on TCP port 80
or 443 and it has sent a packet on either of those ports in the
last five minutes then the new connection will use the same
provider as the connection over which that last packet was
sent.When used in the OUTPUT chain, it causes all matching
connections to an individual remote system to all use the same
provider. For example:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
SAME $FW 0.0.0.0/0 tcp 80,443
If the firewall attempts a connection on TCP port 80 or 443 and
it has sent a packet on either of those ports in the last five
minutes to the same remote system then the new connection will
use the same provider as the connection over which that last
packet was sent.SAVE[/mask] -- save
the packet's mark to the connection's mark using the supplied
mask if any. Your kernel and ip6tables must include CONNMARK
support.As in 1) above, may be followed by :P or :FSTATE {NEW|RELATED|ESTABLISHED|INVALID} [,...]Added in Shorewall 4.5.9. The rule will only match if the
packet's connection is in one of the listed states.TOS(tos[/mask])Added in Shorewall 4.5.1. Sets the Type of
Service field in the IP header. The
tos value may be given as an number
(hex or decimal) or as the name of a TOS type. Valid type names
and their associated hex numeric values are:Minimize-Delay => 0x10,
Maximize-Throughput => 0x08,
Maximize-Reliability => 0x04,
Minimize-Cost => 0x02,
Normal-Service => 0x00To indicate more than one class, add their hex values
together and specify the result.When tos is given as a number,
it may be optionally followed by '/' and a
mask. When no
mask is given, the value 0xff is
assumed. When tos is given as a type
name, the mask 0x3f is
assumed.The action performed is to zero out the bits specified by
the mask, then set the bits specified
by tos.May be optionally followed by ':' and a capital letter
designating the chain where classification is to occur.FFORWARD chain.TPOSTROUTING chain (default).TPROXY(mark[,[port][,[address]]])
-- FORMAT 1Transparently redirects a packet without altering the IP
header. Requires a local provider to be defined in shorewall6-providers(5).There are three parameters to TPROXY - only the first
(mark) is required:mark - the MARK value
corresponding to the local provider in shorewall6-providers(5).port - the port on which
the proxy server is listening. If omitted, the original
destination port.address - a local (to the
firewall) IP address on which the proxy server is listening.
If omitted, the IP address of the interface on which the
request arrives.TPROXY([port][,[address]]])
-- FORMAT 2Transparently redirects a packet without altering the IP
header. Requires a local provider to be defined in shorewall6-providers(5).There are three parameters to TPROXY - only the first
(mark) is required:port - the port on which
the proxy server is listening. If omitted, the original
destination port.address - a local (to the
firewall) IP address on which the proxy server is listening.
If omitted, the IP address of the interface on which the
request arrives.SOURCE - {-|{interface|$FW}|[{interface|$FW}:]<address-or-range[,address-or-range]...}[exclusion]>Source of the packet. A comma-separated list of interface
names, IP addresses, MAC addresses and/or subnets for packets being
routed through a common path. List elements may also consist of an
interface name followed by ":" and an address (e.g.,
eth1:<2002:ce7c:92b4::/48>). For example, all packets for
connections masqueraded to eth0 from other interfaces can be matched
in a single rule with several alternative SOURCE criteria. However,
a connection whose packets gets to eth0 in a different way, e.g.,
direct from the firewall itself, needs a different rule.Accordingly, use $FW in its
own separate rule for packets originating on the firewall. In such a
rule, the ACTION column may NOT specify either :P or :F
because marking for firewall-originated packets always occurs in the
OUTPUT chain.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78When an interface is not specified, the angled brackets
('<' and '>') surrounding the address(es) may be
omitted.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall6-exclusion(5)).DEST - {-|{interface|$FW}[{interface|$FW}:]<address-or-range[,address-or-range]...}[exclusion]>Destination of the packet. Comma separated list of IP
addresses and/or subnets. If your kernel and ip6tables include
iprange match support, IP address ranges are also allowed. List
elements may also consist of an interface name followed by ":" and
an address (e.g., eth1:<2002:ce7c:92b4::/48>). If the
ACTION column specifies a
classification of the form
major:minor then this
column may also contain an interface name.When an interface is not specified, the angled brackets
('<' and '>') surrounding the address(es) may be
omitted.Beginning with Shorewall 4.4.13, $FW may be given by itself or
qualified by an address list. This causes marking to occur in the
INPUT chain.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall6-exclusion(5)).PROTO - {-|{tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}[,...]}Protocol - ipp2p requires
ipp2p match support in your kernel and ip6tables.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...]Optional destination Ports. A comma-separated list of Port
names (from services(5)), port numbers or
port ranges; if the protocol is ipv6-icmp, this column is interpreted as the
destination icmp-type(s). ICMP types may be specified as a numeric
type, a numeric type and code separated by a slash (e.g., 3/4), or
a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no PORT is given, ipp2p is
assumed.An entry in this field requires that the PROTO column specify
tcp (6), udp (17), ipv6-icmp (58), sctp (132) or udplite (136). Use
'-' if any of the following field is supplied.SOURCE PORT(S) (sport) -
[-|port-name-number-or-range[,port-name-number-or-range]...]Optional source port(s). If omitted, any source port is
acceptable. Specified as a comma-separated list of port names, port
numbers or port ranges.An entry in this field requires that the PROTO column specify
tcp (6), udp (17), sctp (132) or udplite (136). Use '-' if any of
the following fields is supplied.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.USER - [!][user-name-or-number][:group-name-or-number]This optional column may only be non-empty if the SOURCE is
the firewall itself.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
groupTEST - [!]value[/mask][:C]Optional. Defines a test on the existing packet or connection
mark. The rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.LENGTH -
[length|[min]:[max]]Optional - packet payload length. This field, if present allow
you to match the length of a packet payload (Layer 4 data ) against
a specific value or range of values. You must have iptables length
support for this to work. A range is specified in the form
min:max where either
min or max (but not both)
may be omitted. If min is omitted, then 0 is
assumed; if max is omitted, than any packet
that is min or longer will match.TOS (Optional) -
tosType of service. Either a standard name, or a numeric value to
match.Minimize-Delay (16)
Maximize-Throughput (8)
Maximize-Reliability (4)
Minimize-Cost (2)
Normal-Service (0)CONNBYTES -
[!]min:[max[:{O|R|B}[:{B|P|A}]]]Optional connection Bytes; defines a byte or packet range that
the connection must fall within in order for the rule to
match.A packet matches if the the packet/byte count is within the
range defined by min and
max (unless ! is given in which case, a packet
matches if the packet/byte count is not within the range).
min is an integer which defines the beginning
of the byte/packet range. max is an integer
which defines the end of the byte/packet range; if omitted, only the
beginning of the range is checked. The first letter gives the
direction which the range refers to:
O - The original
direction of the connection.R - The opposite
direction from the original connection.B - The total of both
directions.
If omitted, B is
assumed.The second letter determines what the range refers
to.
B - BytesP - PacketsA - Average packet
size.
If omitted, B is
assumed.HELPER -
helperOptional. Names a Netfilter protocol
helper module such as ,
, , etc. A packet will
match if it was accepted by the named helper module.Example: Mark all FTP data connections with mark
4:#ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST LENGTH TOS CONNBYTES HELPER
# PORT(S)
4 ::/0 ::/0 TCP - - - - - - - ftpHEADERS -
[!][any:|exactly:]header-list
(Optional - Added in Shorewall 4.4.15)The header-list consists of a
comma-separated list of headers from the following list.auth, ah, or 51Authentication Headers extension
header.esp, or 50Encrypted Security Payload
extension header.hop, hop-by-hop or 0Hop-by-hop options extension header.route, ipv6-route or 41IPv6 Route extension header.frag, ipv6-frag or 44IPv6 fragmentation extension header.none, ipv6-nonxt or 59No next headerproto, protocol or 255Any protocol header.If any: is specified, the
rule will match if any of the listed headers are present. If
exactly: is specified, the will
match packets that exactly include all specified headers. If neither
is given, any: is assumed.If ! is entered, the rule
will match those packets which would not be matched when ! is omitted.PROBABILITY -
[probability]Added in Shorewall 4.5.0. When non-empty, requires the
Statistics Match capability in your kernel
and ip6tables and causes the rule to match randomly but with the
given probability. The
probability is a number 0 <
probability <= 1 and may be expressed
at up to 8 decimal points of precision.ExampleExample 1:Mark all forwarded ICMP echo traffic with packet mark 1. Mark
all forwarded peer to peer traffic with packet mark 4.This is a little more complex than otherwise expected. Since
the ipp2p module is unable to determine all packets in a connection
are P2P packets, we mark the entire connection as P2P if any of the
packets are determined to match.We assume packet/connection mark 0 means unclassified. #ACTION SOURCE DEST PROTO PORT(S) SOURCE USER TEST
# PORT(S)
1 ::/0 ::/0 icmp echo-request
1 ::/0 ::/0 icmp echo-reply
RESTORE ::/0 ::/0 all - - - 0
CONTINUE ::/0 ::/0 all - - - !0
4 ::/0 ::/0 ipp2p:all
SAVE ::/0 ::/0 all - - - !0If a packet hasn't been classified (packet mark is 0), copy the
connection mark to the packet mark. If the packet mark is set, we're
done. If the packet is P2P, set the packet mark to 4. If the packet
mark has been set, save it to the connection mark.FILES/etc/shorewall6/tcrulesSee ALSOhttp://shorewall.net/traffic_shaping.htmhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/PacketMarking.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-ecn(5), shorewall6-exclusion(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-interfaces.xml 0000644 0001750 0001750 00000060713 12222401136 024035 0 ustar teastep teastep
shorewall6-interfaces5interfacesshorewall6 interfaces file/etc/shorewall6/interfacesDescriptionThe interfaces file serves to define the firewall's network
interfaces to shorewall6. The order of entries in this file is not
significant in determining zone composition.Beginning with Shorewall 4.5.3, the interfaces file supports two
different formats:FORMAT 1 (default - deprecated)There is a ANYCAST column which provides compatibility with
older versions of Shorewall..FORMAT 2The BROADCAST column is omitted.The format is specified by a line as follows:
[?]FORMAT {1|2}
The optional '?' was introduced in Shorewall 4.5.11 and ?FORMAT is
the preferred form; the form without the '?' is deprecated.The columns in the file are as follows.ZONE -
zone-nameZone for this interface. Must match the name of a zone
declared in /etc/shorewall6/zones. You may not list the firewall
zone in this column.If the interface serves multiple zones that will be defined in
the shorewall6-hosts(5)
file, you should place "-" in this column.If there are multiple interfaces to the same zone, you must
list them in separate entries.Example:
#ZONE INTERFACE BROADCAST
loc eth1 -
loc eth2 -
Beginning with Shorewall 4.5.17, if you specify a zone for the
'lo' interface, then that zone must be defined as type
in shorewall6-zones(5).INTERFACE -
interface[:port]Logical name of interface. Each interface may be listed only
once in this file. You may NOT specify the name of a "virtual"
interface (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18.
If the option is not specified, then the
logical name is also the name of the actual interface.You may use wildcards here by specifying a prefix followed by
the plus sign ("+"). For example, if you want to make an entry that
applies to all PPP interfaces, use 'ppp+'; that would match ppp0,
ppp1, ppp2, …Please note that the '+' means 'one or more additional characters' so 'ppp'
does not match 'ppp+'.Care must be exercised when using wildcards where there is
another zone that uses a matching specific interface. See shorewall6-nesting(5) for a
discussion of this problem.Shorewall6 allows '+' as an interface name.There is no need to define the loopback interface (lo) in this
file.If a port is given, then the
interface must have been defined
previously with the option. The OPTIONS
column must be empty when a port is
given.ANYCAST - -Enter '-' in this column. It
is here for compatibility between Shorewall6 and Shorewall and is
omitted if FORMAT is 2.OPTIONS (Optional) -
[option[,option]...]A comma-separated list of options from the following list. The
order in which you list the options is not significant but the list
should have no embedded white-space.accept_ra[={0|1|2}]Added in Shorewall 4.5.16. Values are:0Do not accept Router Advertisements.1Accept Route Advertisements if forwarding is
disabled.2Overrule forwarding behavior. Accept Route
Advertisements even if forwarding is enabled.If the option is specified without a value, then the
value 1 is assumed.blacklistCheck packets arriving on this interface against the
shorewall6-blacklist(5)
file.Beginning with Shorewall 4.4.13:If a zone is given in the
ZONES column, then the behavior is as if blacklist had been specified in the
IN_OPTIONS column of shorewall6-zones(5).Otherwise, the option is ignored with a
warning:
WARNING: The 'blacklist'
option is ignored on multi-zone
interfaces
bridgeDesignates the interface as a bridge. Beginning with
Shorewall 4.4.7, setting this option also sets
.destonlyAdded in Shorewall 4.5.17. Causes the compiler to omit
rules to handle traffic from this interface.dhcpSpecify this option when any of the following are
true:the interface gets its IP address via DHCPthe interface is used by a DHCP server running on
the firewallthe interface has a static IP but is on a LAN
segment with lots of DHCP clients.the interface is a simple bridge with a
DHCP server on one port and DHCP clients on another
port.If you use Shorewall-perl for
firewall/bridging, then you need to include
DHCP-specific rules in shorewall-rules(8).
DHCP uses UDP ports 546 and 547.This option allows DHCP datagrams to enter and leave the
interface.forward[={0|1}]Sets the /proc/sys/net/ipv6/conf/interface/forwarding
option to the specified value. If no value is supplied, then 1
is assumed.ignore[=1]When specified, causes the generated script to ignore
up/down events from Shorewall-init for this device.
Additionally, the option exempts the interface from hairpin
filtering. When '=1' is omitted, the ZONE column must contain
'-' and must be the only
OPTION.Beginning with Shorewall 4.5.5, may be specified as
'' which only causes the generated
script to ignore up/down events from Shorewall-init; hairpin
filtering is still applied. In this case, the above
restrictions on the ZONE and OPTIONS columns are
lifted.mss=numberCauses forwarded TCP SYN packets entering or leaving on
this interface to have their MSS field set to the specified
number.nets=(net[,...])Limit the zone named in the ZONE column to only the
listed networks. If you specify this option, be sure to
include the link-local network (ff80::/10).nets=dynamicAdded in Shorewall 4.4.21. Defines the zone as
dynamic. Requires ipset match support
in your iptables and kernel. See http://www.shorewall.net/Dynamic.html
for further information.optionalWhen is specified for an
interface, shorewall6 will be silent when:a /proc/sys/net/ipv6/conf/
entry for the interface cannot be modified.The first global IPv6 address of the interface
cannot be obtained.This option may not be specified together with required.physical=nameAdded in Shorewall 4.4.4. When specified, the interface
or port name in the INTERFACE column is a logical name that
refers to the name given in this option. It is useful when you
want to specify the same wildcard port name on two or more
bridges. See http://www.shorewall.net/bridge-Shorewall-perl.html#Multiple.If the interface name is a wildcard
name (ends with '+'), then the physical
name must also end in '+'.If is not specified, then it's
value defaults to the interface
name.requiredAdded in Shorewall 4.4.10. When specified, the firewall
will fail to start if the interface named in the INTERFACE
column is not usable. May not be specified together with
optional.routeback[={0|1}]If specified, indicates that shorewall6 should include
rules that allow traffic arriving on this interface to be
routed back out that same interface. This option is also
required when you have used a wildcard in the INTERFACE column
if you want to allow traffic between the interfaces that match
the wildcard.If you specify this option, then you should also specify
(see below) if you are running
Shorewall 4.5.7 or later; otherwise, you should specify
(see below).Beginning with Shorewall 4.5.18, you may specify this
option to explicitly reset (e.g., routeback=0). This can be used to
override Shorewall's default setting for bridge devices which
is routeback=1.rpfilterAdded in Shorewall 4.5.7. This is an anti-spoofing
measure that requires the 'RPFilter Match' capability in your
iptables and kernel. It provides a more efficient alternative
to the option below.sourceroute[={0|1}]If this option is not specified for an interface, then
source-routed packets will not be accepted from that interface
unless explicitly enabled via sysconf. Only set this option to
1 (enable source routing) if you know what you are doing. This
might represent a security risk and is not usually
needed.Only those interfaces with the
option will have their setting
changed; the value assigned to the setting will be the value
specified (if any) or 1 if no value is given.This option does not work with a wild-card
interface name (e.g., eth0.+) in
the INTERFACE column.sfilter=(net[,...])Added in Shorewall 4.4.20. At this writing (spring
2011), Linux does not support reverse path filtering (RFC3704)
for IPv6. In its absence, may be used
as an anti-spoofing measure.This option should be used on bridges or other
interfaces with the option. On
these interfaces, should list those
local networks that are connected to the firewall through
other interfaces.tcpflagsPackets arriving on this interface are checked for
certain illegal combinations of TCP flags. Packets found to
have such a combination of flags are handled according to the
setting of TCP_FLAGS_DISPOSITION after having been logged
according to the setting of TCP_FLAGS_LOG_LEVEL.proxyndp[={0|1}]Sets
/proc/sys/net/ipv6/conf/interface/proxy_ndp.Note: This option does
not work with a wild-card interface
name (e.g., eth0.+) in the INTERFACE column.Only those interfaces with the
option will have their setting changed; the value assigned to
the setting will be the value specified (if any) or 1 if no
value is given.unmanagedAdded in Shorewall 4.5.18. Causes all traffic between
the firewall and hosts on the interface to be accepted. When
this option is given:The ZONE column must contain '-'.Only the following other options are allowed with
unmanaged:accept_raforwardignoreoptionalphysicalsourcerouteproxyndpwait=secondsAdded in Shorewall 4.4.10. Causes the generated script
to wait up to seconds seconds for the
interface to become usable before applying the required or optional options.ExampleExample 1:Suppose you have eth0 connected to a DSL modem and eth1
connected to your local network You have a DMZ using eth2.Your entries for this setup would look like:FORMAT 2
#ZONE INTERFACE OPTIONS
net eth0 -
loc eth1 -
dmz eth2 -Example 4 (Shorewall 4.4.9 and later):You have a bridge with no IP address and you want to allow
traffic through the bridge.FORMAT 2
#ZONE INTERFACE OPTIONS
- br0 routebackFILES/etc/shorewall6/interfacesSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-exclusion.xml 0000644 0001750 0001750 00000007755 12222401136 023732 0 ustar teastep teastep
shorewall6-exclusion5exclusionExclude a set of hosts from a definition in a shorewall6
configuration file.address-or-range[,address-or-range]zone-name[,zone-name]DescriptionExclusion is used when you wish to exclude one or more addresses
from a definition. An exclamation point is followed by a comma-separated
list of addresses. The addresses may be single host addresses (e.g.,
fe80::2a0:ccff:fedb:31c4) or they may be network addresses in CIDR format
(e.g., fe80::2a0:ccff:fedb:31c4/64). If your kernel and ip6tables include
iprange support, you may also specify ranges of ip addresses of the form
lowaddress-highaddressNo embedded white-space is allowed.Exclusion can appear after a list of addresses and/or address
ranges. In that case, the final list of address is formed by taking the
first list and then removing the addresses defined in the
exclusion.Beginning in Shorewall 4.4.13, the second form of exclusion is
allowed after all and any in the SOURCE and DEST columns of
/etc/shorewall/rules. It allows you to omit arbitrary zones from the list
generated by those key words.If you omit a sub-zone and there is an explicit or explicit
CONTINUE policy, a connection to/from that zone can still be matched by
the rule generated for a parent zone.For example:
/etc/shorewall6/zones:#ZONE TYPE
z1 ip
z2:z1 ip
.../etc/shorewall6/policy:#SOURCE DEST POLICY
z1 net CONTINUE
z2 net REJECT/etc/shorewall6/rules:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT all!z2 net tcp 22In this case, SSH connections from z2 to net will
be accepted by the generated z1 to
net ACCEPT rule.
FILES/etc/shorewall6/hosts/etc/shorewall6/masq/etc/shorewall6/rules/etc/shorewall6/tcrulesSee ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-conntrack.xml 0000644 0001750 0001750 00000040314 12222401136 023667 0 ustar teastep teastep
shorewall6-conntrack5conntrackshorewall6 conntrack file/etc/shorewall6/conntrackDescriptionThe original intent of the notrack
file was to exempt certain traffic from Netfilter connection tracking.
Traffic matching entries in the file were not to be tracked.The role of the file was expanded in Shorewall 4.4.27 to include all
rules that can be added in the Netfilter raw table. In 4.5.7, the file's name was changed to
conntrack.The file supports two different column layouts: FORMAT 1, FORMAT 2,
and FORMAT 3, FORMAT 1 being the default. The three differ as
follows:in FORMAT 2 and 3, there is an additional leading ACTION
column.in FORMAT 3, the SOURCE column accepts no zone name; rather the
ACTION column allows a SUFFIX that determines the chain(s) that the
generated rule will be added to.When an entry in the following form is encountered, the format of
the following entries are assumed to be of the specified
format.[?]FORMATformatwhere format is either 1,2 or 3.Format 3 was introduced in Shorewall 4.5.10. The optional '?' was
introduced in Shorewall 4.5.11 and ?FORMAT is the preferred form; the form
without the '?' is deprecated.Comments may be attached to Netfilter rules generated from entries
in this file through the use of COMMENT lines. These lines begin with the
word COMMENT; the remainder of the line is treated as a comment which is
attached to subsequent rules until another COMMENT line is found or until
the end of the file is reached. To stop adding comments to rules, use a
line with only the word COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for COMMENT
and is preferred.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION - {NOTRACK|CT:helper:name[(arg=val[,...])|CT:notrack|drop}[:chain-designator]This column is only present when FORMAT >= 2. Values other
than NOTRACK require CT Target support in
your iptables and kernel. or
Disables connection tracking for this packet.Added in Shorewall 4.5.10. Silently discard the
packet.:nameAttach the helper identified by the
name to this connection. This is more
flexible than loading the conntrack helper with preset ports.
May be followed by an option list of
arg=val
pairs in parentheses:=event[,...]Only generate the specified conntrack events for this
connection. Possible event types are: new, related, destroy, reply, assured, protoinfo, helper, mark (this is connection mark, not
packet mark), natseqinfo,
and secmark. If more than
one event is listed, the
event list must be enclosed in
parentheses (e.g., ctevents=(new,related)).Only generate a new
expectation events for this connection.When FORMAT = 1, this column is not present and the rule is
processed as if NOTRACK had been entered in this column.Beginning with Shorewall 4.5.10, when FORMAT = 3, this column
can end with a colon followed by a
chain-designator. The
chain-designator can be one of the
following:PThe rule is added to the raw table PREROUTING chain.
This is the default if no
chain-designator is present.OThe rule is added to the raw table OUTPUT chain.PO or OPThe rule is added to the raw table PREROUTING and OUTPUT
chains.SOURCE (formats 1 and 2) ‒
zone[:interface][:address-list]where zone is the name of a zone,
interface is an interface to that zone,
and address-list is a comma-separated
list of addresses (may contain exclusion - see shorewall6-exclusion
(5)).Beginning with Shorewall 4.5.7, can be
used as the zone name to mean
all zones.Beginning with Shorewall 4.5.10, can be
used as the zone name to mean all
off-firewall zones.SOURCE (format 3) ‒
{-|interface[:address-list]|address-list}Where interface is an interface to
that zone, and address-list is a
comma-separated list of addresses (may contain exclusion - see
shorewall-exclusion
(5)).COMMENT is only allowed in format 1; the remainder of the line
is treated as a comment that will be associated with the generated
rule(s).DEST ‒
{-|interface[:address-list]|address-list}where address-list is a
comma-separated list of addresses (may contain exclusion - see
shorewall6-exclusion
(5)).PROTO ‒
protocol-name-or-number[,...]A protocol name from /etc/protocols or a
protocol number.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT(S) (dport) - port-number/service-name-listA comma-separated list of port numbers and/or service names
from /etc/services. May also include port
ranges of the form
low-port:high-port
if your kernel and iptables include port range support.SOURCE PORT(S) (sport) - port-number/service-name-listA comma-separated list of port numbers and/or service names
from /etc/services. May also include port
ranges of the form
low-port:high-port
if your kernel and iptables include port range support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S).USER/GROUP (user) ‒
[user][:group]May only be specified if the SOURCE
zone is $FW. Specifies the effective user
id and or group id of the process sending the traffic.SWITCH -
[!]switch-name[={0|1}]Added in Shorewall6 4.5.10 and allows enabling and disabling
the rule without requiring shorewall6
restart.Enables the rule if the value stored in
/proc/net/nf_condition/switch-name
is 1. Disables the rule if that file contains 0 (the default). If
'!' is supplied, the test is inverted such that the rule is enabled
if the file contains 0.Within the switch-name, '@0' and
'@{0}' are replaced by the name of the chain to which the rule is a
added. The switch-name (after '@...'
expansion) must begin with a letter and be composed of letters,
decimal digits, underscores or hyphens. Switch names must be 30
characters or less in length.Switches are normally off. To
turn a switch on:echo 1 >
/proc/net/nf_condition/switch-nameTo turn it off again:echo 0 >
/proc/net/nf_condition/switch-nameSwitch settings are retained over shorewall6
restart.When the switch-name is followed by
or , then the switch is
initialized to off or on respectively by the
start command. Other commands do not affect the
switch setting.EXAMPLESExample 1:Use the FTP helper for TCP port 21 connections from the firewall
itself.FORMAT 2
#ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP
# PORT(S) PORT(S)
CT:helper:ftp(expevents=new) fw - tcp 21 Example 2 (Shorewall 4.5.10 or later):Drop traffic to/from all zones to IP address 2001:1.2.3::4FORMAT 2
#ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP
# PORT(S) PORT(S)
DROP all-:2001:1.2.3::4 -
DROP all 2001:1.2.3::4
orFORMAT 3
#ACTION SOURCE DEST PROTO DEST SOURCE USER/GROUP
# PORT(S) PORT(S)
DROP:P 2001:1.2.3::4 -
DROP:PO - 2001:1.2.3::4
FILES/etc/shorewall6/notrackSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-ipsec(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-proxyarp(5),
shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5),
shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5),
shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5),
shorewall6-tunnels(5), shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-ipsets.xml 0000644 0001750 0001750 00000010760 12222401136 023216 0 ustar teastep teastep
shorewall-ipsets5ipsetsSpecifying the name if an ipset in Shorewall6 configuration
files+ipsetname+ipsetname[flag,...]+[ipsetname,...]DescriptionNote: In the above syntax descriptions, the square brackets ("[]")
are to be taken literally rather than as meta-characters.In most places where a network address may be entered, an ipset may
be substituted. Set names must be prefixed by the character "+", must
start with a letter and may be composed of alphanumeric characters, "-"
and "_".Whether the set is matched against the packet source or destination
is determined by which column the set name appears (SOURCE or DEST). For
those set types that specify a tuple, two alternative syntaxes are
available:[number] - Indicates that 'src' or
'dst' should repeated number times. Example: myset[2].[flag,...] where
flag is or
. Example: myset[src,dst].In a SOURCE column, the following pairs are equivalent:+myset[2] and +myset[src,src]In a DEST column, the following pairs are equivalent:+myset[2] and +myset[dst,dst]Beginning with Shorewall 4.4.14, multiple source or destination
matches may be specified by enclosing the set names within +[...]. The set
names need not be prefixed with '+'. When such a list of sets is
specified, matching packets must match all of the listed sets.For information about set lists and exclusion, see shorewall-exclusion (5).Beginning with Shorewall 4.5.16, you can increment one or more
nfacct objects each time a packet matches an ipset. You do that by listing
the objects separated by commas within parentheses.Example:+myset[src](myobject)In that example, when the source address of a packet matches the
myset ipset, the myobject nfacct counter will be incremented.Examples+myset+myset[src]+myset[2]+[myset1,myset2[dst]]FILES/etc/shorewall6/accounting/etc/shorewall6/blacklist/etc/shorewall6/hosts -- Note:
Multiple matches enclosed in +[...] may not be used in this file./etc/shorewall6/maclist -- Note:
Multiple matches enclosed in +[...] may not be used in this file./etc/shorewall6/rules/etc/shorewall6/secmarks/etc/shorewall6/tcrulesSee ALSOshorewall6(8), shorewall6-actions(5), shorewall6-blacklist(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-masq.xml 0000644 0001750 0001750 00000047142 12222401136 022654 0 ustar teastep teastep
shorewall6-masq5masqShorewall6 Masquerade/SNAT definition file/etc/shorewall6/masqDescriptionUse this file to define Source NAT (SNAT). Requires Shorewall 4.5.14
or later.The entries in this file are order-sensitive. The first entry that
matches a particular connection will be the one that is used.If you have more than one ISP link, adding entries to this file
will not force connections to go out
through a particular link. You must use entries in shorewall6-rtrules(5) or
PREROUTING entries in shorewall-tcrules(5) to do
that.The columns in the file are as follows.INTERFACE:DEST - {[+]interfacelist|[:[dest-address[,dest-address]...[exclusion]]|[?]COMMENT}Outgoing interfacelist. This may be a
comma-separated list of interface names. This is usually your
internet interface.Each interface must match an entry in shorewall6-interfaces(5).
Shorewall allows loose matches to wildcard entries in shorewall6-interfaces(5).
For example, ppp0 in this
file will match a shorewall6-interfaces(5)
entry that defines ppp+.Where more that
one internet provider share a single interface, the provider
is specified by including the provider name or number in
parentheses: eth0(Avvanta)In that case, you will want to specify the interface's
address for that provider in the ADDRESS column.The interface may be qualified by adding the character ":"
followed by a comma-separated list of destination host or subnet
addresses to indicate that you only want to change the source IP
address for packets being sent to those particular destinations.
Exclusion is allowed (see shorewall6-exclusion(5)) as
are ipset names preceded by a plus sign '+'.Comments may be attached to Netfilter rules generated from
entries in this file through the use of COMMENT lines. These lines
begin with the word COMMENT; the remainder of the line is treated as
a comment which is attached to subsequent rules until another
COMMENT line is found or until the end of the file is reached. To
stop adding comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for
COMMENT and is preferred.SOURCE -
{interface|address[,address][exclusion]}Set of hosts that you wish to SNAT; one or more host or
network addresses separated by comma. You may use ipset names
preceded by a plus sign (+) to specify a set of hosts.ADDRESS (Optional) - [-|NONAT|[address-or-address-range[,address-or-address-range]...][:lowport-highport][:random][:persistent]|detect|random]If you do not specify an address or address range,
masquerading will be performed. This requires Masquerade
Target support in your kernel and ip6tables.If you specify an address here, SNAT will be used and this
will be the source address.You may also specify a range of up to 256 IP addresses if you
want the SNAT address to be assigned from that range in a
round-robin fashion by connection. The range is specified by
first.ip.in.range-last.ip.in.range.
You may follow the port range with:random in which case assignment of ports
from the list will be random. random may also be specified by itself in
this column in which case random local port assignments are made for
the outgoing connections.Example:
[2001:470:a:227::2]-[2001:470:a:227::10]:1000-1010You may follow the port range (or :random) with :persistent. This is only useful when an
address range is specified and causes a client to be given the same
source/destination IP pair.This column may not contain DNS Names.Normally, Netfilter will attempt to retain the source port
number. You may cause netfilter to remap the source port by
following an address or range (if any) by ":" and a port range with
the format
lowport-highport. If this
is done, you must specify "tcp" or "udp" in the PROTO column.Examples: [2001:470:a:787::2]:5000-6000If you simply place NONAT in
this column, no rewriting of the source IP address or port number
will be performed. This is useful if you want particular traffic to
be exempt from the entries that follow in the file.PROTO (Optional) - {-|[!]{protocol-name|protocol-number}[,...]}If you wish to restrict this entry to a particular protocol
then enter the protocol name (from protocols(5)) or number
here.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) (Optional) -
[[!]port-name-or-number[,port-name-or-number]...]If the PROTO column specifies TCP (6), UDP (17), DCCP (33),
SCTP (132) or UDPLITE (136) then you may list one or more port
numbers (or names from services(5)) or port ranges separated by
commas.Port ranges are of the form
lowport:highport.IPSEC (Optional) -
[option[,option]...]If you specify a value other than "-" in this column, you must
be running kernel 2.6 and your kernel and iptables must include
policy match support.Comma-separated list of options from the following. Only
packets that will be encrypted via an SA that matches these options
will have their source address changed.reqid=numberwhere number is specified using
setkey(8) using the 'unique:number option
for the SPD level.spi=<number>where number is the SPI of the SA
used to encrypt/decrypt packets.proto=ah|esp|ipcompIPSEC Encapsulation Protocolmss=numbersets the MSS field in TCP packetsmode=transport|tunnelIPSEC modetunnel-src=address[/mask]only available with mode=tunneltunnel-dst=address[/mask]only available with mode=tunnelstrictMeans that packets must match all rules.nextSeparates rules; can only be used with strictyesWhen used by itself, causes all traffic that will be
encrypted/encapsulated to match the rule.MARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.USER/GROUP (Optional) -
[!][user-name-or-number][:group-name-or-number][+program-name]Only locally-generated connections will match if this column
is non-empty.When this column is non-empty, the rule matches only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group+upnpd#program named upnpdThe ability to specify a program name was removed from
Netfilter in kernel version 2.6.14.SWITCH -
[!]switch-name[={0|1}]Added in Shorewall 4.5.1 and allows enabling and disabling the
rule without requiring shorewall restart.The rule is enabled if the value stored in
/proc/net/nf_condition/switch-name
is 1. The rule is disabled if that file contains 0 (the default). If
'!' is supplied, the test is inverted such that the rule is enabled
if the file contains 0.Within the switch-name, '@0' and
'@{0}' are replaced by the name of the chain to which the rule is a
added. The switch-name (after '@...'
expansion) must begin with a letter and be composed of letters,
decimal digits, underscores or hyphens. Switch names must be 30
characters or less in length.Switches are normally off. To
turn a switch on:echo 1 >
/proc/net/nf_condition/switch-nameTo turn it off again:echo 0 >
/proc/net/nf_condition/switch-nameSwitch settings are retained over shorewall
restart.Beginning with Shorewall 4.5.10, when the
switch-name is followed by
or , then the switch is
initialized to off or on respectively by the
start command. Other commands do not affect the
switch setting.ORIGINAL DEST (origdest) -
[-|address[,address]...[exclusion]|exclusion](Optional) This column may be included and may contain one or
more addresses (host or network) separated by commas. Address ranges
are not allowed. When this column is supplied, rules are generated
that require that the original destination address matches one of
the listed addresses. It is useful for specifying that SNAT should
occur only for connections that were acted on by a DNAT when they
entered the firewall.ExamplesExample 1:You have a simple 'masquerading' setup where eth0 connects to
a DSL or cable modem and eth1 connects to your local network with
subnet 2001:470:b:787::0/64Your entry in the file will be: #INTERFACE SOURCE ADDRESS
eth0 2001:470:b:787::0/64 -FILES/etc/shorewall6/masq
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcinterfaces.xml 0000644 0001750 0001750 00000020435 12222401136 024361 0 ustar teastep teastep
shorewall6-tcinterfaces5tcinterfacesShorewall6 file/etc/shorewall6/tcinterfacesDescriptionThis file lists the interfaces that are subject to simple traffic
shaping. Simple traffic shaping is enabled by setting TC_ENABLED=Simple in
shorewall6.conf(5).A note on the bandwidth definition used in this
file:don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is not.you can use one of the following units:kbpsKilobytes per second.mbpsMegabytes per second.kbitKilobits per second.mbitMegabits per second.bps or numberBytes per second.k or kbKilo bytes.m or mbMegabytes.Only whole integers are allowed.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).INTERFACEThe logical name of an interface. If you run both IPv4 and
IPv6 Shorewall firewalls, a given interface should only be listed in
one of the two configurations.TYPE - [external|internal]Optional. If given specifies whether the interface is
external (facing toward the
Internet) or internal (facing
toward a local network) and enables SFQ flow classification.Simple traffic shaping is only useful on interfaces where
queuing occurs. As a consequence, internal interfaces seldom
benefit from simple traffic shaping. VPN interfaces are an
exception because the encapsulated packets are later transferred
over a slower external link.IN-BANDWIDTH (in_bandwidth) -
{-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}The incoming bandwidth of that interface.
Please note that you are not able to do traffic shaping on incoming
traffic, as the traffic is already received before you could do so.
But this allows you to define the maximum traffic allowed for this
interface in total, if the rate is exceeded, the packets are
dropped. You want this mainly if you have a DSL or Cable connection
to avoid queuing at your providers side.If you don't want any traffic to be dropped, set this to a
value to zero in which case Shorewall will not create an ingress
qdisc. Must be set to zero if the REDIRECTED INTERFACES column is
non-empty.The optional burst option was added in Shorewall 4.4.18. The
default burst is 10kb. A larger
burst can help make the
bandwidth more accurate; often for fast
lines, the enforced rate is well below the specified
bandwidth.What is described above creates a rate/burst policing filter.
Beginning with Shorewall 4.4.25, a rate-estimated policing filter
may be configured instead. Rate-estimated filters should be used
with Ethernet adapters that have Generic Receive Offload enabled by
default. See Shorewall FAQ
97a.To create a rate-estimated filter, precede the bandwidth with
a tilde ("~"). The optional interval and decay_interval determine
how often the rate is estimated and how many samples are retained
for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt
for details.OUT-BANDWIDTH (out_bandwidth) -
[rate[:[burst][:[latency][:[peek][:[minburst]]]]]]Added in Shorewall 4.4.13. The terms are defined in
tc-tbf(8).Shorewall provides defaults as follows:burst - 10kblatency - 200msThe remaining options are defaulted by tc(8).FILES/etc/shorewall6/tcinterfaces.See ALSOhttp://ace-host.stuart.id.au/russell/files/tc/doc/sch_tbf.txthttp://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txtshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcpri, shorewall6-tos(5),
shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-hosts.xml 0000644 0001750 0001750 00000017533 12222401136 023054 0 ustar teastep teastep
shorewall6-hosts5hostsshorewall6 file/etc/shorewall6/hostsDescriptionThis file is used to define zones in terms of subnets and/or
individual IP addresses. Most simple setups don't need to (should not)
place anything in this file.The order of entries in this file is not significant in determining
zone composition. Rather, the order that the zones are declared in shorewall6-zones(5) determines the
order in which the records in this file are interpreted.The only time that you need this file is when you have more than
one zone connected through a single interface.If you have an entry for a zone and interface in shorewall6-interfaces(5) then do
not include any entries in this file for that same (zone, interface)
pair.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ZONE -
zone-nameThe name of a zone declared in shorewall6-zones(5). You may not
list the firewall zone in this column.HOST(S) (hosts)-
interface:{[{address-or-range[,address-or-range]...|+ipset}[exclusion]The name of an interface defined in the shorewall6-interfaces(5)
file followed by a colon (":") and a comma-separated list whose
elements are either:The IPv6 address of a
host.A network in CIDR format.An IP address range of the form
low.address-high.address.
Your kernel and ip6tables must have iprange match
support.The name of an ipset.The word which makes the zone
dynamic in that you can use the shorewall add
and shorewall delete commands to change to
composition of the zone. This capability was added in Shorewall
4.4.21.
You may also exclude certain hosts through use of an
exclusion (see shorewall6-exclusion(5).
OPTIONS - [option[,option]...]An optional comma-separated list of options from the following
list. The order in which you list the options is not significant but
the list must have no embedded white-space.blacklistCheck packets arriving on this port against the shorewall6-blacklist(5)
file.ipsecThe zone is accessed via a kernel 2.6 ipsec SA. Note
that if the zone named in the ZONE column is specified as an
IPSEC zone in the shorewall6-zones(5) file
then you do NOT need to specify the 'ipsec' option
here.mss=mssAdded in Shorewall 4.5.2. When present, causes the TCP
mss for new connections to/from the hosts given in the HOST(S)
column to be clamped at the specified
mss.routebackshorewall6 should set up the infrastructure to pass
packets from this/these address(es) back to themselves. This
is necessary if hosts in this group use the services of a
transparent proxy that is a member of the group or if DNAT is
used to send requests originating from this group to a server
in the group.tcpflagsPackets arriving from these hosts are checked for
certain illegal combinations of TCP flags. Packets found to
have such a combination of flags are handled according to the
setting of TCP_FLAGS_DISPOSITION after having been logged
according to the setting of TCP_FLAGS_LOG_LEVEL.FILES/etc/shorewall6/hostsSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-template.xml 0000644 0001750 0001750 00000003120 12222401136 023512 0 ustar teastep teastep
shorewall6-5fileShorewall6 file/etc/shorewall6/DescriptionThe columns in the file are as follows.COLUMN 1ExampleFILES/etc/shorewall6/See ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-exclusion(5), shorewall6-hosts(5),
shorewall6-interfaces(5), shorewall6-maclist(5), shorewall6-nesting(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5), shorewall6-providers(5),
shorewall6-rtrules(5), shorewall6-routestopped(5),
shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5),
shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5),
shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-nesting.xml 0000644 0001750 0001750 00000010536 12222401136 023357 0 ustar teastep teastep
shorewall6-nesting5nestingshorewall6 Nested Zoneschild-zone[:parent-zone[,parent-zone]...]DescriptionIn shorewall6-zones(5), a
zone may be declared to be a sub-zone of one or more other zones using the
above syntax. The child-zone may be neither the
firewall zone nor a vserver zone. The firewall zone may not appear as a
parent zone, although all vserver zones are handled as sub-zones of the
firewall zone.Where zones are nested, the CONTINUE policy in shorewall6-policy(5) allows hosts
that are within multiple zones to be managed under the rules of all of
these zones.Example/etc/shorewall6/zones: #ZONE TYPE OPTION
fw firewall
net ipv6
sam:net ipv6
loc ipv6/etc/shorewall6/interfaces: #ZONE INTERFACE BROADCAST OPTIONS
- eth0 detect blacklist
loc eth1 detect/etc/shorewall6/hosts: #ZONE HOST(S) OPTIONS
net eth0:[::\]
sam eth0:[2001:19f0:feee::dead:beef:cafe]/etc/shorewall6/policy: #SOURCE DEST POLICY LOG LEVEL
loc net ACCEPT
sam all CONTINUE
net all DROP info
all all REJECT infoThe second entry above says that when Sam is the client, connection
requests should first be processed 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). You can have this policy
generated for you automatically by using the IMPLICIT_CONTINUE option in
shorewall6.conf(5).Partial /etc/shorewall6/rules: #ACTION SOURCE DEST PROTO DEST PORT(S)
...
ACCEPT sam loc:2001:19f0:feee::3 tcp ssh
ACCEPT net loc:2001:19f0:feee::5 tcp www
...Given these two rules, Sam can connect with ssh to
2001:19f0:feee::3. Like all hosts in the net zone, Sam can connect to TCP
port 80 on 2001:19f0:feee::5. The order of the rules is not
significant.FILES/etc/shorewall6/zones/etc/shorewall6/interfaces/etc/shorewall6/hosts/etc/shorewall6/policy/etc/shorewall6/rulesSee ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-routestopped.xml 0000644 0001750 0001750 00000016500 12222401136 024442 0 ustar teastep teastep
shorewall6-routestopped5routestoppedThe Shorewall6 file that governs what traffic flows through
the firewall while it is in 'stopped' state./etc/shorewall6/routestoppedDescriptionThis file is deprecated in favor of the shorewall6-stoppedrules(5)
file.This file is used to define the hosts that are accessible when the
firewall is stopped or is being stopped. When shorewall6-shell is being
used, the file also determines those hosts that are accessible when the
firewall is in the process of being [re]started.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).INTERFACE -
interfaceInterface through which host(s) communicate with the
firewallHOST(S) - [-|address[,address]...]Optional comma-separated list of IP/subnet addresses. If your
kernel and ip6tables include iprange match support, IP address
ranges are also allowed.If left empty or supplied as "-", 0.0.0.0/0 is assumed.OPTIONS - [-|option[,option]...]An optional comma-separated list of options. The order of the
options is not important but the list can contain no embedded
white-space. The currently-supported options are:routebackSet up a rule to ACCEPT traffic from these hosts back to
themselves. Beginning with Shorewall 4.4.9, this option is
automatically set if routeback is specified in shorewall6-interfaces
(5) or if the rules compiler detects that the interface is a
bridge.sourceAllow traffic from these hosts to ANY destination.
Without this option or the dest option, only traffic from this
host to other listed hosts (and the firewall) is allowed. If
source is specified then
routeback is
redundant.destAllow traffic to these hosts from ANY source. Without
this option or the source
option, only traffic from this host to other listed hosts (and
the firewall) is allowed. If dest is specified then routeback is redundant.criticalAllow traffic between the firewall and these hosts
throughout '[re]start', 'stop' and 'clear'. Specifying
critical on one or more
entries will cause your firewall to be "totally open" for a
brief window during each of those operations. Examples of
where you might want to use this are:'Ping' nodes with heartbeat.LDAP server(s) if you use LDAP AuthenticationNFS Server if you have an NFS-mounted root
filesystem.The source and dest options work best when used in conjunction
with ADMINISABSENTMINDED=Yes in shorewall6.conf(5).ExampleExample 1: #INTERFACE HOST(S) OPTIONS
eth2 2002:ce7c:92b4::/64
eth0 2002:ce7c:92b4:1::/64
br0 - routeback
eth3 - sourceFILES/etc/shorewall6/routestoppedSee ALSOhttp://shorewall.net/starting_and_stopping_shorewall.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-vardir.xml 0000644 0001750 0001750 00000004040 12222401136 023170 0 ustar teastep teastep
shorewall6-vardir5vardirShorewall6 file/etc/shorewall6/vardirDescriptionThis file does not exist by default. You may create the file if you
want to change the directory used by Shorewall6 to store state
information, including compiled firewall scripts. By default, the
directory used is /var/lib/shorewall6/.The file contains a single variable assignment:directorywhere directory is the name of a
directory. If you add this file, you should copy the files from
/var/lib/shorewall6 to the new directory before
performing a shorewall6 restart.ExampleVARDIR=/root/shorewall6FILES/etc/shorewall6/vardirSee ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcpri.xml 0000644 0001750 0001750 00000014423 12222401136 023030 0 ustar teastep teastep
shorewall6-tcpri5tcpriShorewall6 file/etc/shorewall6/tcpriDescriptionThis file is used to specify the priority band of traffic for simple
traffic shaping (TC_ENABLED=Simple in shorewall6.conf(5)). The priority band
of each packet is determined by the last
entry that the packet matches. If a packet doesn't match any entry in this
file, then its priority will be determined by its TOS field. The default
mapping is as follows but can be changed by setting the TC_PRIOMAP option
in shorewall6.conf(5).TOS Bits Means Linux Priority BAND
------------------------------------------------------------
0x0 0 Normal Service 0 Best Effort 2
0x2 1 Minimize Monetary Cost 1 Filler 3
0x4 2 Maximize Reliability 0 Best Effort 2
0x6 3 mmc+mr 0 Best Effort 2
0x8 4 Maximize Throughput 2 Bulk 3
0xa 5 mmc+mt 2 Bulk 3
0xc 6 mr+mt 2 Bulk 3
0xe 7 mmc+mr+mt 2 Bulk 3
0x10 8 Minimize Delay 6 Interactive 1
0x12 9 mmc+md 6 Interactive 1
0x14 10 mr+md 6 Interactive 1
0x16 11 mmc+mr+md 6 Interactive 1
0x18 12 mt+md 4 Int. Bulk 2
0x1a 13 mmc+mt+md 4 Int. Bulk 2
0x1c 14 mr+mt+md 4 Int. Bulk 2
0x1e 15 mmc+mr+mt+md 4 Int. Bulk 2The columns in the file are as follows.BAND - {1|2|3}Classifies matching traffic as High Priority (1), Medium
Priority (2) or Low Priority (3). For those interfaces listed in
shorewall6-tcinterfaces(5),
Priority 2 traffic will be deferred so long and there is Priority 1
traffic queued and Priority 3 traffic will be deferred so long as
there is Priority 1 or Priority 2 traffic to send.PROTO -
protocol[,...]Optional. The name or number of an IPv4
protocol.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) - port [,...]Optional. May only be given if the the PROTO is TCP (6), UDP
(17), DCCP (33), SCTP (132) or UDPLITE (136). A list of one or more
port numbers or service names from /etc/services. Port ranges of the
form
lowport:highport
may also be included.ADDRESS - [address]Optional. The IP or MAC address that the traffic originated
from. MAC addresses must be given in Shorewall format. If this
column contains an address, then the PROTO, PORT(S) and INTERFACE
column must be empty ("-").INTERFACE - [interface]Optional. The logical name of an
interface that traffic arrives from. If
given, the PROTO, PORT(S) and ADDRESS columns must be empty
("-").INTERFACE classification of packets occurs before
classification by PROTO/PORT(S)/ADDRESS. So it is highly
recommended to place entries that specify INTERFACE at the top of
the file so that the rule about last entry
matches is preserved.HELPER -
[helper]Optional. Names a Netfilter protocol helper module such as ftp,
sip, amanda, etc. A packet will match if it was accepted by the
named helper module. You can also append "-" and a port number to
the helper module name (e.g., ftp-21) to specify the port number
that the original connection was made on.FILES/etc/shorewall6/tcpriSee ALSOPRIO(8), shorewall6(8), shorewall6-accounting(5),
shorewall6-actions(5), shorewall6-blacklist(5), shorewall6-hosts(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcinterfaces(5), shorewall6-tos(5),
shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-modules.xml 0000644 0001750 0001750 00000006175 12222401136 023364 0 ustar teastep teastep
shorewall6-modules5modulesshorewall6 file/usr/share/shorewall6/modules/usr/share/shorewall6/helpersDescriptionThese files specify which kernel modules shorewall6 will load before
trying to determine your ip6tables/kernel's capabilities. The
modules file is used when LOAD_HELPERS_ONLY=No in
shorewall6.conf(8); the
helpers file is used when
LOAD_HELPERS_ONLY=Yes.Each record in the files has the following format:loadmodulemodulenamemoduleoptionThe modulename names a kernel module
(without suffix). shorewall6 will search for modules based on your
MODULESDIR and MODULE_SUFFIX settings in shorewall6.conf(8). The
moduleoptions are passed to modprobe (if
installed) or to insmod.The /usr/share/shorewall6/modules file contains a large number of
modules. Users are encouraged to copy the file to /etc/shorewall6/modules
and modify the copy to load only the modules required or use
LOAD_HELPERS_ONLY=Yes.If you build monolithic kernels and have not installed
module-init-tools, then create an empty /etc/shorewall6/modules file;
that will prevent shorewall6 from trying to load modules at
all.Exampleloadmodule ip_conntrack_ftp ports=21,221FILES/usr/share/shorewall6/modules/usr/share/shorewall6/helpers/etc/shorewall6/modules/etc/shorewall6/helpersSee ALSOshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-blrules.xml 0000644 0001750 0001750 00000030540 12222401136 023355 0 ustar teastep teastep
shorewall6-blrules5blrulesshorewall6 Blacklist file/etc/shorewall6/blrulesDescriptionThis file is used to perform zone-specific blacklisting and
whitelisting.Rules in this file are applied depending on the setting of
BLACKLISTNEWONLY in shorewall6.conf(5). If
BLACKLISTNEWONLY=No, then they are applied regardless of the connection
tracking state of the packet. If BLACKLISTNEWONLY=Yes, they are applied to
connections in the NEW and INVALID states.The format of rules in this file is the same as the format of rules
in shorewall6-rules (5). The
difference in the two files lies in the ACTION (first) column.ACTION- {ACCEPT|BLACKLIST|blacklog|CONTINUE|DROP|A_DROP|REJECT|A_REJECT|WHITELIST|LOG|QUEUE|NFQUEUE[(queuenumber)]|[?]COMMENT|action|macro[(target)]}[:{log-level|none}[!][:tag]]Specifies the action to be taken if the packet matches the
rule. Must be one of the following.BLACKLISTAdded in Shorewall 4.5.3. This is actually a macro that
expands as follows:If BLACKLIST_LOGLEVEL is specified in shorewall6.conf(5),
then the macro expands to blacklog.Otherwise it expands to the action specified for
BLACKLIST_DISPOSITION in shorewall6.conf(5).blacklogMay only be used if BLACKLIST_LOGLEVEL is specified in
shorewall6.conf (5).
Logs, audits (if specified) and applies the
BLACKLIST_DISPOSITION specified in shorewall6.conf (5).ACCEPT|CONTINUE|WHITELISTExempt the packet from the remaining rules in this
file.DROPIgnore the packet.A_DROP and A_DROP!Audited versions of DROP. Requires AUDIT_TARGET support
in the kernel and ip6tables.REJECTdisallow the packet and return an icmp-unreachable or an
RST packet.A_REJECTAudited versions of REJECT. Require AUDIT_TARGET support
in the kernel and ip6tables.LOGSimply log the packet and continue with the next
rule.QUEUEQueue the packet to a user-space application such as
ftwall (http://p2pwall.sf.net). The application may reinsert
the packet for further processing.NFLOG[(nflog-parameters)]queues matching packets to a back end logging daemon via
a netlink socket then continues to the next rule. See http://www.shorewall.net/shorewall_logging.html.NFQUEUEQueues the packet to a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not specified, queue
zero (0) is assumed.[?]COMMENTthe rest of the line will be attached as a comment to
the Netfilter rule(s) generated by the following entries. The
comment will appear delimited by "/* ... */" in the output of
"shorewall6 show <chain>". To stop the comment from
being attached to further rules, simply include COMMENT on a
line by itself.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.actionThe name of an action declared in
shorewall6-actions(5) or
in /usr/share/shorewall6/actions.std.macroThe name of a macro defined in a file named
macro.macro. If the macro accepts an
action parameter (Look at the macro source to see if it has
PARAM in the TARGET column) then the
macro name is followed by the
parenthesized target (ACCEPT, DROP, REJECT, ...) to be substituted for the
parameter.Example: FTP(ACCEPT).The ACTION may optionally be
followed by ":" and a syslog log level (e.g, REJECT:info or
Web(ACCEPT):debug). This causes the packet to be logged at the
specified level.If the ACTION names an
action declared in shorewall6-actions(5) or in
/usr/share/shorewall6/actions.std then:If the log level is followed by "!' then all rules in the
action are logged at the log level.If the log level is not followed by "!" then only those
rules in the action that do not specify logging are logged at
the specified level.The special log level none! suppresses logging by the
action.You may also specify NFLOG
(must be in upper case) as a log level.This will log to the NFLOG
target for routing to a separate log through use of ulogd (http://www.netfilter.org/projects/ulogd/index.html).Actions specifying logging may be followed by a log tag (a
string of alphanumeric characters) which is appended to the string
generated by the LOGPREFIX (in shorewall6.conf(5)).For the remaining columns, see shorewall6-rules (5).ExampleExample 1:Drop Teredo packets from the net.DROP net:[2001::/32] allExample 2:Don't subject packets from 2001:DB8::/64 to the remaining
rules in the file.WHITELIST net:[2001:DB8::/64] allFILES/etc/shorewall6/blrulesSee ALSOhttp://shorewall.net/blacklisting_support.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-routes.xml 0000644 0001750 0001750 00000006765 12222401136 023242 0 ustar teastep teastep
shorewall6-routes5routesShorewall6 file/etc/shorewall6/routesDescriptionThis file was added in Shorewall 4.4.15 and is used to define routes
to be added to provider routing tables.The columns in the file are as follows.PROVIDERThe name or number of a provider defined in shorewall6-providers (5).
Beginning with Shorewall 4.5.14, you may also enter
in this column to add routes to the main
routing table.DESTDestination host address or network address.GATEWAY (Optional)If specified, gives the IP address of the gateway to the
DEST.Beginning with Shorewall 4.5.14, you may specify
in this column to create a blackhole
route.Beginning with Shorewall 4.5.15, you may specify
or in this
column to create a prohibit or
unreachable route respectively.DEVICE (Optional)Specifies the device route. If neither DEVICE nor GATEWAY is
given, then the INTERFACE specified for the PROVIDER in shorewall6-providers
(5).This column must be omitted if ,
or is
specified in the GATEWAY column.Files/etc/shorewall6/routesSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6.xml 0000644 0001750 0001750 00000200066 12222401136 021711 0 ustar teastep teastep
shorewall68shorewall6Administration tool for Shoreline Firewall 6
(Shorewall6)shorewall6|-optionsinterface[:host-list]zone | zone host-list
shorewall6|-optionsaddressshorewall6|-optionsdirectoryshorewall6|-optionsshorewall6|-optionsdirectorypathnameshorewall6|-optionsinterface[:host-list]zone | zone host-list
shorewall|-options{ interface |
provider }shorewall6|-optionsaddressshorewall6|-optionsshorewall|-options{ interface |
provider }shorewall6|-optionsdirectory1[user@]system[directory2]shorewall6|-optionsfilenameshorewall6|-optionsshorewall6|-optionsiptables match
expressionshorewall6|-optionsroot-user-namedirectorysystemshorewall6|-optionsaddressshorewall6|-optionsrefresh-intervalshorewall6|-optionsaddressshorewall6|-optionsiptables match
expressionshorewall6|-options-
directorychainshorewall6|-optionsaddressshorewall6|-optionsroot-user-namedirectorysystemshorewall6|-optionsshorewall6|-optionsdirectoryshorewall6|-optionsfilenameshorewall6|-optionstimeoutdirectoryshorewall6|-optionstimeoutdirectoryshorewall6|-optionsfilenameshorewall6|-options
{||}chainshorewall6|-optionsshorewall6|-optionsshorewall6|-optionseventshorewall6|-optionsshorewall6|-optionsshorewall6|-optionsdirectoryshorewall6|-optionsshorewall6|-optionsshorewall6|-optionsdirectorytimeoutshorewall6|-optionsdirectoryshorewall6|-optionsDescriptionThe shorewall6 utility is used to control the Shoreline Firewall 6
(Shorewall6).OptionsThe and options are
used for debugging. See http://www.shorewall.net/starting_and_stopping_shorewall.htm#Trace.The nolock prevents the command from
attempting to acquire the Shorewall6 lockfile. It is useful if you need to
include shorewall6 commands in
/etc/shorewall6/started.The options control the amount of output that
the command produces. They consist of a sequence of the letters v and q. If the
options are omitted, the amount of output is determined by the setting of
the VERBOSITY parameter in shorewall6.conf(5). Each v adds one to the effective verbosity and each
q subtracts one from the effective
VERBOSITY. Alternatively, v may be
followed immediately with one of -1,0,1,2 to specify a specify VERBOSITY.
There may be no white-space between v and
the VERBOSITY.The options may also include the letter
which causes all progress messages to be
timestamped.CommandsThe available commands are listed below.addAdded in Shorewall 4.4.21. Adds a list of hosts or subnets to
a dynamic zone usually used with VPN's.The interface argument names an interface
defined in the shorewall6-interfaces(5)
file. A host-list is comma-separated list whose
elements are host or network addresses.The add command is not very robust. If
there are errors in the host-list,
you may see a large number of error messages yet a subsequent
shorewall show zones command will indicate
that all hosts were added. If this happens, replace
add by delete and run the
same command again. Then enter the correct command.Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall6-zones(5)) allows a
single ipset to handle entries for multiple interfaces. When that
option is specified for a zone, the add command
has the alternative syntax in which the
zone name precedes the
host-list.allowRe-enables receipt of packets from hosts previously
blacklisted by a drop, logdrop, reject, or logreject command.checkCompiles the configuration in the specified
directory and discards the compiled output
script. If no directory is given, then
/etc/shorewall6 is assumed.The -e option causes the
compiler to look for a file named capabilities. This file is
produced using the command shorewall6-lite
show -f capabilities > capabilities on a system with
Shorewall6 Lite installed.The option causes the compiler to be run
under control of the Perl debugger.The option causes the compiler to be
profiled via the Perl command-line
option.The option was added in Shorewall 4.5.2
and causes the compiler to print the generated ruleset to standard
out.The option was added in Shorewall 4.4.20
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.clearClear will remove all rules and chains installed by
Shorewall6. The firewall is then wide open and unprotected. Existing
connections are untouched. Clear is often used to see if the
firewall is causing connection problems.compileCompiles the current configuration into the executable file
pathname. If a directory is supplied,
Shorewall6 will look in that directory first for configuration
files. If the pathname is omitted, the file
firewall in the VARDIR (normally /var/lib/shorewall/) is assumed. A
pathname of '-' causes the compiler to send the
generated script to it's standard output file. Note that '-v-1' is
usually specified in this case (e.g., shorewall6 -v-1
compile -- -) to suppress the 'Compiling...' message
normally generated by /sbin/shorewall6.When -e is specified, the compilation is being performed on a
system other than where the compiled script will run. This option
disables certain configuration options that require the script to be
compiled where it is to be run. The use of -e requires the presence
of a configuration file named capabilities
which may be produced using the command shorewall6-lite show -f capabilities >
capabilities on a system with Shorewall6 Lite
installed.The -c option was added in
Shorewall 4.5.17 and causes conditional compilation of a script. The
script specified by pathname (or implied
if pathname is omitted) is compiled
if it doesn't exist or if there is any file in the
directory or in a directory on the
CONFIG_PATH that has a modification time later than the file to be
compiled. When no compilation is needed, a message is issued and an
exit status of zero is returned.The option causes the compiler to be run
under control of the Perl debugger.The option causes the compiler to be
profiled via the Perl command-line
option.The option was added in Shorewall 4.4.20
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.deleteAdded in Shorewall 4.4.21. The delete command reverses the
effect of an earlier add
command.The interface argument names an interface
defined in the shorewall6-interfaces(5)
file. A host-list is comma-separated list whose
elements are a host or network address.Beginning with Shorewall 4.5.9, the dynamic_shared zone option (shorewall6-zones(5)) allows a
single ipset to handle entries for multiple interfaces. When that
option is specified for a zone, the delete
command has the alternative syntax in which the
zone name precedes the
host-list.disableAdded in Shorewall 4.4.26. Disables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.Beginning with Shorewall 4.5.10, this command may be used with
any optional network interface. interface
may be either the logical or physical name of the interface. The
command removes any routes added from shorewall6-routes(5) and any
traffic shaping configuration for the interface.dropCauses traffic from the listed addresses
to be silently dropped.dumpProduces a verbose report about the firewall configuration for
the purpose of problem analysis.The -x option causes actual
packet and byte counts to be displayed. Without that option, these
counts are abbreviated. The -m
option causes any MAC addresses included in Shorewall6 log messages
to be displayed.The -l option causes the rule
number for each Netfilter rule to be displayed.enableAdded in Shorewall 4.4.26. Enables the optional provider
associated with the specified interface
or provider. Where more than one provider
share a single network interface, a
provider name must be given.Beginning with Shorewall 4.5.10, this command may be used with
any optional network interface. interface
may be either the logical or physical name of the interface. The
command sets /proc entries for the interface,
adds any route specified in shorewall6-routes(5) and
installs the interface's traffic shaping configuration, if
any.exportIf directory1 is omitted, the current
working directory is assumed.Allows a non-root user to compile a shorewall6 script and
stage it on a system (provided that the user has access to the
system via ssh). The command is equivalent to:/sbin/shorewall6 compile -edirectory1directory1/firewall &&\scp directory1/firewalldirectory1/firewall.conf [user@]system:[directory2]In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called firewall in that
directory. If compilation succeeds, then firewall and firewall.conf
are copied to system using scp.forgetDeletes /var/lib/shorewall6/filename and
/var/lib/shorewall6/save. If no filename is
given then the file specified by RESTOREFILE in shorewall6.conf(5) is
assumed.helpDisplays a syntax summary.iptraceThis is a low-level debugging command that causes iptables
TRACE log records to be created. See ip6tables(8) for
details.The ip6tables match expression must
be one or more matches that may appear in both the raw table OUTPUT
and raw table PREROUTING chains.The trace records are written to the kernel's log buffer with
facility = kernel and priority = warning, and they are routed from
there by your logging daemon (syslogd, rsyslog, syslog-ng, ...) --
Shorewall has no control over where the messages go; consult your
logging daemon's documentation.loadIf directory is omitted, the current
working directory is assumed. Allows a non-root user to compile a
shorewall6 script and install it on a system (provided that the user
has root access to the system via ssh). The command is equivalent
to:/sbin/shorewall6 compile -edirectorydirectory/firewall &&\scpdirectory/firewalldirectory/firewall.confroot@system:/var/lib/shorewall6-lite/ &&\ssh root@system'/sbin/shorewall6-lite start'In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called firewall in that
directory. If compilation succeeds, then firewall is copied to
system using scp. If the copy succeeds,
Shorewall6 Lite on system is started via
ssh.If -s is specified and the
start command succeeds, then the
remote Shorewall6-lite configuration is saved by executing shorewall6-lite save via ssh.if -c is included, the
command shorewall6-lite show capabilities -f
> /var/lib/shorewall6-lite/capabilities is executed
via ssh then the generated file is copied to
directory using scp. This step is
performed before the configuration is compiled.If is included, it specifies that the root
user on system is named
root-user-name rather than "root".The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.logdropCauses traffic from the listed addresses
to be logged then discarded. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5).logwatchMonitors the log file specified by the LOGFILE option in
shorewall6.conf(5) and
produces an audible alarm when new Shorewall6 messages are logged.
The -m option causes the MAC
address of each packet source to be displayed if that information is
available. The refresh-interval specifies
the time in seconds between screen refreshes. You can enter a
negative number by preceding the number with "--" (e.g.,
shorewall6 logwatch -- -30). In this case, when a
packet count changes, you will be prompted to hit any key to resume
screen refreshes.logrejectCauses traffic from the listed addresses
to be logged then rejected. Logging occurs at the log level
specified by the BLACKLIST_LOGLEVEL setting in shorewall6.conf (5).noiptraceThis is a low-level debugging command that cancels a trace
started by a preceding iptrace command.The iptables match expression must
be one given in the iptrace command being
canceled.refreshAll steps performed by restart are
performed by refresh with the exception that
refresh only recreates the chains specified in
the command while restart recreates the entire
Netfilter ruleset.When no chain name is given to the refresh command, the mangle table is
refreshed along with the blacklist chain (if any). This allows you
to modify /etc/shorewall6/tcrulesand install
the changes using refresh.The listed chains are assumed to be in the filter table. You
can refresh chains in other tables by prefixing the chain name with
the table name followed by ":" (e.g., nat:net_dnat). Chain names
which follow are assumed to be in that table until the end of the
list or until an entry in the list names another table. Built-in
chains such as FORWARD may not be refreshed.The option was added in Shorewall 4.5.3
causes Shorewall to avoid updating the routing table(s).The option was added in Shorewall 4.5.3
causes the compiler to run under the Perl debugger.The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.The - option was added in Shorewall 4.5.3
and causes Shorewall to look in the given
directory first for configuration files.Example:shorewall6 refresh net2fw nat:net_dnat #Refresh the 'net2loc' chain in the filter table and the 'net_dnat' chain in the nat tablereloadIf directory is omitted, the current
working directory is assumed. Allows a non-root user to compile a
shorewall6 script and install it on a system (provided that the user
has root access to the system via ssh). The command is equivalent
to:/sbin/shorewall6 compile -edirectorydirectory/firewall &&\scpdirectory/firewalldirectory/firewall.confroot@system:/var/lib/shorewall6-lite/ &&\ssh root@system'/sbin/shorewall6-lite restart'In other words, the configuration in the specified (or
defaulted) directory is compiled to a file called firewall in that
directory. If compilation succeeds, then firewall is copied to
system using scp. If the copy succeeds,
Shorewall6 Lite on system is restarted via
ssh.If -s is specified and the
restart command succeeds, then the
remote Shorewall6-lite configuration is saved by executing shorewall6-lite save via ssh.if -c is included, the
command shorewall6-lite show capabilities -f
> /var/lib/shorewall6-lite/capabilities is executed
via ssh then the generated file is copied to
directory using scp. This step is performed
before the configuration is compiled.If is included, it specifies that the root
user on system is named
root-user-name rather than "root".The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.reset [chain,
...]Resets the packet and byte counters in the specified
chain(s). If no
chain is specified, all the packet and
byte counters in the firewall are reset.restartRestart is similar to shorewall6
start except that it assumes that the firewall is already
started. Existing connections are maintained. If a
directory is included in the command,
Shorewall6 will look in that directory first
for configuration files.The option causes Shorewall6 to avoid
updating the routing table(s).The option causes the connection tracking
table to be flushed; the conntrack utility must
be installed to use this option.The option causes the compiler to run
under the Perl debugger.The option suppresses the compilation step
and simply reused the compiled script which last started/restarted
Shorewall, provided that /etc/shorewall6 and its contents have not
been modified since the last start/restart.The option was added in Shorewall 4.4.20
and performs the compilation step unconditionally, overriding the
AUTOMAKE setting in shorewall6.conf(5). When both
and are present, the result
is determined by the option that appears last.The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.restoreRestore Shorewall6 to a state saved using the shorewall6 save command. Existing connections
are maintained. The filename names a restore
file in /var/lib/shorewall6 created using shorewall6 save; if no
filename is given then Shorewall6 will be
restored from the file specified by the RESTOREFILE option in shorewall6.conf(5).safe-restartOnly allowed if Shorewall6 is running. The current
configuration is saved in /var/lib/shorewall6/safe-restart (see the
save command below) then a shorewall6
restart is done. You will then be prompted asking if you
want to accept the new configuration or not. If you answer "n" or if
you fail to answer within 60 seconds (such as when your new
configuration has disabled communication with your terminal), the
configuration is restored from the saved configuration. If a
directory is given, then Shorewall6 will look in that directory
first when opening configuration files.Beginning with Shorewall 4.5.0, you may specify a different
timeout value using the
option. The numeric
timeout may optionally be followed by an
, or suffix
(e.g., 5m) to specify seconds, minutes or hours respectively. If the
suffix is omitted, seconds is assumed.safe-startShorewall6 is started normally. You will then be prompted
asking if everything went all right. If you answer "n" or if you
fail to answer within 60 seconds (such as when your new
configuration has disabled communication with your terminal), a
shorewall6 clear is performed for you. If a directory is given, then
Shorewall6 will look in that directory first when opening
configuration files.Beginning with Shorewall 4.5.0, you may specify a different
timeout value using the
option. The numeric
timeout may optionally be followed by an
, or suffix
(e.g., 5m) to specify seconds, minutes or hours respectively. If the
suffix is omitted, seconds is assumed.saveThe dynamic blacklist is stored in /var/lib/shorewall6/save.
The state of the firewall is stored in
/var/lib/shorewall6/filename for use by the
shorewall6 restore and shorewall6 -f start commands. If
filename is not given then the state is saved
in the file specified by the RESTOREFILE option in shorewall6.conf(5).showThe show command can have a number of different
arguments:actionsProduces a report about the available actions (built-in,
standard and user-defined).capabilitiesDisplays your kernel/ip6tables capabilities. The
-f option causes the display
to be formatted as a capabilities file for use with compile -e.[ [ ] chain...
]The rules in each chain are
displayed using the ip6tables
-Lchain-n -v command. If no
chain is given, all of the chains in the
filter table are displayed. The -x option is passed directly through to
ip6tables and causes actual packet and byte counts to be
displayed. Without this option, those counts are abbreviated.
The -t option specifies the
Netfilter table to display. The default is filter.The -b ('brief') option
causes rules which have not been used (i.e. which have zero
packet and byte counts) to be omitted from the output. Chains
with no rules displayed are also omitted from the
output.The -l option causes
the rule number for each Netfilter rule to be
displayed.If the -t option and
the keyword are both omitted and any of
the listed chains do not exist, a
usage message is displayed.classifiers|filtersDisplays information about the packet classifiers
defined on the system as a result of traffic shaping
configuration.configDisplays distribution-specific defaults.connectionsDisplays the IP connections currently being tracked by
the firewall.event
eventAdded in Shorewall 4.5.19. Displays the named
event.eventsAdded in Shorewall 4.5.19. Displays all events.ipDisplays the system's IPv6 configuration.logDisplays the last 20 Shorewall6 messages from the log
file specified by the LOGFILE option in shorewall6.conf(5). The
-m option causes the MAC
address of each packet source to be displayed if that
information is available.macrosDisplays information about each macro defined on the
firewall system.mangleDisplays the Netfilter mangle table using the command
ip6tables -t mangle -L -n
-v.The -x option
is passed directly through to ip6tables and causes actual
packet and byte counts to be displayed. Without this option,
those counts are abbreviated.marksAdded in Shorewall 4.4.26. Displays the various fields
in packet marks giving the min and max value (in both decimal
and hex) and the applicable mask (in hex).policiesAdded in Shorewall 4.4.4. Displays the applicable policy
between each pair of zones. Note that implicit intrazone
ACCEPT policies are not displayed for zones associated with a
single network where that network doesn't specify
.RoutingDisplays the system's IPv6 routing configuration.tcDisplays information about queuing disciplines, classes
and filters.zonesDisplays the current composition of the Shorewall6 zones
on the system.startStart shorewall6. Existing connections through shorewall6
managed interfaces are untouched. New connections will be allowed
only if they are allowed by the firewall rules or policies. If a
directory is included in the command,
Shorewall6 will look in that directory first
for configuration files. If -f is
specified, the saved configuration specified by the RESTOREFILE
option in shorewall6.conf(5) will be
restored if that saved configuration exists and has been modified
more recently than the files in /etc/shorewall6. When -f is given, a
directory may not be specified.Update: In Shorewall6 4.4.20, a new LEGACY_FASTSTART option
was added to shorewall6.conf(5). When
LEGACY_FASTSTART=No, the modification times of files in
/etc/shorewall6 are compared with that of
/var/lib/shorewall6/firewall (the compiled script that last
started/restarted the firewall).The option causes Shorewall6 to avoid
updating the routing table(s).The option was added in Shorewall 4.4.20
and performs the compilation step unconditionally, overriding the
AUTOMAKE setting in shorewall6.conf(5). When both
and are present, the result
is determined by the option that appears last.The option was added in Shorewall 4.5.3
and causes a Perl stack trace to be included with each
compiler-generated error and warning message.stopStops the firewall. All existing connections, except those
listed in shorewall6-routestopped(5)
or permitted by the ADMINISABSENTMINDED option in shorewall6.conf(5), are taken
down. The only new traffic permitted through the firewall is from
systems listed in shorewall6-routestopped(5)
or by ADMINISABSENTMINDED.statusProduces a short report about the state of the
Shorewall6-configured firewall.tryIf Shorewall6 is started then the firewall state is saved to a
temporary saved configuration
(/var/lib/shorewall6/.try). Next, if Shorewall6
is currently started then a restart
command is issued using the specified configuration
directory; otherwise, a start command is performed using the
specified configuration directory. if an
error occurs during the compilation phase of the restart or start, the command terminates without
changing the Shorewall6 state. If an error occurs during the
restart phase, then a shorewall6 restore is performed using the
saved configuration. If an error occurs during the start phase, then Shorewall6 is cleared. If
the start/restart succeeds and a
timeout is specified then a clear or restore is performed after
timeout seconds.Beginning with Shorewall 4.5.0, the numeric
timeout may optionally be followed by an
, or suffix
(e.g., 5m) to specify seconds, minutes or hours respectively. If the
suffix is omitted, seconds is assumed.updateAdded in Shorewall 4.4.21 and causes the compiler to update
/etc/shorewall6/shorewall6.conf then validate
the configuration. The update will add options not present in the
existing file with their default values, and will move deprecated
options with non-defaults to a deprecated options section at the
bottom of the file. Your existing
shorewall6.conf file is renamed
shorewall6.conf.bak.The option causes the updated
shorewall6.conf file to be annotated with
documentation.The option was added in Shorewall 4.4.26
and causes legacy blacklisting rules (shorewall6-blacklist (5) )
to be converted to entries in the blrules file (shorewall6-blrules (5) ). The
blacklist keyword is removed from shorewall6-zones (5), shorewall-interfaces (5)
and shorewall6-hosts (5).
The unmodified files are saved with a .bak suffix.The option was added in Shorewall 4.5.11.
When this option is specified, the compiler will walk through the
directories in the CONFIG_PATH replacing FORMAT and COMMENT entries
to compiler directives (e.g., ?FORMAT and ?COMMENT. When a file is
updated, the original is saved in a .bak file in the same
directory.For a description of the other options, see the check command above.versionDisplays Shorewall6's version. If the
option is included, the version of Shorewall will also be
displayed.EXIT STATUSIn general, when a command succeeds, status 0 is returned; when the
command fails, a non-zero status is returned.The status command returns exit status as
follows:0 - Firewall is started.3 - Firewall is stopped or cleared4 - Unknown state; usually means that the firewall has never been
started.See ALSOhttp://www.shorewall.net/starting_and_stopping_shorewall.htmshorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-secmarks.xml 0000644 0001750 0001750 00000037142 12222401136 023522 0 ustar teastep teastep
shorewall6-secmarks5secmarksShorewall6 file/etc/shorewall6/secmarksDescriptionUnlike rules in the shorewall6-rules(5) file, evaluation
of rules in this file will continue after a match. So the final secmark
for each packet will be the one assigned by the LAST rule that
matches.The secmarks file is used to associate an SELinux context with
packets. It was added in Shorewall6 version 4.4.13.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).SECMARK -
{SAVE|RESTORE|context|[?]COMMENT
comment}SAVEIf an SELinux context is associated with the packet, the
context is saved in the connection. Normally, the remaining
columns should be left blank.RESTOREIf an SELinux context is not currently associated with
the packet, then the saved context (if any) is associated with
the packet. Normally, the remaining columns should be left
blank.contextAn SELinux context.[?]COMMENTThe remainder of the line is treated as a comment which
is attached to subsequent rules until another COMMENT line is
found or until the end of the file is reached. To stop adding
comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CHAIN:STATE (chain) -
{P|I|F|O|T}[:{N|I|U|IU|NI|NU|NIU|NUI:E|ER}]This column determines the CHAIN where the SELinux context is
to be applied:P - PREROUTINGI - INPUTF - FORWARDO - OUTPUTT - POSTROUTINGIt may be optionally followed by a colon and an indication of
the Netfilter connection state(s) at which the context is to be
applied::N - NEW connection:I - INVALID connection:NI - NEW or INVALID connection:E - ESTABLISHED connection:ER - ESTABLISHED or RELATED connectionBeginning with Shorewall 4.5.10, the following additional
options are available:U - UNTRACKED connection:IU - INVALID or UNTRACKED connection:NU - NEW or UNTRACKED connection:NIU - NEW, INVALID or UNTRACKED connection.SOURCE - {-interface|[interface:]address-or-range[,address-or-range]...}[exclusion]May be:An interface name - matches traffic entering the firewall
on the specified interface. May not be used in classify rules or
in rules using the T in the CHAIN column.A comma-separated list of host or network IP addresses or
MAC addresses.An interface name followed by a colon (":") followed by a
comma-separated list of host or network IP addresses or MAC
addresses.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall6-exclusion(5)).DEST - {-|{interface|[interface:]address-or-range[,address-or-range]...}[exclusion]May be:An interface name. May not be used in the PREROUTING or
INPUT chains. The interface name may be optionally followed by a
colon (":") and an IP address list.A comma-separated list of host or network IP addresses.
The list may include ip address ranges if your kernel and
iptables include iprange support.You may exclude certain hosts from the set already defined
through use of an exclusion (see shorewall6-exclusion(5)).PROTO - {-|tcp:syn|ipp2p|ipp2p:udp|ipp2p:all|protocol-number|protocol-name|all}Protocol - ipp2p requires
ipp2p match support in your kernel and iptables.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.PORT(S) (dport) - [-|port-name-number-or-range[,port-name-number-or-range]...]Optional destination Ports. A comma-separated list of Port
names (from services(5)), port numbers or
port ranges; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s). ICMP types may be specified as a numeric
type, a numeric type and code separated by a slash (e.g., 3/4), or
a typename. See http://www.shorewall.net/configuration_file_basics.htm#ICMP.If the protocol is ipp2p,
this column is interpreted as an ipp2p option without the leading
"--" (example bit for bit-torrent).
If no PORT is given, ipp2p is
assumed.This column is ignored if PROTOCOL = all but must be entered
if any of the following field is supplied. In that case, it is
suggested that this field contain "-"SOURCE PORT(S) (sport) -
[-|port-name-number-or-range[,port-name-number-or-range]...]Optional source port(s). If omitted, any source port is
acceptable. Specified as a comma-separated list of port names, port
numbers or port ranges.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.USER - [!][user-name-or-number][:group-name-or-number]This optional column may only be non-empty if the SOURCE is
the firewall itself.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
groupMARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.EXAMPLEMark the first incoming packet of a connection on the loopback
interface and destined for address ::1 and tcp port 3306 with context
system_u:object_r:mysqld_t:s0 and save that context in the conntrack
table. On subsequent input packets in the connection, set the context from
the conntrack table./etc/shorewall6/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
- lo - ignore/etc/shorewall6/secmarks:#SECMARK CHAIN: SOURCE DEST PROTO DEST SOURCE USER/ MARK
# STATE PORT(S) PORT(S) GROUP
system_u:object_r:mysqld_packet_t:s0 I:N lo ::1 tcp 3306
SAVE I:N
RESTORE I:ERFILES/etc/shorewall6/secmarksSee ALSOhttp://james-morris.livejournal.com/11010.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-actions(5), shorewall6-blacklist(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-blacklist.xml 0000644 0001750 0001750 00000021315 12222401136 023655 0 ustar teastep teastep
shorewall6-blacklist5blacklistshorewall6 Blacklist file/etc/shorewall6/blacklistDescriptionThe blacklist file is used to perform static blacklisting by source
address (IP or MAC), or by application. The use of this file is deprecated
in favor of shorewall6-blrules(5), and beginning
with Shorewall 4.5.7, the blacklist file is no longer installed. Existing
blacklist files can be converted to a corresponding blrules file using the
shorewall6 update -b command.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ADDRESS/SUBNET - {-|~mac-address|ip-address|address-range|+ipset}Host address, network address, MAC address, IP address range
(if your kernel and ip6tables contain iprange match support) or
ipset name prefaced by "+" (if your kernel supports ipset match).
Exclusion (shorewall6-exclusion(5)) is
supported.MAC addresses must be prefixed with "~" and use "-" as a
separator.Example: ~00-A0-C9-15-39-78A dash ("-") in this column means that any source address will
match. This is useful if you want to blacklist a particular
application using entries in the PROTOCOL and PORTS columns.PROTOCOL (proto) - {-|protocol-number|protocol-name}Optional - if specified, must be a protocol number or a
protocol name from protocols(5).PORTS (port) - {-|port-name-or-number[,port-name-or-number]...}May only be specified if the protocol is TCP (6), UDP (17),
DCCP (33), SCTP (132) or UDPLITE (136). A comma-separated list of
destination port numbers or service names from services(5).OPTIONS - {-|{dst|src|whitelist|audit}[,...]}Optional - added in 4.4.12. If specified, indicates whether
traffic from ADDRESS/SUBNET (src) or traffic to
ADDRESS/SUBNET (dst) should be
blacklisted. The default is src. If
the ADDRESS/SUBNET column is empty, then this column has no effect
on the generated rule.In Shorewall 4.4.12, the keywords from and to were used in
place of src and dst respectively. Blacklisting was still
restricted to traffic arriving on an
interface that has the 'blacklist' option set. So to block traffic
from your local network to an internet host, you had to specify
on your internal interface in shorewall6-interfaces
(5).Beginning with Shorewall 4.4.13, entries are applied based
on the blacklist setting in
shorewall6-zones(5):'blacklist' in the OPTIONS or IN_OPTIONS column. Traffic
from this zone is passed against the entries in this file that
have the src option
(specified or defaulted).'blacklist' in the OPTIONS or OUT_OPTIONS column.
Traffic to this zone is passed against the entries in this
file that have the dst
option.In Shorewall 4.4.20, the whitelist option was added. When whitelist is specified, packets/connections
that match the entry are not matched against the remaining entries
in the file.The audit option was also
added in 4.4.20 and causes packets matching the entry to be audited.
The audit option may not be
specified in whitelist entries and require AUDIT_TARGET support in
the kernel and ip6tables.When a packet arrives on an interface that has the blacklist option specified in shorewall6-interfaces(5), its
source IP address and MAC address is checked against this file and
disposed of according to the BLACKLIST_DISPOSITION and BLACKLIST_LOGLEVEL variables in shorewall6.conf(5). If PROTOCOL or PROTOCOL and PORTS
are supplied, only packets matching the protocol (and one of the ports if
PORTS supplied) are blocked.ExampleExample 1:To block DNS queries from address
fe80::2a0:ccff:fedb:31c4: #ADDRESS/SUBNET PROTOCOL PORT
fe80::2a0:ccff:fedb:31c4/ udp 53Example 2:To block some of the nuisance applications: #ADDRESS/SUBNET PROTOCOL PORT
- udp 1024:1033,1434
- tcp 57,1433,1434,2401,2745,3127,3306,3410,4899,5554,6101,8081,9898FILES/etc/shorewall6/blacklistSee ALSOhttp://shorewall.net/blacklisting_support.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-maclist.xml 0000644 0001750 0001750 00000010331 12222401136 023335 0 ustar teastep teastep
shorewall6-maclist5maclistshorewall6 MAC Verification file/etc/shorewall6/maclistDescriptionThis file is used to define the MAC addresses and optionally their
associated IPv6 addresses to be allowed to use the specified interface.
The feature is enabled by using the maclist option in the shorewall6-interfaces(5) or
shorewall6-hosts(5)
configuration file.The columns in the file are as follows.DISPOSITION - {ACCEPT|DROP|REJECT}[log-level]ACCEPT or DROP (if MACLIST_TABLE=filter in shorewall6.conf(5), then REJECT
is also allowed). If specified, the
log-level causes packets matching the
rule to be logged at that level.INTERFACE -
interfaceNetwork interface to a host.MAC -
addressMAC address of the host -- you do not
need to use the shorewall6 format for MAC addresses here. If
IP ADDRESSES is supplied then
MAC can be supplied as a dash
(-)IP ADDRESSES (Optional) -
[address[,address]...]If specified, both the MAC and IP address must match. This
column can contain a comma-separated list of host and/or subnet
addresses. If your kernel and ip6tables have iprange match support
then IP address ranges are also allowed. Similarly, if your kernel
and ip6tables include ipset support than set names (prefixed by "+")
are also allowed.FILES/etc/shorewall6/maclistSee ALSOhttp://shorewall.net/MAC_Validation.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcclasses.xml 0000644 0001750 0001750 00000074651 12222401136 023704 0 ustar teastep teastep
shorewall6-tcclasses5tcclassesShorewall6 file to define HTB and HFSC classes/etc/shorewall6/tcclassesDescriptionA note on the rate/bandwidth definitions used
in this file:don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is NOT.you can use one of the following units:kpbsKilobytes per second.mbpsMegabytes per second.kbitKilobits per second.mbitMegabits per second.bps or numberBytes per second.if you want the values to be calculated for you depending on the
output bandwidth setting defined for an interface in tcdevices, you
can use expressions like the following:full/3causes the bandwidth to be calculated as 1/3 of the full
outgoing speed that is defined.full*9/10will set this bandwidth to 9/10 of the full
bandwidthNote that in a sub-class (a class that has a specified parent
class), full refers to the RATE or CEIL of the parent class rather
than to the OUT-BANDWIDTH of the device.DO NOT add a unit to the rate if it is calculated !The columns in the file are as follows.INTERFACE -
interface[[:parent]:class]Name of interface.You may specify either the interface number or the interface
name. If the classify option is
given for the interface in shorewall6-tcdevices(5),
then you must also specify an interface class (an integer that must
be unique within classes associated with this interface).You may NOT specify wildcards here, e.g. if you have multiple
ppp interfaces, you need to put them all in here!Please note that you can only use interface names in here that
have a bandwidth defined in the shorewall6-tcdevices(5)
file.Normally, all classes defined here are sub-classes of a root
class (class number 1) that is implicitly defined from the entry in
shorewall6-tcdevices(5). You
can establish a class hierarchy by specifying a
parent class -- the number of a class that you
have previously defined. The sub-class may borrow unused bandwidth
from its parent.MARK -
{-|value}The mark value which is an integer in the
range 1-255. You set mark values in the shorewall6-tcrules(5) file,
marking the traffic you want to fit in the classes defined in here.
Must be specified as '-' if the classify option is given for the interface in
shorewall6-tcdevices(5) and
you are running Shorewall 4.5 5 or earlier.You can use the same marks for different interfaces.RATE -
{-|rate[:dmax[:umax]]}The minimum bandwidth this class should get, when the traffic
load rises. If the sum of the rates in this column exceeds the
INTERFACE's OUT-BANDWIDTH, then the OUT-BANDWIDTH limit may not be
honored. Similarly, if the sum of the rates of sub-classes of a
class exceed the CEIL of the parent class, things don't work
well.When using the HFSC queuing discipline, this column specify
the real-time (RT) service curve. leaf classes may specify
dmax, the maximum delay in milliseconds
that the first queued packet for this class should experience. May
be expressed as an integer, optionally followed by 'ms' with no
intervening white-space (e.g., 10ms).HFSC leaf classes may also specify
umax, the largest packet expected in this
class. May be expressed as an integer. The unit of measure is
bytes and the integer may be optionally
followed by 'b' with no intervening white-space (e.g., 800b).
umax may only be given if
dmax is also given.Beginning with Shorewall 4.5.6, HFSC classes may omit this
column (e.g, '-' in the column), provided that an
lsrate is specified (see CEIL below).
These rates are used to arbitrate between classes of the same
priority.CEIL -
[lsrate:]rateThe maximum bandwidth this class is allowed to use when the
link is idle. Useful if you have traffic which can get full speed
when more needed services (e.g. ssh) are not used.You can use the value full in
here for setting the maximum bandwidth to the RATE of the parent
class, or the OUT-BANDWIDTH of the device if there is no parent
class.Beginning with Shorewall 4.5.6, you can also specify an
lsrate (link sharing rate).PRIORITY -
priorityFor HTB:
The priority in which classes will be
serviced by the packet shaping scheduler and also the priority in
which bandwidth in excess of the rate will be given to each
class.Higher priority classes will experience less delay since
they are serviced first. Priority values are serviced in ascending
order (e.g. 0 is higher priority than 1).Classes may be set to the same priority, in which case they
will be serviced as equals.
For both HTB and HFSC, the priority is
used to calculate the priority of following Shorewall-generated
classification filters that refer to the class:Packet MARKtcp-ack and the tos options (see below)The rules for classes with lower numeric priorities will
appear before those with higher numeric priorities.Beginning with Shorewall 4.5.8, the PRIORITY may be omitted
from an HFSC class if you do not use the MARK column or the
tcp-ack or tos options. If you use those features and
omit the PRIORITY, then you must specify a
priority along with the MARK or
option.OPTIONS (Optional) -
[option[,option]...]A comma-separated list of options including the
following:defaultThis is the default class for that interface where all
traffic should go, that is not classified otherwise.You must define default for exactly one class per
interface.tos=0xvalue[/0xmask][:priority]
(mask defaults to 0xff)This lets you define a classifier for the given
value/mask
combination of the IP packet's TOS/Precedence/DiffSrv octet
(aka the TOS byte).Beginning with Shorewall 4.5.8, the
value/mask may be followed by a
colon (":") and a priority. This
priority determines the order in which filter rules are
processed during packet classification. If not specified, the
value (class priority << 8) |
10) is used.tos-tosname[:priority]Aliases for the following TOS octet value and mask
encodings. TOS encodings of the "TOS byte" have been
deprecated in favor of diffserve classes, but programs like
ssh, rlogin, and ftp still use them.tos-minimize-delay 0x10/0x10
tos-maximize-throughput 0x08/0x08
tos-maximize-reliability 0x04/0x04
tos-minimize-cost 0x02/0x02
tos-normal-service 0x00/0x1eBeginning with Shorewall 4.5.8, the
tos-name may be followed by a colon
(":") and a priority. This priority
determines the order in which filter rules are processed
during packet classification. If not specified, the value
(class priority << 8) | 10)
is used.Each of these options is only valid for ONE class per
interface.tcp-ack[:priority]If defined, causes a tc filter to be created that puts
all tcp ack packets on that interface that have a size of
<=64 Bytes to go in this class. This is useful for speeding
up downloads. Please note that the size of the ack packets is
limited to 64 bytes because we want only packets WITHOUT
payload to match.Beginning with Shorewall 4.5.8, the tcp-ack may be followed by a colon
(":") and a priority. This priority
determines the order in which filter rules are processed
during packet classification. If not specified, the value
(class priority << 8) | 20)
is used.This option is only valid for ONE class per
interface.flow=keysShorewall attaches an SFQ queuing discipline to each
leaf HTB class. SFQ ensures that each
flow gets equal access to the
interface. The default definition of a flow corresponds
roughly to a Netfilter connection. So if one internal system
is running BitTorrent, for example, it can have lots of
'flows' and can thus take up a larger share of the bandwidth
than a system having only a single active connection. The
classifier (module cls_flow) works
around this by letting you define what a 'flow' is. The
classifier must be used carefully or it can block off all
traffic on an interface! The flow option can be specified for
an HTB leaf class (one that has no sub-classes). We recommend
that you use the following:Shaping internet-bound traffic:
flow=nfct-srcShaping traffic bound for your local net:
flow=dstThese will cause a 'flow' to consists of the traffic
to/from each internal system.When more than one key is give, they must be enclosed in
parenthesis and separated by commas.To see a list of the possible flow keys, run this
command:
tc filter add flow help
Those that begin with "nfct-" are Netfilter connection
tracking fields. As shown above, we recommend flow=nfct-src;
that means that we want to use the source IP address
before NAT as the key.pfifoWhen specified for a leaf class, the pfifo queuing
discipline is applied to the class rather than the sfq queuing
discipline.limit=numberAdded in Shorewall 4.4.3. When specified for a leaf
class, determines the maximum number of packets that may be
queued within the class. The number must
be > 2 and <= 128. If not specified, the value 127 is
assumed.red=(redoption=value,
...)Added in Shorewall 4.5.6. When specified on a leaf
class, causes the class to use the RED (Random Early
Detection) queuing discipline rather than SFQ. See tc-red (8)
for additional information.Allowable redoptions are:min minAverage queue size at which marking becomes a
possibility.max maxAt this average queue size, the marking
probability is maximal. Must be at least twice
min to prevent synchronous
retransmits, higher for low
min.probability
probabilityMaximum probability for marking, specified as a
floating point number from 0.0 to 1.0. Suggested values
are 0.01 or 0.02 (1 or 2%, respectively).limit limitHard limit on the real (not average) queue size in
bytes. Further packets are dropped. Should be set higher
than
max+burst.
It is advised to set this a few times higher than
max. Shorewall requires that
limit be at least twice
min.burst burstUsed for determining how fast the average queue
size is influenced by the real queue size. Larger values
make the calculation more sluggish, allowing longer
bursts of traffic before marking starts. Real life
experiments support the following guide‐line:
(min+min+max)/(3*avpkt).avpkt avpktOptional. Specified in bytes. Used with burst to
determine the time constant for average queue size
calculations. 1000 is a good value and is the Shorewall
default.bandwidth
bandwidthOptional. This rate is used for calculating the
average queue size after some idle time. Should be set
to the bandwidth of your interface. Does not mean that
RED will shape for you!ecnRED can either 'mark' or 'drop'. Explicit
Congestion Notification allows RED to notify remote
hosts that their rate exceeds the amount of bandwidth
available. Non-ECN capable hosts can only be notified by
dropping a packet. If this parameter is specified,
packets which indicate that their hosts honor ECN will
only be marked and not dropped, unless the queue size
hits limit bytes. Needs a tc
binary with RED support compiled in. Recommended.fq_codel[=(codeloption=value,
...)]Added in Shorewall 4.5.12. When specified for a leaf
class, causes the class to use the FQ_CODEL
(Fair-queuing Controlled-Delay) queuing
discipline rather than SFQ. See tc-fq_codel (8) for additional
information.Allowable codeloptions
are:limithard limit on the real queue size. When this limit
is reached, incoming packets are dropped. If the value
is lowered, packets are dropped so that the new limit is
met. Default is 1000 packets.flowsis the number of flows into which the incoming
packets are classified. Due to the stochastic nature of
hashing, multiple flows may end up being hashed into the
same slot. Newer flows have priority over older ones.
This parameter can be set only at load time since memory
has to be allocated for the hash table. Default value is
1024.targetis the acceptable minimum standing/persistent
queue delay. This minimum delay is identified by
tracking the local minimum queue delay that packets
experience. Default and recommended value is 5ms.intervalis used to ensure that the measured minimum delay
does not become too stale. The minimum delay must be
experienced in the last epoch of length interval. It
should be set on the order of the worst-case RTT through
the bottleneck to give endpoints sufficient time to
react. Default value is 100ms.quantumis the number of bytes used as 'deficit' in the
fair queuing algorithm. Default is set to 1514 bytes
which corresponds to the Ethernet MTU plus the hardware
header length of 14 bytes.ecn | noecncan be used to mark packets instead of dropping
them. If ecn has been enabled, noecn can be used to turn
it off and vice-a-versa. By default, ecn is
enabled.ExamplesExample 1:Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. You have 4 classes here, the first you can use
for voice over IP traffic, the second interactive traffic (e.g.
ssh/telnet but not scp), the third will be for all unclassified
traffic, and the forth is for low priority traffic (e.g.
peer-to-peer).The voice traffic in the first class will be guaranteed a
minimum of 100kbps and always be serviced first (because of the low
priority number, giving less delay) and will be granted excess
bandwidth (up to 180kbps, the class ceiling) first, before any other
traffic. A single VoIP stream, depending upon codecs, after
encapsulation, can take up to 80kbps on a PPPoE/DSL link, so we pad a
little bit just in case. (TOS byte values 0xb8 and 0x68 are DiffServ
classes EF and AFF3-1 respectively and are often used by VOIP
devices).Interactive traffic (tos-minimum-delay) and TCP acks (and ICMP
echo traffic if you use the example in tcrules) and any packet with
a mark of 2 will be guaranteed 1/4 of the link bandwidth, and may
extend up to full speed of the link.Unclassified traffic and packets marked as 3 will be
guaranteed 1/4th of the link bandwidth, and may extend to the full
speed of the link.Packets marked with 4 will be treated as low priority packets.
(The tcrules example marks p2p traffic as such.) If the link is
congested, they're only guaranteed 1/8th of the speed, and even if
the link is empty, can only expand to 80% of link bandwidth just as
a precaution in case there are upstream queues we didn't account
for. This is the last class to get additional bandwidth and the last
to get serviced by the scheduler because of the low priority. #INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 100kbit 180kbit 1 tos=0x68/0xfc,tos=0xb8/0xfc
ppp0 2 full/4 full 2 tcp-ack,tos-minimize-delay
ppp0 3 full/4 full 3 default
ppp0 4 full/8 full*8/10 4FILES/etc/shorewall6/tcclassesSee ALSOtc-hfsc(7)tc-red(8)http://shorewall.net/traffic_shaping.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcfilters.xml 0000644 0001750 0001750 00000024512 12222401136 023706 0 ustar teastep teastep
shorewall6-tcfilters5tcfiltersshorewall6 u32 classifier rules file/etc/shorewall6/tcfiltersDescriptionEntries in this file cause packets to be classified for traffic
shaping.Beginning with Shorewall 4.4.15, the file may contain entries for
both IPv4 and IPv6. By default, all rules apply to IPv6 but that can be
changed by inserting a line as follows:IPV4Following entries apply to IPv4.IPV6Following entries apply to IPv6ALLFollowing entries apply to both IPv4 and IPv6. Each entry is
processed twice; once for IPv4 and once for IPv6.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).CLASS -
interface:classThe name or number of an interface
defined in shorewall6-tcdevices(5)
followed by a class number defined for
that interface in shorewall6-tcclasses(5).SOURCE - {-|address}Source of the packet. May be a host or network
address. DNS names are not
allowed.DEST - {-|address}}Destination of the packet. May be a host or network
address. DNS names are not
allowed.PROTO - {-|{protocol-number|protocol-name|all}[,...]}Protocol.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT (dport) - [-|port-name-or-number]Optional destination Ports. A Port name (from services(5)) or
a port number; if the protocol is icmp, this column is interpreted as the
destination icmp-type(s).SOURCE PORT (sport) -
[-|port-name-or-number]Optional source port.TOS - [-|tos]Optional - specifies the value of the TOS field. The
tos value can be any of the
following:hex-numberhex-number/hex-numberThe hex-numbers must be exactly two
digits (e.g., 0x04)x.LENGTH - [-|number]Optional. Must be a power of 2 between 32 and 8192 inclusive.
Packets with a total length that is strictly less than the specified
number will match the rule.PRIORITY - [-|number]Added in Shorewall 4.5.8. Specifies the rule priority. The
priority value must be > 0 and <= 65535.When a priority is not
given:For Shorewall versions prior to 4.5.8 - all filters have
priority 11.For Shorewall 4.5.8 and later - for each device, the
compiler maintains a high-water priority
with an initial value of 0. When a filter has no
priority, the high-water priority is
incremented by 1 and assigned to the filter. When a
priority greater than the high-water
priority is entered in this column, the high-water priority is
set to the specified priority. An
attempt to assign a priority value greater than 65535
(explicitly or implicitly) raises an error.The default priority values used by other Shorewall-generated
filters are as follows:Classify by packet mark - ( class
priority << 8 ) | 20.Ingress policing - 10Simple TC ACK packets - 1Complex TC ACK packets - ( class
priority << 8 ) | 20.Classify by TOS - ( class
priority << 8 ) | 15.Class with 'occurs' - 65535ExampleExample 1:Place all 'ping' traffic on interface 1 in class 10. Note that
ALL cannot be used because IPv4 ICMP and IPv6 ICMP are two different
protocols. #CLASS SOURCE DEST PROTO DEST
# PORT
IPV4
1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:10 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
IPV6
1:10 ::/0 ::/0 icmp6 echo-request
1:10 ::/0 ::/0 icmp6 echo-replyExample 2:Add two filters with priority 10 (Shorewall 4.5.8 or
later). #CLASS SOURCE DEST PROTO DEST PRIORITY
# PORT
IPV6
1:10 ::/0 ::/0 icmp echo-request 10
1:10 ::/0 ::/0 icmp echo-reply 10FILES/etc/shorewall6/tcfiltersSee ALSOhttp://shorewall.net/traffic_shaping.htmhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/PacketMarking.html
shorewall-docs-xml-4.5.21/manpages6/shorewall6-providers.xml 0000644 0001750 0001750 00000040000 12222401136 023712 0 ustar teastep teastep
shorewall6-providers5providersShorewall6 Providers file/etc/shorewall6/providersDescriptionThis file is used to define additional routing tables. You will want
to define an additional table if:You have connections to more than one ISP or multiple
connections to the same ISPYou run Squid as a transparent proxy on a host other than the
firewall.You have other requirements for policy routing.Each entry in the file defines a single routing table.If you wish to omit a column entry but want to include an entry in
the next column, use "-" for the omitted entry.The columns in the file are as follows.NAME -
nameThe provider name. Must be a valid shell
variable name. The names 'local', 'main', 'default' and 'unspec' are
reserved and may not be used as provider names.NUMBER -
numberThe provider number -- a number between 1 and 15. Each
provider must be assigned a unique value.MARK (Optional) -
valueA FWMARK value used in your shorewall6-tcrules(5) file to
direct packets to this provider.If HIGH_ROUTE_MARKS=Yes in shorewall6.conf(5), then the
value must be a multiple of 256 between 256 and 65280 or their
hexadecimal equivalents (0x0100 and 0xff00 with the low-order byte
of the value being zero). Otherwise, the value must be between 1 and
255. Each provider must be assigned a unique mark value. This column
may be omitted if you don't use packet marking to direct connections
to a particular provider.DUPLICATE -
routing-table-nameThe name of an existing table to duplicate to create this
routing table. May be or the name of a
previously listed provider. You may select only certain entries from
the table to copy by using the COPY column below.INTERFACE -
interfaceThe name of the network interface to the provider. Must be
listed in shorewall6-interfaces(5).GATEWAY - {-|address|detect}The IP address of the provider's gateway router.You can enter "detect" here and Shorewall6 will attempt to
detect the gateway automatically.For PPP devices, you may omit this column.OPTIONS (Optional) - [-|option[,option]...]A comma-separated list selected from the following. The order
of the options is not significant but the list may contain no
embedded white-space.autosrcAdded in Shorewall 4.5.17. Causes a host route to the
provider's gateway router to be added to the provider's
routing table. This is the default behavior unless overridden
by a following noautosrc
option.balanceAdded in Shorewall 4.4.25. Causes a default route to
this provider's gateway to be added to the main routing table (USE_DEFAULT_RT=No)
or to the balance routing
table (USE_DEFAULT_RT=Yes). At most one provider can specify
this option.fallbackAdded in Shorewall 4.4.25. Causes a default route to
this provider's gateway to be added to the default routing table.At most one
provider can specify this option.trackIf specified, inbound connections on this interface are
to be tracked so that responses may be routed back out this
same interface.You want to specify if internet
hosts will be connecting to local servers through this
provider.Beginning with Shorewall 4.4.3,
defaults to the setting of the TRACK_PROVIDERS option in
shorewall6.conf
(5). If you set TRACK_PROVIDERS=Yes and want to override that
setting for an individual provider, then specify
(see below).looseShorewall6 normally adds a routing rule for each IP
address on an interface which forces traffic whose source is
that IP address to be sent using the routing table for that
interface. Setting prevents creation of
such rules on this interface.noautosrcAdded in Shorewall 4.5.17. Prevents the addition of a
host route to the provider's gateway router from being added
to the provider's routing table. This option must be used with
caution as it can cause start and restart failures.notrackAdded in Shorewall 4.4.3. When specified, turns off
.optional (deprecated for
use with providers that do not share an interface)If the interface named in the INTERFACE column is not up
and configured with an IPv4 address then ignore this provider.
If not specified, the value of the
option for the INTERFACE in shorewall6-interfaces(5)
is assumed. Use of that option is preferred to this one,
unless an address is provider in
the INTERFACE column.src=source-addressSpecifies the source address to use when routing to this
provider and none is known (the local client has bound to the
0 address). May not be specified when an
address is given in the INTERFACE
column. If this option is not used, Shorewall6 substitutes the
primary IP address on the interface named in the INTERFACE
column.mtu=numberSpecifies the MTU when forwarding through this provider.
If not given, the MTU of the interface named in the INTERFACE
column is assumed.tproxyAdded in Shorewall 4.5.4. Used for supporting the TPROXY
action in shorewall-tcrules(5). See http://www.shorewall.net/Shorewall_Squid_Usage.html.
When specified, the MARK, DUPLICATE and GATEWAY columns should
be empty, INTERFACE should be set to 'lo' and
should be the only OPTION. Only one
provider is allowed.hostrouteAdded in Shorewall 4.5.21. This is the default behavior
that results in a host route to the defined GATEWAY being inserted into the main
routing table and into the provider's routing table. hostroute is required for older
distributions but nohostroute
(below) is appropriate for recent distributions. hostroute may interfere with Zebra's
ability to add routes on some distributions such as Debian
7.nohostrouteAdded in Shorewall 4.5.21. nohostroute inhibits addition
of a host route to the defined GATEWAY being inserted into the main
routing table and into the provider's routing table. nohostroute is not appropriate for
older distributions but is appropriate for recent
distributions. nohostroute
allows Zebra's to correctly add routes on some distributions
such as Debian 7.COPY -
[{|interface[,interface]...}]A comma-separated list of other interfaces on your firewall.
Wildcards specified using an asterisk ("*") are permitted (e.g.,
tun* ). Usually used only when DUPLICATE is .
Only copy routes through INTERFACE and through interfaces listed
here. If you only wish to copy routes through INTERFACE, enter
in this column.Beginning with Shorewall 4.5.17, blackhole, unreachable and
prohibit routes are no longer copied by default but may be copied by
including blackhole,unreachable and prohibit respectively in the COPY
list.ExamplesExample 1:You run squid in your DMZ on IP address 2002:ce7c:92b4:1::2.
Your DMZ interface is eth2 #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS
Squid 1 1 - eth2 2002:ce7c:92b4:1::2 -Example 2:eth0 connects to ISP 1. The ISP's gateway router has IP
address 2001:ce7c:92b4:1::2.eth1 connects to ISP 2. The ISP's gateway router has IP
address 2001:d64c:83c9:12::8b.eth2 connects to a local network. #NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
ISP1 1 1 main eth0 2001:ce7c:92b4:1::2 track eth2
ISP2 2 2 main eth1 2001:d64c:83c9:12::8b track eth2FILES/etc/shorewall6/providersSee ALSOhttp://shorewall.net/MultiISP.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-rtrules(5), shorewall6-routestopped(5),
shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-rtrules.xml 0000644 0001750 0001750 00000014161 12222401136 023406 0 ustar teastep teastep
shorewall6-rtrules5rtrulesShorewall6 Routing Rules file/etc/shorewall6/rtrulesDescriptionEntries in this file cause traffic to be routed to one of the
providers listed in shorewall6-providers(5).The columns in the file are as follows.SOURCE (Optional) - {-|interface|address|interface:<address>}An ip address (network or host) that
matches the source IP address in a packet. May also be specified as
an interface name optionally followed by ":"
and an address. If the device lo is
specified, the packet must originate from the firewall
itself.Beginning with Shorewall 4.5.0, you may specify
&interface in this column to indicate
that the source is the primary IP address of the named
interface.DEST (Optional) - {-|address}An ip address (network or host) that matches the destination
IP address in a packet.If you choose to omit either SOURCE or DEST, place "-" in that column. Note that you
may not omit both SOURCE and
DEST.PROVIDER -
{provider-name|provider-number|main}The provider to route the traffic through. May be expressed
either as the provider name or the provider number. May also be
main or 254 for the main routing
table. This can be used in combination with VPN tunnels, see example
2 below.PRIORITY -
priorityThe rule's numeric priority which
determines the order in which the rules are processed. Rules with
equal priority are applied in the order in which they appear in the
file.1000-1999Before Shorewall6-generated 'MARK' rules11000-11999After 'MARK' rules but before Shorewall6-generated rules
for ISP interfaces.26000-26999After ISP interface rules but before 'default'
rule.MARK -
{-|mark[/mask]}Optional -- added in Shorewall 4.4.25. For this rule to be
applied to a packet, the packet's mark value must match the
mark when logically anded with the
mask. If a
mask is not supplied, Shorewall supplies
a suitable provider mask.ExamplesExample 1:You want all traffic coming in on eth1 to be routed to the
ISP1 provider. #SOURCE DEST PROVIDER PRIORITY MASK
eth1 - ISP1 1000
FILES/etc/shorewall6/rtrulesSee ALSOhttp://shorewall.net/MultiISP.htmlshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-routestopped(5),
shorewall6-rules(5), shorewall6.conf(5), shorewall6-secmarks(5),
shorewall6-tcclasses(5), shorewall6-tcdevices(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tunnels.xml 0000644 0001750 0001750 00000024712 12222401136 023401 0 ustar teastep teastep
shorewall6-tunnels5tunnelsShorewall6 VPN definition file/etc/shorewall6/tunnelsDescriptionThe tunnels file is used to define rules for encapsulated (usually
encrypted) traffic to pass between the Shorewall6 system and a remote
gateway. Traffic flowing through the tunnel is handled using the normal
zone/policy/rule mechanism. See http://www.shorewall.net/VPNBasics.html
for details.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).TYPE - {ipsec[:{noah|ah}]|ipsecnat|gre|l2tp|pptpclient|pptpserver|{openvpn|openvpnclient|openvpnserver}[:{tcp|udp}][:port]|generic:protocol[:port]}Types are as follows:ipsec - IPv6 IPSEC
ipsecnat - IPv6 IPSEC with NAT Traversal (UDP port 4500 encapsulation)
gre - Generalized Routing Encapsulation (Protocol 47)
l2tp - Layer 2 Tunneling Protocol (UDP port 1701)
openvpn - OpenVPN in point-to-point mode
openvpnclient - OpenVPN client runs on the firewall
openvpnserver - OpenVPN server runs on the firewall
generic - Other tunnel typeIf the type is ipsec, it may
be followed by :ah to indicate that
the Authentication Headers protocol (51) is used by the tunnel (the
default is which means that protocol 51 is
not used). NAT traversal is only supported with ESP (protocol 50) so
ipsecnat tunnels don't allow the
ah option (ipsecnat:noah may be specified but is
redundant).If type is openvpn, openvpnclient or openvpnserver it may optionally be followed
by ":" and tcp or udp to specify the protocol to be used. If
not specified, udp is assumed.
Note: At this writing, OpenVPN does not support IPv6.If type is openvpn, openvpnclient or openvpnserver it may optionally be followed
by ":" and the port number used by the tunnel. if no ":" and port
number are included, then the default port of 1194 will be used. .
Where both the protocol and port are specified, the protocol must be
given first (e.g., openvpn:tcp:4444).If type is generic, it must
be followed by ":" and a protocol name (from /etc/protocols) or a
protocol number. If the protocol is tcp or udp
(6 or 17), then it may optionally be followed by ":" and a port
number.Comments may be attached to Netfilter rules generated from
entries in this file through the use of COMMENT lines. These lines
begin with the word COMMENT; the remainder of the line is treated as
a comment which is attached to subsequent rules until another
COMMENT line is found or until the end of the file is reached. To
stop adding comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym for
COMMENT and is preferred.ZONE -
zoneThe zone of the physical interface
through which tunnel traffic passes. This is normally your internet
zone.GATEWAY(S) (gateway or
gateways) - address-or-range[ , ... ]The IP address of the remote tunnel gateway. If the remote
gateway has no fixed address (Road Warrior) then specify the gateway
as ::/0. May be specified as a
network address and if your kernel and ip6tables include iprange
match support then IP address ranges are also allowed.Beginning with Shorewall 4.5.3, a list of addresses or ranges
may be given. Exclusion (shorewall6-exclusion (5) )
is not supported.GATEWAY ZONE(S) (gateway_zone
or gateway_zones) - [zone[,zone]...]Optional. If the gateway system specified in the third column
is a standalone host then this column should contain a
comma-separated list of the names of the zones that the host might
be in. This column only applies to IPSEC tunnels where it enables
ISAKMP traffic to flow through the tunnel to the remote
gateway(s).ExampleExample 1:IPSec tunnel.The remote gateway is 2001:cec792b4:1::44. The tunnel does not
use the AH protocol #TYPE ZONE GATEWAY
ipsec:noah net 2002:cec792b4:1::44Example 2:Road Warrior (LapTop that may connect from anywhere) where the
"gw" zone is used to represent the remote LapTop #TYPE ZONE GATEWAY GATEWAY ZONES
ipsec net ::/0 gwExample 3:Host 2001:cec792b4:1::44 is a standalone system connected via
an ipsec tunnel to the firewall system. The host is in zone
gw. #TYPE ZONE GATEWAY GATEWAY ZONES
ipsec net 2001:cec792b4:1::44 gwExample 4:OPENVPN tunnel. The remote gateway is 2001:cec792b4:1::44 and
openvpn uses port 7777. #TYPE ZONE GATEWAY GATEWAY ZONES
openvpn:7777 net 2001:cec792b4:1::44Example 8:You have a tunnel that is not one of the supported types. Your
tunnel uses UDP port 4444. The other end of the tunnel is
2001:cec792b4:1::44. #TYPE ZONE GATEWAY GATEWAY ZONES
generic:udp:4444 net 2001:cec792b4:1::44FILES/etc/shorewall6/tunnelsSee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-zones.xml 0000644 0001750 0001750 00000042114 12222401136 023043 0 ustar teastep teastep
shorewall6-zones5zonesShorewall6 zone declaration file/etc/shorewall6/zonesDescriptionThe /etc/shorewall6/zones file declares your network zones. You
specify the hosts in each zone through entries in
/etc/shorewall6/interfaces or
/etc/shorewall6/hosts.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ZONE -
zone[:parent-zone[,parent-zone]...]Name of the zone. The names "all",
"none", "SOURCE" and "DEST" are reserved and may not be used as zone
names. The maximum length of a zone name is determined by the
setting of the LOGFORMAT option in shorewall6.conf(5). With the
default LOGFORMAT, zone names can be at most 5 characters
long.
The maximum length of an iptables log prefix is 29 bytes. As
explained in shorewall6.conf (5), the default
LOGPREFIX formatting string is “Shorewall:%s:%s:” where the first
%s is replaced by the chain name and the second is replaced by the
disposition.The default formatting string has 12 fixed characters
("Shorewall" and three colons).The longest of the standard dispositions are ACCEPT and
REJECT which have 6 characters each.The canonical name for the chain containing the rules
for traffic going from zone 1 to zone 2 is "<zone
1>2<zone 2>".So if M is the maximum zone name length, such chains can
have length 2*M + 1.12 + 6 + 2*M + 1 = 29 which reduces to2*M = 29 - 12 - 6 - 1 = 10 orM = 5
The order in which Shorewall6 matches addresses from packets
to zones is determined by the order of zone declarations. Where a
zone is nested in one or more other zones, you may either ensure
that the nested zone precedes its parents in this file, or you may
follow the (sub)zone name by ":" and a comma-separated list of the
parent zones. The parent zones must have been declared in earlier
records in this file. See shorewall6-nesting(5) for
additional information.Example:#ZONE TYPE OPTIONS IN OPTIONS OUT OPTIONS
a ipv6
b ipv6
c:a,b ipv6Currently, Shorewall6 uses this information to reorder the
zone list so that parent zones appear after their subzones in the
list. The IMPLICIT_CONTINUE option in shorewall6.conf(5) can also
create implicit CONTINUE policies to/from the subzone.Where an ipsec zone is
explicitly included as a child of an ipv6 zone, the ruleset allows CONTINUE
policies (explicit or implicit) to work as expected.In the future, Shorewall6 may make additional use of nesting
information.TYPEipv6This is the standard Shorewall6 zone type and is the
default if you leave this column empty or if you enter "-" in
the column. Communication with some zone hosts may be
encrypted. Encrypted hosts are designated using the 'ipsec'
option in shorewall6-hosts(5).ipsec (or ipsec6)Communication with all zone hosts is encrypted. Your
kernel and ip6tables must include policy match support.firewallDesignates the firewall itself. You must have exactly
one 'firewall' zone. No options are permitted with a
'firewall' zone. The name that you enter in the ZONE column
will be stored in the shell variable $FW which you may use in
other configuration files to designate the firewall
zone.bport (or bport6)The zone is associated with one or more ports on a
single bridge.vserverAdded in Shorewall 4.4.11 Beta 2 - A zone composed of
Linux-vserver guests. The zone contents must be defined in
shorewall6-hosts
(5).Vserver zones are implicitly handled as subzones of the
firewall zone.loopbackAdded in Shorewall 4.5.17.Normally, Shorewall treats the loopback interface (lo)
in the following way:By default, all traffic through the interface is
ACCEPTed.If a $FW -> $FW policy is defined or $FW ->
$FW rules are defined, they are placed in a chain named
${FW}2${F2} or ${FW}-${FW} (e.g., 'fw2fw' or 'fw-fw' )
depending on the ZONE2ZONE setting in shorewall6.conf(5).$FW -> $FW traffic is only filtered in the OUTPUT
chain.By defining a loopback
zone and associating it with the loopback interface in
shorewall-interfaces(5), you can effect a slightly different
model. Suppose that the loopback zone name is 'local';
then:Both $FW -> local and local -> $FW chains are
created.The $FW -> local and local -> $FW policies may
be different.Both $FW -> local and local -> $FW rules may
be specified.Rules to/from the loopback zone and any zone other than
the firewall zone are ignored with a warning.loopback zones may be
nested within other loopback
zones.localAdded in Shorewall 4.5.17. local is the same as ipv6 with the exception that the zone
is only accessible from the firewall and vserver zones.OPTIONS, IN OPTIONS and OUT
OPTIONS (options, in_options, out_options) -
[option[,option]...]A comma-separated list of options. With the exception of the
and options, these
only apply to TYPE zones.blacklistAdded in Shorewall 4.4.13. May not be specified for
firewall or vserver zones.When specified in the IN_OPTIONS column, causes all
traffic from this zone to be passed against the src entries in shorewall6-blacklist(5).When specified in the OUT_OPTIONS column, causes all
traffic to this zone to be passed against the dst entries in shorewall6-blacklist(5).Specifying this option in the OPTIONS column is
equivalent to entering it in both of the IN_OPTIONS and
OUT_OPTIONS column.dynamic_sharedAdded in Shorewall 4.5.9. May only be specified in the
OPTIONS column and indicates that only a single ipset should
be created for this zone if it has multiple dynamic entries in
shorewall6-hosts(5).
Without this option, a separate ipset is created for each
interface.reqid=numberwhere number is specified using
setkey(8) using the 'unique:number option
for the SPD level.spi=<number>where number is the SPI of the SA
used to encrypt/decrypt packets.proto=ah|esp|ipcompIPSEC Encapsulation Protocolmss=numbersets the MSS field in TCP packets. If you supply this
option, you should also set FASTACCEPT=No in shorewall6.conf(5) to
insure that both the SYN and SYN,ACK packets have their MSS
field adjusted.mode=transport|tunnelIPSEC modetunnel-src=address[/mask]only available with mode=tunneltunnel-dst=address[/mask]only available with mode=tunnelstrictMeans that packets must match all rules.nextSeparates rules; can only be used with strictThe options in the OPTIONS column are applied to both incoming
and outgoing traffic. The IN OPTIONS are applied to incoming traffic
(in addition to OPTIONS) and the OUT OPTIONS are applied to outgoing
traffic.If you wish to leave a column empty but need to make an entry
in a following column, use "-".FILES/etc/shorewall6/zonesSee ALSOhttp://www.shorewall.net/Multiple_Zones.html.http://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-nesting(8),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-stoppedrules.xml 0000644 0001750 0001750 00000015325 12222401136 024442 0 ustar teastep teastep
shorewall6-stoppedrules5stoppedrulesThe Shorewall file that governs what traffic flows through the
firewall while it is in the 'stopped' state./etc/shorewall6/stoppedrulesDescriptionThis file is used to define the hosts that are accessible when the
firewall is stopped or is being stopped.Changes to this file do not take effect until after the next
shorewall start, shorewall
restart, or command.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION -
Determines the disposition of the packet.
means that the packet will be accepted.
indicates that no conntrack entry should be
created for the packet. does not imply
.SOURCE - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets originating on the
firewall itself, while interface
specifies packets arriving on the named interface.This column may also include a comma-separated list of
IP/subnet addresses. If your kernel and iptables include iprange
match support, IP address ranges are also allowed. Ipsets and
exclusion are also supported. When or interface
are specified, the list must be preceded by a colon (":").If left empty or supplied as "-", ::/0 is assumed.DEST - [-|[$FW|interface]|[{$FW|interface}[:address[,address]...]]|[address[,address]...] matches packets addressed the firewall
itself, while interface specifies packets
arriving on the named interface. Neither may be specified if the
target is .This column may also include a comma-separated list of
IP/subnet addresses. If your kernel and iptables include iprange
match support, IP address ranges are also allowed. Ipsets and
exclusion are also supported. When or interface
are specified, the list must be preceded by a colon (":").If left empty or supplied as "-", ::/0 is assumed.PROTO (Optional) ‒
protocol-name-or-number[,...]Protocol.Beginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT(S) (dport) ‒
service-name/port-number-listOptional. A comma-separated list of port numbers and/or
service names from /etc/services. May also
include port ranges of the form
low-port:high-port
if your kernel and iptables include port range support.SOURCE PORT(S) (sport) ‒
service-name/port-number-listOptional. A comma-separated list of port numbers and/or
service names from /etc/services. May also
include port ranges of the form
low-port:high-port
if your kernel and iptables include port range support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.FILES/etc/shorewall6/stoppedrulesSee ALSOhttp://shorewall.net/starting_and_stopping_shorewall.htmhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall(8), shorewall-accounting(5), shorewall-actions(5),
shorewall-blacklist(5), shorewall-hosts(5), shorewall_interfaces(5),
shorewall-ipsets(5), shorewall-maclist(5), shorewall-masq(5),
shorewall-nat(5), shorewall-netmap(5), shorewall-params(5),
shorewall-policy(5), shorewall-providers(5), shorewall-proxyarp(5),
shorewall-rtrules(5), shorewall-rules(5), shorewall.conf(5),
shorewall-secmarks(5), shorewall-tcclasses(5), shorewall-tcdevices(5),
shorewall-tcrules(5), shorewall-tos(5), shorewall-tunnels(5),
shorewall-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-policy.xml 0000644 0001750 0001750 00000032516 12222401136 023211 0 ustar teastep teastep
shorewall6-policy5policyshorewall6 policy file/etc/shorewall6/policyDescriptionThis file defines the high-level policy for connections between
zones defined in shorewall6-zones(5).The order of entries in this file is importantThis file determines what to do with a new connection request if
we don't get a match from the /etc/shorewall6/rules file . For each
source/destination pair, the file is processed in order until a match is
found ("all" will match any client or server).Intra-zone policies are pre-definedFor $FW and for all of the zones defined in /etc/shorewall6/zones,
the POLICY for connections from the zone to itself is ACCEPT (with no
logging or TCP connection rate limiting but may be overridden by an
entry in this file. The overriding entry must be explicit (specifying
the zone name on both SOURCE and DEST) or it must use "all+ or it must
use "all+" (Shorewall 4.5.17 or later).Similarly, if you have IMPLICIT_CONTINUE=Yes in shorewall6.conf,
then the implicit policy to/from any sub-zone is CONTINUE. These
implicit CONTINUE policies may also be overridden by an explicit entry
in this file.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).SOURCE -
zone|$FW|all|all+Source zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or
"all+".Support for "all+" was added in Shorewall 4.5.17. "all" does
not override the implicit intra-zone ACCEPT policy while "all+"
does.DEST -
zone|$FW|all|all+Destination zone. Must be the name of a zone defined in shorewall-zones(5), $FW, "all" or
"all+". If the DEST is a bport zone, then the SOURCE must be "all",
"all+", another bport zone associated with the same bridge, or it
must be an ipv4 zone that is associated with only the same
bridge.Support for "all+" was added in Shorewall 4.5.17. "all" does
not override the implicit intra-zone ACCEPT policy while "all+"
does.POLICY - {ACCEPT|DROP|REJECT|CONTINUE|QUEUE|NFQUEUE[(queuenumber)]|NONE}[:{default-action-or-macro|None}]Policy if no match from the rules file is found.If the policy is neither CONTINUE nor NONE then the policy may
be followed by ":" and one of the following:The word "None" or "none". This causes any default action
defined in shorewall.conf(5) to be
omitted for this policy.The name of an action. The action will be invoked before
the policy is enforced.Actions can have parameters specified.Beginning with Shorewall 4.5.10, the action name can be
followed optionally by a colon and a log level. The level will be
applied to each rule in the action or body that does not already
have a log level.Possible actions are:ACCEPTAccept the connection.DROPIgnore the connection request.REJECTFor TCP, send RST. For all other, send an "unreachable"
ICMP.QUEUEQueue the request for a user-space application such as
Snort-inline.NFQUEUEQueue the request for a user-space application using the
nfnetlink_queue mechanism. If a
queuenumber is not given, queue
zero (0) is assumed.CONTINUEPass the connection request past any other rules that it
might also match (where the source or destination zone in
those rules is a superset of the SOURCE or DEST in this
policy). See shorewall6-nesting(5)
for additional information.NONEAssume that there will never be any packets from this
SOURCE to this DEST. shorewall6 will not create any
infrastructure to handle such packets and you may not have any
rules with this SOURCE and DEST in the /etc/shorewall6/rules
file. If such a packet is
received, the result is undefined. NONE may not be used if the
SOURCE or DEST columns contain the firewall zone ($FW) or
"all".LOG LEVEL (loglevel) -
[log-level|NFLOG]Optional - if supplied, each connection handled under the
default POLICY is logged at that level. If not supplied, no log
message is generated. See syslog.conf(5) for a description of log
levels.You may also specify NFLOG (must be in upper case). This will
log to the NFLOG target and will send to a separate log through use
of ulogd (http://www.netfilter.org/projects/ulogd/index.html).If you don't want to log but need to specify the following
column, place "-" here.BURST:LIMIT (limit) -
[{s|d}:[[name]:]]]rate/{second|minute}[:burst]If passed, specifies the maximum TCP connection
rate and the size of an acceptable
burst. If not specified, TCP connections are
not limited. If the burst parameter is
omitted, a value of 5 is assumed.When or is specified,
the rate applies per source IP address or per destination IP address
respectively. The name may be chosen by
the user and specifies a hash table to be used to count matching
connections. If not give, the name shorewall is assumed. Where more than one
POLICY specifies the same name, the connections counts for the
policies are aggregated and the individual rates apply to the
aggregated count.CONNLIMIT -
limit[:mask]May be used to limit the number of simultaneous connections
from each individual host to limit
connections. While the limit is only checked on connections to which
this policy could apply, the number of current connections is
calculated over all current connections from the SOURCE host. By
default, the limit is applied to each host individually but can be
made to apply to networks of hosts by specifying a
mask. The mask
specifies the width of a VLSM mask to be applied to the source
address; the number of current connections is then taken over all
hosts in the subnet
source-address/mask.ExampleAll connections from the local network to the internet are
allowedAll connections from the internet are ignored but logged at
syslog level KERNEL.INFO.All other connection requests are rejected and logged at level
KERNEL.INFO. #SOURCE DEST POLICY LOG BURST:LIMIT
# LEVEL
loc net ACCEPT
net all DROP info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT infoFILES/etc/shorewall6/policySee ALSOhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-ipsec(5), shorewall6-maclist(5), shorewall6-masq(5),
shorewall6-nat(5), shorewall6-netmap(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-proxyarp(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-accounting.xml 0000644 0001750 0001750 00000077444 12222401136 024055 0 ustar teastep teastep
shorewall6-accounting5accountingShorewall6 Accounting file/etc/shorewall6/accountingDescriptionAccounting rules exist simply to count packets and bytes in
categories that you define in this file. You may display these rules and
their packet and byte counters using the shorewall6 show
accounting command.Beginning with Shorewall 4.4.18, the accounting structure can be
created with three root chains:accountin: Rules that are valid
in the INPUT chain (may not specify
an output interface).accountout: Rules that are
valid in the OUTPUT chain (may not specify an input interface or a MAC
address).accounting: Other rules.The new structure is enabled by sectioning the accounting file in a
manner similar to the rules
file. The sections are INPUT,
OUTPUT and FORWARD and must appear in that order (although any
of them may be omitted). The first non-commentary record in the accounting
file must be a section header when sectioning is used.If sections are not used, the Shorewall rules compiler cannot
detect certain violations of netfilter restrictions. These violations
can result in run-time errors such as the following:
ip6tables-restore v1.4.13: Can't use -o
with INPUT
Beginning with Shorewall 4.4.20, the ACCOUNTING_TABLE setting was
added to shorewall.conf and shorewall6.conf. That setting determines the
Netfilter table (filter or mangle) where the accounting rules are added.
When ACCOUNTING_TABLE=mangle is specified, the available sections are
PREROUTING, INPUT, OUTPUT,
FORWARD and POSTROUTING.Section headers have the form:section-nameWhen sections are enabled:A jump to a user-defined accounting chain must appear before
entries that add rules to that chain. This eliminates loops and
unreferenced chains.An output interface may not be specified in the PREROUTING and INPUT sections.In the OUTPUT and POSTROUTING sections:An input interface may not be specifiedJumps to a chain defined in the INPUT or PREROUTING sections that specifies an input
interface are prohibitedMAC addresses may not be usedJump to a chain defined in the INPUT or PREROUTING section that specifies a MAC
address are prohibited.The default value of the CHAIN column is:accountin in the INPUT sectionaccountout in the OUTPUT sectionaccountfwd in the FORWARD sectionaccountpre in the PREROUTING sectionaccountpost in the
POSTROUTING sectionTraffic addressed to the firewall goes through the rules defined
in the INPUT section.Traffic originating on the firewall goes through the rules
defined in the OUTPUT section.Traffic being forwarded through the firewall goes through the
rules from the FORWARD sections.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).ACTION - {COUNT|DONE|chain[:{COUNT|JUMP}]|[?]COMMENT
comment}What to do when a matching packet is found.COUNTSimply count the match and continue with the next
ruleDONECount the match and don't attempt to match any other
accounting rules in the chain specified in the CHAIN column.chain[:COUNT]Where chain is the name of a chain;
shorewall6 will create the chain automatically if it doesn't
already exist. If a second chain is mentioned in the CHAIN
column, then a jump from this second chain to
chain is created. If no chain is
named in the CHAIN column, then a jump from the default chain
to chain is created. If :COUNT is included, a counting rule
matching this entry will be added to
chain. The chain may
not exceed 29 characters in length and may be composed of
letters, digits, dash ('-') and underscore ('_').chain:JUMPLike the previous option without the :COUNT part.INLINEAdded in Shorewall 4.5.16. Allows free form ip6tables
matches to be specified following a ';'. In the generated
ip6tables rule(s), the free form matches will follow any
matches that are generated by the column contents.NFACCT({object[!]}[,...])Added in Shorewall 4.5.7. Provides a form of accounting
that survives shorewall stop/shorewall
start and shorewall restart. Requires the
NFaccnt Match capability in your kernel and iptables.
object names an nfacct object (see
man nfaccnt(8)). Multiple rules can specify the same
object; all packets that match any
of the rules increment the packet and bytes count of the
object.Prior to Shorewall 4.5.16, only one
object could be specified.
Beginning with Shorewall 4.5.16, an arbitrary number of
objects may be given.With Shorewall 4.5.16 or later, an nfacct
object in the list may optionally
be followed by ! to indicate
that the nfacct object will be
incremented unconditionally for each packet. When ! is omitted, the
object will be incremented only if
all of the matches in the rule succeed.NFLOG[(nflog-parameters)]
- Added in Shorewall-4.4.20.Causes each matching packet to be sent via the currently
loaded logging back end (usually nfnetlink_log) where it is
available to accounting daemons through a netlink
socket.[?]COMMENTThe remainder of the line is treated as a comment which
is attached to subsequent rules until another COMMENT line is
found or until the end of the file is reached. To stop adding
comments to rules, use a line with only the word
COMMENT.Beginning with Shorewall 4.5.11, ?COMMENT is a synonym
for COMMENT and is preferred.CHAIN - {-|chain}The name of a chain. If specified as
- the accounting chain is assumed when the file is
un-sectioned. When the file is sectioned, the default is one of
accountin, accountout, etc. depending on the section. This is the
chain where the accounting rule is added. The
chain will be created if it doesn't already
exist. The chain may not exceed 29 characters
in length.SOURCE - {-|any|all|interface|interface:address|address}Packet Source.The name of an interface, an
address (host or net) or an
interface name followed by ":" and a host
or net address. An ipset name is also
accepted as an address.DESTINATION (dest) - {-|any|all|interface|interfaceaddress|address}Packet Destination.Format same as SOURCE
column.PROTOCOL (proto) - {-|any|all|protocol-name|protocol-number|ipp2p[:{udp|all}]}A protocol-name (from protocols(5)), a
protocol-number, ipp2p, ipp2p:udp or ipp2p:allBeginning with Shorewall 4.5.12, this column can accept a
comma-separated list of protocols.DEST PORT(S) (dport) -
{-|any|all|ipp2p-option|port-name-or-number[,port-name-or-number]...}Destination Port number. Service name from services(5) or
port number. May only be specified if the
protocol is TCP (6), UDP (17), DCCP (33), SCTP (132) or UDPLITE
(136).You may place a comma-separated list of port names or numbers
in this column if your kernel and ip6tables include multi-port match
support.If the PROTOCOL is ipp2p then
this column must contain an ipp2p-option
("ip6tables -m ipp2p --help") without the leading "--". If no option
is given in this column, ipp2p is
assumed.SOURCE PORT(S) (sport) -
{-|any|all|port-name-or-number[,port-name-or-number]...}Service name from services(5) or port
number. May only be specified if the protocol is TCP (6),
UDP (17), DCCP (33), SCTP (132) or UDPLITE (136).You may place a comma-separated list of port numbers in this
column if your kernel and ip6tables include multi-port match
support.Beginning with Shorewall 4.5.15, you may place '=' in this
column, provided that the DEST PORT(S) column is non-empty. This
causes the rule to match when either the source port or the
destination port in a packet matches one of the ports specified in
DEST PORTS(S). Use of '=' requires multi-port match in your iptables
and kernel.USER/GROUP (user) - [!][user-name-or-number][:group-name-or-number][+program-name]This column may only be non-empty if the CHAIN is OUTPUT.When this column is non-empty, the rule applies only if the
program generating the output is running under the effective
user and/or group
specified (or is NOT running under that id if "!" is given).Examples:joeprogram must be run by joe:kidsprogram must be run by a member of the 'kids'
group!:kidsprogram must not be run by a member of the 'kids'
group+upnpd#program named upnpdThe ability to specify a program name was removed from
Netfilter in kernel version 2.6.14.MARK - [!]value[/mask][:C]Defines a test on the existing packet or connection mark. The
rule will match only if the test returns true.If you don't want to define a test but need to specify
anything in the following columns, place a "-" in this field.!Inverts the test (not equal)valueValue of the packet or connection mark.maskA mask to be applied to the mark before testing.:CDesignates a connection mark. If omitted, the packet
mark's value is tested.IPSEC - option-list
(Optional - Added in Shorewall 4.4.13 but broken until 4.5.4.1
)The option-list consists of a comma-separated list of options
from the following list. Only packets that will be encrypted or have
been decrypted via an SA that matches these options will have their
source address changed. May only be specified when sections are
used.reqid=numberwhere number is specified using
setkey(8) using the 'unique:number option
for the SPD level.spi=<number>where number is the SPI of the SA
used to encrypt/decrypt packets.proto=ah|esp|ipcompIPSEC Encapsulation Protocolmss=numbersets the MSS field in TCP packetsmode=transport|tunnelIPSEC modetunnel-src=address[/mask]only available with mode=tunneltunnel-dst=address[/mask]only available with mode=tunnelstrictMeans that packets must match all rules.nextSeparates rules; can only be used with strictyes or ipsecWhen used by itself, causes all traffic that will be
encrypted/encapsulated or has been decrypted/un-encapsulated
to match the rule.no or noneWhen used by itself, causes all traffic that will not be
encrypted/encapsulated or has been decrypted/un-encapsulated
to match the rule.inMay only be used in the FORWARD section and must be the
first or the only item the list. Indicates that matching
packets have been decrypted in input.outMay only be used in the FORWARD section and must be the
first or the only item in the list. Indicates that matching
packets will be encrypted on output.If this column is non-empty and sections are not used,
then:A chain NAME appearing in the ACTION column must be a
chain branched either directly or indirectly from the accipsecin or accipsecout chain.The CHAIN column must contain either accipsecin or accipsecout or a chain branched either
directly or indirectly from those chains.These rules will NOT appear in the accounting chain.HEADERS -
[!][any:|exactly:]header-list
(Optional - Added in Shorewall 4.4.15)The header-list consists of a
comma-separated list of headers from the following list.auth, ah, or 51Authentication Headers extension
header.esp, or 50Encrypted Security Payload
extension header.hop, hop-by-hop or 0Hop-by-hop options extension header.route, ipv6-route or 41IPv6 Route extension header.frag, ipv6-frag or 44IPv6 fragmentation extension header.none, ipv6-nonxt or 59No next headerproto, protocol or 255Any protocol header.If any: is specified, the
rule will match if any of the listed headers are present. If
exactly: is specified, the will
match packets that exactly include all specified headers. If neither
is given, any: is assumed.If ! is entered, the rule
will match those packets which would not be matched when ! is omitted.In all of the above columns except ACTION and CHAIN,
the values -, any and all may be
used as wildcards. Omitted trailing columns are also treated as
wildcards.FILES/etc/shorewall6/accountingSee ALSOhttp://shorewall.net/Accounting.html
http://shorewall.net/shorewall_logging.htmlhttp://shorewall.net/configuration_file_basics.htm#Pairsshorewall6(8), shorewall6-actions(5), shorewall6-blacklist(5),
shorewall6-hosts(5), shorewall6-interfaces(5), shorewall6-maclist(5),
shorewall6-netmap(5),shorewall6-params(5), shorewall6-policy(5),
shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcdevices(5),
shorewall6-tcrules(5), shorewall6-tos(5), shorewall6-tunnels(5),
shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-params.xml 0000644 0001750 0001750 00000007725 12222401136 023201 0 ustar teastep teastep
shorewall6-netmap(5),shorewall6-params5paramsShorewall6 parameters file/etc/shorewall6/paramsDescriptionAssign any shell variables that you need in this file. The file is
always processed by /bin/sh or by the shell specified
through SHOREWALL_SHELL in shorewall6.conf (5) so the full range
of shell capabilities may be used.It is suggested that variable names begin with an upper case letter
to distinguish them from variables used internally within the Shorewall
programsThe following variable names must be avoided. Those in bold font must be avoided in all Shorewall
versions; those in regular font must be avoided in versions prior to
4.4.8.Any option from shorewall6.conf
(5)COMMANDCONFDIRDEBUGECHO_EECHO_NEXPORTFASTFILEMODEHOSTNAMEIPT_OPTIONSNOROUTESPREVIEWPRODUCTPROFILEPURGERECOVERINGRESTOREPATHRING_BELLSHAREDIRAny name beginning with SHOREWALL_ or
SW_STOPPINGTESTTIMESTAMPUSE_VERBOSITYVARDIRVERBOSEVERBOSE_OFFSETVERSIONExample params file:NET_IF=eth0
NET_OPTIONS=dhcp,nosmurfsExample shorewall6-interfaces(5)
file.ZONE INTERFACE BROADCAST OPTIONS
net $NET_IF - $NET_OPTIONSThis is the same as if the interfaces file had contained:ZONE INTERFACE BROADCAST OPTIONS
net eth0 - dhcp,nosmurfsFILES/etc/shorewall6/paramsSee ALSOhttp://www.shorewall.net/configuration_file_basics.htm#Variablesshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-policy(5), shorewall6-providers(5),
shorewall6-rtrules(5), shorewall6-routestopped(5), shorewall6-rules(5),
shorewall6.conf(5), shorewall6-secmarks(5), shorewall6-tcclasses(5),
shorewall6-tcdevices(5), shorewall6-tcrules(5), shorewall6-tos(5),
shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/manpages6/shorewall6-tcdevices.xml 0000644 0001750 0001750 00000030033 12222401136 023653 0 ustar teastep teastep
shorewall6-tcdevices5tcdevicesShorewall6 Traffic Shaping Devices file/etc/shorewall6/tcdevicesDescriptionEntries in this file define the bandwidth for interfaces on which
you want traffic shaping to be enabled.If you do not plan to use traffic shaping for a device, don't put it
in here as it limits the throughput of that device to the limits you set
here.A note on the bandwidth definitions used in
this file:don't use a space between the integer value and the unit: 30kbit
is valid while 30 kbit is not.you can use one of the following units:kbpsKilobytes per second.mbpsMegabytes per second.kbitKilobits per second.mbitMegabits per second.bps or numberBytes per second.Only whole integers are allowed.The columns in the file are as follows (where the column name is
followed by a different name in parentheses, the different name is used in
the alternate specification syntax).INTERFACE -
[number:]interfaceName of interface. Each interface may be
listed only once in this file. You may NOT specify the name of an
alias (e.g., eth0:0) here; see http://www.shorewall.net/FAQ.htm#faq18You may NOT specify wildcards here, e.g. if you have multiple
ppp interfaces, you need to put them all in here!If the device doesn't exist, a warning message will be issued
during "shorewall6 [re]start" and "shorewall6 refresh" and traffic
shaping configuration will be skipped for that device.Shorewall6 assigns a sequential interface
number to each interface (the first entry in the file is
interface 1, the second is interface 2 and so on) Beginning with
Shorewall6-perl 4.1.6, you can explicitly specify the interface
number by prefixing the interface name with the number and a colon
(":"). Example: 1:eth0.IN-BANDWIDTH (in_bandwidth) -
{-|bandwidth[:burst]|~bandwidth[:interval:decay_interval]}The incoming bandwidth of that interface.
Please note that you are not able to do traffic shaping on incoming
traffic, as the traffic is already received before you could do so.
But this allows you to define the maximum traffic allowed for this
interface in total, if the rate is exceeded, the packets are
dropped. You want this mainly if you have a DSL or Cable connection
to avoid queuing at your providers side.If you don't want any traffic to be dropped, set this to a
value to zero in which case Shorewall will not create an ingress
qdisc.Must be set to zero if the REDIRECTED INTERFACES column is
non-empty.The optional burst option was added in Shorewall 4.4.18. The
default burst is 10kb. A larger
burst can help make the
bandwidth more accurate; often for fast
lines, the enforced rate is well below the specified
bandwidth.What is described above creates a rate/burst policing filter.
Beginning with Shorewall 4.4.25, a rate-estimated policing filter
may be configured instead. Rate-estimated filters should be used
with Ethernet adapters that have Generic Receive Offload enabled by
default. See Shorewall FAQ
97a.To create a rate-estimated filter, precede the bandwidth with
a tilde ("~"). The optional interval and decay_interval determine
how often the rate is estimated and how many samples are retained
for estimating. Please see http://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txt
for details.OUT-BANDWIDTH (out_bandwidth) -
bandwidthThe outgoing bandwidth of that interface.
This is the maximum speed your connection can handle. It is also the
speed you can refer as "full" if you define the tc classes in shorewall6-tcclasses(5).
Outgoing traffic above this rate will be dropped.OPTIONS - {-|{classify|htb|hfsc|linklayer={ethernet|atm|adsl}|tsize=tsize|mtu=mtu|mpu=mpu|overhead=overhead}
,...} ― When specified, Shorewall will not
generate tc or Netfilter rules to classify traffic based on packet
marks. You must do all classification using CLASSIFY rules in shorewall-tcrules(5). - Use the Hierarchical Token
Bucket queuing discipline. This is the default. - Shorewall normally uses the
Hierarchical Token Bucket queuing discipline. When
is specified, the Hierarchical Fair
Service Curves discipline is used instead(see tc-hfsc
(7)).linklayer - Added in
Shorewall 4.5.6. Type of link (ethernet, atm, adsl). When specified,
causes scheduler packet size manipulation as described in tc-stab
(8). When this option is given, the following options may also be
given after it:
mtu=mtu - The
device MTU; default 2048 (will be rounded up to a power of
two)mpu=mpubytes -
Minimum packet size used in calculations. Smaller packets will be
rounded up to this sizetsize=tablesize
- Size table entries; default is 512overhead=overheadbytes
- Number of overhead bytes per packet.
REDIRECTED INTERFACES
(redirect) -
[interface[,interface]...]Added in Shorewall6-perl 4.1.6. May only be specified if the
interface in the INTERFACE column is an Intermediate Frame Block
(IFB) device. Causes packets that enter each listed interface to be
passed through the egress filters defined for this device, thus
providing a form of incoming traffic shaping. When this column is
non-empty, the classify option is
assumed.ExamplesExample 1:Suppose you are using PPP over Ethernet (DSL) and ppp0 is the
interface for this. The device has an outgoing bandwidth of 500kbit
and an incoming bandwidth of 6000kbit #INTERFACE IN-BANDWIDTH OUT-BANDWIDTH OPTIONS REDIRECTED
# INTERFACES
1:ppp0 6000kbit 500kbitFILES/etc/shorewall6/tcdevicesSee ALSOtc-hfsc (7)http://shorewall.net/traffic_shaping.htmhttp://ace-host.stuart.id.au/russell/files/tc/doc/estimators.txtshorewall6(8), shorewall6-accounting(5), shorewall6-actions(5),
shorewall6-blacklist(5), shorewall6-hosts(5), shorewall6-interfaces(5),
shorewall6-maclist(5), shorewall6-netmap(5),shorewall6-params(5),
shorewall6-policy(5), shorewall6-providers(5), shorewall6-rtrules(5),
shorewall6-routestopped(5), shorewall6-rules(5), shorewall6.conf(5),
shorewall6-secmarks(5), shorewall6-tcclasses(5), shorewall6-tcrules(5),
shorewall6-tos(5), shorewall6-tunnels(5), shorewall6-zones(5)
shorewall-docs-xml-4.5.21/PortKnocking.xml 0000644 0001750 0001750 00000014571 12222401136 020356 0 ustar teastep teastep
Port Knocking and Other Uses of 'Recent Match'TomEastep2005200620092013Thomas M. EastepPermission 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.The techniques described in this article were superceded in
Shorewall 4.5.19 with the introduction of Shorewall Events.The feature described in this article require 'Recent Match' in
your iptables and kernel. See the output of shorewall show
capabilities to see if you have that match.What is Port Knocking?Port knocking is a technique whereby attempting to connect to port A
enables access to port B from that same host. For the example on which
this article is based, see http://www.soloport.com/iptables.html
which should be considered to be part of this documentation.Implementing Port Knocking in ShorewallIn order to implement this solution, your iptables and kernel must
support the 'recent match' extension (see FAQ
42).In this example:Attempting to connect to port 1600 enables SSH access. Access is
enabled for 60 seconds.Attempting to connect to port 1601 disables SSH access (note
that in the article linked above, attempting to connect to port 1599
also disables access. This is an port scan defence as explained in the
article).To implement that approach:Add an action named SSHKnock (see the Action documentation). Leave the
action.SSHKnock file empty.Create /etc/shorewall/SSHKnock with the following
contents.use Shorewall::Chains;
if ( $level ) {
log_rule_limit( $level,
$chainref,
'SSHKnock',
'ACCEPT',
'',
$tag,
'add',
'-p tcp --dport 22 -m recent --rcheck --name SSH ' );
log_rule_limit( $level,
$chainref,
'SSHKnock',
'DROP',
'',
$tag,
'add',
'-p tcp ! --dport 22 ' );
}
add_rule( $chainref, '-p tcp --dport 22 -m recent --rcheck --seconds 60 --name SSH -j ACCEPT' );
add_rule( $chainref, '-p tcp --dport 1599 -m recent --name SSH --remove -j DROP' );
add_rule( $chainref, '-p tcp --dport 1600 -m recent --name SSH --set -j DROP' );
add_rule( $chainref, '-p tcp --dport 1601 -m recent --name SSH --remove -j DROP' );
1;Now if you want to protect SSH access to the firewall from the
Internet, add this rule in
/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST PORT(S)
SSHKnock net $FW tcp 22,1599,1600,1601If you want to log the DROPs and ACCEPTs done by SSHKnock, you
can just add a log level as in:#ACTION SOURCE DEST PROTO DEST PORT(S)
SSHKnock:info net $FW tcp 22,1599,1600,1601Assume that you forward port 22 from external IP address
206.124.146.178 to internal system 192.168.1.5. In
/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT- net loc:192.168.1.5 tcp 22 - 206.124.146.178
SSHKnock net $FW tcp 1599,1600,1601
SSHKnock net loc:192.168.1.5 tcp 22 - 206.124.146.178You can use SSHKnock with DNAT on earlier releases provided
that you omit the ORIGINAL DEST entry on the second SSHKnock rule.
This rule will be quite secure provided that you specify
'routefilter' on your external interface and have
NULL_ROUTE_RFC1918=Yes in
shorewall.conf.For another way to implement Port Knocking, see the Manual Chain documentation.Limiting Per-IP Connection RateThis information has been moved to the Actions article.
shorewall-docs-xml-4.5.21/Shorewall_and_Aliased_Interfaces.xml 0000644 0001750 0001750 00000035723 12222401136 024317 0 ustar teastep teastep
Shorewall and Aliased InterfacesTomEastep2001-2009Thomas M. EastepPermission 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.This article applies to Shorewall 4.3 and
later. If you are running a version of Shorewall earlier than Shorewall
4.3.5 then please see the documentation for that
release.BackgroundThe traditional net-tools contain a program called
ifconfig which is used to configure network devices.
ifconfig introduced the concept of aliased or
virtual interfaces. These virtual interfaces have
names of the form interface:integer (e.g., eth0:0) and ifconfig treats them more or
less like real interfaces.ifconfig[root@gateway root]# ifconfig eth0:0
eth0:0 Link encap:Ethernet HWaddr 02:00:08:3:FA:55
inet addr:206.124.146.178 Bcast:206.124.146.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11 Base address:0x2000
[root@gateway root]# The ifconfig utility is being gradually phased out in favor of the
ip utility which is part of the
iproute package. The ip utility does not use the
concept of aliases or virtual interfaces but rather treats additional
addresses on an interface as objects in their own right. The ip utility
does provide for interaction with ifconfig in that it allows addresses to
be labeled where these labels take the form of
ipconfig virtual interfaces.ip[root@gateway root]# ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc htb qlen 100
link/ether 02:00:08:e3:fa:55 brd ff:ff:ff:ff:ff:ff
inet 206.124.146.176/24 brd 206.124.146.255 scope global eth0
inet 206.124.146.178/24 brd 206.124.146.255 scope global secondary eth0:0
[root@gateway root]# One cannot type
ip addr show dev eth0:0 because
eth0:0 is a
label for a particular address rather than a device name.[root@gateway root]# ip addr show dev eth0:0
Device "eth0:0" does not exist.
[root@gateway root]#The iptables program doesn't support virtual interfaces in either
its -i or -o command options; as a
consequence, Shorewall does not allow them to be used in the
/etc/shorewall/interfaces file or anywhere else except as described in the
discussion below.Adding Addresses to InterfacesMost distributions have a facility for adding additional addresses
to interfaces. If you have already used your distribution's capability to
add your required addresses, you can skip this section.Shorewall provides facilities for automatically adding addresses to
interfaces as described in the following section. It is also easy to add
them yourself using the ip utility. The
above alias was added using:ip addr add 206.124.146.178/24 brd 206.124.146.255 dev eth0 label eth0:0You probably want to arrange to add these addresses when the device
is started rather than placing commands like the above in one of the
Shorewall extension scripts. For example, on RedHat systems, you can place
the commands in /sbin/ifup-local:#!/bin/sh
case $1 in
eth0)
/sbin/ip addr add 206.124.146.178 dev eth0 label eth0:0
;;
esacRedHat systems also allow adding such aliases from the network
administration GUI (which only works well if you have a graphical
environment on your firewall).On Debian and LEAF/Bering systems, it is as simple as adding the
command to the interface definition as follows:# Internet interface
auto eth0
iface eth0 inet static
address 206.124.146.176
netmask 255.255.255.0
gateway 206.124.146.254
up ip addr add 206.124.146.178/24 brd 206.124.146.255 dev eth0 label eth0:0So how do I handle more than one address on an interface?The answer depends on what you are trying to do with the interfaces.
In the sub-sections that follow, we'll take a look at common
scenarios.The examples in the following sub-sections assume that the local
network is 192.168.1.0/24.Separate RulesIf you need to make a rule for traffic to/from the firewall itself
that only applies to a particular IP address, simply qualify the $FW
zone with the IP address.allow SSH from net to eth0:0 above/etc/shorewall/rules#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net $FW:206.124.146.178 tcp 22DNATSuppose that I had set up eth0:0 as above and I wanted to port
forward from that virtual interface to a web server running in my local
zone at 192.168.1.3. That is accomplished by a single rule in the
/etc/shorewall/rules file:#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT(S) DEST
DNAT net loc:192.168.1.3 tcp 80 - 206.124.146.178 SNATIf you wanted to use eth0:0 as the IP address for outbound
connections from your local zone (eth1), then in
/etc/shorewall/masq:#INTERFACE SUBNET ADDRESS
eth0 192.168.1.0/24 206.124.146.178Similarly, you want SMTP traffic from local system 192.168.1.22 to
have source IP 206.124.146.178:#INTERFACE SUBNET ADDRESS PROTO DEST PORT(S)
eth0 192.168.1.22 206.124.146.178 tcp 25Shorewall can create the alias (additional address) for you if you
set ADD_SNAT_ALIASES=Yes in
/etc/shorewall/shorewall.conf.Addresses added by ADD_SNAT_ALIASES=Yes are deleted and re-added
during shorewall restart. As a consequence,
connections using those addresses may be severed.Shorewall can create the label (virtual interface)
so that you can see the created address using ifconfig. In addition to
setting ADD_SNAT_ALIASES=Yes, you specify the virtual interface name in
the INTERFACE column as follows./etc/shorewall/masq#INTERFACE SUBNET ADDRESS
eth0:0 192.168.1.0/24 206.124.146.178Shorewall
can also set up SNAT to round-robin over a range of IP addresses. To do
that, you specify a range of IP addresses in the ADDRESS column. If you
specify a label in the INTERFACE column, Shorewall will use that label
for the first address of the range and will increment the label by one
for each subsequent label./etc/shorewall/masq#INTERFACE SUBNET ADDRESS
eth0:0 192.168.1.0/24 206.124.146.178-206.124.146.180The above would create three IP addresses:eth0:0 = 206.124.146.178
eth0:1 = 206.124.146.179
eth0:2 = 206.124.146.180One-to-one NATIf you wanted to use one-to-one NAT to link eth0:0 with local address 192.168.1.3, you
would have the following in
/etc/shorewall/nat:#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0 192.168.1.3 no noShorewall can create the alias (additional address) for you if you
set ADD_IP_ALIASES=Yes in /etc/shorewall/shorewall.conf.Addresses added by ADD_IP_ALIASES=Yes are deleted and re-added
during shorewall restart. As a consequence,
connections using those addresses may be severed.Shorewall can create the label (virtual interface)
so that you can see the created address using ifconfig. In addition to
setting ADD_IP_ALIASES=Yes, you specify the virtual interface name in
the INTERFACE column as follows./etc/shorewall/nat#EXTERNAL INTERFACE INTERNAL ALL INTERFACES LOCAL
206.124.146.178 eth0:0 192.168.1.3 no noIn either case, to create rules in
/etc/shorewall/rules that pertain only to this NAT
pair, you simply qualify the local zone with the internal IP
address.You want to allow SSH from the net to 206.124.146.178 a.k.a.
192.168.1.3.#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT net loc:192.168.1.3 tcp 22MULTIPLE SUBNETSSometimes multiple IP addresses are used because there are
multiple subnetworks configured on a LAN segment. This technique does
not provide for any security between the subnetworks if the users of the
systems have administrative privileges because in that case, the users
can simply manipulate their system's routing table to bypass your
firewall/router. Nevertheless, there are cases where you simply want to
consider the LAN segment itself as a zone and allow your firewall/router
to route between the two subnetworks.Local interface eth1 interfaces to 192.168.1.0/24 and
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
eth1:0 is 192.168.20.254. You simply want your firewall to route
between these two subnetworks.In /etc/shorewall/zones:#ZONE TYPE OPTIONS
loc ipv4In /etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 - routebackIn /etc/shorewall/rules, simply specify
ACCEPT rules for the traffic that you want to permit.Local interface eth1 interfaces to 192.168.1.0/24 and
192.168.20.0/24. The primary IP address of eth1 is 192.168.1.254 and
eth1:0 is 192.168.20.254. You want to make these subnetworks into
separate zones and control the access between them (the users of the
systems do not have administrative privileges).In /etc/shorewall/zones:#ZONE TYPE OPTIONS
loc ipv4
loc2 ipv4In /etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
- eth1 - In /etc/shorewall/hosts:#ZONE HOSTS OPTIONS
loc eth1:192.168.1.0/24
loc2 eth1:192.168.20.0/24In /etc/shorewall/rules, simply specify
ACCEPT rules for the traffic that you want to permit.For more information on handling multiple networks through a
single interface, see Routing on One
Interface.Defining a Zone-per-AddressShorewall's support for Linux
Vservers can (mis-)used to create a separate zone per alias.
Note that this results in a partitioning of the firewall
zone. In this usage, you probably want to define an ACCEPT
policy between your vserver zones and the firewall zone.
shorewall-docs-xml-4.5.21/GettingStarted.xml 0000644 0001750 0001750 00000015204 12222401136 020670 0 ustar teastep teastep
Getting Started with ShorewallTomEastep2006200720102011Thomas M. EastepPermission 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.Do not attempt to install Shorewall on a
remote system. You are virtually assured to lock yourself
out.Please read this short article first.Introduction to
ShorewallNow, install Shorewall.Next, read the QuickStart Guide that is appropriate for your
configuration:If you just want to protect a system: (Requires
Shorewall 4.4.12-Beta3 or later)Universal configuration --
requires no configuration to protect a single system.If you have only one public IP
address:Standalone Linux System with a
single network interface (if you are running Shorewall 4.4.12 Beta 3 or
later, use the Universal
configuration instead).Two-interface Linux System
acting as a firewall/router for a small local networkThree-interface Linux
System acting as a firewall/router for a small local network and a
DMZ.If you have more than one public IP
address:The Shorewall Setup
Guide outlines the steps necessary to set up a firewall where
there are multiple public IP addresses involved or if you want to learn
more about Shorewall than is explained in the single-address guides
above.The following articles are also recommended reading for
newcomers.Configuration File
Basics
Man
PagesUsing MAC
Addresses in ShorewallComments in
configuration filesUsing Shell
VariablesAttach Comment
to Netfilter RulesUsing DNS
NamesLine
ContinuationComplementing
an IP address or SubnetINCLUDE
DirectiveIP Address
RangesPort
Numbers/Service NamesShorewall
Configurations (making a test
configuration)Port
Ranges
Operating
Shorewall and Shorewall Lite contains a lot of useful
operational hints.PPPPPPPS ( or, Paul's Principles for Practical Provision of Packet
Processing with Shorewall ) http://linuxman.wikispaces.com/PPPPPPS
shorewall-docs-xml-4.5.21/Shorewall-perl.xml 0000644 0001750 0001750 00000137342 12222401136 020650 0 ustar teastep teastep
Shorewall-perlTomEastep200720092012Thomas M. EastepPermission 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.Shorewall-perl - What is it?Shorewall-perl was released as a companion product to Shorewall in
Shorewall 4.0.0.Shorewall-perl contained a re-implementation of the Shorewall
compiler written in Perl. The advantages of using Shorewall-perl over
Shorewall-shell (the shell-based compiler included in earlier Shorewall
3.x releases) were:The Shorewall-perl compiler was much faster.The script generated by the compiler used
iptables-restore to instantiate the Netfilter
configuration. So it ran much faster than the script generated by the
Shorewall-shell compiler and did not stop new connections during
shorewall restart.The Shorewall-perl compiler did more thorough checking of the
configuration than the Shorewall-shell compiler did.The error messages produced by the compiler were better, more
consistent and always included the file name and line number where the
error was detected.Going forward, the Shorewall-perl compiler got all enhancements;
the Shorewall-shell compilerl only got those enhancements that were
easy to retrofit.Beginning with Shorewall 4.3.5, Shorewall-perl is an integral part
of Shorewall and support for Shorewall-shell has been discontinued.Shorewall-perl - The down sideWhile there are significant advantages to using Shorewall-perl,
there are also disadvantages.IncompatibilitiesThere are a number of incompatibilities between the Shorewall-perl
compiler and the earlier one.The Perl-based compiler requires multiport match in your
kernel and iptables.BRIDGING=Yes is not supported. The kernel code necessary to
support this option was removed in Linux kernel 2.6.20. Alternative bridge support
is provided by Shorewall-perl.DYNAMIC_ZONES=Yes is not supported in Shorewall-perl 4.2.
Use an ipset to define your
dytnamic zones. In Shorewall 4.4, dynamic zone support based on
ipsets was added to Shorewall.The BROADCAST column in the interfaces file is essentially
unused if your kernel/iptables has Address Type Match support. If
that support is present and you enter anything in this column but
'-' or 'detect', you will receive a warning.The 'refresh' command is now similar to restart with the
exceptions that:The command fails if Shorewall is not running.A directory name cannot be specified in the
command.The refresh command does not alter the Netfilter
configuration except for the static blacklist (it also refreshes
the mangle table, beginning with Shorewall 4.2.0).With the shell-based compiler, extension scripts were copied
into the compiled script and executed at run-time. In many cases,
this approach doesn't work with Shorewall Perl because (almost) the
entire rule set is built by the compiler. As a result,
Shorewall-perl runs some extension scripts at compile-time rather
than at run-time. Because the compiler is written in Perl, your
extension scripts from earlier versions will no longer work.The following table summarizes when the various extension
scripts are run:Compile-time (Must be written
in Perl)Run-timeEliminatedinitdoneclearcontinuemacloginitPer-chain (including those associated with
actions)startstartedstopstoppedtcclearCompile-time extension scripts are executed using the Perl
'eval `cat <file>`' mechanism. Be sure that each script
returns a 'true' value; otherwise, the Shorewall-perl compiler will
assume that the script failed and will abort the compilation.When a script is invoked, the $chainref scalar variable will usually hold a
reference to a chain table entry.$chainref->{name}
contains the name of the chain$chainref->{table}
holds the table nameTo add a rule to the chain:add_rule $chainref,
the-ruleWherethe rule is a scalar argument
holding the rule text. Do not include "-A
chain-name"Example:add_rule $chainref, '-j ACCEPT';To insert a rule into the chain:insert_rule $chainref, rulenum,
the-ruleThe log_rule_limit function works like it does in the shell
compiler with three exceptions:You pass the chain reference rather than the name of the
chain.The commands are 'add' and 'insert' rather than '-A' and
'-I'.There is only a single "pass as-is to iptables" argument
(so you must quote that part)Example: log_rule_limit
'info' ,
$chainref ,
$chainref->{name},
'DROP' ,
'', #Limit
'' , #Log tag
'add'
'-p tcp '; Here is an example of an actual initdone script used with
Shorewall 3.4:run_iptables -t mangle -I PREROUTING -p esp -j MARK --set-mark 0x50
run_iptables -t filter -I INPUT -p udp --dport 1701 -m mark --mark 0x50 -j ACCEPT
run_iptables -t filter -I OUTPUT -p udp --sport 1701 -j ACCEPT
Here is the corresponding script used with
Shorewall-perl:use Shorewall::Chains;
insert_rule $mangle_table->{PREROUTING}, 1, "-p esp -j MARK --set-mark 0x50";
insert_rule $filter_table->{INPUT}, 1, "-p udp --dport 1701 -m mark --mark 0x50 -j ACCEPT";
insert_rule $filter_table->{OUTPUT}, 1, "-p udp --sport 1701 -j ACCEPT";
1;The initdone script is unique because the $chainref variable
is not set before the script is called. The above script illustrates
how the $mangle_table, $filter_table, and $nat_table references can
be used to add or insert rules in arbitrary chains.The /etc/shorewall/tos file now has
zone-independent SOURCE and DEST columns as do all other files
except the rules and policy files.The SOURCE column may be one of the following:[all:]<address>[,...][all:]<interface>[:<address>[,...]]$FW[:<address>[,...]]The DEST column may be one of the following:[all:]<address>[,...][all:]<interface>[:<address>[,...]]This is a permanent change. The old zone-based rules have
never worked right and this is a good time to replace them. I've
tried to make the new syntax cover the most common cases without
requiring change to existing files. In particular, it will handle
the tos file released with Shorewall 1.4 and earlier.Shorewall-perl insists that ipset names begin with a letter
and be composed of alphanumeric characters and underscores (_). When
used in a Shorewall configuration file, the name must be preceded by
a plus sign (+) as with the shell-based compiler.From Shorewall-perl 4.0.0 - Shorewall 4.4.5, Shorewall was out
of the ipset load/reload business with the exception of ipsets used
for dynamic zones:
With scripts generated by the Perl-based Compiler, the
Netfilter rule set is never cleared. That means that there is no
opportunity for Shorewall to load/reload your ipsets since that
cannot be done while there are any current rules using
ipsets.So:Your ipsets must be loaded before Shorewall starts. You
are free to try to do that with the following code in
/etc/shorewall/init (it works for me; your mileage
may vary):if [ "$COMMAND" = start ]; then
ipset -U :all: :all:
ipset -U :all: :default:
ipset -F
ipset -X
ipset -R < /etc/shorewall/ipsets
fiThe file /etc/shorewall/ipsets will
normally be produced using the ipset -S
command. I have this in my
/etc/shorewall/stop file:if ipset -S > /etc/shorewall/ipsets.tmp; then
mv -f /etc/shorewall/ipsets /etc/shorewall/ipsets.bak
mv /etc/shorewall/ipsets.tmp /etc/shorewall/ipsets
fiThe above extension scripts will work most of the time
but will fail in a shorewall stop -
shorewall start sequence if you use ipsets
in your routestopped file (see below).Your ipsets may not be reloaded until Shorewall is
stopped or cleared.If you specify ipsets in your routestopped file then
Shorewall must be cleared in order to reload your
ipsets.As a consequence, scripts generated by the Perl-based
compiler will ignore /etc/shorewall/ipsets
and will issue a warning if you set SAVE_IPSETS=Yes in
shorewall.conf.
Beginning with Shorewall 4.4.6 (and 4.5.3), SAVE_IPSETS=Yes is
once again supported. See shorewall.conf(5).Because the configuration files (with the exception of
/etc/shorewall/params) are now processed by the
Shorewall-perl compiler rather than by the shell, only the basic
forms of Shell expansion ($variable and ${variable}) are supported.
The more exotic forms such as ${variable:=default} are not
supported. Both variables defined in /etc/shorewall/params and
environmental variables (exported by the shell) can be used in
configuration files.USE_ACTIONS=No is not supported. That option is intended to
minimize Shorewall's footprint in embedded applications. As a
consequence, Default Macros are not supported by
Shorewall-perl.DELAYBLACKLISTLOAD=Yes is not supported. The entire rule set
is atomically loaded with one execution of
iptables-restore.MAPOLDACTIONS=Yes is not supported. People should have
converted to using macros by now.The pre Shorewall-3.0 format of the zones file is not
supported (IPSECFILE=ipsec); neither is the
/etc/shorewall/ipsec file.BLACKLISTNEWONLY=No is not permitted with FASTACCEPT=Yes. This
combination doesn't work in previous versions of Shorewall so the
Perl-based compiler simply rejects it.Shorewall-perl has a single rule generator that is used for
all rule-oriented files. This implementation enforces consistency of
syntax between files.With shorewall-shell, there is a special syntax in the SOURCE
column of /etc/shorewall/masq to designate "all traffic entering the
firewall on this interface except...".Example:#INTERFACE SOURCE ADDRESSES
eth0 eth1!192.168.4.9 ...Shorewall-perl
uses syntax that is consistent with the rest of
Shorewall:#INTERFACE SOURCE ADDRESSES
eth0 eth1:!192.168.4.9 ...The 'allowoutUPnP' built-in action is no longer supported. In
kernel 2.6.14, the Netfilter team have removed support for '-m owner
--owner-cmd' which that action depended on.The PKTTYPE option is ignored by Shorewall-perl.
Shorewall-perl will use Address type match if it is available;
otherwise, it will behave as if PKTTYPE=No had been
specified.Shorewall-perl detects dead policy file entries that result
when an entry is masked by an earlier more general entry.Example:#SOURCE DEST POLICY LOG LEVEL
all all REJECT info
loc net ACCEPTShorewall-shell silently accepts the above even though the
loc->net policy is useless. Shorewall-perl generates a fatal
compilation error.In the SOURCE column of the rules file, when an interface name
is followed by a list of IP addresses, the behavior of
Shorewall-perl differs from that of Shorewall-shell.Example:#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT loc:eth0:192.168.1.3,192.168.1.5 $FW tcp 22With
Shorewall-shell, this rule accepts SSH connection to the firewall
from 192.168.1.3 through eth0 or from 192.168.1.5 through any
interface. With Shorewall-perl, the rule accepts SSH connections
through eth0 from 192.168.1.3 and through eth0 from 192.168.1.5.
Shorewall-shell supports this syntax that gives the same result as
Shorewall-perl.#ACTION SOURCE DEST PROTO DEST
# PORT(S)
ACCEPT loc:eth0:192.168.1.3,eth0:192.168.1.5 $fw tcp 22
Shorewall-perl does not support this alternative syntax.Shorewall-perl gives a warning if a zone name is entered in
the DEST column of a nonat rule. Nonat rules
include:DNAT-REDIRECT-NONATSo rather than this:#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT- net loc:192.168.1.3 tcp 21you instead want:#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT- net 192.168.1.3 tcp 21Supplying an interface name in the SOURCE column of
/etc/shorewall/masq is deprecated as of Shorewall 4.4. Entering the
name of an interface there will result in a compile-time
warning:WARNING: Using an interface as the masq SOURCE requires the
interface to be up and configured when Shorewall
starts/restartsTo avoid this warning, replace interface names by the
corresponding network() in CIDR format (e.g.,
192.168.144.0/24).Dependence on PerlShorewall-perl is dependent on Perl which has a large disk
footprint. This makes Shorewall-perl less desirable in an embedded
environment. The best way to work around this limitation is to install
Shorewall-perl on an administrative system and employ Shorewall-lite on
your embedded systems. Shorewall-perl will run on Windows under Cygwin and on an Apple MacIntosh running OS X.
Install from a shell prompt using the
install.sh script.Installing Shorewall Version 4.0 or 4.2Shorewall 4.2 contains six packages, four of which are also included
in Shorewall 4.0:Shorewall-shell - the old
shell-based compiler and related components.Shorewall-perl - the new
Perl-based compiler.Shorewall-common - the part of
Shorewall common to both compilers.Shorewall-lite- same as the 3.4
version of Shorewall Lite. Can run scripts generated by either
Shorewall-perl or Shorewall-shell.Shorewall6 - The utilities for
creating and operating an Ipv6 firewall. Requires Shorewall-perl and
Shorewall-common. Introduced in Shorewall 4.2.4.Shorewall6-lite - Ipv6
equivalent of Shorewall Lite. Can run scripts generated by
Shoreall-perl 4.2.4 and later.If you upgrade to Shorewall Version 4.0 or 4.2, you must install
Shorewall-shell and/or Shorewall-perl; in fact, if you are using the
tarball for your installation, you must install Shorewall-shell and/or
Shorewall-perl before you upgrade
Shorewall. See the upgrade issues
for details.Compiler Selection (Shorewall 4.0-4.2)If you only install one compiler, then that compiler will be
used.If you install both compilers, then the compiler actually used for
IPv4 depends on the SHOREWALL_COMPILER setting in
shorewall.conf.The value of this new option can be either 'perl' or 'shell'.If you add 'SHOREWALL_COMPILER=perl' to
/etc/shorewall/shorewall.conf then by default, the
new compiler will be used on the system. If you add it to
shorewall.conf in a separate directory (such as a
Shorewall-lite export directory) then the new compiler will only be used
when you compile from that directory.If you only install one compiler, it is suggested that you do not
set SHOREWALL_COMPILER.If both compilers are installed, you can select the compiler to use
on the command line using the 'C option:'-C shell' means use the shell compiler'-C perl' means use the perl compilerThe -C option overrides the setting in
shorewall.conf.Example:shorewall restart -C perlWhen the Shorewall-perl compiler has been selected, the
params file is processed using the shell
option which causes all variables set within the file
to be exported automatically by the shell. The Shorewall-perl compiler
uses the current environmental variables to perform variable expansion
within the other Shorewall configuration files.The Shorewall Perl ModulesIn Shorewall 4.4 and later, Shorewall's Perl modules are installed
by default in /usr/share/shorewall/Shorewall and the names of the packages
are of the form Shorewall::name. So by using this
directiveuse lib '/usr/share/shorewall';You can then load the modules via normal Perl use statements./usr/share/shorewall/compiler.plWhile the compiler is normally run indirectly using
/sbin/shorewall, it can be run directly as well.compiler.pl [ option ... ] [ filename ]If a filename is given, then the
configuration will be compiled and the output placed in the named file.
If filename is not given, then the configuration
will simply be syntax checked.Options are:-v<verbosity>--verbosity=<verbosity>The <verbosity> is a number
between 0 and 2 and corresponds to the VERBOSITY setting in
shorewall.conf. This setting controls the verbosity
of the compiler itself.The VERBOSITY setting in the
shorewall.conf file read by the compiler will
determine the default verbosity for the compiled program.-e--exportIf given, the configuration will be compiled for export
to another system.-d
<directory>--directory=<directory>If this option is omitted, the configuration in
/etc/shorewall is compiled/checked. Otherwise, the configuration in the
named directory will be compiled/checked.-t--timestampIf given, each progress message issued by the compiler
and by the compiled program will be timestamped.--debugIf given, when a warning or error message is issued, it
is supplemented with a stack trace. Requires the Carp Perl
module.--refresh=<chainlist>If given, the compiled script's 'refresh' command will
refresh the chains in the comma-separated
<chainlist> rather than
'blacklst'.--log=<logfile>If given, compiler will log to this file provider that
--log_verbosity is > -1.--log_verbosity=-1|0|1|2If given, controls the verbosity of logging to the log specified
by the --log parameter.-f=4|6--family=4|6Specifies whether an IPv4 or an IPv6 firewall is to be
created.--previewAdded in Shorewall 4.4.6. If no filename is given, this option
causes the generated input to iptables-input to be displayed on standard
output.-c--confessAdded in Shorewall 4.4.20. Causes error and warning messages to
include a Perl stack trace. Useful for finding the place in the code
where the message is generated.-u--updateAdded in Shorewall 4.4.21. Causes the .conf file to be updated
(shorewall update command).-a--annotateAdded in Shorewall 4.4.21. Causes the updated .conf file to be
annotated with documentation. Ignored unless --update is also specified.--convertAdded in Shorewall 4.4.26. Causes the compiler to convert an
existing blacklist file into an
equivalent blrules
file.--config_path=path[:path]...Added in Shorewall 4.4.26. Search path for configuration
files.--shorewallrc=pathAdded in Shorewall 4.5.1. Specifies the location of the
shorewallrc file.Example (compiles the configuration in the current directory
generating a script named 'firewall' and using VERBOSITY
2)./usr/share/shorewall/compiler.pl -v 2 -d . firewallPrior to Shorewall 4.4.19, the Perl-based compiler did not
process /etc/shorewall/params. To include
definitions in that file, you would need to do something like the
following:. /usr/share/shorewall/lib.base # In case /etc/shorewall/params does INCLUDE
set -a # Export all variables set in /etc/shorewall/params
. /etc/shorewall/params
set +a
/usr/share/compiler.pl ...Shorewall::CompilerTo avoid a proliferation of parameters to
Shorewall::Compiler::compile(), that function uses named parameters.
Parameter names are:script ('object' is also accepted but deprecated)Output script file. If omitted or '', the configuration is
syntax checked.directoryDirectory. If omitted or '', configuration files are located
using CONFIG_PATH. Otherwise, the directory named by this
parameter is searched first.verbosityVerbosity; range -1 to 2timestamp0|1 -- timestamp messages.debug0|1 -- include stack trace in warning/error messages.export0|1 -- compile for export.chainsList of chains to be reloaded by 'refresh'logFile to log compiler messages to.log_verbosityLog Verbosity; range -1 to 2.familyAddress family: 4 or 6preview0 or 1. Added in Shorewall 4.4.6. A value of 1 causes the
generated ruleset to be printed to standard output.confess0 or 1. Added in Shorewall 4.4.20. A value of 1 causes error
and warning messages to include a Perl stack trace. Useful for
finding the place in the code where the message is
generated.update0 or 1. Added in Shorewall 4.4.21. A value of 1 causes the
.conf file to be updated (shorewall update
command).config_pathList of pathnames separated by ':' or ''. Added in Shorewall
4.4.26. The list of directories where the compiler is to search
for input files.shorewallrcPathname of the global shorewallrc file. Added in Shorewall
4.5.1.shorewallrc1Pathname of the export shorewallrc file. Added in Shorewall
4.5.8.Those parameters that are supplied must have defined values.
Defaults are: script: '' ('check' command)directory: ''verbosity: 1timestamp: 0debug: 0export: 0chains: ''log: ''log_verbosity: -1family: 4preview: 0confess: 0update: 0config_path: Contents of
/var/lib/shorewall/configpath or
/var/lib/shorewall6/configpath depending on the
setting of family.shorewallrc: ''.Example: use lib '/usr/share/shorewall/';
use Shorewall::Compiler;
compiler( script => '/root/firewall', log => '/root/compile.log', log_verbosity => 2 ); Shorewall::Chainsuse lib '/usr/share/shorewall';
use Shorewall::Chains;
my $chainref1 = chain_new $table, $name1;
add_rule $chainref1, $rule;
insert_rule $chainref1, $ordinal, $rule;
my $chainref2 = new_manual_chain $name3;
my $chainref3 = ensure_manual_chain $name;
log_rule_limit $level, $chainref3, $name, $disposition, $limit, $tag, $command, $predicates;
my $chainref4 = $chain_table{$table}{$name};
my $chainref5 = $nat_table{$name};
my $chainref6 = $mangle_table{$name};
my $chainref7 = $filter_table{$name};Shorewall::Chains is
Shorewall-perl's interface to iptables/netfilter. It creates a
chain table (%chain_table) which is populated as
the various tables are processed. The table (actually a hash) is
two-dimensional with the first dimension being the Netfilter table name
(raw, mangle, nat and filter) and the second dimension being the chain
name. Each table is a hash reference -- the hash defines the attributes
of the chain. See the large comment at the beginning of the module
(/usr/share/shorewall-perl/Shorewall/Chains.pm).The module export the chain table along with three hash references
into the table:$nat_tableReference to the 'nat' portion of the table
($chain_table{nat}). This is a hash whose key is the chain name.
This variable is not set when an IPv6 firewall is being
created.$mangle_tableReference to the 'mangle' portion of the table
($chain_table{mangle}). This is a hash whose key is the chain
name.$filterReference to the 'filter' portion of the table
($chain_table{filter}). This is a hash whose key is the chain
name.You can create a new chain in any of the tables using new_chain(). Arguments to the function
are:$table'nat', 'mangle', or 'filter'.$nameName of the chain to create.The function creates a hash at $chain_table{$table}{$name} and
populates the hash with default values. A reference to the hash is
returned.Each chain table entry includes a list of rules to be added to the
chain. These rules are written to the iptables-restore input file when
the resulting script is executed. To append a rule to that list, call
add_rule(). Arguments are:$chainrefA reference to the chain table entry.$ruleThe rule to add. Do not include the leading '-A ' in this
argument -- it will be supplied by the function.To insert a rule into that list, call insert_rule(). Arguments are:$chainrefA reference to the chain table entry.$ordinalThe position of the inserted rule in the list. A value of 1
inserts the rule at the head of the list, a value of 2 places the
rule second in the list, and so on.$ruleThe rule to add. Do not include the leading '-I' in this
argument -- it will be supplied by the function.To create a manual chain,
use the new_manual_chain() function. The function accepts a single
argument which is the name of the chain. The function returns a
reference to the resulting chain table entry.A companion function, ensure_manual_chain(), can be called when a
manual chain of the desired name may have already been created. If a
manual chain table entry with the passed name already exists, a
reference to the chain table entry is returned. Otherwise, the function
calls new_manual_chain() and returns
the result.To create a logging rule, call log_rule_limit(). Arguments are:$levelThe log level. May be specified as a name or as a
number.$chainrefChain table reference for the chain to which the rule is to
be added.$nameThe chain name to be reported in the log message (see
LOGFORMAT in shorewall.conf(5)).$dispositionThe disposition to be reported in the log message (see
LOGFORMAT in shorewall.conf(5)).$limitRate limiting match. If an empty string is passed, the
LOGRATE/LOGBURST (shorewall.conf(5)) is
used.$tagLog tag.$commandIf 'add', append the log rule to the chain. If 'insert',
then insert the rule at the beginning of the chain.$predicatesAny additional matches that are to be applied to the
rule.Shorewall::Configuse lib '/usr/share/shorewall';
use Shorewall::Config;
warning message "This entry is bogus";
fatal_error "You have made an error";
progress_message "This will only be seen if VERBOSITY >= 2";
progress_message2 "This will only be seen if VERBOSITY >= 1";
progress_message3 "This will be seen unless VERBOSITY < 0";
The shorewall() function may
be optionally included:use lib '/usr/share/shorewall';
use Shorewall::Config qw/shorewall/;
shorewall $config_file_entry;The Shorewall::Config module
provides basic services to Shorewall-perl. By default, it exports the
functions that produce progress messages and warning/error
messages.To issue a warning message, call warning_message(). The single argument describes
the warning.To raise a fatal error, call fatal_error(). Again, the single argument
described the error.In both cases, the function will augment the warning/error with
the current configuration file and line number, if any. fatal_error() raised an exception via either
confess() or die(), depending on whether the debugging stack
trace is enabled or not..The three 'progress message' functions conditionally produce
output depending on the current verbosity setting.The shorewall() function is used
by embedded Perl
scripts to generate entries to be included in the current
configuration file.
shorewall-docs-xml-4.5.21/MultiISP_ru.xml 0000644 0001750 0001750 00000151624 12222401136 020123 0 ustar teastep teastep
Shorewall и подключение к Internet по нескольким каналамTomEastep200520062007Thomas M. Eastep2007Russian Translation: Grigory MokhinЭтот документ разрешается копировать, распространять и/или изменять при выполнении условий лицензии GNU Free Documentation License версии 1.2 или более поздней, опубликованной Free Software Foundation; без неизменяемых разделов, без текста на верхней обложке, без текста на нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation License.Вы должны установить современный дистрибутив, который обновляется поставщиком, прежде чем пытаться настроить работу в этом режиме. Старые дистрибутивы не удовлетворяют минимальным требованиям, и вам потребуется перекомпилировать iptables, ядро и прочее программное обеспечение в системе. Если вы проигнорируете этот совет, то не рассчитывайте, что кто-либо сможет вам помочь..Чтение только документации Shorewall не будет достаточным для понимания раскрываемых здесь тем. Shorewall упрощает работу с iptables, но разработчики Shorewall не имеют достаточных ресурсов, чтобы учить вас основам управляемой маршрутизации в Linux (равно как и пособие по вождению комбайна не учит правильно выращивать пшеницу). Скорее всего вам потребуется обратиться к следующим дополнительным источникам:LARTC HOWTO: http://www.lartc.orgВывод команды man ipВывод команд ip route help и ip rule helpПоддержка нескольких соединений с InternetНачиная с версии 2.3.2 в Shorewall реализована ограниченная поддержка нескольких соединений с Internet. Ниже описаны существующие ограничения:Используется статическая конфигурация маршрутов. Поэтому не предусмотрены меры по защите от сбоя какого-либо из каналов связи с провайдером.Изменения маршрутизации и очистка кэша маршрутов осуществляются при запуске и при перезапуске Shorewall (если не указана опция "-n" для shorewall restart). Вообще говоря, в идеальном случае перезапуск пакетного фильтра никак не должен влиять на маршрутизацию.В версиях Shorewall ниже 3.4.0 маршруты и правила маршрутизации, добавляемые при запуске, не удалялись полностью в ходе выполнения команд shorewall stop, shorewall clear или shorewall restart.ОбзорПредположим, что система, в которой работает файрвол, подключена к двум провайдерам по двум интерфейсам Ethernet, как показано на рисунке.eth0 подключен к ISP1. IP-адрес eth0 - это 206.124.146.176, и шлюз провайдера имеет IP-адрес 206.124.146.254.eth1 подключен к ISP2. IP-адрес eth1 - это 130.252.99.27, и шлюз провайдера имеет IP-адрес 130.252.99.254.eth2 подключен к локальной сети. У него может быть любой IP-адрес.Все эти провайдеры должны быть перечислены в файле /etc/shorewall/providers.В записях в файле /etc/shorewall/providers можно указать, что для исходящих соединений должно быть включено распределение нагрузки по двум каналам связи с провайдерами. В записях в файле /etc/shorewall/tcrules можно указать, что некоторые исходящие соединения должны использовать определённый канал провайдера. Правила в файле /etc/shorewall/tcrules необязательны для того, чтобы настройка /etc/shorewall/providers работала, но необходимо указать уникальное значение MARK для каждого из провайдеров, чтобы Shorewall настроил правила маркировки.Если задать опцию track в файле /etc/shorewall/providers, то соединения из Internet будут автоматически маршрутизироваться обратно через правильный интерфейс на соответствующий шлюз провайдера. Это будет работать как в том случае, когда соединение обрабатывается самим файрволом, так и для соединений, маршрутизируемых или пробрасываемых к системам позади файрвола.Shorewall настраивает маршрутизацию и обновляет файл /etc/iproute2/rt_tables, включая в него имена таблиц и их номера.При этом используются функции маркировки пакетов для управления маршрутизацией. Как следствие этого возникают ограничения на записи в файле /etc/shorewall/tcrules:Маркировка пакетов для целей управления трафиком не может осуществляться в цепочке PREROUTING для соединений с участием провайдеров, для которых задана опция 'track' (см. далее).Нельзя использовать опции SAVE или RESTORE.Нельзя использовать маркировку соединений.Файл /etc/shorewall/providers может также использоваться в других сценариях маршрутизации. В документации по работе с Squid приведены примеры.Файл /etc/shorewall/providersДалее описаны поля этого файла. Как и везде в файлах конфигурации Shorewall, укажите в поле для столбца "-", если не требуется задавать никакое значение.NAMEИмя провайдера. Должно начинаться с буквы и состоять из букв и цифр. Имя провайдера становится именем сгенерированной таблицы маршрутизации для этого провайдера.NUMBERЧисло от 1 до 252. Оно будет номером таблицы маршрутизации для сгенерированной таблицы для этого провайдера.MARKМетка, применяемая в файле /etc/shorewall/tcrules для направления пакетов через этого провайдера. Shorewall также помечает этой меткой соединения, которые входят через этого провайдера, и восстанавливает метку пакета в цепочке PREROUTING. Метка должна быть целым числом от 1 до 255.Начиная с Shorewall версии 3.2.0 Beta 6, можно задать опцию HIGH_ROUTE_MARKS=Yes в файле /etc/shorewall/shorewall.conf. Это позволяет решить следующие задачи:Использовать метки пакетов для управления трафиком, при условии что эти метки присваиваются в цепочке FORWARD.Использовать значения меток > 255 для меток провайдера. Эти метки должны быть кратными 256 в диапазоне 256-65280 (в 16-ричном представлении 0x100 - 0xFF00, с нулевыми младшими 8 битами).DUPLICATEИмя или номер таблицы маршрутизации, которая будет продублирована. Можно указать 'main' или имя или номер ранее объявленного провайдера. Для большинства приложений здесь достаточно будет указать 'main'.INTERFACEИмя интерфейса канала связи с провайдером.В реализации поддержки нескольких подключений с провайдерами Shorewall предполагается, что каждый провайдер подключен к собственному интерфейсу.GATEWAYIP-адрес шлюза провайдера.Здесь можно указать detect для автоматического определения IP-адреса шлюза.Совет:"detect" следует указывать в том случае, если интерфейс из поля INTERFACE настраивается динамически по DHCP.OPTIONSСписок параметров через запятую, описанных ниже:trackЕсли эта опция включена, то будут отслеживаться соединения, ВХОДЯЩИЕ через этот интерфейс, чтобы ответы могли маршрутизироваться обратно через этот же интерфейс.Укажите 'track', если через этого провайдера к локальным серверам будут обращаться хосты из Internet. Вместе с 'track' всегда следует указывать опцию 'balance'.Для работы с этой функцией ядро и iptables должны поддерживать цель CONNMARK и сравнение connmark. Расширение цели ROUTE не требуется.В iptables 1.3.1 есть ошибка в реализации CONNMARK и iptables-save/iptables-restore. Поэтому при настройке нескольких провайдеров команда shorewall restore может быть не выполнена. Если это имеет место, примените исправление iptables, доступное по адресу http://shorewall.net/pub/shorewall/contrib/iptables/CONNMARK.diff.Если используется файл /etc/shorewall/providers для настройки нескольких соединений с Internet, укажите опцию 'track', даже если в ней нет необходимости. Она помогает поддерживать длительные соединения, в которых могут быть долгие периоды отсутствия трафика.balanceОпция 'balance' позволяет распределять нагрузку исходящих потоков между несколькими провайдерами. Распределение нагрузки не будет идеальным, поскольку оно осуществляется посредством маршрутов, а маршруты кэшируются. При этом маршрут к хостам, к которым часто обращаются пользователи, будет проходить всегда через одного и того же провайдера.По умолчанию всем провайдерам присваивается одинаковый вес (1). Вес конкретного провайдера можно изменить опцией balance с "=" и весом (например, balance=2). Веса отражают относительную пропускную способность каналов связи с провайдером. Они должны быть небольшими числами, потому что ядро создает дополнительные маршруты для каждого приращения веса. Если файл /etc/shorewall/providers используется для настройки нескольких соединений с Internet, укажите опцию 'balance', даже если в ней нет необходимости. Для направления всего трафика через какого-либо определенного провайдера можно использовать файл /etc/shorewall/tcrules. Если вы проигнорируете этот совет, то прочитайте FAQ 57 и FAQ 58.Если указана опция 'balance', но весь трафик по-прежнему идёт через одного провайдера, то причина этого может состоять в том, что ядро не собрано с опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED=n. У некоторых пользователей пересборка ядра с этой опцией помогла устранить неполадку.Эта неполадка присутствует в ядре SuSE 10.0, и согласно в этом случае может возникать критическая ошибка ядра. В SUSE 10.1 и SLES 10 опция CONFIG_IP_ROUTE_MULTIPATH_CACHED=n включена по умолчанию. Источник неполадки описан здесь: несовместимость между исправлениями от LARTC и опцией CONFIG_IP_ROUTE_MULTIPATH_CACHED.looseНе включать правила маршрутизации, которые принудительно направляют через данный интерфейс трафик, исходный IP-адрес которого совпадает с адресом интерфейса канала с провайдером. Эта опция полезна для определения провайдеров, которые должны использоваться только при наличии соответствующей метки пакета. Эту опцию нельзя указывать совместно с balance.optional (начиная с Shorewall 3.2.2)Shorewall определит, работает ли этот интерфейс и настроен ли его IP-адрес. Если он не настроен, то будет показано предупреждение, а сам провайдер не будет включен.Параметр 'optional' предназначен для определения состояния интерфейсов, которые могли бы вызвать сбой команды shorewall start или shorewall restart - однако даже если интерфейс находится в состоянии, в котором Shorewall может [пере]запуститься без ошибок, это не означает, что трафик может с гарантией проходить через этот интерфейс.Для тех, кто окончательно запутался в том, что такое track и balance:track управляет входящими соединениями.balance управляет исходящими соединениями.COPYЕсли в поле DUPLICATE указана существующая таблица, то Shorewall копирует все маршруты, проходящие через интерфейс, указанный в столбце INTERFACE, а также через интерфейс, указанный в этом поле. В этом поле следует указать все интерфейсы в системе файрвола, исключая интерфейсы Internet, указанные в поле INTERFACE этого файла.Какие функции выполняет запись в файле providersДобавление записи в файле providers приводит к созданию альтернативной таблицы маршрутизации. Помимо этого:Если не указана опция loose, то создается правило ip для каждого IP-адреса из поля INTERFACE, которое обеспечивает маршрутизацию трафика с этого адреса через соответствующую таблицу маршрутизации.Если указана опция track, то соединения, для которых хотя бы один пакет прошел на интерфейс, указанный в поле INTERFACE, получат метку соединения, заданную в поле MARK. В цепочке PREROUTING метка пакетов, имеющих метку соединения, будет задана равной метке соединения, и такие помеченные пакеты не будут подчиняться правилам для цепочки PREROUTING, заданным в файле /etc/shorewall/tcrules. Это обеспечивает маршрутизацию через правильный интерфейс для входящих соединений.Если указана опция balance, то Shorewall заменит маршрут по умолчанию с весом 100 в таблице маршрутизации 'main' маршрутом с распределением нагрузки между шлюзами, для которых опция balance включена. Поэтому, если вы настраиваете маршруты по умолчанию, то укажите их вес меньше, чем 100, иначе маршрут, добавленный Shorewall, не будет иметь силы.Больше эти записи не делают ничего. Вспомните основной принцип, описанный в документации по маршрутизации Shorewall:Маршрутизация отвечает за то, куда направляются пакеты.После того, как маршрут пакета определён, файрвол (Shorewall) определяет, разрешить ли отправку пакета по его маршруту.Итак, если вы хотите направить трафик через определённого провайдера, то необходимо пометить этот трафик значением MARK провайдера в файле /etc/shorewall/tcrules и пометить пакет в цепочке PREROUTING; другим способом будет указание соответствующих правил в файле /etc/shorewall/rtrules.В Shorewall версий ниже 3.4.0 записи из файла /etc/shorewall/providers необратимо изменяют маршрутизацию системы, то есть эти изменения не отменяются при вызове команды shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива.Дополнительные замечания:Влияние изменений, вносимых Shorewall в таблицу маршрутизации, можно уменьшить, указав параметр metric для каждого настраиваемого маршрута по умолчанию. Shorewall создаст маршрут по умолчанию с распределением нагрузки (если опция balance включена для какого-либо из провайдеров), который не будет включать метрику и тем самым не будет заменять никакой существующий маршрут, для которого метрика отлична от нуля.Опция -n команд shorewall restart и shorewall restore позволяет предотвратить изменение маршрутизации.Файл /etc/shorewall/stopped можно также использовать для восстановления маршрутизации при остановке Shorewall. Когда система работает в обычной конфигурации маршрутизации (одна таблица), то ее содержимое можно сохранить следующим образом:ip route ls > routesНиже приведен пример файла routes для моей системы:192.168.1.1 dev eth3 scope link
206.124.146.177 dev eth1 scope link
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
192.168.2.0/24 via 192.168.2.2 dev tun0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.254
206.124.146.0/24 dev eth3 proto kernel scope link src 206.124.146.176
169.254.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 206.124.146.254 dev eth3Отредактируйте этот файл следующим образом:ip route flush table main
ip route add 192.168.1.1 dev eth3 scope link
ip route add 206.124.146.177 dev eth1 scope link
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
192.168.2.0/24 via 192.168.2.2 dev tun0
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
192.168.2.2 dev tun0 proto kernel scope link src 192.168.2.1
ip route add 206.124.146.177 dev eth1 scope link
ip route add 206.124.146.177 dev eth1 scope link
ip route add 206.124.146.177 dev eth1 scope link
ip route flush cacheСохраните этот файл как /etc/shorewall/stopped.В этот файл можно также добавить следующее:ip rule ls | while read priority rule; do
case ${priority%:} in
0|3276[67])
;;
*)
ip rule del $rule
;;
esac
doneЭтот код удаляет все правила маршрутов, за исключением маршрута по умолчанию.Какие функции НЕ выполняет запись в файле providersShorewall - это инструмент для настройки Netfilter, а не процесс, который непрерывно работает в системе, поэтому записи в файле providers не обеспечивают автоматического переключения в случае сбоя одного из каналов связи с Internet .Марсианские пакетыВ конфигурации с несколькими провайдерами часто возникает типичная неполадка с "марсианскими пакетами". Если для сетевых интерфейсов задана опция routefilter в файле /etc/shorewall/interfaces (а вместе с этой опцией должны быть задана опция logmartians), то могут возникать ошибки, и в протоколе будут сообщения следующего вида: Feb 9 17:23:45 gw.ilinx kernel: martian source 206.124.146.176 from 64.86.88.116, on dev eth1
Feb 9 17:23:45 gw.ilinx kernel: ll header: 00:a0:24:2a:1f:72:00:13:5f:07:97:05:08:00Это сообщение может ввести в заблуждение. Исходным IP входящего пакета является 64.86.88.116, а целевым IP - 206.124.146.176. Следует также учитывать, что целевой IP-адрес входящего пакета мог быть уже изменен, либо в DNAT, либо записью в файле /etc/shorewall/masq (SNAT или Masquerade) для первоначального исходящего соединения. Поэтому целевой IP-адрес (206.124.146.176) может отличаться от исходного целевого IP-адреса пришедшего пакета. Эти неполадки могут возникать по следующим причинам: Оба внешних интерфейса подключены на один хаб или коммутатор. Никогда не подключайте несколько интерфейсов файрвола на один хаб, если хотите избежать неприятных и труднообъяснимых неполадок. В файле providers указаны вместе опции loose и balance. Это приводит к тому, что отдельные соединения будут перескакивать между интерфейсами, и будут возникать ошибки. Локальный трафик направляется через один из интерфейсов с помощью маркировки пакетов записью из файла /etc/shorewall/tcrules. Вместо этого следует привязать приложение к соответствующему локальному IP-адресу требуемого интерфейса. См. далее.Если больше ничего не помогает, удалите опцию routefilter для внешнего интерфейса. При этом можно добавить правила для регистрации и сбрасывания пакетов из Интернета, имеющих адрес источника из вашей локальной сети. Например, если локальная сеть в указанной выше конфигурации имеет адреса 192.168.1.0/24, то добавьте следующее правило:#ACTION SOURCE DEST
DROP:info net:192.168.1.0/24 allBe sure the above rule is added before any other rules with net in the SOURCE column.ПримерКонфигурация схемы сети, показанной на рисунке в начале этого документа, описывается в файле /etc/shorewall/providers следующим образом.#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
ISP1 1 1 main eth0 206.124.146.254 track,balance eth2
ISP2 2 2 main eth1 130.252.99.254 track,balance eth2Прочие файлы конфигурации будут иметь следующий вид: /etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
net eth0 detect …
net eth1 detect …/etc/shorewall/policy:#SOURCE DESTINATION POLICY LIMIT:BURST
net net DROPЕсли соединения файрвола будут перенаправляться с помощью правил /etc/shorewall/tcrules, или если для провайдеров указана опция balance, то независимо от того, есть ли маскируемые хосты, в файл /etc/shorewall/masq необходимо добавить следующие записи.#INTERFACE SUBNET ADDRESS
eth0 130.252.99.27 206.124.146.176
eth1 206.124.146.176 130.252.99.27Эти записи обеспечивают отправку пакетов, созданных в системе файрвола, с правильным исходным IP-адресом, соответствующим интерфейсу, через который они направляются.Если какой-либо из интерфейсов имеет динамический IP-адрес, то указанные правила можно создать с помощью переменных оболочки. Например, если eth0 имеет динамический IP-адрес:/etc/shorewall/params:ETH0_IP=$(find_first_interface_address eth0)/etc/shorewall/masq:#INTERFACE SUBNET ADDRESS
eth0 130.252.99.27 $ETH0_IP
eth1 $ETH0_IP 130.252.99.27Если есть маскируемые хосты, то настройте в файле /etc/shorewall/masq маскарадинг для обоих провайдеров. Например, если маскируются хосты, подключенные через eth2 то это делается так:#INTERFACE SUBNET ADDRESS
eth0 eth2 206.124.146.176
eth1 eth2 130.252.99.27Записи в файле /etc/shorewall/masq никак не влияют на то, через какого провайдера пройдёт конкретное соединение. Для этого применяются правила в файле /etc/shorewall/tcrules или /etc/shorewall/rtrules.Предположим, что требуется направить весь исходящий трафик SMTP из локальной сети через провайдера 2. В файле /etc/shorewall/tcrules укажите следующее (и в версии Shorewall ниже 3.0.0 также задайте TC_ENABLED=Yes в файле /etc/shorewall/shorewall.conf).#MARK SOURCE DEST PROTO PORT(S) CLIENT USER TEST
# PORT(S)
2:P <локальная сеть> 0.0.0.0/0 tcp 25Если провайдеров больше, чем 2Для более чем двух провайдеров требуется внести соответствующие дополнения: Для каждого внешнего адреса в файл /etc/shorewall/masq необходимо добавить записи для случаев, когда соединение, использующее этот адрес как SOURCE, направляется через интерфейс с отличным адресом. Для каждого внешнего интерфейса в файл /etc/shorewall/masq необходимо добавить записи для каждой внутренней подсети, которая будет маскироваться (или для которой применяется SNAT) через этот интерфейс. Например, для eth3 с IP-адресом 16.105.78.4 и шлюзом 16.105.78.254, необходимо добавить следующее:/etc/shorewall/providers:#NAME NUMBER MARK DUPLICATE INTERFACE GATEWAY OPTIONS COPY
ISP1 1 1 main eth0 206.124.146.254 track,balance eth2
ISP2 2 2 main eth1 130.252.99.254 track,balance eth2
ISP3 3 3 main eth3 16.105.78.254 track,balance eth2/etc/shorewall/masq:#INTERFACE SUBNET ADDRESS
eth0 130.252.99.27 206.124.146.176
eth3 130.252.99.27 16.105.78.4
eth1 206.124.146.176 130.252.99.27
eth3 206.124.146.176 16.105.78.4
eth0 16.106.78.4 206.124.146.176
eth1 16.106.78.4 130.252.99.27
eth0 eth2 206.124.146.176
eth1 eth2 130.252.99.27
eth3 eth2 16.105.78.4Приложения, работающие в системе файрволаИногда возникают неполадки с приложениями, работающими в системе файрвола. Это часто имеет место, для для внешних интерфейсов в файле /etc/shorewall/interfaces указана опция routefilter (см. выше). В этом случае рекомендуется связать приложение с определенным локальным IP-адресом вместо 0.Примеры:Squid: В файле squid.conf задайте tcp_outgoing_address равным IP-адресу интерфейса, на котором будет работать Squid.Для OpenVPN задайте опцию local(--local в командной строке с IP-адресом, на котором должен принимать соединения сервер./etc/shorewall/rtrulesФайл /etc/shorewall/rtrules добавлен в Shorewall в версии 3.2.0. Файл rtrules позволяет направлять определенный трафик через конкретного провайдера, как и записи из файла tcrules . Разница между этими двумя файлами состоит в том что записи в rtrules никак не связаны с Netfilter.В Shorewall версий ниже 3.4.0 записи из файла /etc/shorewall/rtrules необратимо изменяют маршрутизацию в системе, то есть эти изменения не отменяются при вызове команды shorewall stop или shorewall clear. Для того чтобы восстановить исходные маршруты, может потребоваться перезапустить сеть. Обычно это делает команда /etc/init.d/network restart или /etc/init.d/networking restart. Обратитесь к документации по сети вашего дистрибутива.Также обратите внимание на предупреждение в разделе Какие функции выполняет запись в файле providers.Правила маршрутизацииПравила маршрутизации управляются ядром Linux. Их можно просмотреть командой ip rule ls . При маршрутизации пакета правила обрабатываются в указанном порядке, пока не будет найден маршрут пакета.gateway:~ # ip rule ls
0: from all lookup local <=== Локальные IP-адреса (система файрвола)
10001: from all fwmark 0x1 lookup Blarg <=== Это и следующее правило генерируются
10002: from all fwmark 0x2 lookup Comcast записями 'MARK' из /etc/shorewall/providers.
20000: from 206.124.146.176 lookup Blarg <=== Это и следующее правило не генерируются, если
20256: from 24.12.22.33 lookup Comcast указана опция 'loose'; они основаны на выводе 'ip addr ls'
32766: from all lookup main <=== Это таблица маршрутизации, показанная в выводе 'iproute -n'
32767: from all lookup default <=== Эта таблица обычно пуста
gateway:~ #В этом примере настроены два провайдера: Blarg и Comcast, с метками MARK 1 и 2 соответственно.Файл rtrulesДалее описаны столбцы файла:SOURCE (Необязательный)IP-адрес (подсеть или хост), с которыми совпадает исходный IP-адрес пакета. Может указываться как имя интерфейса, за которым следует необязательная часть из ":" и адреса. Если указано устройство 'lo', то пакет должен исходить из системы файрвола.DEST (Необязательный)IP-адрес (подсеть или хост), с которыми совпадает целевой IP-адрес пакета.Если опущен SOURCE или DEST, то в укажите в одном из этих полей "-". Необходимо задать хотя бы одно из полей SOURCE или DEST.PROVIDERПровайдер, через которого должен проходить трафик. Может быть задан как имя провайдера или его номер.PRIORITYПриоритет правила, определяющий порядок обработки правил.1000-1999: перед правилами Shorewall, генерируемыми на основе меток 'MARK'11000- 11999: после правил 'MARK', но перед правилами Shorewall, генерируемыми для интерфейсов провайдеров.26000-26999: после интерфейсов провайдеров, но перед правилом 'default'.Правила с одинаковым приоритетом обрабатываются в том порядке, как они указаны в файле.Пример 1: Направить весь трафик, приходящий на eth1, через Comcast.#SOURCE DEST PROVIDER PRIORITY
eth1 - Comcast 1000С этим правилом вывод ip rule ls будет следующим.gateway:~ # ip rule ls
0: from all lookup local
1000: from all iif eth1 lookup Comcast
10001: from all fwmark 0x1 lookup Blarg
10002: from all fwmark 0x2 lookup Comcast
20000: from 206.124.146.176 lookup Blarg
20256: from 24.12.22.33 lookup Comcast
32766: from all lookup main
32767: from all lookup default
gateway:~ #Обратите внимание, что приоритет 1000 приводит к тому, что проверка на eth1 осуществляется перед проверкой fwmark.Пример 2: Используется OpenVPN (маршрутизируемая конфигурация /tunX) в сочетании с несколькими провайдерами. В этом случае необходимо настроить правило, согласно которому трафик OpenVPN будет направляться обратно через интерфейс tunX, а не через какого-либо из провайдеров. 10.8.0.0/24 - это подсеть, выбранная для OpenVPN (сервер 10.8.0.0 255.255.255.0).#SOURCE DEST PROVIDER PRIORITY
- 10.8.0.0/24 main 1000
shorewall-docs-xml-4.5.21/IPIP.xml 0000644 0001750 0001750 00000013770 12222401136 016507 0 ustar teastep teastep
GRE and IPIP TunnelsTomEastep20012002200320042005Thomas M. EastepPermission 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.GRE and IPIP Tunnels are insecure when used over the Internet; use
them at your own riskGRE and IPIP tunneling with Shorewall can be used to bridge two
masqueraded networks.The simple scripts described in the Linux Advanced Routing and Shaping
HOWTO work fine with Shorewall. Shorewall also includes
a tunnel script for automating tunnel configuration. If you have installed
the RPM, the tunnel script may be found in the Shorewall documentation
directory (usually /usr/share/doc/shorewall-<version>/).Bridging two Masqueraded NetworksSuppose that we have the following situation:We want systems in the 192.168.1.0/24 subnetwork to be able to
communicate with the systems in the 10.0.0.0/8 network. This is
accomplished through use of the /etc/shorewall/tunnels file, the
/etc/shorewall/policy file and the /etc/shorewall/tunnel script that is
included with Shorewall.The tunnel script is not installed in /etc/shorewall
by default -- If you install using the tarball, the script is included in
the tarball; if you install using the RPM, the file is in your Shorewall
documentation directory (normally
/usr/share/doc/shorewall-<version>).In the /etc/shorewall/tunnel script, set the
tunnel_type parameter to the type of tunnel that you want
to create./etc/shorewall/tunneltunnel_type=greIf you use the PPTP connection tracking modules from Netfilter
Patch-O-Matic (ip_conntrack_proto_gre ip_conntrack_pptp,
ip_nat_proto_gre and ip_nat_pptp) then you cannot use GRE
tunnels.On each firewall, you will need to declare a zone to represent the
remote subnet. We'll assume that this zone is called vpn
and declare it in /etc/shorewall/zones on both systems as follows.#ZONE TYPE OPTIONS
vpn ipv4On system A, the 10.0.0.0/8 will comprise the vpn zone. In /etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
vpn tosysb 10.255.255.255In /etc/shorewall/tunnels on system A, we need the following:#TYPE ZONE GATEWAY GATEWAY ZONE
ipip net 134.28.54.2This entry in /etc/shorewall/tunnels, opens the firewall so that the
IP encapsulation protocol (4) will be accepted to/from the remote
gateway.In the tunnel script on system A:tunnel script on system Atunnel=tosysb
myrealip=206.161.148.9 (for GRE tunnel only)
myip=192.168.1.1
hisip=10.0.0.1
gateway=134.28.54.2
subnet=10.0.0.0/8
Similarly, On system B the 192.168.1.0/24 subnet will comprise the
vpn zone. In
/etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST
vpn tosysa 192.168.1.255In /etc/shorewall/tunnels on system B, we have:#TYPE ZONE GATEWAY GATEWAY ZONE
ipip net 206.191.148.9And in the tunnel script on system B:tunnel script on system Btunnel=tosysa
myrealip=134.28.54.2 (for GRE tunnel only)
myip=10.0.0.1
hisip=192.168.1.1
gateway=206.191.148.9
subnet=192.168.1.0/24You can rename the modified tunnel scripts if you like; be sure that
they are secured so that root can execute them.You will need to allow traffic between the vpn zone
and the loc zone on both systems -- if you simply want to
admit all traffic in both directions, you can use the policy file:#SOURCE DEST POLICY LOG LEVEL
loc vpn ACCEPT
vpn loc ACCEPTOn both systems, restart Shorewall and run the modified tunnel
script with the start argument on each system. The systems
in the two masqueraded subnetworks can now talk to each other
shorewall-docs-xml-4.5.21/Manpages.xml 0000644 0001750 0001750 00000021242 12222401136 017472 0 ustar teastep teastep
Shorewall 4.4 ManpagesTomEastep2007200820092010201120122013Thomas M. EastepPermission 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.These manpages are for Shorewall 4.0 only. They describe features
and options not available on earlier releases.The docbook to manpage translation tool that we are using has some
indentation issues which require us to choose between correct output of
the man command and correctly-indented HTML. We've chosen in favor of the
man command so some of the manpages accessed through the links below have
indentation problems. We're working to resolve these issues and ask for
your patience.Section 5 — Files and Concepts
accounting - Define
IP accounting rules.actions -
Declare user-defined actions.arprules
- (Added in Shorewall 4.5.12) Define arpfilter rules.blacklist - Static
blacklisting.conntrack - Specify
helpers for connections or exempt certain traffic from netfilter
connection tracking.ecn -
Disabling Explicit Congestion Notificationexclusion - Excluding
hosts from a network or zonehosts -
Define multiple zones accessed through a single interfaceinterfaces - Define
the interfaces on the system and optionally associate them with
zones.ipsets -
Describes how to specify set names in Shorewall configuration
files.maclist -
Define MAC verification.masq -
Define Masquerade/SNATmodules -
Specify which kernel modules to load.nat - Define
one-to-one NAT.nesting -
How to define nested zones.netmap -
How to map addresses from one net to another.notrack -
Exclude certain traffic from Netfilter connection trackingparams -
Assign values to shell variables used in other files.policy -
Define high-level policies for connections between zones.providers - Define
routing tables, usually for multiple Internet links.proxyarp
- Define Proxy ARP.rtrules -
Define routing rules.routes -
(Added in Shorewall 4.4.15) Add additional routes to provider routing
tables.routestopped -
Specify connections to be permitted when Shorewall is in the stopped
state (deprecated in Shorewall 4.5.8).rules -
Specify exceptions to policies, including DNAT and REDIRECT.secmarks
- Attach an SELinux context to a packet.tcclasses - Define htb
classes for traffic shaping.tcdevices - Specify
speed of devices for traffic shaping.tcfilters - Classify
traffic for shaping; often used with an IFB to shape ingress
traffic.tcinterfaces -
Specify devices for simplified traffic shaping.tcpri -
Classify traffic for simplified traffic shaping.stoppedrules -
Specify connections to be permitted when Shorewall is in the stopped
state (added in Shorewall 4.5.8).tcrules -
Define packet marking rules, usually for traffic shaping.tos - Define
TOS field manipulation.tunnels -
Define VPN connections with endpoints on the firewall.shorewall.conf - Specify
values for global Shorewall options.shorewall-lite.conf -
Specify values for global Shorewall Lite options.vardir -
Redefine the directory where Shorewall keeps its state
information.vardir-lite -
Redefine the directory where Shorewall Lite keeps its state
information.zones -
Declare Shorewall zones.
Section 8 — Administrative Commands
shorewall -
/sbin/shorewall command syntax and semantics.shorewall-init - Companion
package that allows for automatic start/stop of other Shorewall
products based on network events.shorewall-lite -
/sbin/shorewall-lite command syntax and semantics.
shorewall-docs-xml-4.5.21/two-interface_ru.xml 0000644 0001750 0001750 00000216313 12222401136 021221 0 ustar teastep teastep
Основной файервол с двумя интерфейсамиTomEastep2002-2005Thomas M. EastepPermission 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.Эта статья применима для Shorewall версии 3.0
и выше. Если Вы работаете с более ранней версией Shorewall чем Shorewall
3.0.0, тогда смотрите документацию для этого выпуска.ВведениеУстановка Linux системы как файервола для небольшой сети довольно
простая задача, если Вы понимаете основы и следуете документации.Это руководство не пытается ознакомить Вас со всеми особенностями
Shorewall. Оно больше сфокусировано на том, что требуется для настройки
Shorewall в наиболее типичных конфигурациях:Linux система, используемая как файервол/маршрутизатор для
небольшой локальной сети.Один внешний (публичный) IP-адрес.Если Вы имеете более одного публичного
IP-адреса, это руководство не то, что Вам нужно.
Смотрите вместо этого Руководство по установке
Shorewall.Интернет-соединение посредством кабельного модема,
DSL, ISDN, Frame Relay,
коммутирумой линии ...Вот схема типичной установки:Общая конфигурация файервола с двумя интерфейсамиСистемные требованияShorewall требует, чтобы у Вас был установлен пакет
iproute/iproute2 (на
RedHat, этот пакет называется
iproute). Вы можете определить установлен ли этот пакет по
наличию программы ip на Вашем файерволе. Как root, Вы
можете использовать команду which для проверки
наличия этой программы:[root@gateway root]# which ip
/sbin/ip
[root@gateway root]#Перед тем как начатьЯ рекомендую Вам прочитать все руководство для первоначального
ознакомления, а лишь затем пройти его снова, внося изменения в Вашу
конфигурацию.Если Вы редактируете Ваши файлы конфигурации на
Windows системе, Вы должны сохранить их как
Unix файлы в том случае, если Ваш редактор
поддерживает эту возможность, иначе Вы должны пропустить их через
программу dos2unix перед тем как использовать их.
Аналогично, если Вы копируете конфигурационный файл с Вашего жесткого
диска с Windows на дискету, Вы должны воспользоваться
dos2unix для копии перед ее использованием с
Shorewall. Windows
версия dos2unixLinux
версия dos2unixСоглашенияМеста, в которых рекомендуется вносить изменения, отмечены как
.Замечания по настройке уникальные для проекта LEAF/Bering,
отмечены как .PPTP/ADSLЕсли У Вас есть ADSL модем и Вы используете
PPTP для взаимодействия с сервером на этом модеме, Вы
должны сделать изменения рекоммендуемые здесьв дополнение к тем, что описаны в последующих
шагах. ADSL с
PPTP наиболее распространен в Европе, особенно в
Австрии.Концепции ShorewallКонфигурационные файлы Shorewall находятся в директории /etc/shorewall -- в случае простой установки
Вам необходимо иметь дело только с немногими из них, как описано в этом
руководстве.Замечание для пользователей
DebianЕсли Вы при установке пользовались .deb, Вы обнаружите, что
директория /etc/shorewall
пуста. Это сделано специально. Поставляемые шаблоны файлов
конфигурации Вы найдете на вашей системе в директории /usr/share/doc/shorewall-common/default-config.
Просто скопируйте нужные Вам файлы из этой директории в /etc/shorewall и отредактируйте
копии.Заметьте, что Вы должны скопировать /usr/share/doc/shorewall-common/default-config/shorewall.conf
и /usr/share/doc/shorewall=common/default-config/modules
в /etc/shorewall даже если Вы
не будете изменять эти файлы.После того как Вы установили
Shorewall, Вы можете найти примеры файлов настроек в следующих
местах:Если Вы при установке использовали RPM,
примеры будут находится в поддиректории Samples/two-interface директории с
документацией Shorewall. Если Вы не знаете где расположена директория
с документацией Shorewall, Вы можете найти примеры используя
команду:~# rpm -ql shorewall | fgrep two-interfaces
/usr/share/doc/packages/shorewall/Samples/two-interfaces
/usr/share/doc/packages/shorewall/Samples/two-interfaces/interfaces
/usr/share/doc/packages/shorewall/Samples/two-interfaces/masq
/usr/share/doc/packages/shorewall/Samples/two-interfaces/policy
/usr/share/doc/packages/shorewall/Samples/two-interfaces/routestopped
/usr/share/doc/packages/shorewall/Samples/two-interfaces/rules
/usr/share/doc/packages/shorewall/Samples/two-interfaces/zones
~#Если Вы установили Shorewall из tarball'а, примеры находятся в
директории Samples/two-interface внутри
tarball'а.Если же Вы пользовались пакетом .deb, примеры находятся в
директории/usr/share/doc/shorewall-common/examples/two-interface.По мере того как мы будем знакомится с каждым файлом, я надеюсь, что
Вы просмотрите реальный файл на вашей системе -- каждый файл содержит
детальное описание конфигурационных инструкций и значений по
умолчанию.Shorewall видит сеть, в которой он работает, как состоящую из набора
зон(zones). В примере конфигурации с двумя
интерфейсами, определены следующие зоны:#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
fw firewall
net ipv4
loc ipv4Зоны Shorewall описаны в файле /etc/shorewall/zones.Заметьте, что Shorewall рассматривает систему файервола как свою
собственную зону. При обработке файла
/etc/shorewall/zones имя зоны файервола
(fw в примере выше) храниться в переменной shell
$FW, которая может использоваться во всей
конфигурации Shorewall для ссылки на сам файервол.Правила о том какой трафик разрешен, а какой запрещен выражаются в
терминах зон.Вы отражаете Вашу политику по умолчанию для соединений из одной
зоны в другую в файле/etc/shorewall/policy.Вы определяете исключения из политики по умолчанию в файле
/etc/shorewall/rules.Для каждого запроса на соединение входящего в файервол, запрос
сначала проверяется на соответствие файлу
/etc/shorewall/rules. Если в этом файле не найдено
правил соответствующих запросу на соединение, то применяется первая
политика из файла /etc/shorewall/policy, которая
соответсвует запросу. Если есть общее действие (common
action) определенное для политики в файле
/etc/shorewall/actions или
/usr/share/shorewall/actions.std, тогда это действие
выполняется перед тем как .Файл /etc/shorewall/policy, входящий в пример с
двумя интерфейсами, имеет следующие политики:#SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
loc net ACCEPT
net all DROP info
all all REJECT infoВ примере с двумя интерфейсами строка показанная внизу
закомментирована. Если Вы хотите, чтобы Ваш файервол имел полный доступ к
серверам Интернет, раскомментируйте эту строчку. #SOURCE DEST POLICY LOG LEVEL LIMIT:BURST
$FW net ACCEPTПолитики приведенные выше
будут:разрешать все запросы на соединение из Вашей локальной сети в
Интернет;отбрасывать (игнорировать) все запросы на соединение из Интернет
к Вашему файерволу или локальной сети;Опционально разрешать все запросы на соединение с файервола в
Интернет (если Вы раскомментировали дополнительную политику);отвергать все другие запросы на соединение (Shorewall требует
наличия такой политики, применимой для всех остальных
запросов).Важно отметить, что политики Shorewall (и правила) ссылаются на
соединения, а не на поток пакетов. С
политикой определенной в файле
/etc/shorewall/policy, показанной выше, разрешены соединения из
зоны loc в зону net, хотя на сам файервол
соединения из зоны loc не разрешены.В данный момент Вы можете отредактировать ваш файл
/etc/shorewall/policy и внести изменения, какие Вы
считаете необходимыми.Сетевые интерфейсыФайервол имеет два сетевых интерфейса. Если соединение с Интернет
осуществляется при помощи кабельного или DSL
Модема, Внешним интерфейсом будет тот
ethernet-адаптер (например, eth0),
который подсоединен к этому Модему, если же Вы соединены посредством протокола
Point-to-Point Protocol over Ethernet
(PPPoE) или Point-to-Point Tunneling
Protocol (PPTP), то в этом случае
Внешним интерфейсом будет PPP
интерфейс (например, ppp0). Если
Вы подсоединены через обычный модем, Вашим Внешним
интерфейсом будет также ppp0. Если Вы соединяетесь используя
ISDN, Внешним интерфейсом будет
ippp0.Если Ваш внешний интерфейс - это ppp0 или ippp0, тогда Вы можете захотеть установить
переменную CLAMPMSS=yes в /etc/shorewall/shorewall.conf.Ваш Внешний интерфейс будет ethernet-адаптер
(eth0 or eth1) и будет соединен с
хабом или коммутатором. Другие
Ваши компьютеры будут соединены с тем же хабом/коммутатором (заметьте:
если Вы имеете только одну внутреннюю систему, Вы можете соединить
файервол с этим компьютером напрямую, используя кроссоверный (cross-over)
кабель.НЕ подсоединяйте внутренний и внешний
интерфейсы к одному т тому же хабу или коммутатору исключая время
тестирование.Вы можете провести тестирование используя
данную конфигурацию, если Вы указали параметр
ARP_FILTER в /etc/shorewall/interfaces
для всех интерфейсов подсоединенных к общему хабу/коммутатору.
Использовать такие установки на рабочем
файерволе строго не рекоммендуется.Пример конфигурации Shorewall с двумя интерфейсами подразумевает,
что внешний интерфейс - это eth0,
а внутренний - eth1. Если Ваша
конфигурация отличается, Вы должны будете изменить пример файл /etc/shorewall/interfaces
соответственно. Пока Вы здесь, Вы возможно захотите просмотреть список
опций, специфичных для интерфейса. Вот несколько подсказок:Если Ваш внешний интерфейс ppp0 или ippp0, Вы можете заменить
detect(обнаружить) во втором столбце на
-(знак минус в ковычках).Если Ваш внешний интерфейс ppp0 или ippp0 или Вы имеете статический
IP-адрес, Вы можете удалить dhcp из
списка опций.Если Ваш внешний интерфейс является мостом, созданным с
использованием утилиты brctl, тогда Вы должны добавить опцию routeback в
список опций.IP-адресаПеред тем как идти дальше, мы должны сказать несколько слов о
Internet Protocol (IP)-адресах.
Обычно, Ваш Интернет-провайдер(Internet Service
Provider - ISP) назначает Вам один
IP-адрес. Этот адрес может быть назначен статически,
при помощи Протокола Динамического Конфигурирования Хостов
(Dynamic Host Configuration Protocol -
DHCP), в процессе установки Вами коммутированного
соединения (обычный модем), или при установке Вами другого типа
PPP (PPPoA, PPPoE
и т.д.) соединения. В последнем случае Ваш ISP может
назначит Вам статический IP-адрес; что означает, что Вы
настраиваете внешний интерфейс Вашего файервола на использование этого
адреса постоянно. Как бы ни был назначен Вам внешний адрес, он будет
разделяться между всеми Вашими системами при доступе в Интернет. Вы должны
будете назначить свои собственные адреса в Вашей внутренней сети
(внутренний интерфейс на Вашем файерволе, плюс другие Ваши компьютеры).
RFC-1918 резервирует несколько Частных
(Private) IP-адресов для этих целей:
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255Перед запуском Shorewall, Вы должны взглянуть
на IP-адрес Вашего внешнего интерфейса и если он входит в один указанных
выше пазонов, Вы должны удалить опцию norfc1918 из строки
для внешнего интерфейса в файле /etc/shorewall/interfaces.Вы можете захотеть назначить Ваши адреса из такой же подсети
(subnet). Для наших целей мы можем рассматривать подсеть состоящую из
диапазона адресов x.y.z.0 - x.y.z.255. Такая подсеть
будет иметь Маску Подсети (Subnet
Mask) - 255.255.255.0.
Адрес x.y.z.0 зарезервирован как Адрес
Подсети (Subnet Address), а x.y.z.255 как
Широковещательный Адрес Подсети (Subnet Broadcast
Address). В Shorewall подсеть описывается с использованием
нотации Бесклассовой
Междоменной Маршрутизации (Classless InterDomain Routing -
CIDR notation) с адресом посети оканчивающимся
/24. 24 указывает число непрерывных
ведущих бит установленных в 1 слева в маске подсети.
Диапазон:10.10.10.0 -
10.10.10.255Адрес
подсети:10.10.10.0Широковещательный
адрес:10.10.10.255Нотация
CIDR:10.10.10.0/24Удобно назначать внутреннему интерфейсу либо первый
используемый адрес подсети (10.10.10.1 в примере выше), либо последний
используемый адрес (10.10.10.254).Одна из целей разбиения на подсети - это позволить всем компьютерам
в подсети понимать с какими другими компьютерами можно взаимодействовать
напрямую. При взаимодействии с системами находящимися вне подсети, системы
посылают пакеты через шлюз (маршрутизатор) (gateway
(router)).Ваши локальные компьютеры (computer 1 и computer 2 на диаграмме
выше) должны быть сконфигурированы так, чтобы
IP-адресом их маршрутизатора по умолчанию был
IP-адрес внутреннего интерфейса файервола.Короткая предшествующая дискуссия лишь поверхностно затронула
вопросы связанные с подсетями и маршрутизацией. Если Вы заинтересованы
узнать больше об IP-адресации и маршрутизации, я очень
рекомендую Основы IP: Что нужно знать каждому об адресации и
маршрутизации (IP Fundamentals: What Everyone Needs to Know
about Addressing & Routing), Thomas A. Maufer, Prentice-Hall,
1999, ISBN 0-13-975483-0 (link).Оставшаяся часть руководства расчитана на то, что Вы имеете сеть,
сконфигурированную так, как показано здесь: Маршрутизатором по умолчанию для computer 1 и 2 должен
быть 10.10.10.254.Ваш ISP может назначить Вашему внешнему
интерфейсу адрес из RFC-1918. Если этот адрес из
подсети 10.10.10.0/24,
тогда Вы должны будете выделить ДРУГУЮ подсеть
RFC-1918 для вашей локальной
подсети.IP-маскарадинг (SNAT)Адреса зарезервированные RFC-1918 иногда называют
немаршрутизируемыми потому, что магистральные маршрутизаторы Интернет не
переправляют пакеты, которые имеют адрес назначения из
RFC-1918. Когда одна из Ваших локальных систем
(допустим computer 1) посылает запрос на соединение хосту в Интернете,
файервол должен выполнить Трансляцию Сетевого Адреса (Network
Address Translation - NAT). Файервол
перезаписывает адрес источника в пакете адресом внешнего интерфейса
файервола; другими словами, файервол делает так, чтобы это выглядело как
файервол сам инициируетсоединение. Это необходимо так как хост назначения
должен быть способен направить пакеты назад файерволу через маршрутизаторы
(вспомним, что пакеты с адресом назначения зарезервированным
RFC-1918 не могут быть маршрутизированы через Интернет
и следовательно удаленный хост не сможет адресовать ответ на computer 1).
Когда файервол принимает ответный пакет, он перезаписывает адрес
назначения обратно в 10.10.10.1
и переправляет пакет на computer 1.На Linux системах, описанный выше процесс называют
IP-маскарадингом (IP
Masquerading), но Вы будете также встречать термин
Преобразование Сетевого Адреса Источника (Source Network Address
Translation - SNAT). Shorewall следует
соглашению используемому Netfilter: Masquerade описывает случай, когда Вы
позволяете своему файерволу автоматически определять адрес внешнего
интерфейса.SNAT используют в случае, когда Вы
определенно указываете адрес источника, который Вы хотите
использовать для покидающих Вашу локальную сеть пакетов. В Shorewall оба режима Маскарадинг
(Masquerading) и SNAT конфигурируются
записями в файле /etc/shorewall/masq. Вы
будете обычно использовать Маскарадинг, если Ваш внешний
IP-адрес - динамический и SNAT, если
внешний IP-адрес - статический.Если Ваш внешний интерфейс файервола - eth0, Вам не нужно изменять файл из примера.
В противном случае, отредактируйте /etc/shorewall/masq и
измените первый столбец на имя Вашего внешнего интерфейса и второй столбец
на имя Вашего внутреннего интерфейса.Если Ваш внешний IP-адрес - статический, Вы
можете ввести его в третьем столбце записи файла /etc/shorewall/masq если
Вам нравиться, хотя Ваш файервол будет прекрасно работать, даже если Вы
оставите этот столбец пустым. Вводя Ваш статический
IP-адрес в третьем столбце, Вы делаете обработку
исходящих пакетов немного более эффективной.Если Вы используете пакет Debian, проверьте
пожалуйста Ваш файл shorewall.conf, чтобы убедиться,
что следующее установлено правильно; если нет, измените это
соответственно:IP_FORWARDING=OnПеренаправление портов (DNAT)Одной из Ваших целей может быть запуск одного или более серверов на
Ваших локальных компьютерах. Так как эти компьютеры имеют адреса из
RFC-1918, то клиентам из Интернет невозможно
соединиться напрямую с ними. Это более невозможно для тех клиентов, кто
адресует свои запросы для соединения на файервол, который переписывает
адрес назначения на адрес Вашего сервера и переправляет пакет на этот
сервер. Когда Ваш сервер отвечает, файервол автоматически выполняет
SNAT для перезаписи адреса источника в ответе.Описанный выше процесс называется Перенапрвление Портов
(Port Forwarding) или Преобразование Сетевого Адреса
Назначения (Destination Network Address Translation -
DNAT). Вы настраиваете перенаправление портов при
помощи правил DNAT в файле /etc/shorewall/rules.Основная форма примерного правила перенаправления портов в /etc/shorewall/rules
такая:#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net loc:<server local ip address>[:<server port>] <protocol><port>Shorewall
имеет макрос (macros) для многих
популярных приложений. Смотрите в
/user/share/shorewall/macro.*, чтобы увидеть, что
доступно в Вашем релизе. Макрос упрощает создание правил
DNAT предоставляя протокол и порт(ы) как показано
ниже.Web-серверВы запускаете Web-сервер на computer 2 и Вы хотите перенаправить
входящие на порт 80 TCP-пакеты на эту систему:
#ACTION SOURCE DEST PROTO DEST PORT(S)
Web/DNAT net loc:192.168.1.5FTP-серверВы запустили FTP-сервер на computer 1, так
что Вы хотите перенаправить входящие на порт 21
TCP-пакеты на эту систему: #ACTION SOURCE DEST PROTO DEST PORT(S)
FTP/DNAT net loc:10.10.10.1Для FTP
Вы должны также буете иметь отслеживание FTP
соединений (connection tracking) и поддержку NAT в
Вашем ядре. Для ядер, предоставляемых продавцами дистрибутивов, это
означает, что должны быть загружены модули ip_conntrack_ftp и ip_nat_ftp. Shorewall автоматически
загрузит эти модули если они доступны и расположены в стандартных
местах внутри /lib/modules/<kernel
version>/kernel/net/ipv4/netfilter.Нужно иметь в виду пару важных моментов: Вы должны протестировать приведенные выше правила для клиентов
вне Вашей локальной сети (т.е., не тестировать из браузера,
запущенного на computer 1 или 2 или на файерволе). Если Вы хотите
иметь доступ к Вашему Web-серверу и/или
FTP-серверу с Вашего файервола, используя
IP-адрес Вашего внешнего интерфейса, смотрите
Shorewall FAQ #2.Многие ISP блокируют входящие запросы для
соединения на порт 80. Если у Вас есть проблемы при соединении с
Вашим Web-сервером, попробуйте следующее правило и попытайтесь
соединиться с портом 5000 (например, подключитесь к
http://w.x.y.z:5000, где
w.x.y.z - Ваш внешний
IP).#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net loc:10.10.10.2:80 tcp 5000В этом месте измените /etc/shorewall/rules
добавив любое правило DNAT, какое Вам
необходимо.Когда тестируете правила DNAT похожие на те,
что приведены выше, Вы должны тестировать с клиента ИЗВНЕ ВАШЕГО
ФАЙЕРВОЛА (в зоне net). Вы не можете протестировать эти
правила изнутри файервола!Советы по разрешению проблем с DNAT, смотрите в
FAQs 1a и 1b.Сервер Доменных Имен (Domain Name Server - DNS)Обычно, когда Вы соединяетесь с Вашим ISP, как
часть получения IP-адреса будет автоматически настроен
резольвер Сервиса Доменных Имен (Domain Name Service
- DNS) Вашего файервола (например, будет записан файл
/etc/resolv.conf). Как
альтернатива, Ваш ISP может сообщить Вам
IP-адреса пары DNS-серверов, чтобы
Вы вручную указали их как Ваши первичный и вторичный сервера имен. Вне
зависимости от того как Вы настроете DNS на Вашем
файерволе, на Вас лежит ответственность за то как будет настроен резольвер
на Ваших внутренних системах. Вы можете применить один из двух подходов:
Вы можете настроить Ваши внутренние системы на использование
серверов имен Вашего ISP. Если Ваш
ISP дал Вам адреса этих серверовthe или если эти
адреса доступны на Web-сайте, Вы можете настроить Ваши внутренние
системы на использование этих адресов. Если эта информация
недоступна, загляните в /etc/resolv.conf
на Вашем файерволе -- сервера имен указаны в записях
nameserver этого файла. Вы можете настроить
Кэширующий Сервер Имен (Caching Name Server) на
Вашем файерволе. Red Hat имеет
RPM для кэширующего сервера имен (которому также
необходим пакет bind-RPM), а
для пользователей Bering существует dnscache.lrp.
Если Вы пойдете этим путем, Вы настраиваете Ваши внутренние системы
на использование самого файервола как первичного (и только) сервера
имен. Вы используете внутренний IP-адрес
файервола (10.10.10.254 в
примере выше) для адреса сервера имен, если Вы запускаете сервер
имен на Вашем файерволе. Чтобы позволить Вашим локальным системам
общаться с Вашим кэширующим сервером имен, Вы должны открыть доступ
к порту 53 (оба UDP и TCP) на
файерволе из внутренней сети. Вы можете сделать это, добавив
следующее правило в файл /etc/shorewall/rules.#ACTION SOURCE DEST PROTO DEST PORT(S)
DNS/ACCEPT loc $FWДругие соединенияПример с двумя интерфейсами включает следующие
правила:#ACTION SOURCE DEST PROTO DEST PORT(S)
DNS/ACCEPT $FW netЭто правило разрешает доступ к
DNS с Вашего файервола и может быть удалено, если Вы
раскомментировали строку в /etc/shorewall/policy,
разрешающую все соединения с файервола в Интернет.В показанном выше правиле DNS/ACCEPT - это пример
привлечения макроса (macro invocation). Shorewall
включает множество макросов (смотри
/usr/share/shorewall/macro.*) и Вы можете добавить Ваш собственный.Вам не обязательно использовать предопределенные макросы при
написании правил в файле /etc/shorewall/rules;
Shorewall будет запускаться немного быстрее, если Вы будете писать Ваши
правила напрямую, чем при использовании макросов. Правил, показанное выше
может быть также записано как:#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT $FW net udp 53
ACCEPT $FW net tcp 53В случаях когда Shorewall не имеет предопределенных макросов,
отвечающих Вашим потребностям, Вы можете либо определить свой собственный
макрос, либо просто записать соответствующие правила напрямую. Эта страница может помочь Вам в случае, если Вы
не знаете используемые протокол и порт.Пример также включает: #ACTION SOURCE DEST PROTO DEST PORT(S)
SSH/ACCEPT loc $FW Это правило разрешает Вам
запускать SSH-сервер на Вашем файерволе и соединяться с
ним с Ваших локальных систем.Если Вы хотите разрешить другие соединения с Вашего файервола к
другим системам, основной формат использования макроса
такой:#ACTION SOURCE DEST PROTO DEST PORT(S)
<macro>/ACCEPT $FW <destination zone>Основной
формат при отсутствии предопределенных макросами действий
такой:#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT $FW <destination zone> <protocol> <port>Web-сервер на файрволеВы хотите запустить Web-сервер на Вашем файерволе:
#ACTION SOURCE DEST PROTO DEST PORT(S)
Web/ACCEPT net $FW
Web/ACCEPT loc Эти два правила, конечно, должны быть
добавлены к тем правилам, которые указаны выше в абзаце Вы можете настроить Кэширующий Сервер Имен на
Вашем файерволе.Если Вы не знаете какой порт и протокол использует конкретное
приложение, смотрите здесь. Я не рекоммендую разрешать telnet в/из
Интернет потому, что он использует открытый текст (даже для передачи
имени и пароля!). Если Вы хотите иметь доступ к командному
интерпретатору Вашего файервола из Интернет, используйте
SSH:#ACTION SOURCE DEST PROTO DEST PORT(S)
SSH/ACCEPT net $FWПользователи дистрибутива Bering захотят добавить следующие два
правила для совместимости с конфигурацией Shorewall от
Jacques.#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT loc $FW udp 53 #Allow DNS Cache to work
ACCEPT loc $FW tcp 80 #Allow Weblet to workЗапись 1 разрешает использование кэширующего
DNS.Запись 2 разрешает работу weblet.Теперь Вы можете отредактировать Ваш файл /etc/shorewall/rules,
добавляя или удаляя другие соединения по необходимости.Что нужно помнитьВы не можете Ваш файервол
изнутри. Только потому, что Вы посылаете запросы на внешний
IP-адрес Вашего файервола не означает, что запросы
будут ассоциированы с внешним интерфейсом или зоной
net. Любой трафик, создаваемый из локальной сети будет
ассоциироваться с Вашим локальным интерфейсом и будет воспринят как
трафик loc->fw.IP-адреса - это свойства систем, а не
интерфейсов. Ошибочно верить, что Ваш файервол способен
переправит пакеты только потому, что Вы можете пропинговать
IP-адрес всех интерфейсов файервола из локальной
сети. Единственное заключение, которое Вы можете вынести из такого
успешного пингования - это наличие рабочей связи между локальной
системой и файерволом и то, что Вы, возможно, правильно указали
маршрутизатор по умолчанию на локальной системе.Все IP-адреса, настроенные на интерфейсах
файервола, принадлежат зоне $FW (fw). Если
192.168.1.254 - это IP-адрес Вашего внутреннего
интерфейса, то Вы можете написать $FW:192.168.1.254 в правиле, но Вы не
можете написать loc:192.168.1.254. Также не играет роли
добавление адреса 192.168.1.254 в зону loc при помощи
записи в файле /etc/shorewall/hosts.Ответные пакеты НЕ следуют автоматически
обратно тем маршрутом, который использовал исходный запрос.
Все пакеты маршрутизируются согласно таблице маршрутизации каждого
хоста на всем пути. Этот вопрос обычно встает когда людч устанавливают
файервол Shorewall параллельно с имеющимся шлюзом и пытаются
использовать DNAT сквозь Shorewall без изменения
шлюза по умолчанию системы, принимающей переправленные запросы.
Запросы проходят сквозь файервол Shorewall, где изменяется
IP-адрес назначения, но ответы уходят неизмененными
через старый шлюз.Shorewall сам не имеет представления о
внутренней и внешней стороне. Воплощение этих концепций
зависит от того, как настроен Shorewall.Запуск и останов Вашего файерволаПроцедура установки настраивает
Вашу систему для запуска Shorewall при загрузке системе, но запуск
остается отключен, так что система не будет пытаться запустить Shorewall
до полного завершения конфигурирования. Как только Вы полностью завершите
конфигурирование Вашего файервола, Вы можете включить запуск Shorewall,
отредактировав файл /etc/shorewall/shorewall.conf и
установив параметр STARTUP_ENABLED=Yes.Пользователи пакета .deb должны отредактировать файл
/etc/default/shorewall и установить параметр
STARTUP=1.Вы должны разрешить запуск путем редактирования файла
/etc/shorewall/shorewall.conf и установки
параметра STARTUP_ENABLED=Yes.Файервол запускается при помощи команды
shorewall start и останавливается при
помощи shorewall stop. Когда файервол
остановливается, маршрутизация разрешается на те хосты, которые указаны в
/etc/shorewall/routestopped.
Запущенный файервол может быть перезапущен при помощи команды
shorewall restart. Если Вы хотите
полностью удалить изменения сделанные Shorewall из конфигурации Вашего
Netfilter, используйте команду shorewall
clear.Пример с двумя интерфейсами предполагает, что Вы хотите разрешить
маршрутизацию к/из eth1 (локальная
сеть) когда Shorewall остановлен. Если Ваша локальная сеть не подсоединена
к eth1 или Вы не хотите разрешать
доступ к/из других хостов, измените файл /etc/shorewall/routestopped
соответственно.Если Вы подсоединены к Вашему файерволу из Интернет, не
используйте команду shorewall stop
если Вы не добавили запись для IP-адреса, с
которого Вы подсоединены, в /etc/shorewall/routestopped.
Также, я не рекоммендую использовать shorewall
restart; лучше создать альтернативную
конфигурацию и протестировать ее при помощи команды
shorewall
try.Дополнительно рекоммендуемая литератураЯ особо рекоммендую просмотреть Вам страницу Общих Особенностей Файлов
Конфигурации -- она содержит полезные советы об особенностях
Shorewall, делающую администрирование Вашего файервола проще.Добавление сегмента беспроводной связи к Вашему файерволу с двумя
интерфейсамиКак только Вы будете иметь работающую конфигурацию с двумя
интерфейсами, следующий логический шаг - добавление беспроводной сети.
Первый шаг включает добавление дополнительной сетевой карты в Ваш
файервол, либо карты беспроводного интерфейса, либо Ethernet-карты,
которая соединена с Точкой Беспроводного Доступа (Wireless
Access Point).Когла Вы добавляете сетевую карту, она необязательно будет
определена как следующая по порядку сетевой интерфейс. Например, если
Вы имеете две карты Ethernet в Вашей системе (eth0 и eth1) и Вы добавляете третью карту,
которая использует такой же драйвер как и одна из имеющихся, то эта
третья карта необязательно будет определена как eth2; она может определиться как
eth0 или eth1! Вы можете оставить все как есть,
либо можете переставлять карты в слотах до тех пор, пока новая карта
не будет определена как eth2.Ваша новая сеть будет выглядеть примерно так, как показано на
следующем рисунке.Во-первых необходимо отметить, что компьютеры в Вашей беспроводной
сети будут принадлежать другой подсети, чем те, что находяться в проводной
локальной сети. В примере выше мы выбрали для использования сеть
10.10.11.0/24. Computers 3 и 4 должны быть настроены с
IP-адресом маршрутизатора по умолчанию
10.10.11.254.Во-вторых мы решили включить беспроводную сеть как часть зоны
loc. Поскольку Shorewall по умолчанию разрешает
внутризонный трафик, трафик может свободно перемещаться между локальными
проводной и беспроводной сетями.Необходимо выполнить всего-лишь два изменения в настройках
Shorewall:Нужно добавить запись для интерфейса беспроводной сети в файл
/etc/shorewall/interfaces. Если беспроводной
интерфейс wlan0, то запись
может выглядеть так:#ZONE INTERFACE BROADCAST OPTIONS
loc wlan0 detect maclistКак показано выше, я рекоммендую использовать опцию maclist для беспроводного сегмента.
Добавив записи для computers 3 и 4 в файл
/etc/shorewall/maclist, Вы можете быть
уверенными, что Вашими соседями не сможет стать любой, используя Ваше
Интернет соединение. Начните без этой опции, а когда у Вас все
заработает, добавьте ее и настройте Ваш файл
/etc/shorewall/maclist.Вам необходимо добавить запись в файл
/etc/shorewall/masq для маскарадинга трафика из
беспроводной сети в Интернет. Если Ваш Интернет-интерфейс eth0 и Ваш беспроводной интерфейс
wlan0, то запись будет
такой:#INTERFACE SUBNET ADDRESS
eth0 wlan0Еще одно замечание. Для того, чтобы между беспроводной и проводной
сетями работала сеть Microsoft, Вам необходим либо
WINS-сервер, либо PDC. Я лично
пользуюсь Samba, настроенной как WINS-сервер,
работающей на моем файерволе. Запуск WINS-сервера на
Вашем файерволе потребует правил, перечисленных в документации Shorewall/Samba.
shorewall-docs-xml-4.5.21/upgrade_issues.xml 0000644 0001750 0001750 00000154707 12222401136 020776 0 ustar teastep teastep
Upgrade IssuesTomEastep2002200320042005200620072008200920122013Thomas M. EastepPermission 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.ImportantIt is important that you read all of the sections on this page where
the version number mentioned in the section title is later than what you
are currently running.In the descriptions that follows, the term
group refers to a particular network or subnetwork
(which may be 0.0.0.0/0 or it may be a host address)
accessed through a particular interface.Examples:eth0:0.0.0.0/0eth2:192.168.1.0/24eth3:192.0.2.123You can use the shorewall show
zones command to see the groups associated with each of your
zones.Versions >= 4.5.0Shorewall, Shorewall6, Shorewall-lite and Shorewall6-lite now
depend on the new package Shorewall-core. If you use the Shorewall
installers, you must install Shorewall-core prior to installing or
upgrading any of the other packages.The BLACKLIST section of the rules file has been eliminated. If
you have entries in that file section, you must move them to the
blrules file.This version of Shorewall requires the Digest::SHA1 or the
Digest:SHA Perl module.Debian: libdigest-sha-perlFedora: perl-Digest-SHA1OpenSuSE: perl-Digest-SHA1The generated firewall script now maintains the
/var/lib/shorewall[6][-lite]/interface.status files used by SWPING and
by LSM.Beginning with Shorewall 4.5.2, using /etc/shorewall-lite/vardir
and /etc/shorewall6-lite/vardir to specify VARDIR is deprecated in
favor of the VARDIR setting in shorewallrc.NOTE: While the name of the variable remains VARDIR, the meaning
is slightly different. When set in shorewallrc, each product
(shorewall-lite, and shorewall6-lite) will create a directory under
the specified path name to hold state information.Example:
VARDIR=/opt/var/The state directory for shorewall-lite will be
/opt/var/shorewall-lite/ and the directory for shorewall6-lite will
be /opt/var/shorewall6-lite.
When VARDIR is set in /etc/shorewall[6]/vardir, the product will
save its state directly in the specified directory.Begining with Shorewall 4.5.6, the tcrules file is processed if
MANGLE_ENABLED=Yes, independent of the setting of TC_ENABLED. This
allows actions like TTL and TPROXY to be used without enabling traffic
shaping. If you have rules in your tcrules file that you only want
processed when TC_ENABLED is other than 'No', then enclose them
in
?IF $TC_ENABLED...?ENDIF
If they are to be processed only if TC_ENABLED=Internal, then
enclose them in
?IF TC_ENABLED eq 'Internal'...?ENDIF.
Beginning with Shorewall 4.5.7, the deprecated
/etc/shorewall[6]/blacklist files are no longer installed. Existing
files are still processed by the compiler.Note that blacklist files may be converted to equivalent blrules
files using shorewall[6] update -b.In Shorewall 4.5.7, the
/etc/shorewall[6]/notrack file was renamed
/etc/shorewall[6]/conntrack. When upgrading to a
release >= 4.5.7, the conntrack file will be
installed along side of an existing notrack
file.If the 'notrack' file is non-empty, a warning message is issued
during compilation:
WARNING: Non-empty notrack file (...); please move its
contents to the conntrack file
This warning can be eliminated by removing the notrack file (if
it has no entries), or by moving its entries to the conntrack file and
removing the notrack file. Note that the conntrack file is always
populated with rulesIn Shorewall 4.5.8, the /etc/shorewall[6]/routestopped files
were deprecated if favor of new /etc/shorewall[6]/stoppedrules
counterparts. The new files have much more familiar and
straightforward semantics. Once a stoppedrules file is populated, the
compiler will process that file and will ignore the corresponding
routestopped file.In Shorewall 4.5.8, a new variable (VARLIB) was added to the
shorewallrc file. This variable assumes the role formerly played by
VARDIR, and VARDIR now designates the configuration directory for a
particular product.This change should be transparent to all users:If VARDIR is set in an existing shorewallrc file and VARLIB
is not, then VARLIB is set to ${VARDIR} and VARDIR is set to
${VARLIB}/${PRODUCT}.If VARLIB is set in a shorewallrc file and VARDIR is not,
then VARDIR is set to ${VARLIB}/${PRODUCT}.The Shorewall-core installer will automatically update
~/.shorewallrc and save the original in ~/.shorewallrc.bak.Previously, the macro.SNMP macro opened both UDP ports 161 and
162 from SOURCE to DEST. This is against the usual practice of opening
these ports in the opposite direction. Beginning with Shorewall 4.5.8,
the SNMP macro opens port 161 from SOURCE to DEST as before, and a new
SNMPTrap macro is added that opens port 162 (from SOURCE to
DEST).Beginning with Shorewall 4.5.11, ?FORMAT is preferred over
FORMAT for specifying the format of records in these configuration
files:action.* filesconntrackinterfacemacro.* filestcrulesThe first instance of 'FORMAT' (without the '?') will generate
this warning:WARNING: FORMAT is deprecated in favor of ?FORMAT; consider
running 'shorewall update -D'As the warning suggests, 'shorewall[6] update -D' will convert
all instances of FORMAT to ?FORMAT in files on the CONFIG_PATH.Also beginning with Shorewalll 4.5.11, ?COMMENT is preferred
over COMMENT for specifying comments to be attached to generated
Netfilter rules in the following files:accountingaction.* filesblrulesconntrackmacro.* filesmasqnatrulessecmarkstcrulestunnelsThe first instance of 'COMMENT' (without the '?') will generate
this warning:WARNING: COMMENT is deprecated in favor of ?COMMENT;
consider running 'shorewall update -D'As the warning suggests, 'shorewall[6] update -D' will convert
all instances of COMMENT to ?COMMENT in files on the
CONFIG_PATH.Also beginning with Shorewalll 4.5.11, ?COMMENT is preferred
over COMMENT for specifying comments to be attached to generated
Netfilter rules in the following files:accountingaction.* filesblrulesconntrackmacro.* filesmasqnatrulessecmarkstcrulestunnelsVersions >= 4.4.0If you are using Shorewall-perl, there are no additional upgrade
issues. If you are using Shorewall-shell or are upgrading from a
Shorewall version earlier than 4.0.0 then you will need to migrate to Shorewall-perl.
Shorewall-4.3.5 and later only use the perl-based compiler.If you have specified "SHOREWALL_COMPILER=shell" in
shorewall.conf, then you must either:change that specification to "SHOREWALL_COMPILER=perl";
orchange that specification to "SHOREWALL_COMPILER=";
ordelete the specification altogether.Failure to do so will result in the following
warning:
WARNING: SHOREWALL_COMPILER=shell ignored. Support for
Shorwall-shell has been removed in this release.
The shorewall stop, shorewall
clear, shorewall6 stop and
shorewall6 clear commands no longer read the
routestopped file. The
routestopped file used is the one that was
present at the last start,
restart or restore
command.If you modify the routestopped file, you must restart
Shorewall before the changes to that file will take effect.The old macro parameter syntax (e.g., SSH/ACCEPT) is now
deprecated in favor of the new syntax (e.g., SSH(ACCEPT)). The 4.3
documentation uses the new syntax exclusively, although the old syntax
continues to be supported.Support for the SAME target in /etc/shorewall/masq and
/etc/shorewall/rules has been removed, following the removal of the
underlying support in the Linux kernel.Supplying an interface name in the SOURCE column of
/etc/shorewall/masq is now deprecated. Entering the name of an
interface there will result in a compile-time warning:WARNING: Using an interface as the masq SOURCE requires the
interface to be up and configured when Shorewall
starts/restartsTo avoid this warning, replace interface names by the
corresponding netwok(s) in CIDR format (e.g.,
192.168.144.0/24).Previously, Shorewall has treated traffic shaping class IDs as
decimal numbers (or pairs of decimal numbers). That worked fine until
IPMARK was implemented. IPMARK requires Shorewall to generate class
Ids in numeric sequence. In 4.3.9, that didn't work correctly because
Shorewall was generating the sequence "..8,9,10,11..." when the
correct sequence was "...8,9,a,b,...". Shorewall now treats class IDs
as hex, like 'tc' and 'iptables' do.This should only be an issue if you have more than 9 interfaces
defined in /etc/shorewall/tcdevices and if you
use class IDs in /etc/shorewall/tcrules. You will
need to renumber the class IDs for devices 10 and greater.Support for the 'norfc1918' interface and host option has been
removed. If 'norfc1918' is specified for an entry in either the
interfaces or the hosts file, a warning is issued and the option is
ignored. Simply remove the option to avoid the warning.Similarly, if RFC1918_STRICT=Yes or a non-empty
RFC1918_LOG_LEVEL is given in shorewall.conf, a warning will be issued
and the option will be ignored.You may simply delete the RFC1918-related options from your
shorewall.conf file if you are seeing warnings regarding them.Users who currently use 'norfc1918' are encouraged to consider
using NULL_ROUTE_RFC1918=Yes instead.The install.sh scripts in the Shorewall and Shorewall6 packages
no longer create a backup copy of the existing configuration. If you
want your configuration backed up prior to upgrading, you will need to
do that yourself. As part of this change, the fallback.sh scripts are
no longer released.Previously, if an ipsec zone was defined as a sub-zone of an
ipv4 or ipv6 zone using the special <child>:<parent>,...
syntax, CONTINUE policies for the sub-zone did not work as expected.
Traffic that was not matched by a sub-zone rule was not compared
against the parent zone(s) rules. In 4.4.0, such traffic IS compared
against the parent zone rules.The name any is now reserved
and may not be used as a zone name.Perl module initialization has changed in Shorewall 4.4.1.
Previously, each Shorewall Perl package would initialize its global
variables for IPv4 in an INIT block. Then, if the compilation turned
out to be for IPv6, Shorewall::Compiler::compiler() would reinitialize
them for IPv6.Beginning in Shorewall 4.4.1, the modules do not initialize
themselves in an INIT block. So if you use Shorewall modules outside
of the Shorewall compilation environment, then you must explicitly
call the module's 'initialize' function after the module has been
loaded.Checking for zone membership has been tighened up. Previously, a
zone could contain <interface>:0.0.0.0/0 along with other hosts;
now, if the zone has <interface>:0.0.0.0/0 (even with
exclusions), then it may have no additional members in /etc/shorewall/hosts.ADD_IP_ALIASES=No is now the setting in the released shorewall.conf and in all
of the samples. This will not affect you during upgrade unless you
choose to replace your current shorewall.conf with the one from the
release (not recommended).The names of interface configuration variables in generated
scripts have been changed to ensure uniqueness. These names now begin
with SW_. This change will only affect you if your extension scripts
are using one or more of these variables.Old Variable NameNew Variable Nameiface_addressSW_iface_ADDRESSiface_BCASTSSW_iface_BCASTSiface_ACASTSSW_iface_CASTSiface_GATEWAYSW_iface_NETWORKSiface_ADDRESSESSW_iface_ADDRESSESiface_NETWORKSSW_iface_NETWORKSiface_MACSW_iface_MACprovider_IS_USABLESW_provider_IS_USABLEwere iface is a capitalized interface
name (e.g., ETH0) and provider is the
capitalized name of a provider.If your /etc/shorewall/params (or
/etc/shorewall6/params)
file sends output to Standard Output, you need to be aware that the
output will be redirected to Standard Error beginning with Shorewall
4.4.16.Beginning with Shorewall 4.4.17, the EXPORTPARAMS option is
deprecated. With EXPORTPARAMS=No, the variables set by /etc/shorewall/params
(/etc/shorewall6/params)
at compile time are now available in the compiled firewall
script.The iprange and ipaddr
commands require the 'bc' utility.Beginning with Shorewall 4.4.26, the WIDE_TC_MARKS and
HIGH_ROUTE_MARKS options are deprecated in favor of TC_BITS,
MASK_BITS, PROVIDER_BITS and PROVIDER_OFFSET. See the Packet Marking using
/etc/shorewall/tcrules article. The shorewall
update (shorewall6 update) command will
automatically generate the correct values for these new options
depending on your settings of WIDE_TC_MARKS and
HIGH_ROUTE_MARKS.Be sure to check the latest 4.4 Release Notes linked from the home page.Versions >= 4.2.0Previously, when HIGH_ROUTE_MARKS=Yes, Shorewall allowed
non-zero mark values < 256 to be assigned in the OUTPUT chain. This
has been changed so that only high mark values may be assigned there.
Packet marking rules for traffic shaping of packets originating on the
firewall must be coded in the POSTROUTING table.Previously, Shorewall did not range-check the value of the
VERBOSITY option in shorewall.conf. Beginning with Shorewall 4.2: a) A
VERBOSITY setting outside the range -1 through 2 is rejected. b) After
the -v and -q options are applied, the resulting value is adjusted to
fall within the range -1 through 2.Specifying a destination zone in a NAT-only rule now generates a
warning and the destination zone is ignored. NAT-only rules
are:NONATREDIRECT-DNAT-The default value for LOG_MARTIANS has been changed. Previously,
the defaults were: Shorewall-perl - 'Off' Shorewall-shell - 'No' The
new default values are:Shorewall-perl'On.Shorewall-shell'Yes'Shorewall-perl users may:Accept the new default -- martians will be logged from all
interfaces with route filtering except those with log_martians=0
in /etc/shorewall/interfaces.Explicitly set LOG_MARTIANS=Off to maintain compatibility
with prior versions of Shorewall.Shorewall-shell users may:Accept the new default -- martians will be logged from all
interfaces with the route filtering enabled.Explicitly set LOG_MARTIANS=No to maintain compatibility
with prior versions of Shorewall.The value of IMPLICIT_CONTINUE in shorewall.conf (and samples)
has been changed from Yes to No. If you are a Debian or Ubuntu user
and you select replacement of shorewall.conf during upgrade to
Shorewall 4.2, you will want to change IMPLICIT_CONTINUE back to 'Yes'
if you have nested zones that rely on IMPLICIT_CONTINUE=Yes for proper
operation.The 'norfc1918' option is deprecated. Use explicit rules
instead. Note that there is a new 'Rfc1918' macro that acts on
addresses reserved by RFC 1918.DYNAMIC_ZONES=Yes is no longer supported by Shorewall-perl. Use
ipset-based zones instead.Versions >= 4.0.0-Beta7Beginning with Shorewall 4.0.0, there is no single 'shorewall'
package. Rather there are two compiler packages (shorewall-shell and
shorewall-perl) and a set of base files (shorewall-common) required by
either compiler package.Although the names of the packages are changing, you can upgrade
without having to uninstall/reinstall.To repeat: You do not need to uninstall
any existing package.If you attempt to upgrade using the shorewall-common RPM, you
get this result:gateway:~ # rpm -Uvh shorewall-common-4.0.0.noarch.rpm
error: Failed dependencies:
shorewall_compiler is needed by shorewall-common-4.0.0-1.noarch
gateway:~ #You must either:rpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpmorrpm -Uvh shorewall-shell-4.0.0.noarch.rpm shorewall-perl-4.0.0.noarch.rpm shorewall-common-4.0.0.noarch.rpmIf
you don't want shorewall-shell, you must use the second command
(installing both shorewall-shell and shorewall-perl) then remove
shorewall-shell using this command:rpm -e shorewall-shellIf
you are upgrading using the tarball, you must install shorewall-shell
and/or shorewall-perl before you upgrade using shorewall-common.
Otherwise, the install.sh script fails with:ERROR: No Shorewall compiler is installedThe shorewall-shell and shorewall-perl packages are
installed from the tarball in the expected way; untar the package, and
run the install.sh script.Example 1: You have 'shorewall' installed and you want to
continue to use the shorewall-shell compiler.tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-shell-4.0.0.tar.bz2
pushd shorewall-shell-4.0.0
./install.sh
popd
pushd shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restartExample 2: You have shorewall
3.4.4 and shorewall-perl 4.0.0-Beta7 installed and you want to upgrade
to 4.0. You do not need the shell-based compiler.tar -jxf shorewall-common-4.0.0.tar.bz2
tar -jxf shorewall-perl-4.0.0.tar.bz2
pushd shorewall-perl-4.0.0
./install.sh
popd
pushd /shorewall-common-4.0.0
./install.sh
shorewall check
shorewall restart The RPMs are set up so that if
you upgrade an existing Shorewall installation as part of a
distribution upgrade and you have not already installed
shorewall-perl, then you will end up with Shorewall-common and
Shorewall-shell installed.The ROUTE_FILTER and LOG_MARTIANS options in shorewall.conf work
slightly differently in Shorewall 4.0.0. In prior releases, leaving
these options empty was equivalent to setting them to 'No' which
caused the corresponding flag in /proc to be reset for all interfaces.
Beginning in Shorewall 4.0.0, leaving these options empty causes
Shorewall to leave the flags in /proc as they are. You must set the
option to 'No' in order to obtain the old behavior.The option is now the default for ipsec
tunnels. Tunnels that use AH (protocol 51) must specify
in the TYPE column.Users upgrading from Debian Etch (Shorewall 3.2.6) to Debian
Lenny (Shoreall 4.0.15) report finding an issue with VOIP (Asterisk)
traffic. See Shorewall FAQ 77 for
details.Versions >= 3.4.0-Beta1Shorewall supports the notion of "default actions". A default
action defines a set of rules that are applied before a policy is
enforced. Default actions accomplish two goals:Relieve log congestion. Default actions typically include
rules to silently drop or reject traffic that would otherwise be
logged when the policy is enforced.Insure correct operation. Default actions can also avoid
common pitfalls like dropping connection requests on TCP port 113.
If these connections are dropped (rather than rejected) then you
may encounter problems connecting to Internet services that
utilize the AUTH protocol of client authentication.In prior Shorewall versions, default actions (action.Drop and
action.Reject) were defined for DROP and REJECT policies in
/usr/share/shorewall/actions.std. These could be
overridden in /etc/shorewall/actions.This approach has two drawbacks:All DROP policies must use the same default action and all
REJECT policies must use the same default action.Now that we have modularized action processing,
we need a way to define default rules for a policy that does not
involve actions.If you have not overridden the defaults using entries in
/etc/shorewall/actions then you need make no
changes to migrate to Shorewall version 3.4. If you have overridden
either of these entries, then please read on.The change in version 3.4 is two-fold:Four new options have been added to the
/etc/shorewall/shorewall.conf file that allow
specifying the default action for DROP, REJECT, ACCEPT and
QUEUE.The options are DROP_DEFAULT, REJECT_DEFAULT, ACCEPT_DEFAULT
and QUEUE_DEFAULT.DROP_DEFAULT describes the rules to be applied before a
connection request is dropped by a DROP policy; REJECT_DEFAULT
describes the rules to be applied if a connection request is
rejected by a REJECT policy. The other two are similar for ACCEPT
and QUEUE policies. The value assigned to these may be:The name of an action.The name of a macro.'None' or 'none'The default values are:DROP_DEFAULT="Drop"REJECT_DEFAULT="Reject"ACCEPT_DEFAULT=noneQUEUE_DEFAULT=noneIf USE_ACTIONS=Yes, then these values refer to action.Drop
and action.Reject respectively. If USE_ACTIONS=No, then these
values refer to macro.Drop and macro.Reject.If you set the value of either option to "None" then no
default action will be used and the default action or macro (if
any) must be specified in
/etc/shorewall/policy.The POLICY column in /etc/shorewall/policy has been
extended.In /etc/shorewall/policy, when the
POLICY is DROP, REJECT, ACCEPT or QUEUE then the policy may be
followed by ":" and one of the following:The word "None" or "none". This causes any default
action defined in
/etc/shorewall/shorewall.conf to be
omitted for this policy.The name of an action (requires that USE_ACTIONS=Yes in
shorewall.conf). That action will be
invoked before the policy is enforced.The name of a macro. The rules in that macro will be
applied before the policy is enforced. This does not require
USE_ACTIONS=Yes.Example:#SOURCE DEST POLICY LOG
# LEVEL
loc net ACCEPT
net all DROP:MyDrop info
#
# THE FOLLOWING POLICY MUST BE LAST
#
all all REJECT:MyReject infoThe 'Limit' action is now a builtin. If you have 'Limit' listed
in /etc/shorewall/actions, remove the entry. Also
remove the files /etc/shorewall/action.Limit
and/or /etc/shorewall/Limit if you have
them.This issue only applies if you have entries in
/etc/shorewall/providers.Previously, Shorewall has not attempted to undo the changes it
has made to the firewall's routing as a result of entries in
/etc/shorewall/providers and
/etc/shorewall/routes. Beginning with this
release, Shorewall will attempt to undo these changes. This change can
present a migration issue in that the initial routing configuration
when this version of Shorewall is installed has probably been changed
by Shorewall already. Hence, when Shorewall restores the original
configuration, it will be installing a configuration that the
previously-installed version has already modified.The steps to correcting this after you have installed version
3.4 or later of Shorewall are as follows:shorewall[-lite] stopRemove the files
/var/lib/shorewall[-lite]/default_route and
/var/lib/shorewall[-lite]/undo_routing if
they exist.Either restart networking or reboot.shorewall[-lite] startThis issue only applies if you run Shorewall Lite.The /etc/shorewall-lite/shorewall.conf file
has been renamed
/etc/shorewall-lite/shorewall-lite.conf. When you
upgrade, your shorewall.conf file will be renamed
shorewall-lite.conf.Version >= 3.2.0If you are upgrading from version 2.4 or earlier, please read
the 3.0.0 upgrade considerations below.A number of macros have been split into two. The macros affected
are:IMAPLDAPNNTPPOP3SMTPEach of these macros now handles only traffic on the native
(plaintext) port. There is a corresponding macro with S added to the
end of the name for the SSL version of the same protocol. Thus each
macro results in the insertion of only one port per invocation. The
Web macro has not been split, but two new macros, HTTP and HTTPS have
been created. The Web macro is deprecated in favour of these new
macros, and may be removed from future Shorewall releases.These changes have been made to ensure no unexpected ports are
opened due to the use of macros.In previous Shorewall releases, DNAT and REDIRECT rules
supported a special syntax for exclusion of a subnet from the effect
of the rule.Example:
Z2 is a subzone of Z1:DNAT Z1!Z2 loc:192.168.1.4 ...
That feature has never worked correctly when Z2 is a dynamic
zone. Furthermore, now that Shorewall supports exclusion lists, the
capability is redundant since the above rule can now be written in the
form:DNAT Z1:!<list of exclusions> loc:192.168.1.4 ...Beginning with Shorewall 3.2.0, the special exclusion syntax
will no longer be supported.Important if you use the QUEUE target.In the /etc/shorewall/rules file and in actions, you may now
specify 'tcp:syn' in the PROTO column. 'tcp:syn' is equivalent to
'tcp' but also requires that the SYN flag is set and the RST, FIN and
ACK flags be off ("--syn" is added to the iptables rule).As part of this change, Shorewall no longer adds the "--syn"
option to TCP rules that specify QUEUE as their target.Extension Scripts may require changeIn previous releases, extension scripts were executed during
[re]start by using the Bourne Shell "." operator.
In addition to executing commands during [re]start,
these scripts had to "save" the commands to be executed during
shorewall restore.This clumsiness has been eliminated in Shorewall 3.2. In
Shorewall 3.2, extension scripts are copied in-line into the compiled
program and are executed in-line during start,
restart and restore. This
applies to all extension scripts except those associated with a chain
or action -- those extension scripts continue to be processed at
compile time.This new approach has two implications for existing
scripts.It is no longer necessary to save the commands; so functions
like 'save_command', 'run_and_save_command' and
'ensure_and_save_command' need no longer be called. The generated
program will contain functions with these names:save_command() - does nothingrun_and_save_command() - runs the passed
commandensure_and_save_command() - runs the passed command and
stops the firewall if the command fails.These functions should provide for transparent migration of
scripts that use them until you can get around to eliminating
their use completely.When the extension script is copied into the compiled
program, it is indented to line up with the surrounding code. If
you have 'awk' installed on your system, the Shorewall compiler
will correctly handle line continuation (last character on the
line = "\"). If you do not have awk, it will not be possible to
use line-continuation in your extension scripts. In no case is it
possible to continue a quoted string over multiple lines without
having additional whitespace inserted into the string.Beginning with this release, the way in which packet marking in
the PREROUTING chain interacts with the 'track' option in
/etc/shorewall/providers has changed in two ways:Packets arriving on a tracked interface are now passed to
the PREROUTING marking chain so that they may be marked with a
mark other than the 'track' mark (the connection still retains the
'track' mark).When HIGH_ROUTE_MARKS=Yes, you can still clear the mark on
packets in the PREROUTING chain (i.e., you can specify a mark
value of zero).Kernel version 2.6.16 introduces 'xtables', a new common packet
filtering and connection tracking facility that supports both IPv4 and
IPv6. Because a different set of kernel modules must be loaded for
xtables, Shorewall now includes two 'modules' files:/usr/share/shorewall/modules -- the
former /etc/shorewall/modules/usr/share/shorewall/xmodules -- a new file that support
xtables.If you wish to use the new file, then simply execute this
command:cp -f /usr/share/shorewall/xmodules
/etc/shorewall/modules(Versions >= 3.2.3)
Previously, CLASSIFY tcrules were always processed out of the
POSTROUTING chain. Beginning with this release, they are processed out
of the POSTROUTING chain *except* when the SOURCE is
$FW[:<address>] in which case the rule is processed out of the
OUTPUT chain.With correctly-coded rulesets, this change should have no
effect. Users having incorrectly-coded tcrules may need to change
them.Example:
#MARK/ SOURCE DEST PROTO DEST SOURCE
#CLASSIFY PORTS(S) PORT(S)
1:110 $FW eth3 tcp - 22
While the user may have expected this rule to only affect
traffic from the firewall itself, the rule was really equivalent to
this one:
#MARK/ SOURCE DEST PROTO DEST SOURCE
#CLASSIFY PORTS(S) PORT(S)
1:110 0.0.0.0/0 eth3 tcp - 22
So after this change, the second rule will be required rather
than the first if that is what was really wanted.Version >= 3.0.0The "monitor" command has been eliminated.The "DISPLAY" and "COMMENTS" columns in the /etc/shorewall/zones
file have been removed and have been replaced by the former columns of
the /etc/shorewall/ipsec file. The latter file has been
removed.Additionally the FW option in shorewall.conf has been deprecated
and is no longer set to 'fw' by default. New users are expected to
define the firewall zone in /etc/shorewall/zones.Adhering to the principle of least astonishment, the old
/etc/shorewall/ipsec file will continue to be
supported. A new IPSECFILE variable in /etc/shorewall/shorewall.conf
determines the name of the file that Shorewall looks in for IPSEC
information. If that variable is not set or is set to the empty value
then IPSECFILE=ipsec is assumed. So if you simply upgrade and don't do
something idiotic like replace your current shorewall.conf file with
the new one, your old configuration will continue to work. A dummy
'ipsec' file is included in the release so that your package manager
(e.g., rpm) won't remove your existing file.The shorewall.conf file included in this release sets
IPSECFILE=zones so that new users are expected to use the new zone file
format.The DROPINVALID option has been removed from shorewall.conf. The
behavior will be as if DROPINVALID=No had been specified. If you wish
to drop invalid state packets, use the dropInvalid built-in
action.The 'nobogons' interface and hosts option as well as the
BOGON_LOG_LEVEL option have been eliminated.Most of the standard actions have been replaced by parameterized
macros (see below). So for example, the action.AllowSMTP and
action.DropSMTP have been removed an a parameterized macro macro.SMTP
has been added to replace them.In order that current users don't have to immediately update
their rules and user-defined actions, Shorewall can substitute an
invocation of the a new macro for an existing invocation of one of the
old actions. So if your rules file calls AllowSMTP, Shorewall will
replace that call with SMTP(ACCEPT). Because this substitution is
expensive, it is conditional based on the setting of MAPOLDACTIONS in
shorewall.conf. If this option is set to YES or if it is not set (such
as if you are using your old shorewall.conf file) then Shorewall will
perform the substitution. Once you have converted to use the new
macros, you can set MAPOLDACTIONS=No and invocations of those actions
will go much quicker during 'shorewall [re]start'.The STATEDIR variable in /etc/shorewall/shorewall.conf has been
removed. STATEDIR is now fixed at /var/lib/shorewall. If you have
previously set STATEDIR to another directory, please copy the files
from that directory to /var/lib/shorewall/ before [re]starting
Shorewall after the upgrade to this version.The "shorewall status" command now just gives the status of
Shorewall (started or not-started). The previous status command has
been renamed "dump". The command also shows the state relative to the
state diagram at http://shorewall.net/starting_and_stopping_shorewall.htm.
In addition to the state, the time and date at which that state was
entered is shown.Note that at least one "shorewall [re]start" must be issued
after upgrading to this release before "shorewall status" will show
anything but "Unknown" for the state.The "shorewall forget" command now removes the dynamic blacklist
save file (/var/lib/shorewall/save).In previous versions of Shorewall, the rules generated by
entries in /etc/shorewall/tunnels preceded those
rules generated by entries in
/etc/shorewall/rules. Beginning with this
release, the rules generated by entries in the tunnels file will
appear *AFTER* the rules generated by the rules file. This may cause
you problems if you have REJECT, DENY or CONTINUE rules in your rules
file that would cause the tunnel transport packets to not reach the
rules that ACCEPT them. See http://www.shorewall.net/VPNBasics.html
for information on the rules generated by entries in the tunnels
file.The NEWNOTSYN and LOGNEWNOTSYN options in shorewall.conf have
been removed as have the 'newnotsyn' options in
/etc/shorewall/interfaces and
/etc/shorewall/hosts.TCP new-not-syn packets may be blocked using the 'dropNotSyn' or
'rejNotSyn' built-in actions.Example: Reject all new-not-syn packets from the net and log
them at the 'info' level.#ACTION SOURCE DEST PROTO
SECTION NEW
rejNotSyn:info net all tcpNote that the rule is added at the front of the NEW section of
the rules file.A new TC_SCRIPT option replaces TC_ENABLED in shorewall.conf. If
the option is not set then the internal shaper (tc4shorewall by Arne
Bernin) is used. Otherwise, the script named in the variable is
used.Users who currently use an
/etc/shorewall/tcstart file and wish to continue
to do so should set TC_SCRIPT=/etc/shorewall/tcstart in
shorewall.conf.Version >= 2.4.0Shorewall now enforces the restriction that mark values used in
/etc/shorewall/tcrules are less than 256. If you
are using mark values >= 256, you must change your configuration
before you upgrade.The value "ipp2p" is no longer accepted in the PROTO column of
the /etc/shorewall/rules file. This support has
never worked as intended and cannot be made to work in a consistent
way. A "Howto" article on filtering P2P with Shorewall and ipp2p will
be forthcoming.LEAF/Bering packages for 2.4.0 and later releases are not
available from shorewall.net. See the LEAF site for those
packages.
shorewall-docs-xml-4.5.21/traffic_shaping_ru.xml 0000644 0001750 0001750 00000213115 12222401136 021576 0 ustar teastep teastep
Управление трафиком и шейпинг трафикаTomEastepArneBernin2001-2007Thomas M. Eastep2005Arne Bernin & Thomas M. Eastep2007Russian Translation: Grigory MokhinЭтот документ разрешается копировать, распространять и/или
изменять при выполнении условий лицензии GNU Free Documentation License
версии 1.2 или более поздней, опубликованной Free Software Foundation;
без неизменяемых разделов, без текста на верхней обложке, без текста на
нижней обложке. Копия лицензии приведена по ссылке GNU Free Documentation
License.Управление трафиком - это сложная тема, и не следует ожидать от
сообщества Shorewall готовых ответов на возникающие в связи с этим
вопросы. Поэтому, если вам нужны готовые рецепты, как нажать кнопку, чтобы
все заработало само, лучше даже не пытайтесь организовать управление
трафиком с помощью Shorewall. Вас ожидают неприятные разочарования, и вряд
ли кто-либо сможет вам помочь.Иначе говоря, чтение только документации Shorewall не будет
достаточным для понимания раскрываемых здесь тем.Как минимум, потребуется обратиться к следующим дополнительным
источникам:LARTC HOWTO: http://www.lartc.orgРуководство по HTB: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htmНекоторые документы с сайта http://www.netfilter.org/documentation/index.html#documentation-howto.
Рекомендуем ознакомиться с очень хорошим руководством Оскара
Андреассона.Вывод команды man iptablesВведениеНачиная с версии 2.5.5 в Shorewall реализована встроенная поддержка
управления трафиком и шейпинга трафика. В более ранних версиях эти
возможности были ограниченными. Можно было использовать собственный
сценарий tcstart (это можно и сейчас), но, за исключением файла tcrules, в
файлах конфигурации Shorewall не была предусмотрена возможность
определения классов и дисциплин очередей.До сих пор поддержка управления трафиком является неполной,
например, не поддерживаются все опции (и особенно различные алгоритмы
очередей) из ядра Linux, но для большинства случаев она будет достаточной.
Если у вас уже есть сценарий для управления трафиком, который вы
собираетесь использовать и в будущем, то соответствующие инструкции
приведены по ссылке ниже в этом
документе. Для того чтобы это заработало, требуется включить
поддержку управления трафиком в ядре и в Shorewall, как описано
далее.Управление трафиком и шейпинг трафика в LinuxВ этом разделе кратко описано, как работает управление трафиком в
Linux. Даже если этого должно быть достаточно для настройки управления
трафиком в файлах конфигурации Shorewall, мы очень рекомендуем внимательно
прочитать руководство Linux Advanced
Routing and Shaping HOWTO. Во время написания этого документа
текущей версией была 1.0.0.Начиная с версии 2.2, в Linux реализованы полные возможности
управления трафиком. Предусмотрены различные алгоритмы, которые
применяются для приоритизации очередей пакетов, выходящих с интерфейса.
Стандартный алгоритм называется pfifo, и, как следует из самого названия,
это очередь типа первым пришел - первым ушел. Фактически при этом никакого
управления трафиком не происходит, и если какое-то соединение забивает
весь канал, то этот алгоритм не сможет этого предотвратить.Для управления трафиком в Shorewall используются два алгоритма, HTB
(иерархический набор маркеров) и SFQ (очередь с равноправным
стохастическим упорядочением). SFQ использует простую схему: отслеживаются
все соединения (tcp или udp), и трафик распределяется между ними. Обычно
это работает хорошо. HTB позволяет определить набор классов, между
которыми распределяется трафик. Для каждого класса можно указать
минимальную и максимальную полосу пропускания, а сами классы упорядочить в
иерархическую структуру, чтобы классы с меньшим приоритетом получали
доступ к каналу только в том случае, если запросы более важных классы
удовлетворены. Встроенные функции управления трафиком в Shorewall
позволяют определить такие классы и указать для них полосу пропускания.
Внутри самих классов используется SFQ, чтобы их различные внутренние
потоки данных обрабатывались как равноправные.Управлять можно только исходящим трафиком.
Причина этого состоит в том, что входящие пакеты уже пришли на сетевую
плату, и нужно решить, что с ними делать. Их можно только
сбросить, но особого смысла в этом не будет, поскольку пакет уже пришёл,
пройдя через узкое место - входящий канал. Следующим узким местом может
быть интерфейс, с которого уходит этот пакет, и именно на нём может
образовываться очередь. Поэтому определение очередей для входящих пакетов
не будет особенно полезным, эти пакеты просто нужно передать как можно
быстрее на исходящий интерфейс.Есть одно исключение. Если ограничить входящий трафик значением чуть
меньшим, чем фактическая пропускная способность канала, то будет исключено
образование очередей на другом конце соединения. Это бывает полезно, если
управление потоком на другом конце канала невозможно, а сам он подключен к
сети по более быстрому каналу, например, если вы подключены к провайдеру
по кабельному модему или модему DSL, а маршрутизатор провайдера подключен
к быстрому магистральному каналу. Поэтому, если отбрасывать слишком быстро
приходящие пакеты, то основной протокол сможет это обнаружить и снизить
скорость соединения. В TCP такой механизм встроен, в UDP не встроен, но
протокол, работающий поверх UDP, может иметь такой механизм.В таких случаях создание очередей будет иметь неприятные
последствия, если есть пакеты, которые должны проходить в первую очередь,
как, например, VoIP или ssh. Для таких соединений важно, чтобы пакеты
проходили с минимальной задержкой. Для других пакетов, таких как загрузка
по HTTP, задержка на несколько секунд не будет иметь значения.Если на другом конце канала образуется очередь, а маршрутизатор не
поддерживает QoS или биты QoS настроены неверно, то пакеты, для которых
важна минимальная задержка, будут ждать в той же очереди, что и менее
важные пакеты загрузки по HTTP, и задержка может быть большой.Управление исходящим трафиком достигается посредством распределения
потока пакетов по классам. Класс связан ровно с
одним сетевым интерфейсом и имеет ряд атрибутов:PRIORITY - используется для указания приоритетов классов, к
которым относятся отправляемые пакеты. Приоритет - это число, при этом
1 задаёт наивысший приоритет, 2 - следующий по важности и т.д.RATE - скорость, то есть минимальная гарантированная пропускная
способность, которая должна обеспечиваться для класса, когда
возрастает нагрузка на канал. Классы с более высоким приоритетом
(меньшие значения PRIORITY) обслуживаются даже в том случае, если
заданы другие классы с гарантированной пропускной способностью, но
низшим приоритетом (большие значения PRIORITY).CEIL - ограничение, максимальная полоса пропускания, которая
отводится для класса, когда канал свободен.MARK - метка. В Netfilter предусмотрены способы
маркировки пакетов. Метки пакетов - это числа.
В Shorewall они могут принимать значение от 1 до 255. Метки пакетов
присваиваются различным типам пакетов согласно правилам, заданным в
файле /etc/shorewall/tcrules.Для каждого интерфейса необходимо задать один класс, который будет
классом по умолчанию. К этому классу будут
относиться непомеченные данные, то есть пакеты, для которых не задана
метка в файле /etc/shorewall/tcrules.Netfilter также поддерживает метки соединений. Метки соединений
можно присвоить соединениям в правилах
/etc/shorewall/tcrules, можно скопировать метку
пакета в метку соединения (SAVE), или скопировать метку соединения в метку
пакета (RESTORE).Конфигурация ядра LinuxДля работы требуется ядро не ниже 2.4.18. На рисунке показаны опции
ядра, которые необходимо включить. Для встроенной поддержки необходимы
опции HTB scheduler, Ingress scheduler, PRIO pseudoscheduler и SFQ queue.
Прочие планировщики или алгоритмы очередей необязательны.Также требуются классификаторы u32 и fw из главного меню Networking
Options (не показаны).На следующем рисунке показано, как я настроил QoS у себя в ядре
2.6.13:Конфигурация ядра изменилась в 2.6.16 -- вот мои
рекомендации.Включение поддержки TC в ShorewallПоддержку TC требуется включить независимо от того, применяются ли
встроенные функции или вы используете собственный сценарий tcstart.Для включения встроенных функций управления трафиком в Shorewall
выполните следующее:Задайте TC_ENABLED равным
"Internal" в /etc/shorewall/shorewall.conf. Если TC_ENABLED=Yes, то
Shorewall будет искать внешний файл tcstart (см. далее).Если задать параметр CLEAR_TC в
/etc/shorewall/shorewall.conf равным Yes, то при запуске, перезапуске
и остановке Shorewall будет сбрасываться текущая конфигурация
управления трафиком. Обычно именно это и требуется при работе с
встроенными функциями, а также с собственным сценарием tcstart.Следующие действия зависят от того, применяются ли встроенные
функции или собственный сценарий. Подробнее это объясняется в
следующих разделах.Работа с встроенными функциями управления трафиком и
шейпингаВстроенные в Shorewall функции управления трафиком - это тонкая
оболочка для очереди входящих пакетов (ingress qdisc), HTB и SFQ. Эта
оболочка позволяет выполнить следующие задачи:Определить классы HTB в файлах конфигурации Shorewall.Включить загрузку конфигурации управления трафиком вместе с
загрузкой правил фильтрации пакетов и правил для меток.Распределить пакеты по классам HTB согласно значениям
TOS.Отнести исходящие пакеты TCP ACK к классу HTB.Распределить пакеты по классам HTB согласно значениям меток
пакетов.Встроенные в Shorewall функции управления трафиком ограничены
десятью (10) устройствами.Больше никаких задач встроенные функции управления трафиком не
выполняют. Поэтому, чтобы их использовать, необходимо понимать, как
работает HTB и управление трафиком в Linux, и как работают метки пакетов
Netfilter. За дополнительной информацией обратитесь к ссылкам, приведенным
в начале этого документа.Для задания пропускной способности (как устройств, так и классов)
используйте kbit или kbps (для килоБАЙТ в секунду) БЕЗ пробела между числом и единицей измерения (то
есть 100kbit НО НЕ 100 kbit). Можно также
использовать mbit, mbps или число (означающее байты), но поддерживаются
только целые числа (0.5 использовать нельзя).Для того чтобы правильно настроить устройства, необходимо выяснить
фактическую пропускную способность канала в обоих направлениях. Это
особенно важно для соединений DSL или любых других, для которых пропускная
способность канала не гарантирована. Не верьте числам, которые называет
провайдер, но сами измерьте реальную скорость канала. В этом могут помочь
различные утилиты в сети, попробуйте поискать "dsl speed test" в google
(для Германии можно использовать arcor speed
check). Найдите тест поближе к себе./etc/shorewall/tcdevicesВ этом файле можно задать пропускную способность способность
канала для устройств, для которых будет включено управление трафиком.
Это означает, что в этом файле необходимо определить параметры для
устройства, чтобы для него заработало управление трафиком.Далее описаны столбцы файла:INTERFACE - Имя интерфейса. Интерфейс может быть указан не
более одного раза. Использовать псевдоним интерфейса (например,
eth0:0) здесь нельзя, см. FAQ
#18. Также нельзя использовать символы подстановки,
например, если есть несколько интерфейсов ppp, то все их необходимо
здесь перечислить. В версиях Shorewall до 3.0.8 и 3.2.0 Beta 8,
устройство, имя которого указано в столбце, должно было существовать
в момент запуска, перезапуска или обновления Shorewall. Начиная с
версии 3.0.8 и 3.2.0 Beta 8 Shorewall может определить, существует
ли устройство, и настроит его только в том случае, если оно
существует. Если оно не существует, то будет показано следующее
предупреждение:WARNING: Device <устройство> not
found -- traffic-shaping configuration skippedIN-BANDWIDTH - Пропускная способность входящего канала для
этого интерфейса. Обратите внимание, что шейпинг входящего трафика
невозможен, так как пакеты уже пришли. В этом столбце можно задать
максимальную скорость, разрешенную для этого интерфейса, при
превышении которой пакеты будут отбрасываться. Это полезно главным
образом для соединений DSL или кабельных, чтобы избежать очередей в
устройствах провайдера. Если не следует отбрасывать никакие пакеты,
то укажите значение, превышающее фактическую максимальную скорость
канала (в Shorewall начиная с версии 3.2.6 можно также указать
0).Для того чтобы определить оптимальное значение, укажите
сначала значение, которое заведомо ниже, чем измеренная скорость
канала (процентов на 20). Далее, в ходе загрузки файлов, измеряйте
время ответа на ping между своей системой и
маршрутизатором провайдера и постепенно увеличивайте это значение.
Оптимальным будет значение, при превышении которого время ответа на
ping будет резко расти.OUT-BANDWIDTH - Пропускная способность исходящего канала для
этого интерфейса. Это максимальная скорость, с которой может
работать исходящее соединение. В терминах классов tc эта скорость
называется полной (full). Превышающий эту скорость исходящий трафик
будет отбрасываться.Предположим, что вы работаете с PPP по Ethernet (DSL), а
интерфейс - это ppp0. Устройство имеет исходящую скорость 500 кбит и
входящую - 6000 кбит#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 6000kbit 500kbit/etc/shorewall/tcclassesВ этом файле можно задать классы, по которым будет распределяться
исходящий трафик.INTERFACE - Имя интерфейса. Должно совпадать с именем
интерфейса в файле
/etc/shorewall/tcdevices.MARK - метка. Должна быть целым числом от 1 до 255. Эти метки
задаются в файле tcrules. Они помечают пакеты, которые тем самым
будут отнесены к определенным здесь классам очередей. Одни и те же
метки могут использоваться для разных интерфейсов.RATE - скорость, то есть минимальная гарантированная
пропускная способность, которая должна обеспечиваться для класса,
когда возрастает нагрузка на канал. Классы с более высоким
приоритетом обслуживаются даже в том случае, если заданы другие
классы с гарантированной пропускной способностью, но низшим
приоритетом. Если сумма значений RATE для всех
классов, присвоенных интерфейсу, превышает OUT-BANDWIDTH для
интерфейса, то предел OUT-BANDWIDTH не будет
соблюдаться.CEIL - ограничение, максимальная полоса пропускания, которая
отводится для данного класса, когда канал свободен. Это полезно,
если есть трафик, для которого будет выделяться полная скорость
канала, если более важные службы (такие как ssh) не используются.
Значение "full" означает, что максимальная пропускная способность
для класса определяется значением, заданным для интерфейса.PRIORITY - позволяет указать приоритет для класса. Пакеты из
класса с более высоким приоритетом (то есть меньшим значением) будут
обрабатываться раньше, чем пакеты с низшим приоритетом. Здесь можно
просто указать значение метки, если метки присваиваются согласно
приоритетам.OPTIONS - Список параметров через запятую. Возможны следующие
параметры:default - класс по умолчанию для интерфейса, к которому
будет отнесен весь трафик, не отнесенный к другим
классам.Необходимо указать default ровно для одного класса для интерфейса.tos-<имя-tos> - позволяет указать фильтр для
заданного <имени-tos>, что в свою очередь позволяет
определить значение бит Type Of Service в пакете ip, вследствие
чего пакет будет отнесен к этому классу. Учтите, что этот фильтр
переопределяет все заданные метки, поэтому, если задать фильтр
tos для класса, то все пакеты, имеющие эту метку, войдут в этот
класс независимо от того, какая у них уже есть метка. Возможные
значения этого параметра: tos-minimize-delay (16)
tos-maximize-throughput (8) tos-maximize-reliability (4)
tos-minimize-cost (2) tos-normal-service (0)Каждая из этих опций применима только для одного класса интерфейса.tcp-ack - эта опция создает фильтр tc и класс, в который
помещаются все пакеты tcp ack на этом интерфейсе, размер которых
не превышает 64 байта. Это позволяет ускорить загрузку.
Ограничение размера пакетов ack 64 байтами служит для того,
чтобы исключить из этого класса все приложения (например, p2p),
которые помечают каждый пакет как пакет ack. Этому фильтру
должны соответствовать только пакеты БЕЗ дополнительной
нагрузки, отсюда и ограничение размера. Пакеты большего размера
будут отнесены в другие классы.Эта опция применима только для одного класса интерфейса./etc/shorewall/tcrulesКлассификатор fwmark является удобным средством для классификации
пакетов при управлении трафиком. В файле
/etc/shorewall/tcrules эти метки представлены в виде
таблицы. Глубже познакомиться с маркировкой пакетов в
Netfilter/Shorewall позволяет этот
документ.Обычно метка пакета ставится в цепочке PREROUTING перед тем, как
осуществляется замена адресов. При этом невозможно помечать входящие
пакеты согласно их целевому адресу, если применяется SNAT или
Masquerading. Тем не менее, можно осуществлять маркировку пакетов в
цепочке FORWARD, если задать опцию MARK_IN_FORWARD_CHAIN в файле
shorewall.conf.Далее описаны столбцы файла:MARK или CLASSIFY - MARK задает значение метки, которая
присваивается пакету в случае совпадения с правилом. Она должна быть
целым числом от 1 до 255. Вслед за этим значением может идти
: и одно из значений: F,
P или "T", которые обозначают соответственно
маркировку в цепочках FORWARD, PREROUTING или POSTROUTING. Если эти
дополнительные спецификаторы опущены, то цепочка, в которой
осуществляется маркировка пакетов, определяется следующим
образом:Если SOURCE - это
$FW[:<адрес>], то правило вставляется
в цепочку OUTPUT.В противном случае цепочка определяется по значению опции
MARK_IN_FORWARD_CHAIN из файла shorewall.conf.Спецификатор "T" был добавлен в Shorewall версии 3.3.6 и
недоступен в более ранних версиях.Обычно метка присваивается пакету. Если вслед за меткой
указать ":" и "C", то метка будет применяться к соединению. "C"
можно сочетать с "F", "P" или "T", чтобы указать, что соединение
следует пометить в определенной цепочке (например, "CF", "CP",
"CT").Предусмотрены также следующие специальные значения:RESTORE[/маска] --
восстановить метку пакета из метки соединения, используя маску,
если она указана. Ядро и iptables должны поддерживать
CONNMARK.Как и ранее, можно использовать дополнительные
спецификаторы :P, :F или :T.SAVE[/маска] --
сохранить метку пакета в метке соединения, используя маску, если
она указана. Ядро и iptables должны поддерживать
CONNMARK.Как и ранее, можно использовать дополнительные
спецификаторы :P, :F или :T.CONTINUE - прекратить
обработку дальнейших правил маркировки в таблице.Как и ранее, можно использовать дополнительные
спецификаторы :P, :F или :T.COMMENT (Начиная с
Shorewall версии 3.3.3) -- остальной текст в строке будет
добавлен как комментарий в правила Netfilter, генерируемые по
следующим записям. Комментарий будет выделен символам "/* ...
*/" в выводе команды shorewall show
mangleДля того чтобы комментарий не применялся к последующим
строкам, укажите COMMENT в отдельной строке.При работе с CLASSIFY ядро и iptables должны поддерживать
CLASSIFY. В этом случае в столбце будет содержаться классификатор
(classid) в виде <основной>:<дополнительный>, где
<основной> и <дополнительный> должны быть целыми
числами. Он соответствует указанию 'class' в следующих модулях
управления трафиком:atmcbqdsmarkpfifo_fasthtbprioВ версиях Shorewall до 3.2.3 правила классификации всегда
помещались в цепочку POSTROUTING. Начиная с Shorewall версии 3.2.3
классификация осуществляется в цепочке POSTROUTING, кроме тех случаев, когда SOURCE содержит
$FW[:<адрес>], для которых классификация
осуществляется в цепочке OUTPUT. При работе со встроенными функциями
управления трафиком класс <основной> - это номер устройства
(первая запись в файле /etc/shorewall/tcdevices
- это устройство 1, вторая - устройство 2 и т.д.), а класс
<дополнительный> - это значение MARK класса, перед которой
стоит число "1" (для MARK со значением 1 <дополнительный>
класс - это 11, для MARK со значением 22 - <дополнительный>
класс 122, и т.д.).SOURCE - источник пакета. Это может быть разделенный запятыми
список имен интерфейсов, IP-адресов, MAC-адресов и/или подсетей для
пакетов, маршрутизируемых по общему пути. Элементы списка могут
также включать имя интерфейса, к которому прибавлено ":" и адрес
(например, eth1:192.168.1.0/24). Так, все пакеты для соединений,
маскируемых через eth0 с других интерфейсов, можно описать одним
правилом с несколькими критериями SOURCE. Однако соединение, пакеты
которого приходят на eth0 по другому пути, например, из самой
системы файрвола, требуют отдельного правила.Поэтому создавайте отдельное правило с $FW для пакетов,
исходящих из системы файрвола. В таком правиле столбец MARK не может
содержать ":P" или ":F", поскольку маркировка пакетов, исходящих из
системы файрвола, всегда осуществляется в цепочке OUTPUT.MAC-адреса необходимо предварять символом "~" и использовать
"-" как разделитель.Пример: ~00-A0-C9-15-39-78DEST - назначение пакета. Список IP-адресов и/или подсетей,
разделенный запятыми. Если ядро и iptables поддерживают iprange, то
можно также указывать диапазоны IP-адресов. Элементы списка могут
также включать имя интерфейса, к которому прибавлено ":" и адрес
(например, eth1:192.168.1.0/24). Если в столбце MARK указан
спецификатор в виде <основной>:<дополнительный>, то
столбец может также содержать имя интерфейса.PROTO - протокол. Должен быть указан как "tcp", "udp", "icmp",
"ipp2p", "ipp2p:udp", "ipp2p:all", число или "all". Для "ipp2p"
требуется поддержка ipp2p в ядре и iptables.PORT(S) - целевые порты. Список имен портов (из
/etc/services), номеров портов или диапазонов портов, разделенный
запятыми. Если протокол - это "icmp", то столбец считается целевым
типом icmp.Если протокол - это ipp2p, то столбец интерпретируется как
опция ipp2p без начального "--" (например, "bit" для bit-torrent).
Если PORT не указан, предполагается "ipp2p".Этот поле игнорируется, если PROTOCOL = all, но должно быть
указано, если задано любое из последующих полей. В этом случае
рекомендуется указывать в этом поле "-"CLIENT PORT(S) - необязательные порты, применяемые клиентом.
Если они не указаны, то допускается любой целевой порт. Задается как
список, разделенный запятыми, имен портов, номеров портов или
диапазонов портов.USER/GROUP (Начиная с Shorewall версии 1.4.10) -
Необязательный параметр имени пользователя или группы. Он может
указываться, только если SOURCE - это сама система файрвола. Если
значение поля задано, то правило применяется только в том случае,
если программа, создавшая пакет, работает от имени указанного
пользователя и/или группы. Возможные значения:[!][<имя пользователя или номер>]:[<имя группы или
номер>][+<имя программы>]Двоеточие указывать необязательно, если задано только имя
пользователя.Примеры:joe # программа должна выполняться пользователем joe
:kids # программа выполняется участниками группы 'kids'
!:kids # программа выполняется участниками группы 'kids'
+upnpd # программа upnpd (эта функция была удалена из Netfilter в версии ядра 2.6.14).TEST - задает тест для проверки существующей метки пакета или
соединения. Правило будет совпадать только в том случае, если тест
возвращает true. Тесты имеют следующий формат:
[!]<значение>[/<маска>][:C]Здесь:! Обратное соответствие (не равно)<значение> Значение метки соединения или
пакета.<маска> Маска, применяемая к метке перед
сравнением:C обозначает метку соединения. Если она не указана, то
сравнивается метка пакета.LENGTH - длина пакета (необязательный параметр, начиная с
Shorewall версии 3.2.0). Если указано это значение, то сравнивается
длина пакета с указанным значением или диапазоном значений. Диапазон
задается в виде <мин>:<макс>, где можно опустить или
<мин>, или <макс>, но не оба эти параметра. Если опущен
<мин>, то он считается равным 0, если опущен <макс>, то
совпадающим будет любой пакет, длина которого не меньше
<мин>.Для этой опции необходима поддержка сравнения длины в
iptables. Если значение не указано или задано как "-", то сравнение
длины не выполняется.Примеры: 1024, 64:1500, :100TOS - тип обслуживания (необязательный параметр, начиная с
Shorewall версии 3.2.0 Beta 6). Стандартное имя или число.
Все пакеты, приходящие на eth1, должны иметь метку 1. Все
пакеты, приходящие на eth2 и eth3, должны иметь метку 2. Все пакеты,
созданные в системе файрвола, должны иметь метку 3.#MARK SOURCE DESTINATION PROTOCOL PORT(S)
1 eth1 0.0.0.0/0 all
2 eth2 0.0.0.0/0 all
2 eth3 0.0.0.0/0 all
3 $FW 0.0.0.0/0 allВсе пакеты GRE (протокол 47), не созданные в системе файрвола и
имеющие целевой адрес 155.186.235.151, должны иметь метку 12.#MARK SOURCE DESTINATION PROTOCOL PORT(S)
12 0.0.0.0/0 155.182.235.151 47Все пакеты SSH, приходящие с 192.168.1.0/24 и предназначенные
для 155.186.235.151, должны иметь метку 22.#MARK SOURCE DESTINATION PROTOCOL PORT(S)
22 192.168.1.0/24 155.182.235.151 tcp 22Все пакеты SSH, проходящие через первое устройство в файле
/etc/shorewall/tcdevices, должны быть отнесены в класс с меткой
10.#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT
# PORT(S)
1:110 0.0.0.0/0 0.0.0.0/0 tcp 22
1:110 0.0.0.0/0 0.0.0.0/0 tcp - 22Все пакеты echo ICMP должны иметь метку 1. Весь трафик
протоколов p2p должен иметь метку 4.Это чуть более сложный случай. Поскольку модуль ipp2p не в
состоянии распознать все пакеты в соединении как пакеты P2P, то все
соединение помечается как P2P, если совпадение найдено хотя бы для
одного пакета. Предполагается, что метка пакета/соединения 0 означает
неклассифицированные пакеты.#MARK SOURCE DESTINATION PROTOCOL PORT(S) CLIENT USER/ TEST
# PORT(S) GROUP
1 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
RESTORE 0.0.0.0/0 0.0.0.0/0 all - - - 0
CONTINUE 0.0.0.0/0 0.0.0.0/0 all - - - !0
4 0.0.0.0/0 0.0.0.0/0 ipp2p:all
SAVE 0.0.0.0/0 0.0.0.0/0 all - - - !0Последние четыре правила означают следующее:
"Если пакет не был классифицирован (метка пакета 0), то
скопировать метку соединения в метку пакета. Если метка пакета уже
задана, то никаких действий более не требуется. Если пакет относится
к типу P2P, то задать метку пакета 4. Если метка пакета задана, то
сохранить ее в качестве метки соединения."
Устройства pppЕсли подключение к провайдеру выполняется через ppp/pppoe/pppoa, и
вы используете управление трафиком, то необходимо перезапустить
управление трафиком shorewall. Причина этого состоит в том, что если
соединение ppp перезапускается (обычно это происходит как минимум раз в
день), то все фильтры и qdisc tc, связанные с этим
интерфейсом, будут удалены.Самым простым решением будет перезапуск shorewall при повторном
установлении соединения. Для этого добавьте в сценарий
/etc/ppp/ip-up.d следующую строку.#! /bin/sh
/sbin/shorewall refreshРабочие примерыКонфигурация для замены WondershaperВстроенные функции управления трафиком позволяют полностью
заменить сценарий wondershaper. Примеры файлов конфигурации приведены
по адресу "http://www1.shorewall.net/pub/shorewall/Samples/tc4shorewall/.
Обратите внимание, что эти примеры необходимо настроить, чтобы они
работали в вашей среде. В них предполагается, что интерфейс соединения
с провайдером - это ppp0 (для DSL), и для другого типа соединения его
необходимо изменить. Также требуется изменить параметры в файле
tcdevices.wondershaper, чтобы они отвечали фактической скорости
канала. Ниже приведены соответствующие строки из файлов конфигурации.
В итоге получается точная замена того, что должен делать wondershaper.
Но вы можете и вносить улучшения...Файл tcdevices#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 5000kbit 500kbitФайл tcclasses#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 full full 1 tcp-ack,tos-minimize-delay
ppp0 2 9*full/10 9*full/10 2 default
ppp0 3 8*full/10 8*full/10 2Файл tcrules#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
# PORT(S)
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
# метка для трафика с низким приоритетом:
# mldonkey
3 0.0.0.0/0 0.0.0.0/0 udp - 4666Wondershaper позволяет определить набор хостов и/или портов,
которым присваивается низкий приоритет. Для этого в tcrules этим
хостам нужно присвоить метку 3 (как это делается в примерах файлов
конфигурации).Присвоение низкого приоритета хостамДопустим, что в сценарии wondershaper были следующие параметры
(только в качестве примера):
# Низкий приоритет для исходящего трафика - можно оставить пустым,
# чтобы применять сетевые маски для низкого приоритета
NOPRIOHOSTSRC="192.168.1.128/25 192.168.3.28"
# Низкий приоритет - маска для назначения
NOPRIOHOSTDST=60.0.0.0/24
# Низкий приоритет - порты источника
NOPRIOPORTSRC="6662 6663"
# Низкий приоритет - порты назначения
NOPRIOPORTDST="6662 6663"Эти параметры будут отражены следующим образом в файле
tcrules:3 192.168.1.128/25 0.0.0.0/0 all
3 192.168.3.28 0.0.0.0/0 all
3 0.0.0.0/0 60.0.0.0/24 all
3 0.0.0.0/0 0.0.0.0/0 udp 6662,6663
3 0.0.0.0/0 0.0.0.0/0 udp - 6662,6663
3 0.0.0.0/0 0.0.0.0/0 tcp 6662,6663
3 0.0.0.0/0 0.0.0.0/0 tcp - 6662,6663Простая конфигурацияНиже приведен простой пример для общего подключения к Интернет с
разных компьютеров. Фактически здесь настроен шейпинг для двух хостов
с IP-адресами 192.168.2.23 и 192.168.2.42Файл tcdevices#INTERFACE IN-BANDWITH OUT-BANDWIDTH
ppp0 6000kbit 700kbitКанал имеет входящие 6 мбит и исходящие 700 кбит.Файл tcclasses#INTERFACE MARK RATE CEIL PRIORITY OPTIONS
ppp0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay
ppp0 2 3*full/10 9*full/10 2 default
ppp0 3 2*full/10 8*full/10 2Добавляется класс для пакетов tcp ack с высоким приоритетом,
чтобы ускорить загрузку. Следующие два класса совместно используют
большую часть пропускной способности канала для двух хостов, и если
соединение свободно, то всю пропускную способность. Так как хосты
считаются равноправными, они имеют одинаковый приоритет. Последний
класс предназначен для остального трафика.Файл tcrules#MARK SOURCE DEST PROTO PORT(S) CLIENT USER
# PORT(S)
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request
1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply
2:F 192.168.2.23 0.0.0.0/0 all
3:F 192.168.2.42 0.0.0.0/0 allПакеты ping icmp и ответы помечаются отдельно, как относящиеся
к интерактивному классу. Для них метка ставится для обоих
хостов.Замечания для пользователей XenЕсли управление трафиком включено в dom0, но исходящий трафик при
этом шейпится неправильно, то причиной этого может быть "выгрузка
контрольных сумм" (checksum offloading) в ваших domU. Просмотрите вывод
команды "shorewall show tc". Ниже приведен пример:class htb 1:130 parent 1:1 leaf 130: prio 3 quantum 1500 rate 76000bit ceil 230000bit burst 1537b/8 mpu 0b overhead 0b cburst 1614b/8 mpu 0b overhead 0b level 0
Sent 559018700 bytes 75324 pkt (dropped 0, overlimits 0 requeues 0)
rate 299288bit 3pps backlog 0b 0p requeues 0
lended: 53963 borrowed: 21361 giants: 90174
tokens: -26688 ctokens: -14783В приведенном примере легко обнаружить две проблемы:Скорость (299288) заметно превышает установленный предел
(230000).Сообщается о большом числе огромных пакетов (90174).Эта неполадка устраняется выключением "checksum offloading" в domU с
помощью программы ethtool. За инструкциями обратитесь к
статье по Xen.Применение собственных сценариев tcЗамена встроенного файла tcstartЕсли вы предпочитаете сами создать файл запуска tc, просто
поместите его в /etc/shorewall/tcstart.В сценарии tcstart вместо вызова программы tc
используйте функцию run_tc из Shorewall, чтобы при ошибке tc остановить
файрвол.Задайте TC_ENABLED=Yes и CLEAR_TC=YesУкажите сценарий /etc/shorewall/tcstart с правилами управления
трафиком.Укажите также необязательный сценарий /etc/shorewall/tcclear
для остановки управления трафиком. Обычно это не требуется.Если сценарий tcstart применяет классификатор
fwmark, то можно помечать пакеты, используя записи из
/etc/shorewall/tcrules.Управление трафиком, внешнее по отношению к ShorewallДля того чтобы запустить управление трафиком при поднятии сетевых
интерфейсов, необходимо запустить сценарий управления трафиком именно в
этот момент. Это зависит от применяемого дистрибутива и здесь не
описывается. После этого сделайте следующее:Задайте TC_ENABLED=No и CLEAR_TC=NoЕсли сценарий применяет классификатор fwmark,
то можно помечать пакеты, используя записи из
/etc/shorewall/tcrules.Инструменты тестированияКак минимум один пользователь Shorewall посчитал полезными следующие
инструменты: http://e2epi.internet2.edu/network-performance-toolkit.html
shorewall-docs-xml-4.5.21/FAQ_fr.xml 0000644 0001750 0001750 00000324457 12222401136 017053 0 ustar teastep teastep
FAQ ShorewallVersion Franaise de Shorewall
FAQsShorewall CommunityTomEastepGuyMarcenacAdaptation franaise2001-2006Thomas M. EastepGuy MarcenacPermission est accorde de copier, distribuer et/ou modifier ce
document selon les termes de la Licence de Documentation Libre GNU (GNU
Free Documentation License), version 1.2 ou toute version ultrieure
publie par la Free Software Foundation ; sans section Invariables, sans
premire de Couverture, et sans texte de quatrime de couverture. Une
copie de la prsente Licence est incluse dans la section intitule. Une
traduction franaise de la licence se trouve dans la section
Licence de
Documentation Libre GNU. Ce paragraphe est une
traduction franaise pour aider votre comprhension. Seul le texte
original en anglais prsent ci-dessous fixe les conditions
d'utilisation de cette documentation.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.Notes du traducteur : Si vous
trouvez des erreurs ou si vous avez des amliorations apporter cette
traduction vous pouvez me
contacter.Cet article s'applique Shorewall 3.0 et
ses versions ultrieures. Si vous utilisez une version plus ancienne de
Shorewall, rfrez-vous la documentation s'appliquant votre
version.Installation de ShorewallO puis-je trouver des instructions d'installation et de
configuration pas pas ?Rponse: Allez voir les guides de dmarrage
rapide.(FAQ 37) Je viens d'installer Shorewall sur Debian et le
rpertoire /etc/shorewall est vide!!!Rponse:Aprs avoir install le paquetage .deb, avant de commencer
configurer Shorewall, vous devriez prendre connaissance de ce conseil
de Lorenzo Martignoni, le mainteneur Debian de Shorewall:Pour plus d'information quant l'utilisation de
Shorewall sur un systme Debian vous devriez aller voir le fichier
/usr/share/doc/shorewall/README.Debian distribu avec le paquetage
Debian de Shorewall.Si vous vous servez du .deb pour installer, vous vous rendrez
compte que votre rpertoire /etc/shorewall est
vide. Ceci est voulu. Les squelettes des fichiers de configuration se
trouvent sur votre systme dans le rpertoire /usr/share/doc/shorewall/default-config.
Copiez simplement les fichiers dont vous avez besoin depuis ce
rpertoire dans /etc/shorewall,
puis modifiez ces copies.Remarquez que vous devez copier
/usr/share/doc/shorewall/default-config/shorewall.conf
et /usr/share/doc/shorewall/default-config/modules
dans /etc/shorewall mme si
vous ne modifiez pas ces fichiers.(FAQ 44) Je n'arrive pas installer ou mettre jour le RPM -
J'ai le message d'erreur "error: failed dependencies:iproute is
needed..."Rponse: Lisez les Instructions d'installation!(FAQ 50) Quand j'installe ou que je mets jour, j'obtiens de
multiples instances du message suivant "warning: user teastep does not
exist - using root"Rponse: Vous pouvez sans aucun
risque ignorer ce message. Il tait d une erreur mineure de paquetage
qui a t corrige depuis. Cela ne change rien dans l'utilisation de
Shorewall.Transfert de port (Redirection de Port)(FAQ 1) Je veux rediriger le port UDP 7777 vers mon PC personnel
qui a l'adresse 192.1683.1.5. J'ai cherch partout et je ne trouve pas
comment faire.Rponse: Le premier exemple de la
documentation du fichier
rules vous indique comment faire du transfert de port avec
Shorewall. Le format d'une rgle de redirection de port vers un systme
local se prsente comme suit:#ACTION SOURCE DEST PROTO DEST PORT
DNAT net loc:<adresse IP locale>[:<port local>] <protocole> <n port>Ainsi pour rediriger le port UDP 7777 vers le systme interne
192.168.1.5, la rgle est:#ACTION SOURCE DEST PROTO DEST PORT
DNAT net loc:192.168.1.5 udp 7777Si vous voulez rediriger vers un systme interne les requtes
envoyes une adresse donne (<IP externe>)
sur votre firewall:#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT net loc:<adresse IP locale>[:<port local>]<protocole> <n port> - <IP externe>Enfin, si vous avez besoin de rediriger une plage de ports,
spcifiez la plage de ports <premier port>:<dernier port>
dans la colonne DEST PORT.(FAQ 1a) D'accord -- j'ai suivi toutes ces instruction, mais
cela ne marche toujours pas.Rponse: Ceci se produit
gnralement lorsque:Vous tentez de tester depuis l'intrieur de votre firewall
(non, cela ne marchera pas -- allez voir la FAQ 2 ).Vous avez un problme plus lmentaire de configuration de
votre systme local (celui vers lequel vous tentez de rediriger
les paquets), une mauvaise passerelle par dfaut par exemple (elle
devrait tre configure avec l'adresse IP de l'interface interne
de votre firewall).Votre FAI bloque le trafic entrant sur ce port
particulier.Vous utilisez une version de Mandriva antrieure la 10.0
final et vous avez configur le partage de connexion internet. Si
c'est le cas, le nom de votre zone locale n'est pas 'loc' mais
'masq' (dans vos rgles changez toutes les instances de 'loc' pour
'masq'). Vous pouvez envisager de r-installer Shorewall avec une
configuration conforme la documentation de Shorewall. Voir le
guide Firewall deux
interfaces pour plus de dtails.(FAQ 1b) J'ai malgr tout encore des problmes avec la
redirection de portRponse: pour aller plus avant
dans le diagnostic du problme:En tant que root, tapez iptables -t nat
-Z. Ceci remet zro les compteurs Netfilter
de la table nat.Essayez de vous connecter au port redirig depuis un hte
externe.En tant que root, tapez shorewall[-lite]
show natReprez la rgle DNAT approprie. Elle sera dans une chane
nomme <zone source>_dnat
(net_dnat dans les exemples ci-dessus).Est-ce que le dcompte de paquets dans la premire colonne
est suprieur zro ? Si cela est le cas, la requte de connexion
atteint le firewall et est bien redirige vers le serveur. Dans ce
cas, le problme vient en gnral de l'absence de paramtrage ou
d'un paramtrage erron de la passerelle par dfaut sur le systme
local (celui vers lequel vous essayez de transfrer les paquets --
sa passerelle par dfaut devrait tre l'adresse IP de l'interface
du firewall connecte ce systme local).Si le dcompte de paquets est gal zro:La requte de connexion n'arrive pas jusqu' votre
serveur (il est possible que votre FAI bloque ce port)Vous essayez de vous connecter une adresse IP
secondaire sur votre firewall et votre rgle ne redirige que
l'adresse IP primaire (dans votre rgle DNAT vous devez
spcifier l'adresse IP secondaire dans la colonne ORIG.
DEST.)Pour d'autres raisons, votre rgle DNAT ne correspond
pas la requte de connexion. Dans ce cas, pour aller plus
loin dans le diagnostic, vous pourrez avoir vous servir d'un
sniffer de paquets comme tcpdump ou
ethereal.Si le nombre de paquets est diffrent de zro, vrifiez
dans votre log si la connexion est droppe ou rejete. Si
c'est le cas, il est possible que vous ayez un problme de
dfinition de zone qui fasse que le serveur soit dans une zone
diffrente de ce qui est spcifi dans la colonne DEST. A
l'invite root, tapez "shorewall[-lite] show
zones" et assurez-vous que vous avez bien spcifi
dan la colonne DEST la premire zone de la liste qui
correspond OUT=<dev> et DEST=<ip> dans le
message REJECT/DROP de votre fichier log.(FAQ 1c) Je voudrais que lorsque je me connecte depuis internet
au port 1022 de mon firewall, cette connexion soit redirige vers le
port 22 de mon systme local 192.168.1.3. Comment faire ?Rponse:Dans le fichier
/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST PORT
DNAT net loc:192.168.1.3:22 tcp 1022(FAQ 1d) J'ai un serveur web dans man DMZ et j'utilise le
transfert de port pour rendre ce serveur accessible depuis internet.
Cela fonctionne trs bien sauf lorsque mes utilisateurs locaux
essayent de se connecter au serveur en utilisant l'adresse IP externe
du firewall.Rponse: Supposons que:L'adresse IP externe est 206.124.146.176 sur eth0.L'adresse IP du serveur est 192.168.2.4Vous pouvez activer l'accs au serveur depuis votre rseau local
en utilisant l'adresse IP externe du firewall. Pour cela, vous pouvez
ajouter cette rgle:#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT DEST
DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176Si votre adresse IP externe est dynamique, vous devez faire
comme suit:Dans /etc/shorewall/params:ETH0_IP=`find_interface_address eth0`Pour les utilisateurs de 2.1.0 et des versions
ultrieures:ETH0_IP=`find_first_interface_address eth0`Et votre rgle DNAT deviendra:#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IP(FAQ 1e) Dans le but de dcourager les attaques en force brute,
je voudrais rediriger toutes les connexions internet arrivant sur un
port non standard (4104) vers le port 22 du firewall/routeur. J'ai
remarqu que lorsque je paramtre une rgle REDIRECT sur le firewall,
il ouvre sur internet les deux ports 4104 et 22 . Est-il possible de
rediriger seulement le port 4104 vers le port 22 de localhost et que
toutes les tentatives de connexion depuis internet au port 22 soient
ignores ?Rponse: avec l'aimable
autorisation de Ryan: en supposant que l'adresse de l'interface locale
de votre firewall soit 192.168.1.1, si vous configurez SSHD pour qu'il
n'coute que sur cette interface et que vous ajoutez la rgle
suivante, le port 4104 sera en coute sur internet et le port 22 sera
en coute sur votre LAN.#ACTION SOURCE DEST PROTO DEST PORT(S)
DNAT net fw:192.168.1.1:22 tcp 4104(FAQ 30) Quand doit-on utiliser des rgles DNAT et quand doit-on
utiliser des rgles ACCEPT ?Rponse: Je vous suggre de
revenir au guides de
dmarrage rapide adapt votre configuration. Ces guides
couvrent ce sujet sous un angle didactique. Vous devriez utiliser des
rgles DNAT pour les connexions qui doivent aller dans le sens inverse
de celles en provenance de la SNAT/Masquerade. Ainsi, si vous utilisez
la SNAT ou Masquerade depuis votre rseau local vers internet, vous
aurez besoin d'utiliser des rgles DNAT pour autoriser les connexions
d'internet vers votre rseau local. Vous utiliserez galement des rgles
DNAT si vous voulez r-crire l'adresse IP ou le numro de port
destination. Si vous avez besoin d'intercepter des connexions
lorsqu'elles arrivent sur le firewall et que vous voulez les traiter sur
le firewall lui-mme, vous utiliserez une rgle REDIRECT. Dans tous les
autres cas, vous utiliserez ACCEPT.(FAQ 38) O trouver plus d'information sur la DNAT?Rponse: Ian Allen a crit cet
article au sujet de la DNAT
et Linux.(FAQ 48) Comment configurer un proxy transparent avec
Shorewall?Rponse: Vous pouvez voir Shorewall et Squid.DNS et Transfert de Port/Traduction d'Adresses Rseau NAT(FAQ 2) Je transfre (port forward) toutes les requtes web
soumises www.mondomaine.com (IP 130.151.100.69) vers le systme
192.168.1.5 de mon rseau local. Les clients externes peuvent accder
http://www.mondomaine.com mais les clients internes ne le peuvent
pas.Rponse: j'ai deux objections
cette configuration.Avoir un serveur sur votre rseau local accessible depuis
internet est comme lever des loups cot de votre poulailler. Si
le serveur est compromis, il n'y a rien entre ce serveur et vos
autres systmes locaux. Pour le prix d'un adaptateur ethernet et
d'un cble crois, vous pouvez mettre votre serveur en DMZ de telle
faon qu'il soit isol de vos systmes locaux - en supposant que le
serveur puisse tre install cot de votre firewall, bien entendu
:-)La meilleure solutions pour l'accessibilit votre serveur
est d'utiliser les vues de Bind Version 9 (ou
bien d'utiliser un serveur DNS spar pour les clients locaux) afin
que www.mondomaine.com soit rsolu en 130.141.100.69 pour les
clients externes et en 192.168.1.5 pour les clients internes. C'est
ce que je fait ici shorewall.net pour mes systmes locaux qui
utilisent la NAT un--un (one-to-one NAT).Supposons que votre interface externe soit eth0, que votre
interface interne soit eth1 et que eth1 ait l'adresse 192.168.1.254 sur
le sous-rseau 192.168.1.0/24:tout le trafic redirig par cette bidouille sera vu par le
serveur comme provenant du firewall (192.168.1.254) au lieu de venir
du client d'origine! Ce qui fait que les logs d'accs du serveur
seront inutilisables pour dterminer quels htes locaux accdent au
serveur.Dans /etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
loc eth1 detect routebackDans /etc/shorewall/masq:#INTERFACE SUBNET ADDRESS PROTO PORT(S)
eth1:192.168.1.5 eth1 192.168.1.254 tcp wwwDans /etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT loc loc:192.168.1.5 tcp www - 130.151.100.69Bien entendu, cette rgle ne fonctionnera que si vous avez une
adresse IP externe statique. Si vous avez une adresse dynamique vous
devez inclure ceci dans
/etc/shorewall/params:ETH0_IP=`find_first_interface_address eth0`et votre rgle DNAT deviendra:#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT loc loc:192.168.1.5 tcp www - $ETH0_IPLorsque vous utilisez cette technique, il vous faudra
configurer votre client DHCP/PPPoE de faon ce qu'il relance
shorewall chaque fois qu'il obtient une nouvelle adresse IP.(FAQ 2a) J'ai une zone Z avec un sous-rseau RFC
1918 et j'utilise la NAT un--un (one-to-one NAT) pour assigner des
adresses non-RFC1918 aux htes de la zone Z. Les htes
dans la zone Z ne peuvent pas communiquer entre eux en
utilisant leur adresse externe (adresses non-FRC1918) et donc ils ne
peuvent pas communiquer en utilisant leurs noms DNS.Si la colonne ALL INTERFACES dans le fichier
/etc/shorewall/nat est vide ou contient Yes, vous
verrez aussi dans votre journal des messages comme celui-ci chaque
fois que vous tenterez d'accder un hte de la zone Z depuis un
autre hte de la zone Z en utilisant son adresse publique:Oct 4 10:26:40 netgw kernel:
Shorewall:FORWARD:REJECT:IN=eth1 OUT=eth1 SRC=192.168.118.200
DST=192.168.118.210 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=1342 DF
PROTO=TCP SPT=1494 DPT=1491 WINDOW=17472 RES=0x00 ACK SYN URGP=0Rponse: C'est encore un
problme trs bien rsolu par l'utilisation des vues de
Bind Version 9.
Les clients internes comme les clients externes peuvent alors accder
aux htes NATs en utilisant leur nom rseau.Une autre bonne faon d'approcher le problme est d'abandonner
la NAT un--un au profit du Proxy ARP. De cette faon, les machines
dans Z ont des adresses non-RFC1918 et on peut y accder aussi bien
depuis l'intrieur que depuis l'extrieur en utilisant la mme
adresse.Si vous n'aimez pas ces solutions et que vous prfrez btement
router tout le trafic de Z vers Z par votre firewall:Activez l'option routeback sur l'interface vers Z.Mettez Yes dans la colonne ALL INTERFACES du
fichier nat.Exemple:Zone: dmz Interface: eth2 Ssous-rseau: 192.168.2.0/24 Addresse: 192.168.2.254Dans le fichier
/etc/shorewall/interfaces:#ZONE INTERFACE BROADCAST OPTIONS
dmz eth2 192.168.2.255 routebackDans le fichier /etc/shorewall/nat,
assurez-vous d'avoir Yes dans la colonne ALL
INTERFACES.Dans le fichier
/etc/shorewall/masq:#INTERFACE SUBNETS ADDRESS
eth2 eth2 192.168.2.254Tout comme dans la bidouille prsente dans la FAQ2 ci-dessus,
le trafic de la dmz vers la dmz semblera provenir du firewall et non
du vritable hte source.(FAQ 2b) J'ai un serveur web dans ma DMZ et je me sers du
transfert de port pour le rendre accessible sur internet en tant que
www.mondomaine.com. Cela marche trs bien sauf pour mes utilisateurs
locaux lorsqu'ils tentent de se connecter
www.mondomaine.com.Rponse: Supposons que:L'adresse externe IP soit 206.124.146.176 sur eth0 (www.mondomaine.com).L'adresse IP du serveur soit 192.168.2.4Vous pouvez autoriser les machines du rseau local accder
votre serveur en utilisant l'adresse IP externe du firewall. Il suffit
d'ajouter cette rgle:#ACTION SOURCE DEST PROTO DEST PORT(S) SOURCE ORIGINAL
# PORT DEST
DNAT loc dmz:192.168.2.4 tcp 80 - 206.124.146.176Si votre adresse IP externe vous est alloue dynamiquement, vous
devez faire comme suit:Dans le fichier
/etc/shorewall/params:ETH0_IP=`find_first_interface_address eth0`Et votre rgle DNAT deviendra:#ACTION SOURCE DEST PROTO DEST PORT SOURCE ORIGINAL
# PORT DEST.
DNAT loc dmz:192.168.2.4 tcp 80 - $ETH0_IPAvec des adresses IP dynamiques, vous n'utiliserez pas
shorewall[-lite] save ni
shorewall[-lite] restore.(FAQ 2c) J'ai essay d'appliquer la rponse la FAQ 2 mon
interface externe et la zone net. Cela ne marche pas. Pourquoi
?Rponse: Avez-vous activ
IP_FORWARDING=On dans
shorewall.conf?Netmeeting/MSN(FAQ 3) Je veux utiliser Netmeeting ou la messagerie instantane
MSN avec Shorewall. Que faire ?Rponse: Il existe un module de
suivi de connexion H.323 qui est d'un grand secours avec
Netmeeting. Prenez cependant en compte cet article rcent d'un des
dveloppeurs de Netfilter:
> Je sais que PoM -ng va traiter ce problme, mais en attendant qu'il soit prt,
> et que tous les extras y soient ports, existe-t-il un moyen d'utiliser le patch
> noyau pour le module de suivi de connexion H.323 avec un noyau 2.6 ?
> j'utilise un noyau 2.6.1 et le noyau 2.4 n'est pas install sur le systme, c'est
> pourquoi je ne peux pas envisager de revenir en 2.4 ... et le module n'a pas
> encore t port en 2.6, dommage.
> Quelles options ai-je part d'installer une application gatekeeper (qui ne
> fonctionne pas dans mon rseau) ou un proxy (ce que je prfrerais viter) ?
Je suggre tous de configurer un proxy (gatekeeper): le module est vraiment
nul et ne mrite pas d'exister. a a t un trs bon outil de dveloppement et
de deboguage de l'interface newnat.
Vous pouvez aller voir ici une
solution pour la messagerie instantane MSN. Vous devez avoir conscience
que cette solution comporte des risques de scurit significatifs. Vous
pouvez galement vrifier auprs de la liste de diffusion de Netfilter
http://www.netfilter.org.Ports ouverts(FAQ 51) Comment ouvrir des ports dans Shorewall?Rponse: Aucune personne ayant
install Shorewall en utilisant un des Guides de Dmarrage Rapide
ne devrait avoir poser cette question.Quel que soit le guide que vous avez utilis, toutes les
communications sortantes sont ouvertes par dfaut. Vous n'avez donc pas
"ouvrir de port" en sortie.En entre:Si vous avez install en utilisant le guide Firewall Monoposte
(une interface), relisez cette
section SVP.Si vous avez utilis le guide Firewall deux interfaces pour
installer merci de relire ces sections: Transfert de ports (DNAT),
et Autres
connexionsSi vous avez utilis le guide Firewall trois interfaces pour
installer merci de relire ces sections: Transfert de ports (DNAT) et
Autres
ConnexionsSi vous avez install en utilisant le Guide de configuration
Shorewall vous feriez mieux de lire le guide nouveau --
vous avez vraiment rat beaucoup de choses.Voyez galement la section
Transfert de Ports de cette FAQ.(FAQ 4) Je viens juste d'utiliser un scanner de port en ligne
pour vrifier le paramtrage de mon firewall et certains ports
apparaissent ferms (closed) alors que d'autres sont
bloqus (blocked). Pourquoi ?Rponse: La configuration par
dfaut de Shorewall invoque l'action Drop avant de mettre en oeuvre une politique
DROP, et la politique par dfaut d'internet vers toutes les zones est
DROP. L'action Drop est dfinie dans le fichier
/usr/share/shorewall/action.Drop qui invoque
lui-mme la macro Auth (dfinie dans le
fichier /usr/share/shorewall/macro.Auth) qui
spcifie l'action REJECT (c.a.d.,
Auth/REJECT). Cela est ncessaire pour
viter les problmes de connexion sortante des services qui utilisent
le mcanisme Auth pour identifier les utilisateurs. C'est
le seul service configur par dfaut pour rejeter (REJECT) les
paquets.Si vous voyez d'autres ports TCP ferms autres que le port 113
(auth) c'est que vous avez ajout des rgles REJECT pour ces ports ou
bien qu'un routeur l'extrieur de votre firewall rpond aux requtes
de connexion sur ce port.(FAQ 4a) Je viens d'excuter un scan UDP de mon firewall avec
nmap et il trouve des centaines de ports ouverts!!!!Rponse: Respirez fond et
lisez la section man de nmap au sujet des scans UDP. Si nmap n'a
aucun retour de votre firewall, il
donnera ce port comme tant ouvert. Si vous voulez voir quels sont les
ports UDP rellement ouverts, modifiez temporairement votre politique
net->all pour REJECT, relancez Shorewall et refaites le scan UDP
nmap.(FAQ 4b) Quoi que je change dans mes rgles, Il y a un port que
je n'arrive pas fermer.J'avais une rgle qui autorisait telnet de mon rseau local vers
mon firewall. Je l'ai enleve et j'ai relanc Shorewall mais ma
session telnet fonctionne encore!!!Rponse: Les rgles traitent de
l'tablissement de nouvelles connexions. Lorsqu'une connexion est
tablie par le firewall, elle restera utilisable jusqu' la
dconnexion tcp ou jusqu'au time out pour les autres protocoles. Si
vous fermez votre session telnet et que vous essayez d'tablir un
nouvelle session, votre firewall bloquera cette tentative.(FAQ 4c) Comment utiliser Shorewall avec PortSentry?Answer: Vous trouverez ici la
description d'une bonne intgration de Shorewall et
PortSentry.(FAQ 4d) Comment utiliser Shorewall avec Snort-Inline?Rponse:Allez
voir cette contribution de Michael Cooke.Problmes de connexion(FAQ 5) J'ai install Shorewall et je ne peux plus
pinger travers le firewallRponse: Pour une description
complte de la gestion du ping par Shorewall, voyez
cette page.(FAQ 15) Mes systmes locaux ne peuvent rien voir sur
internetRponse: Chaque fois que je lis
mes systmes ne peuvent rien voir sur internet, je me
demande o l'auteur a bien pu acheter des ordinateurs avec des yeux et
ce que ces ordinateurs peuvent bien voir lorsque tout
fonctionne convenablement. Ceci mis part, les causes habituelles ce
type de problmes sont:L'adresse de la passerelle par dfaut n'est pas configure
l'adresse de l'interface locale du firewall sur chacun des systmes
locaux.L'entr pour le rseau local dans le fichier
/etc/shorewall/masq est errone ou
manquante.La configuration du DNS sur les systmes locaux est mauvaise
ou bien l'utilisateur fait tourner un serveur DNS sur le firewall et
il n'a pas autoris le port 53 UDP et TCP de son firewall vers
internet.Le forwarding n'est pas activ (ceci est souvent le cas pour
les utilisateurs Debian). Excutez cette commande:cat /proc/sys/net/ipv4/ip_forwardSi la valeur est 0 (zro) mettez IP_FORWARDING=On dans le fichier
/etc/shorewall/shorewall.conf et relancez
Shorewall.(FAQ 29) FTP ne fonctionne pasRponse: Voir la page Shorewall et FTP.(FAQ 33) Depuis mes clients derrire le firewall les connexions
vers certains sites chouent. Les connexions vers les mmes sites, mais
depuis le firewall fonctionnent. Qu'est-ce qui ne va pas ?Rponse: Trs probablement, il
vous faudra mettre CLAMPMSS=Yes dans le fichier /etc/shorewall/shorewall.conf.(FAQ 35) J'ai deux interfaces ethernet vers mon rseau local que
j'ai montes en pont (bridge). Quand Shorewall est dmarr, je n'arrive
pas faire passer le trafic travers le pont. J'ai dfini l'interface
pont (br0) comme interface locale dans /etc/shorewall/interfaces. Les
interfaces ethernet pontes ne sont pas dfinies pour
Shorewall. Comment demander Shorewall d'autoriser le trafic travers
le pont ?Rponse: ajouter l'option
routeback l'interface br0 dans le fichier /etc/shorewall/interfaces.Pour plus d'information sur ce type de configuration, voir la
documentation pour un pont simple avec
Shorewall.Journalisation(FAQ 6) O sont enregistrs les messages de journalisation et
comment modifier leur destination ?Rponse: NetFilter utilise
l'quivalent noyau de syslog (voir man syslog) pour
journaliser les messages. Il utilise toujours le dispositif LOG_KERN
(voir man openlog) et vous devez choisir le niveau de
journalisation (log level, voir man syslog) dans vos
politiques et dans vos
rgles. La destination des
messages journaliss par syslog est contrle avec
/etc/syslog.conf (voir man
syslog.conf). Lorsque vous avez modifi
/etc/syslog.conf, assurez-vous de redmarrer
syslogd (sur un systme RedHat, service syslog
restart).Par dfaut, les versions plus anciennes de Shorewall limitaient le
taux de journalisation des messages grce des paramtres du fichier
/etc/shorewall/shorewall.conf -- Si vous voulez
journaliser tous les messages, positionnez ces paramtres comme
suit:LOGLIMIT=""
LOGBURST=""On peut galement paramtrer
Shorewall pour qu'il enregistre les messages de journalisation dans un
fichier spar.(FAQ 6a) Existe-t-il des analyseur de journal qui fonctionnent
avec Shorewall?Rponse: Voil plusieurs liens
qui peuvent vous aider:http://www.shorewall.net/pub/shorewall/parsefw/http://www.fireparse.comhttp://cert.uni-stuttgart.de/projects/fwlogwatchhttp://www.logwatch.orghttp://gege.org/iptableshttp://home.regit.org/ulogd-php.htmlPersonnellement, j'utilise Logwatch. Il m'envoie chaque jour par
courriel un rapport pour chacun de mes diffrents systmes. Chaque
rapport rsume l'activit journalise sur le systme
correspondant.(FAQ 6b) Mes journaux sont inonds de messages DROP pour des
requtes de connections sur le port 10619. Puis-je exclure
temporairement de la journalisation Shorewall les messages d'erreur
pour ce port ?Rponse: Ajoutez temporairement
la rgle suivante:#ACTION SOURCE DEST PROTO DEST PORT(S)
DROP net fw udp 10619Sinon, si vous ne mettez pas le paramtre BLACKLIST_LOGLEVEL et
que vous avez spcifi l'option 'blacklist' sur votre interface
externe dans le fichier
/etc/shorewall/interfaces, vous pouvez
blacklister le port. Dans le fichier
/etc/shorewall/blacklist:#ADDRESS/SUBNET PROTOCOL PORT
- udp 10619(FAQ 6d) Pourquoi l'adresse MAC dans les messages de
journalisation Shorewall est-elle si longue ? Je pensais que l'adresse
MAC ne faisait que 6 octets.Rponse: Ce qui est labelis
comme adresse MAC dans les messages de journalisation Shorewall est en
fait l'entte de la trame ethernet. Elle contient:l'adresse MAC de destination (6 octets)l'adresse MAC source (6 octets)le type de trame ethernet (2 octets)ExempleMAC=00:04:4c:dc:e2:28:00:b0:8e:cf:3c:4c:08:00adresse MAC de destination = 00:04:4c:dc:e2:28adresse MAC source = 00:b0:8e:cf:3c:4ctype de trame ethernet = 08:00 (IP Version 4)(FAQ 16) Shorewall crit ses messages de journalisation
directement sur ma console et la rend inutilisable!Rponse:Trouvez o klogd est dmarr (ce sera depuis un des fichiers
du rpertoire /etc/init.d --
sysklogd, klogd, ...). Modifiez ce fichier ou le fichier de
configuration appropri de telle manire que klogd soit dmarr avec
-c <n> avec
<n> tant un niveau de journalisation
infrieur ou gal 5; ou alorsVoir la page man de dmesg (man
dmesg). Vous devez ajouter une commande dmesg
adapte dans vos scripts de dmarrage ou la placer dans le fichier
/etc/shorewall/start.Sous RedHat et Mandriva, le niveau de journalisation maximum
envoy la console est spcifi par la variable LOGLEVEL du fichier
/etc/sysconfig/init. Positionnez
LOGLEVEL=5 pour liminer de la console les messages de
niveau info.Sous Debian, vous pouvez mettre KLOGD=-c 5 dans
le fichier /etc/init.d/klogd afin d'liminer de
la console les messages de niveau info (log level 6).Sous SUSE, ajoutez -c 5 KLOGD_PARAMS dans le
fichier /etc/sysconfig/syslog fin d'liminer de
la console les messages de niveau info (log level 6).(FAQ 17) Pourquoi ces paquets sont-ils ignors/rejets
(dropped/rejected)? Comment dcode-t-on les messages de journalisation
Shorewall?Rponse: Avec Shorewall, les
paquets ignors/rejets peuvent avoir t journaliss en sortie d'un
certain nombre de chanes (comme indiqu dans le message):man1918 or logdropL'adresse destination est liste dans le fichier
/usr/share/shorewall/rfc1918 avec une cible
logdrop -- voir /usr/share/shorewall/rfc1918.rfc1918 or logdropL'adresse source ou destination est liste dans le fichier
/usr/share/shorewall/rfc1918 avec un cible
logdrop -- voir /usr/share/shorewall/rfc1918.Si vous voyez des paquets rejets par la chane rfc1918 et
que ni l'adresse IP source ni l'adresse IP de destination ne
sont rserves par la RFC 1918, cela provient la plupart du
temps d'un ancien fichier rfc1918 dans
/etc/shorewall (ceci
arrive le plus frquemment lorsque vous utilisez une Debian ou
un de ses drivs). Le fichier rfc1918
incluait aussi bien les bogons que les
trois plages rserves par la RFC 1918. Il tait install dans
le rpertoire /etc/shorewall. Maintenant le
fichier ne contient que les trois plages d'adresse de la RFC
1918 et il est install dans le rpertoire /usr/share/shorewall. Retirez le
fichier rfc1918 prim de votre rpertoire /etc/shorewall.all2<zone>, <zone>2all or all2allVous avez une politique qui spcifie un
niveau de journalisation et ce paquet a t journalis par cette
politique. Si vous voulez autoriser (ACCEPT) ce trafic, il vous
faudra une rgle
cette fin.<zone1>2<zone2>Ou bien vous avez une politique pour le trafic de
la <zone1> vers la
<zone2> qui spcifie un
niveau de journalisation et ce paquet a t journalis par cette
politique ou alors ce paquet correspond une rgle incluant un niveau de
journalisation.A partir de Shorewall 3.3.3, les paquets loggs par ces
chaines peuvent avoir une source et/ou une destination
n'appartenant aucune zone dfinie (voir le rsultat de la
commande shorewall[-lite] show zones).
Souvenez-vous que l'appartenance une zone ncessite la fois
une interface du firewall et une adresse ip.@<source>2<dest>Vous avez une politique pour le trafic de <source> vers <dest> dans laquelle vous avez spcifi
un taux de limitation des connexions TCP (les valeurs dans la
colonne LIMIT:BURST). Les paquet journalis dpassait cette limite
et a t ignor (DROP). Il faut noter que ces messages au journal
sont eux-mme svrement limits afin qu'une inondation SYN
(syn-flood) ne provoque pas un dni de service (DOS) secondaire
par un nombre excessif de messages de journalisation. Ces messages
ont t introduits dans Shorewall 2.2.0 Beta 7.<interface>_macCe paquet a t journalis par l'option d'interfacemaclist .logpktCe paquet a t journalis par l'option d'interfacelogunclean.badpktCe paquet a t journalis par l'option d'interfacedropunclean tel que spcifi dans
le paramtre LOGUNCLEAN du
fichier /etc/shorewall/shorewall.conf.blacklstCe paquet a t journalis parce que l'adresse IP source est
inscrite dans la liste noire /etc/shorewall/blacklist.INPUT or FORWARDCe paquet a une adresse IP source qui n'est dfinie dans
aucune de vos zones (shorewall[-lite] show
zones et regardez les dfinitions de zones) ou
alors la chane est FORWARD et l'adresse IP de destination ne
figure dans aucune de vos zones dfinies. Si la chane est FORWARD
et les interfaces IN et OUT sont identiques, vous avez sans doute
besoin de l'option routeback sur
cette interface dans le fichier /etc/shorewall/interfaces
ou bien vous avez besoin de l'option routeback pour l'entre adquate dans le
fichier/etc/shorewall/hosts.A partir de 3.3.3, de tels paquets peuvent aussi tre loggs
par les chaines <zone>2all et all2all.OUTPUTCe paquet a une adresse IP destination qui n'est dfinie
dans aucune de vos zones (shorewall check et
regardez les dfinitions de zones).A partir Shorewall 3.3.3, de tels paquets peuvent aussi tre
loggs par les chaines fw2all et all2all.logflagsCe paquet a t journalis parce qu'il a chou aux
contrles mis en oeuvre par l'option d'interfacetcpflags.Exemple:Jun 27 15:37:56 gateway kernel:
Shorewall:all2all:REJECT:IN=eth2OUT=eth1SRC=192.168.2.2DST=192.168.1.3 LEN=67 TOS=0x00 PREC=0x00 TTL=63 ID=5805 DF PROTO=UDP
SPT=1803 DPT=53 LEN=47Examinons les partie importantes de ce message:all2all:REJECTCe paquet a t rejet (REJECT) par la chane all2all -- le paquet a t rejet par la
politique all->all REJECT (voir
all2all ci-dessus).IN=eth2Le paquet est arriv dans le firewall par eth2. Lorsque
vous voyez IN= sans aucun nom d'interface, c'est
que le paquet provient du firewall lui-mme.OUT=eth1Si il avait t autoris, ce paquet aurait t transmis
eth1. Lorsque vous voyez OUT= sans aucun nom
d'interface, c'est que le paquet aurait t trait par le
firewall lui-mme.Lorsqu'une rgle DNAT est journalise, on n'a jamais de
OUT= parce que le paquet est journalis avant d'tre rout.
Par ailleurs, la journalisation DNAT donnera l'adresse IP
destination et le numro de port destination
d'origine.SRC=192.168.2.2Ce paquet a t envoy par 192.168.2.2DST=192.168.1.3Ce paquet a pour destination 192.168.1.3PROTO=UDPLe protocole est UDPDPT=53Le port de destination est le port 53 (DNS)Pour plus d'informations concernant les messages de
journalisation, voir http://logi.cc/linux/netfilter-log-format.php3.Dans ce cas, 192.168.2.2 tait dans la zone dmz
et 192.168.1.3 tait dans la zone loc. Il me manquait
la rgle suivante:ACCEPT dmz loc udp 53(FAQ 21) Je vois occasionnellement ces tranges messages dans mon
journal. De quoi s'agit-il?Nov 25 18:58:52 linux kernel:
Shorewall:net2all:DROP:IN=eth1 OUT=
MAC=00:60:1d:f0:a6:f9:00:60:1d:f6:35:50:08:00 SRC=206.124.146.179
DST=192.0.2.3 LEN=56 TOS=0x00 PREC=0x00 TTL=110 ID=18558 PROTO=ICMP
TYPE=3 CODE=3 [SRC=192.0.2.3 DST=172.16.1.10 LEN=128 TOS=0x00 PREC=0x00
TTL=47 ID=0 DF PROTO=UDP SPT=53 DPT=2857 LEN=108 ]192.0.2.3 est externe mon firewall... mon rseau local est
172.16.0.0/24Rponse: Bien que la plupart des
gens associent ICMP (Internet Control Message Protocol)
ping, ICMP est une pice cl de IP. ICMP sert informer
l'expditeur d'un paquet des problmes rencontrs. C'est ce qui se
produit ici. Malheureusement, de nombreuses implmentations ne
fonctionnent pas ds lors que la traduction d'adresses est implique (y
compris SNAT, DNAT et Masquerade). C'est ce que vous voyez avec
travers ces messages. Quand Netfilter renvoie ces messages, la partie
prcdent le "[" dcrit le paquet ICMP, et la partie entre "[" et "]"
dcrit le paquet pour lequel ICMP rpond.Voici mon interprtation de ce qui se passe -- pour confirmer
l'analyse, il faudrait avoir un sniffeur de paquets
chacune des extrmits de la connexion.L'hte 172.16.1.10 plac derrire la passerelle NAT
206.124.146.179 a envoy une requte DNS UDP 192.0.2.3 et votre
serveur DNS a tent d'envoyer un rponse (l'information en rponse est
entre les crochets -- remarquez le port source 53 qui indique qu'il
s'agit d'une rponse DNS). Quand la rponse a t envoye
206.124.146.179, le firewall a rcrit l'adresse IP destination
172.16.1.10 puis a fait suivre le paquet 172.16.1.10 qui n'avait plus
de connexion UDP sur le port 2857. Ceci provoque la gnration d'un
message ICMP port unreachable (type 3, code 3) en retour vers 192.0.2.3.
Ce paquet est renvoy par 206.124.146.179 qui change correctement
l'adresse source dans le paquet pour 206.124.146.179 mais ne modifie pas
de la mme faon l'IP destination dans la rponse DNS d'origine. Lorsque
le paquet ICMP atteint votre firewall (192.0.2.3), celui-ci n'a aucun
enregistrement lui indiquant qu'il a envoy une rponse DNS
172.16.1.10 et par consquent ce paquet ICMP semble n'tre associ
rien de ce qui a t envoy. Le rsultat est que ce paquet est
journalis et ignor (DROP) par la chane all2all. J'ai galement vu des
cas dans lesquels la source IP dans le paquet ICMP lui-mme n'est pas
r-crite l'adresse externe de la passerelle NAT distante. Dans ce cas
votre firewall va journaliser et ignorer (DROP) le paquet par la chane
rfc1918 cas son IP source est rserve par la RFC 1918.(FAQ 52) Quand je blackliste une adresse IP avec
"shorewall[-lite] drop www.xxx.yyy.zzz", pourquoi est-ce qu'il y a
toujours des entres REDIRECT et DNAT en provenance de cette adresse
dans mon journal ?J'ai blacklist l'adresse 130.252.100.59 avec la commande
shorewall drop 130.252.100.59 mais je vois toujours
ces messages dans le journal:Jan 30 15:38:34 server Shorewall:net_dnat:REDIRECT:IN=eth1 OUT= MAC=00:4f:4e:14:97:8e:00:01:5c:23:24:cc:08:00
SRC=130.252.100.59 DST=206.124.146.176 LEN=64 TOS=0x00 PREC=0x00 TTL=43 ID=42444 DF
PROTO=TCP SPT=2215 DPT=139 WINDOW=53760 RES=0x00 SYN URGP=0Rponse: Veuillez vous rfrer
Shorewall Netfilter
Documentation. La journalisation des rgles REDIRECT et DNAT se
produit dans la chane PREROUTING de la table nat dans laquelle
l'adresse est toujours valide. Le blacklistage se produit dans les
chanes INPUT et FORWARD de la table filter qui ne sont traverses que
plus tard.(FAQ 56) Quand je dmarre ou redmarre Shorewall, je vois ces
messages dans mon fichier log. Est-ce grave ?
Rponse: Non. Ceci se produit
lorsque shorewall teste votre systme pour dterminer les fonctions
qu'il supporte. Ils ne prsentent aucun risque.Routage(FAQ 32) J'ai deux connexions internet avec deux FAI diffrents
sur mon firewall. Comment le configurer avec Shorewall?Rponse: voir cet article sur
Shorewall et le routage.(FAQ 49) Quand je dmarre Shorewall, ma table de routage est
dtruite. Pourquoi Shorewall fait-il cela?Rponse: Ceci est en gnral la
consquence d'une btise dans la configuration du NAT un--un
(one-to-one NAT):Vous spcifiez l'adresse IP primaire d'une interface dans la
colonne EXTERNAL du fichier /etc/shorewall/nat
alors que la documentation et les commentaires dans le fichier vous
mettent en garde contre une telle configuration.Vous spcifiez ADD_IP_ALIASES=Yes et RETAIN_ALIASES=No dans le
fichier /etc/shorewall/shorewall.conf.Cette combinaison fait dtruire par Shorewall l'adresse primaire
de l'interface rseau spcifie dans la colonne INTERFACE, ce qui a en
gnral pour consquence de dtruire routes les routes sortantes de
cette interface. La solution est de ne pas
spcifier l'adresse primaire d'une interface dans la colonne
EXTERNAL.Dmarrer et arrter Shorewall(FAQ 7) Quand j'arrte Shorewall avec la commande
shorewall[-lite] stop, je ne peux plus me connecter
quoi que ce soit. Pourquoi cette commande ne fonctionne-t-elle
pas?Rponse: La commande stop est prvue pour mettre votre firewall
dans un tat de scurit o seuls les htes lists dans le fichier
/etc/shorewall/routestopped sont activs. Si vous
voulez ouvrir compltement votre firewall, il vous faut utiliser la
commande shorewall clear.(FAQ 8) Quand je tente de lancer Shorewall sur RedHat, je reois
des messages d'erreur insmod -- qu'est-ce qui ne va pas?Rponse: La sortie que vous avez
ressemble ceci:/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: init_module: Device or resource busy
Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o failed
/lib/modules/2.4.17/kernel/net/ipv4/netfilter/ip_tables.o: insmod ip_tables failed
iptables v1.2.3: can't initialize iptables table `nat': iptables who? (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.En gnral, ce problme est corrig par la squence de commandes
qui suit:service ipchains stop
chkconfig --delete ipchains
rmmod ipchainsPar ailleurs, assurez-vous d'avoir vrifi dans l'errata que vous n'avez pas de problmes li
la version d'iptables (v1.2.3) distribue avec RH7.2.(FAQ 8a) Quand je tente de lancer Shorewall sur une RedHat, je
reois un message qui me renvoie la FAQ #8Rponse: Ceci se traite en
gnral avec la squence de commandes prsente ci-dessus dans la
.(FAQ 9) Pourquoi Shorewall ne russit-il pas dtecter
convenablement mes interfaces au dmarrage?Je viens d'installer Shorewall et quand je lance la commande
start, voil ce qui se passe :Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf ...
Starting Shorewall...
Loading Modules...
Initializing...
Determining Zones...
Zones: net loc
Validating interfaces file...
Validating hosts file...
Determining Hosts in Zones...
Net Zone: eth0:0.0.0.0/0
Local Zone: eth1:0.0.0.0/0
Deleting user chains...
Creating input Chains...
...Pourquoi est-ce que Shorewall ne dtecte-t-il pas correctement mes
interfaces?Rponse: La sortie ci-dessus est
parfaitement normale. La zone Net est dfinie comme tant compose de
toutes les machines connectes eth0 et la zone Local est dfinie comme
tant compose de toutes celles connectes eth1. Si vous utilisez
Shorewall 1.4.10 ou une version plus rcente, vous pouvez envisager de
paramtrer l'option
d'interfacedetectnet pour
votre interface locale (eth1 dans l'exemple ce-dessus). Ceci forcera
Shorewall restreindre la zone locale aux seuls rseaux routs par
cette interface.(FAQ 22) Je voudrais excuter certaines commandes iptables au
dmarrage de Shorewall. Dans quel fichier les mettre?Rponse: Vous pouvez placer ces
commandes dans une des Scripts d'Extension
Shorewall. Assurez-vous de bien examiner le contenu des chanes
que vos commandes vont modifier afin d'tre certain que ces commandes
feront bien ce qu'elles sont censes faire. De nombreuses commandes
publies dans des guides (HOWTOs) ainsi que dans d'autres modes
opratoires font usage de la commande -A qui ajoute les rgles en fin de
chane. La plupart des chanes construites par Shorewall se terminent
par une rgle inconditionnelle DROP, ACCEPT ou REJECT et donc toute
rgle que vous pourriez ajouter aprs serait ignore. Consultez
man iptables et prenez connaissance de la commande -I
(--insert).(FAQ 34) Comment acclrer le dmarrage (start/restart)?Rponse: L'utilisation d'un shell
lger tel que ash peut diminuer de faon trs
significative le temps ncessaire pour dmarrer (start/restart)
Shorewall. Voyez la variable SHOREWALL_SHELL dans le fichier
shorewall.conf.Utilisez un mulateur de terminal rapide -- en particulier la
console KDE dfile beaucoup plus vite que le terminal Gnome. Vous pouvez
galement utiliser l'option '-q' si vous redmarrez distance ou depuis
un terminal lent (ou rediriger la sortie vers un fichier comme dans
shorewall restart > /dev/null).Mettez votre matriel niveau. De nombreux utilisateurs ont
constat que mme une amlioration modeste de la CPU et de la vitesse de
la mmoire (par exemple passer d'un P3 avec de la SDRAM un P4 avec de
la DDR) avait des effets trs significatifs. Les CPU dotes de la
technologie EM64T, aussi bien celles d'AMD que celles d'Intel, montrent
des performances de redmarrage trs acceptables, mme si vous avez un
jeu de rgles assez complexe.Shorewall offre galement une fonction de dmarrage rapide. Pour
l'utiliser:Avec Shorewall dans l'tat dmarr,
excutez shorewall save. Cela va crer le script
/var/lib/shorewall/restore.Utilisez l'option -f avec la
commande start (par exemple, shorewall -f start).
Ceci forcera Shorewall chercher le script
/var/lib/shorewall/restore et l'excuter si
il existe. Excuter /var/lib/shorewall/restore
prend beaucoup moins de temps que d'excuter un shorewall
start complet.Le script /etc/init.d/shorewall excut
au dmarrage du systme utilise l'option -f.Le script /var/lib/shorewall/restore peut
tre excut tout moment pour restaurer le firewall. Il peut tre
invoqu directement ou bien indirectement en utilisant la commande
shorewall restore.Si vous modifiez votre configuration de Shorewall, vous devez
excuter un shorewall start (sans
-f) ou un shorewall
restart avant de refaire un shorewall save.
La commande shorewall save sauvegarde la
configuration qui tournait au moment o elle a t excute et non celle
que reprsentent les fichiers de configuration que vous avez
modifis.De mme, si vous modifiez votre configuration Shorewall et que
vous tes satisfait du rsultat, vous devez excuter une commande
shorewall save, sans quoi vous reviendriez
l'ancienne configuration enregistre dans
/var/lib/shorewall/restore lors du prochain
dmarrage de votre systme.Finalement, le temps pendant lequel les nouvelles connexions sont
bloques durant le redmarrage de Shorewall peut tre rduit dans de
trs grande proportions en upgradant vers Shorewall 3.2 ou une version
ultrieure. A partir de la 3.2, shorewall [re]start
procde en deux tapes:La configuration courante est compile afin de produire un
programme shell conu pour votre configuration.Si la compilation se droule sans erreur, le programme compil
est excut pour [re]dmarrer votre firewall.(FAQ 43) Je viens d'installer le RPM Shorewall et Shorewall ne
dmarre pas au lancement du systme (boot).Rponse: Quand vous installez
avec la commande "rpm -U", Shorewall n'excute pas les outils de votre
distribution qui configurent le dmarrage de Shorewall. Vous devrez
excuter cet outils vous-mme (insserv, chkconfig, run-level editor,
…) pour que Shorewall dmarre aux niveaux d'excutions
(run-level) auxquels vous voulez l'utiliser.(FAQ 45) Pourquoi est-ce que "shorewall[-lite] start" choue
lorsque je tente de mettre en place SNAT/Masquerade?shorewall start produit la sortie
suivante:…
Processing /etc/shorewall/policy...
Policy ACCEPT for fw to net using chain fw2net
Policy ACCEPT for loc0 to net using chain loc02net
Policy ACCEPT for loc1 to net using chain loc12net
Policy ACCEPT for wlan to net using chain wlan2net
Masqueraded Networks and Hosts:
iptables: Invalid argument
ERROR: Command "/sbin/iptables -t nat -A …" FailedRponse: Dans 99.999% des cas,
cette erreur provient d'un problme de comptabilit des versions
d'iptables et du noyau.Votre iptables doit tre compil en utilisant un arbre de
sources du noyau qui soit compatible au niveau Netfilter avec le
noyau que vous excutez sur votre systme.Si vous recompilez iptables avec les paramtres par dfaut
puis que vous l'installez, il sera install dans
/usr/local/sbin/iptables. Comme on peut le voir
ci-dessus, votre variable IPTABLES est configure
/sbin/iptables dans votre fichier
shorewall.conf.(FAQ 59) Aprs le dmarrage de Shorewall, de nombreux modules
netfilter inutiliss sont chargs. Comment viter cela ?Rponse: Copiez
/usr/share/shorewall/modules (ou
/usr/share/shorewall/xmodules suivant le cas) vers
/etc/shorewall/modules et modifiez cette copie pour
qu'elle ne contienne que les modules dont vous avez besoin.(FAQ 61) Je viens juste d'installer le nouveau kernel Debian, et
maintenant "shorewall start" choue avec le message "ipt_policy:
matchsize 116 != 308". Qu'est-ce qui ne va pas?Rponse: Votre version d'iptables
est incompatible avec votre kernel.recompilez iptables en utilisant les headers de votre nouveau
kernel; ou biensi vous n'avez pas besoin du support de "policy match" (vous
n'utilisez pas l'implmentation IPSEC du kernel 2.6) vous pouvez
renommer /lib/iptables/libipt_policy.so.Multiples FAIs(FAQ 57) J'ai configur deux FAIs dans Shorewall mais quand
j'essaye d'utiliser le second, cela ne fonctionne pas.Rponse: La documentation
Multi-ISP vous recommande trs fortement d'utiliser l'option
d'quilibrage (balance) pour tous les
FAIs mme si vous voulez spcifier manuellement quel FAI utiliser. Si
vous ne le faites pas et que votre table principale de routage n'a
qu'une seule route par dfaut, vous devez dsactiver le filtrage de
route. Ne spcifiez pas l'option routefilter sur l'autre interface dans
/etc/shorewall/interfaces et dsactivez toute
protections contre le spoofing d'adresses IP que
votre distribution pourrait offrir.(FAQ 58) Mais si je spcifie 'balance' est-ce que shorewall ne va
pas quilibrer le trafic entre les interfaces ? Je ne veux pas qu'il le
fasse !Rponse: Supposez que vous
vouliez que tout le trafic passe par le FAI1 (mark 1) jusqu' ce que
vous spcifiez diffremment. Dans ce cas, ajoutez simplement ces deux
rgles comme premires rgles de marquage dans votre fichier
/etc/shorewall/tcrules:#MARK SOURCE DEST
1:P 0.0.0.0/0
1:P $FW
<other MARK rules>Maintenant, tout le trafic qui n'est pas marqu par une de vos
autres rgles de marquage aura mark=1 et sera envoy par le FAI1. Ceci
fonctionnera que l'option balance soit
spcifie ou pas.Au sujet de Shorewall(FAQ 10) Sur quelles distributions Shorewall tourne-t-il?Rponse: Shorewall fonctionnera
sur n'importe quelle distribution GNU/Linux distribution runissant les
pr-requis Shorewall
indiqus dans ce document.(FAQ 11) Quelles sont les caractristiques de Shorewall ?Rponse: voir la liste des caractristiques de
Shorewall.(FAQ 12) Existe-t-il une interface graphique?Rponse: Oui. Webmin offre le
support de Shorewall 3.x partir dans sa version 1.300. Voir http://www.webmin.com(FAQ 13) Pourquoi l'avez-vous appel
Shorewall?Rponse: Shorewall est le
rsultat de la concatnation de Shoreline (la ville o je vis) et de
Firewall. En fait le nom complet du
produit est Shoreline Firewall mais on utilise plus
communment Shorewall.(FAQ 23) Pourquoi utilisez-vous des polices de caractres aussi
affreuses sur votre site web?Rponse: Le site web de Shorewall
est presque entirement neutre en ce qui concerne les polices (
l'exception de quelques pages il ne spcifie explicitement aucune
police). Les polices que vous voyez sont largement celles configures
par dfaut dans votre navigateur. Si vous ne les aimez pas reconfigurez
votre navigateur.(FAQ 25) Comment savoir quelle version de Shorewall ou de
Shorewall Lite j'utilise?Rponse: A l'invite du systme,
tapez:/sbin/shorewall[-lite] version(FAQ 31) Est-ce que Shorewall fournit une protection
contre....IP Spoofing: envoyer des paquets par l'interface WAN en se
servant d'adresses IP du rseau local comme adresse source?Rponse: Oui.Tear Drop: Envoyer des paquets contenant des fragments qui se
recouvrent ?Rponse: Ceci est de la
responsabilit de la pile IP, ce n'est pas celle d'un firewall
bas sur Netfilter car le r-assemblage des fragments est fait
avant que le filtre de paquets ne voie chaque paquet.Smurf and Fraggle: Envoyer des paquets qui utilisent comme
adresse source l'adresse de diffusion (broadcast) du WAN ou du
LAN?Rponse: On peut configurer
Shorewall pour le faire avec sa fonction de liste noire (blacklist). A
partir de la version 2.0.0, Shorewall filtre ces paquets avec
l'option d'interface nosmurfs dans le
fichier /etc/shorewall/interfaces.Land Attack: Envoyer des paquets utilisant la mme adresse
comme source et comme destination?Rponse: Oui lorsque
l'option d'interface
routefilter est slectionne.DOS: Dni de Service SYN Dos - ICMP Dos - protection DOS par
hteRponse: Shorewall offre la
possibilit de limiter les paquets SYN les paquets ICMP. Netfilter
tel qu'il est inclus dans les noyaux Linux standard ne supporte
pas la mise en oeuvre de limitations par hte distant sauf en
utilisant une rgle explicite qui spcifie l'adresse IP de l'hte.
Cette forme de limitation est supporte par Shorewall.(FAQ 36) Est-ce que Shorewall tourne sur le noyau Linux
2.6?Rponse: Shorewall fonctionne
avec les noyaux 2.6 avec les deux restrictions suivantes:Dans les noyaux 2.6 jusqu'au 2.6.16, Netfilter/iptables
n'offre pas un support complet d'IPSEC -- il existe des patch pour
le noyau et pour iptables. Vous trouverez des dtails la page
Shorewall IPSEC-2.6.Les noyaux 2.6 n'offrent pas le support des options logunclean
et dropunclean du fichier
/etc/shorewall/interfaces. Le support de ces
options a galement t retir de Shorewall dans la version
2.0.0.RFC 1918(FAQ 14) Je suis connect avec un modem cble qui a son propre
serveur web interne utilis pour le paramtrage et la supervision. Mais
bien entendu, si j'active le blocage des adresse de la RFC 1918 sur mon
interface internet eth0, le serveur web du modem est bloqu lui
aussi.Est-il possible de rajouter une rgle avant la rgle de blocage
rfc1918 de faon autoriser tout le trafic en provenance et
destination de 192.168.100.1, adresse de mon modem, tout en continuant
filtrer les autres adresses rfc1918?Rponse: Ajoutez ce qui suit dans
le fichier /etc/shorewall/rfc1918
(Remarque: Si vous utilisez 2.0.0 ou une version ultrieure, il est
possible que ayez pralablement copier le fichier
/usr/share/shorewall/rfc1918 vers
/etc/shorewall/rfc1918):Assurez-vous d'ajouter l'entre AU-DESSUS de l'entre pour
192.168.0.0/16.#SUBNET TARGET
192.168.100.1 RETURNSi vous ajoutez une seconde adresse IP l'interface externe de
votre firewall qui corresponde l'adresse du modem, vous devez
ajouter une entre pour cette adresse dans le fichier
/etc/shorewall/rfc1918. Par exemple, si vous
configurez l'adresse 192.168.100.2 sur votre firewall, vous devrez
ajouter les deux entres suivantes dans le fichier
/etc/shorewall/rfc1918:#SUBNET TARGET
192.168.100.1 RETURN
192.168.100.2 RETURN(FAQ 14a) Bien qu'il assigne des adresses IP publiques, le
serveur DHCP de mon FAI a une adresse de la RFC 1918. Si j'active le
filtrage RFC 1918 sur mon interface externe, mon client DHCP ne peut
plus renouveler son bail.Rponse: La solution est la
mme que dans la FAQ 14 prsente
au-dessus. Substituez-y simplement l'adresse du serveur DHCP de votre
FAI.(FAQ 14b) Je me connecte internet par PPPoE. Quand j'essaye
de me connecter au serveur web incorpor mon modem DSL, la connexion
est refuse.Dans mon journal je peux voir ce qui suit:Mar 1 18:20:07 Mail kernel: Shorewall:OUTPUT:REJECT:IN= OUT=eth0 SRC=192.168.1.2 DST=192.168.1.1 LEN=60
TOS=0x00 PREC=0x00 TTL=64 ID=26774 DF PROTO=TCP SPT=32797 DPT=80 WINDOW=5840 RES=0x00 SYN URGP=0 Rponse: Le fait que le message
soit journalis par la chane OUTPUT signifie que l'adresse de
destination n'appartient aucune des zones dfinies (voir la FAQ 17). Vous devez:Ajouter une zone pour votre modem dans le fichier
/etc/shorewall/zones:#ZONE TYPE OPTIONS
modem ipv4Dans le fichier
/etc/shorewall/interfaces, associer cette
zone avec l'interface laquelle votre modem est connect (eth0
dans l'exemple):#ZONE INTERFACE BROADCAST OPTIONS
modem eth0 detectAutoriser le trafic web vers le modem dans le fichier
/etc/shorewall/rules:#ACTION SOURCE DEST PROTO DEST PORT(S)
ACCEPT fw modem tcp 80
ACCEPT loc modem tcp 80Notez qu'un grand nombre de ces modems cable/DSL n'a pas de
passerelle par dfaut ou alors que leur passerelle par dfaut est
fixe une adresse IP diffrente de l'adresse que vous avez attribue
votre interface externe. Dans un cas comme dans l'autre, vous pouvez
avoir des difficults naviguer sur votre modem depuis votre rseau
local, mme si toutes les routes sont correctement tablies sur votre
firewall. Pour rsoudre ce problme, on masquerade le
trafic depuis rseau local vers le modem./etc/shorewall/masq:#INTERFACE SUBNET ADDRESS
eth0 eth1 # eth1 = interface to local networkA titre d'exemple lorsque le modem cable/ADSL est
pont (bridge), vous pouvez aller voir ma configuration. Dans ce cas, je
masquerade en utilisant l'adresse IP de mon interface
locale!Adresses Alias IP/Interfaces virtuelles(FAQ 18) Existe-t-il un moyen d'utiliser des adresses IP aliases
avec Shorewall, et de maintenir des jeux de rgles spars pour ces
diffrentes adresses IP?Rponse: Oui. Voyez Shorewall et les interfaces
aliases.Shorewall Lite(FAQ 53) Qu'est-ce que Shorewall Lite?Rponse: Shorewall Lite est un
produit partenaire de Shorewall. Il est conu pour vous permettre de
maintenir les informations de toutes vos configurations de Shorewall sur
un seul systme dans votre rseau. Pour plus de dtails, voir Compiled Firewall script
documentation.(FAQ 54) Si je veux installer Shorewall Lite, est-ce que je dois
aussi installer Shorewall sur le mme systme ?Rponse: Non. En fait, nous
recommandons que vous n'installiez pas Shorewall sur les systmes sur
lesquels vous souhaitez utiliser Shorewall Lite. Vous devez avoir
install Shorewall sur au moins un des systmes de votre rseau pour
pouvoir utiliser Shorewall Lite.(FAQ 55) Comment dcider quel produit utiliser - Shorewall ou
Shorewall Lite?Rponse: Si vous prvoyez d'avoir
un seul firewall, Shorewall est le choix logique. Je pense aussi que
Shorewall est le choix le plus appropri pour un portable car vous
pouvez avoir changer sa configuration lorsque vous tes en
dplacement. Dans tous les autres cas, Shorewall Lite fonctionnera trs
bien. A shorewall.net, les deux portables ainsi que mon ordinateur de
bureau linux sont installs avec la version complte de Shorewall. Tous
les autres systmes Linux qui ont un firewall utilisent Shorewall Lite
et leurs rpertoires de configuration sont sur mon ordinateur de
bureau.(FAQ 60) Quelles restrictions de compatibilit existent entre
Shorewall et Shorewall LiteRponse: Voir le tableau
ci-dessous (C = Compltement compatible avec toutes les fonctionnalits
disponibles, P1 = Compatible mais la totalit des fonctions de Shorewall
ne sont pas disponibles, P2 = Compatible mais la totalit des fonctions
de Shorewall Lite ne sont pas disponibles, I = incompatible).Shorewall Lite 3.2.0Shorewall Lite 3.2.1Shorewall Lite 3.2.2Shorewall Lite 3.2.3Shorewall 3.2.0CCP2P2Shorewall 3.2.1CCCP2Shorewall 3.2.2P1P1CCShorewall 3.2.3P1P1CCDivers(FAQ 20) Je viens d'installer un serveur. Dois-je modifier
Shorewall pour autoriser les accs internet mon serveur?Rponse : Oui. Consultez le
guides de dmarrage
rapide que vous avez utilis pour votre configuration initiale
afin d'avoir des informations ncessaires l'criture des rgles pour
votre serveur.(FAQ 24) Comment puis-je autoriser des connexions internet au
port ssh, par exemple, mais seulement depuis certaines adresses IP
spcifiques?Rponse : Dans la colonne SOURCE
de la rgle, faites suivre net de : puis
d'une liste spare par des virgules d'adresses de machines ou de
sous-rseauxnet:<ip1>,<ip2>,...Exemple:ACCEPT net:192.0.2.16/28,192.0.2.44 fw tcp 22(FAQ 26) Quand j'essaye d'utiliser nmap avec n'importe laquelle
des options SYN depuis le firewall lui-mme ou depuis n'importe quelle
machine derrire le firewall, j'obtiens une erreur operation not
permitted. Comment utiliser nmap avec Shorewall?"Rponse : Retirez temporairement
les rgles rejNotSyn, dropNotSyn and dropInvalid du fichier
/etc/shorewall/rules et relancez Shorewall.(FAQ 27) Je compile un nouveau noyau (kernel) pour mon firewall.
A quoi devrais-je faire attention?Rponse : Commencez par regarder
la page de configuration du noyau pour
Shorewall. Vous souhaiterez sans doute vous assurer que vous
avez bien slectionn NAT of local
connections (READ HELP) dans le menu de
configuration de Netfilter. Sans cela, les rgles DNAT ayant votre
firewall comme zone source ne fonctionneraient pas avec votre nouveau
noyau.(FAQ 27a) Je viens de compiler (ou j'ai tlcharg ou rcupr
par n'importe quel autre moyen) et d'installer un nouveau noyau et
Shorewall ne dmarre plus. Je sais que les options de mon noyau sont
correctes.Les dernires lignes de la trace
de dmarrage sont les suivantes:+ run_iptables2 -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
+ '[' 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE' = 'x-t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.
0/0 -j MASQUERADE' ']'
+ run_iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
+ iptables -t nat -A eth0_masq -s 192.168.2.0/24 -d 0.0.0.0/0 -j
MASQUERADE
iptables: Invalid argument
+ '[' -z '' ']'
+ stop_firewall
+ set +xRponse: votre noyau contient
des enttes incompatibles avec celles utilises pour compiler votre
programme iptables. Vous devez recompiler
iptables en utilisant l'arbre de sources de votre
nouveau noyau.(FAQ 28) Comment utiliser Shorewall en pont filtrant (Bridging
Firewall)?Rponse : Le support Shorewall
pour les ponts filtrant existe — voir
ici pour les dtails.(FAQ 39) Comment bloquer les connexion un domaine
particulier?J'ai essay de bloquer Adsense de Google. Adsense est un
Javascript que les gens ajoutent leur pages web. J'ai ajout la rgle
suivante:#ACTION SOURCE DEST PROTO
REJECT fw net:pagead2.googlesyndication.com allCependant, ceci bloque parfois les accs "google.com". Pourquoi?
Avec dig, je trouve les adresses IP suivantes pour le domaine
googlesyndication.com:216.239.37.99
216.239.39.99Et celles-ci pour google.com:216.239.37.99
216.239.39.99
216.239.57.99Je suppose donc que ce n'est pas le domaine qui
est bloqu mais plutt ses adresses IP. Comment bloquer rellement un
nom de domaine?Rponse: Les filtres de paquets
basent leurs dcisions sur le contenu des diffrents enttes de
protocole qui se trouvent au dbut de chaque paquet. Les filtres de
paquet suivi d'tats (dont Netfilter est un exemple) utilisent une
combinaison du contenu de l'entte et de l'tat de la connexion cr
lors du traitement de paquets prcdents. Netfilter (et l'usage qui en
est fait par Shorewall) prend galement en compte l'interface rseau sur
laquelle chaque paquet est entr ou sur laquelle le paquet va quitter le
routeur/firewall.Lorsque vous spcifiez un nom de domaine dans une
rgle Shorewall, le programme iptables rsout ce nom en une ou
plusieurs adresses IP et les vritables rgles qui seront cres sont
exprimes avec ces adresses IP. C'est pourquoi la rgle que vous avez
entre est quivalente :#ACTION SOURCE DEST PROTO
REJECT fw net:216.239.37.99 all
REJECT fw net:216.239.39.99 allSachant que
l'hbergement multiple bas sur le nom d'hte est une pratique courante
(par exemple, lists.shorewall.net et www1.shorewall.net sont hbergs
tous les deux sur le mme systme avec un seule adresse IP), il n'est
pas possible de filtrer les connexions vers un nom particulier au seul
examen des enttes de protocole. Alors que certains protocoles tels que
FTP ncessitent que le firewall examine et
ventuellement modifie les donnes (payload) du paquet, analyser les
donnes de paquets individuellement ne fonctionne pas toujours car le
flux de donnes de niveau application peut tre fractionn de manire
arbitraire entre les paquets. Ceci est une des faiblesses de l'extension
'string match' de Netfilter que l'on trouve dans le Patch-O-Matic-ng. Le
seul moyen sr pour filtrer sur le contenu des paquets est d'utiliser un
proxy pour les connexions concernes -- dans le cas de HTTP, on pourra
utiliser une application telle que Squid. Lorsqu'on utilise un
proxy, celui-ci r-assemble des messages complets de niveau applicatif
qui peuvent alors tre analyss de manire prcise.(FAQ 42) Comment connatre quelles sont les fonctions supportes
par mon noyau et ma version d'iptables?Rponse: En tant que root,
utilisez la commande shorewall[-lite] show
capabilities.gateway:~# shorewall show capabilities
Loading /usr/share/shorewall/functions...
Processing /etc/shorewall/params ...
Processing /etc/shorewall/shorewall.conf...
Loading Modules...
Shorewall has detected the following iptables/netfilter capabilities:
NAT: Available
Packet Mangling: Available
Multi-port Match: Available
Extended Multi-port Match: Available
Connection Tracking Match: Available
Packet Type Match: Available
Policy Match: Available
Physdev Match: Available
IP range Match: Available
Recent Match: Available
Owner Match: Available
Ipset Match: Available
ROUTE Target: Available
Extended MARK Target: Available
CONNMARK Target: Available
Connmark Match: Available
Raw Table: Available
gateway:~#(FAQ 19) Comment ouvrir le firewall pour tout le trafic de/vers
le LAN?Rponse : Ajoutez ces deux
politiques:#SOURCE DESTINATION POLICY LOG LIMIT:BURST
# LEVEL
$FW loc ACCEPT
loc $FW ACCEPT Vous pouvez galement supprimer toutes les rgles ACCEPT de
$FW->loc et loc->$FW car ces rgles sont maintenant redondantes
avec les deux politiques fixes ci-dessus.