shorewall_code/Samples/three-interfaces/rules

#
# Shorewall version 3.0 - Sample Rules File for three-interface configuration.
#
# /etc/shorewall/rules
#
#	Rules in this file govern connection establishment. 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 match is the one
#	that determines the disposition of the request.
#
#	In most places where an IP address or subnet is allowed, you
#	can preceed the address/subnet with "!" (e.g., !192.168.1.0/24) to
#	indicate that the rule matches all addresses except the address/subnet
#	given. Notice that no white space is permitted between "!" and the
#	address/subnet.
#------------------------------------------------------------------------------
# WARNING: 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 followed by the
# section name.
#
# Sections are as follows and must appear in the order listed:
#
#	ESTABLISHED		Packets in the ESTABLISHED 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 ACCEPT rule inserted
#				at the end of this section.
#
#	RELATED			Packets in the RELATED 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 ACCEPT rule inserted
#				at the end of this section.
#
#	NEW			Packets in the NEW and INVALID states are
#				processed by rules in this section.
#
# WARNING: If you specify FASTACCEPT=Yes in shorewall.conf then the
#	   ESTABLISHED and RELATED sections must be empty.
#
# Note: If you are not familiar with Netfilter to the point where you are
#	comfortable with the differences between the various connection
#	tracking states, then I suggest that you omit the ESTABLISHED and
#	RELATED sections and place all of your rules in the NEW section.
#
# 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.
#
# Columns are:
#
#	ACTION		ACCEPT, DROP, REJECT, DNAT, DNAT-, REDIRECT, CONTINUE,
#			LOG, QUEUE or an <action>.
#
#				ACCEPT	 -- allow the connection request
#				ACCEPT+	 -- like ACCEPT but also excludes the
#					    connection from any subsequent
#					    DNAT[-] or REDIRECT[-] rules
#				NONAT	 -- Excludes the connection from any
#					    subsequent DNAT[-] or REDIRECT[-]
#					    rules but doesn't generate a rule
#					    to accept the traffic.
#				DROP	 -- ignore the request
#				REJECT	 -- disallow the request and return an
#					    icmp-unreachable or an RST packet.
#				DNAT	 -- Forward 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.
#				SAME	 -- Similar to DNAT except that the
#					    port may not be remapped and when
#					    multiple server addresses are
#					    listed, all requests from a given
#					    remote system go to the same
#					    server.
#				SAME-	 -- Advanced users only.
#					    Like SAME but only generates the
#					    NAT iptables rule and not
#					    the companion ACCEPT rule.
#				REDIRECT -- Redirect the request to a local
#					    port on the firewall.
#				REDIRECT-
#					 -- Advanced users only.
#					    Like REDIRET but only generates the
#					    REDIRECT iptables rule and not
#					    the companion ACCEPT rule.
#
#				CONTINUE -- (For 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 /etc/shorewall/zones, this
#					    connection request will be passed
#					    to the rules defined for that
#					    (those) zone(s).
#				LOG	 -- Simply log the packet and continue.
#				QUEUE	 -- Queue the packet to a user-space
#					    application such as ftwall
#					    (http://p2pwall.sf.net).
#				<action> -- The name of an action defined in
#					    /etc/shorewall/actions or in
#					    /usr/share/shorewall/actions.std.
#
#				<macro>  -- The name of a macro defined in a
#					    file named macro.<macro-name>.
#
#			The ACTION may optionally be followed
#			by ":" and a syslog log level (e.g, REJECT:info or
#			DNAT:debug). This causes the packet to be
#			logged at the specified level.
#
#			If the ACTION names an action defined in
#			/etc/shorewall/actions 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 (must be in upper case) as a
#			log level.This will log to the ULOG target for routing
#			to a separate log through use of ulogd
#			(http://www.gnumonks.org/projects/ulogd).
#
#			Actions specifying logging may be followed by a
#			log tag (a string of alphanumeric characters)
#			are appended to the string generated by the
#			LOGPREFIX (in /etc/shorewall/shorewall.conf).
#
#			Example: ACCEPT:info:ftp would include 'ftp '
#			at the end of the log prefix generated by the
#			LOGPREFIX setting.
#
#	SOURCE		Source hosts to which the rule applies. May be a zone
#			defined in /etc/shorewall/zones, $FW to indicate the
#			firewall itself, "all", "all+" or "none" If the ACTION
#			is DNAT	or REDIRECT, sub-zones of the specified zone
#			may be excluded from the rule by following the zone
#			name with "!' and a comma-separated list of sub-zone
#			names.
#
#			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.
#
#			Except when "all[+]" is specified, clients may be
#			further restricted to a list of subnets and/or hosts by
#			appending ":" and a comma-separated list of subnets
#			and/or hosts. Hosts may be specified by IP or MAC
#			address; mac addresses must begin with "~" and must use
#			"-" as a separator.
#
#			Hosts may be specified as an IP address range using the
#			syntax <low address>-<high address>. This requires that
#			your kernel and iptables contain iprange match support.
#			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 source bindings to be
#			matched.
#
#			dmz:192.168.2.2		Host 192.168.2.2 in the DMZ
#
#			net:155.186.235.0/24	Subnet 155.186.235.0/24 on the
#						Internet
#
#			loc:192.168.1.1,192.168.1.2
#						Hosts 192.168.1.1 and
#						192.168.1.2 in the local zone.
#			loc:~00-A0-C9-15-39-78	Host in the local zone with
#						MAC address 00:A0:C9:15:39:78.
#
#			net:192.0.2.11-192.0.2.17
#						Hosts 192.0.2.11-192.0.2.17 in
#						the net zone.
#
#			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:192.168.1.5).
#
#	DEST		Location of Server. May be a zone defined in
#			/etc/shorewall/zones, $FW to indicate the firewall
#			itself, "all". "all+" or "none".
#
#			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.
#
#			Except when "all[+]" is specified, the server may be
#			further restricted to a particular subnet, host or
#			interface by appending ":" and the subnet, host or
#			interface. See above.
#
#				Restrictions:
#
#				1. MAC addresses are not allowed.
#				2. In DNAT rules, only IP addresses are
#				   allowed; no FQDNs or subnet addresses
#				   are permitted.
#				3. You may not specify both an interface and
#				   an address.
#
#			Like in the SOURCE column, you may specify a range of
#			up to 256 IP addresses using the syntax
#			<first ip>-<last ip>. 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.
#
#			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 modifiy 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 number MUST be specified as an integer
#			and not as a name from /etc/services.
#
#			if the ACTION is REDIRECT, this column needs only to
#			contain the port number on the firewall that the
#			request should be redirected to.
#
#	PROTO		Protocol - Must be "tcp", "udp", "icmp", "ipp2p",
#			a number, or "all". "ipp2p" requires ipp2p match
#			support in your kernel and iptables.
#
#	DEST 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.
#
#			A port range is expressed as <low port>:<high port>.
#
#			This column is ignored if PROTOCOL = all but must be
#			entered if any of the following ields are supplied.
#			In that case, it is suggested that this field contain
#			 "-"
#
#			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.
#			Otherwise, a separate rule will be generated for each
#			port.
#
#	CLIENT PORT(S)	(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.
#
#			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.
#			Otherwise, a separate rule will be generated for each
#			port.
#
#	ORIGINAL DEST	(0ptional) -- If ACTION is DNAT[-] or REDIRECT[-]
#			then if included and different from the IP
#			address given in the SERVER column, this is an address
#			on some interface on the firewall and connections to
#			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 usually 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 "!" then
#			the rule will be followed only if the original
#			destination address in the connection request does not
#			match any of the addresses listed.
#
#			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 "!".
#
#			See http://shorewall.net/PortKnocking.html for an
#			example of using an entry in this column with a
#			user-defined action rule.
#
#	RATE LIMIT	You may rate-limit the rule by placing a value in
#			this colume:
#
#				<rate>/<interval>[:<burst>]
#
#			where <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 whitespace embedded in the specification.
#
#				Example: 10/sec:20
#
#	USER/GROUP	This column may only be non-empty if the SOURCE is
#			the firewall itself.
#
#			The column may contain:
#
#	[!][<user name or number>][:<group name or number>][+<program name>]
#
#			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:
#
#				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'
#
#	Example: Accept SMTP requests from the DMZ to the internet
#
#	#ACTION SOURCE	DEST PROTO	DEST	SOURCE	ORIGINAL
#	#				PORT	PORT(S) DEST
#	ACCEPT	dmz	net	  tcp	smtp
#
#	Example: 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,http
#
#	Example: 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:10
#
#	Example: 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.2
#
#	Example: 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.69
#
#	Example: 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	22
#############################################################################################################
#ACTION		SOURCE		DEST		PROTO	DEST	SOURCE		ORIGINAL	RATE		USER/
#							PORT	PORT(S)		DEST		LIMIT		GROUP
#
#	Accept DNS connections from the firewall to the Internet
#
DNS/ACCEPT	$FW		net
#
#
#	Accept SSH connections from the local network to the firewall and DMZ
#
SSH/ACCEPT      loc             $FW
SSH/ACCEPT      loc             dmz
#
#	DMZ DNS access to the Internet
#
DNS/ACCEPT	dmz		net


# Reject Ping from the "bad" net zone.

Ping/REJECT     net             $FW

#
#       Make ping work bi-directionally between the dmz, net, Firewall and local zone
#       (assumes that the loc-> net policy is ACCEPT).
#

Ping/ACCEPT     loc             $FW
Ping/ACCEPT     dmz             $FW
Ping/ACCEPT     loc             dmz
Ping/ACCEPT     dmz             loc
Ping/ACCEPT     dmz             net

ACCEPT		$FW		net		icmp
ACCEPT		$FW		loc		icmp
ACCEPT		$FW		dmz		icmp

# Uncomment this if using Proxy ARP and static NAT and you want to allow ping from
# the net zone to the dmz and loc

#Ping/ACCEPT    net             dmz
#Ping/ACCEPT    net             loc

#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVE