Firewall configuration The firewall configuration located in /etc/config/firewall. Overview OpenWrt relies on netfilter for packet filtering, NAT and ...
13 downloads
19 Views
460KB Size
Firewall configuration The firewall configuration located in
/etc/config/firewall.
Overview OpenWrt relies on netfilter for packet filtering, NAT and mangling. The UCI Firewall provides a configuration interface that abstracts from the iptables system to provide a simplified configuration model that is fit for most regular purposes while enabling the user to supply needed iptables rules on his own when needed. UCI Firewall maps two or more Interfaces together into Zones that are used to describe default rules for a given interface, forwarding rules between interfaces, and extra rules that are not covered by the first two. In the config file, default rules come first but they are the last to take effect. The netfilter system is a chained processing filter where packets pass through various rules. The first rule that matches is executed, often leading to another rule-chain until a packet hits either ACCEPT or DROP/REJECT. Such an outcome is final, therefore the default rules take effect last, and the most specific rule takes effect first. Zones are also used to configure masquerading also known as NAT (network-address-translation) as well as port forwarding rules, which are more generally known as redirects. Zones must always be mapped onto one or more Interfaces which ultimately map onto physical devices; therefore zones cannot be used to specify networks (subnets), and the generated iptables rules operate on interfaces exclusively. The difference is that interfaces can be used to reach destinations not part of their own subnet, when their subnet contains another gateway. Usually however, forwarding is done between lan and wan interfaces, with the router serving as 'edge' gateway to the internet. The default configuration of UCI Firewall provides for such a common setup.
Requirements firewall (or firewall3) and its dependencies (pre-installed) iptables (pre-installed) iptables-mod-? (optional), see OPKG Netfilter Packages.
Sections Below is an overview of the section types that may be defined in the firewall configuration. A minimal firewall configuration for a router usually consists of one defaults section, at least two zones (lan and wan) and one forwarding to allow traffic from lan to wan. (The forwarding section is not strictly required when there are no more than two zones as the rule can then be set as the 'global default' for that zone.)
Defaults The defaults section declares global firewall settings which do not belong to specific zones. The following options are defined within this section: Name
Type
Required Default
Description
input
string
no
REJECT Set policy for the INPUT chain of the filter table.
output
string
no
REJECT Set policy for the OUTPUT chain of the filter table.
forward
string
no
REJECT Set policy for the FORWARD chain of the filter table.
drop_invalid
boolean no
0
syn_flood
boolean no
0
Drop invalid packets (e.g. not matching any active connection). Enable
SYN flood [http://en.wikipedia.org/wiki/SYN flood] protection
(obsoleted by synflood_protect setting).
synflood_protect
boolean no
0
Enable
synflood_rate
string
no
25
Set rate limit (packets/second) for SYN packets above which the traffic is considered a flood.
synflood_burst
string
no
50
Set burst limit for SYN packets above which the traffic is considered a flood if it exceeds the allowed rate.
tcp_syncookies
boolean no
1
Enable the use of cookies].
tcp_ecn
boolean no
0
tcp_westwood
boolean no
0
tcp_window_scaling
boolean no
1
accept_redirects
boolean no
0
accept_source_route boolean no
0
custom_chains
boolean no
1
disable_ipv6
boolean no
0
SYN flood [http://en.wikipedia.org/wiki/SYN flood] protection.
SYN cookies [http://en.wikipedia.org/wiki/SYN
Enable TCP window scaling.
Disable IPv6 firewall rules.
Zones A zone section groups one or more interfaces and serves as a source or destination for forwardings, rules and redirects. Masquerading (NAT) of outgoing traffic is controlled on a per-zone basis. Note that masquerading is defined on the outgoing interface. INPUT rules for a zone describe what happens to traffic trying to reach the router itself through that interface. OUTPUT rules for a zone describe what happens to traffic originating from the router itself. FORWARD rules for a zone describe what happens to traffic coming from that zone and passing to another zone. The options below are defined within Name
Type
Required
zone sections:
Default
Description
name
zone name
yes
(none)
Unique zone name
network
list
no
(none)
List of interfaces attached to this zone. If omitted and neither extra* options, subnets or devices are given, the value of name is used by default
masq
boolean no
0
Specifies whether outgoing zone traffic should be masqueraded - this is typically enabled on the wan zone
masq_src
list of no subnets
0.0.0.0/0
Limit masquerading to the given source subnets. Negation is possible by prefixing the subnet with !; multiple subnets are allowed.
masq_dest
list of no subnets
0.0.0.0/0
Limit masquerading to the given destination subnets. Negation is possible by prefixing the subnet with !; multiple subnets are allowed.
1 if masquerading Force connection tracking for this zone (see Note on connection tracking) is used, 0 otherwise
conntrack
boolean no
mtu_fix
boolean no
0
Enable MSS clamping for outgoing zone traffic
input
string
no
DROP
Default policy (ACCEPT, REJECT, DROP) for incoming zone traffic
forward
string
no
DROP
Default policy (ACCEPT, REJECT, DROP) for forwarded zone traffic
output
string
no
DROP
Default policy (ACCEPT, REJECT, DROP) for outgoing zone traffic
family
string
no
any
Protocol family (ipv4, ipv6 or any) to generate iptables rules for.
log
boolean no
0
Create log rules for rejected and dropped traffic in this zone.
log_limit
string
10/minute
Limits the amount of log messages per interval.
no
List of raw network device names attached to this zone, e.g. ppp+ to
device
list
no
(none)
match any PPP interface. Only supported by the Firewall v2, version 58 and above
subnet
list
extra
no
string
(none)
no
(none)
List of IP subnets attached to this zone. Only supported by the Firewall v2, version 58 and above Extra arguments passed directly to iptables. Note that these options are passed to both source and destination classification rules, therfore direction-specific options like –dport should not be used here - in this case the extra_src and extra_dest options should be used instead. Only supported by the Firewall v2, version 58 and above
extra_src
string
no
extra_dest string
no
Value of
Extra arguments passed directly to iptables for source classification rules.
extra
Value of
extra
Only supported by the Firewall v2, version 58 and above Extra arguments passed directly to iptables for destination classification rules. Only supported by the Firewall v2, version 58 and above
Forwardings The
forwarding sections control the traffic flow between zones and may enable
MSS clamping
[http://en.wikipedia.org/wiki/Path_MTU_discovery#Problems_with_PMTUD] for specific directions. Only one
direction is covered by a forwarding rule. To allow bidirectional traffic flows between two zones, two forwardings are required, with src and dest reversed in each. Below is a listing of allowed option within forwardings: Name
Type
Required Default
Description
src
zone name
yes
(none)
Specifies the traffic source zone. Must refer to one of the defined zone names
dest
zone name
yes
(none)
Specifies the traffic destination zone. Must refer to one of the defined zone names
mtu_fix boolean no
0
Enable MSS clamping for traffic flowing from the source zone to the destination zone (Deprecated and moved to zone sections in 8.09.2+)
family
any
Protocol family (ipv4, ipv6 or any) to generate iptables rules for.
string
no
The iptables rules generated for this section rely on the state match which needs connection tracking to work. At least one of the src or dest zones needs to have connection tracking enabled through either the masq or the conntrack option.
Redirects Port forwardings (DNAT) are defined by redirect sections. All incoming traffic on the specified source zone which matches the given rules will be directed to the specified internal host. Redirects are also commonly known as "port forwarding", and "virtual servers". Port ranges are specified as syntax.
start:stop, for instance 6666:6670. This is similar to the iptables
The options below are valid for redirects: Name
src
Type
Required
Default
yes for zone name
DNAT
(none)
Specifies the traffic source zone. Must refer to one of the defined zone names. For typical port forwards this usually is wan
(none)
Match incoming traffic from the specified source ip address
(none)
For DNAT, match incoming traffic directed at the given destination ip address. For SNAT rewrite the source address to the given address.
(none)
Match incoming traffic from the specified mac address
target
src_ip
ip address
src_dip
ip address
no yes for
SNAT
target
src_mac
mac address
no
Description
src_port
port or range
no
(none)
Match incoming traffic originating from the given source port or port range on the client host
src_dport
port or range
no
(none)
For DNAT, match incoming traffic directed at the given destination port or port range on this host. For SNAT rewrite the source ports to the given value.
proto
protocol name or number
yes
tcpudp
Match incoming traffic using the given protocol
dest
zone name
(none)
Specifies the traffic destination zone. Must refer to one of the defined zone names. For DNAT target on Attitude Adjustment, NAT reflection works only if this is equal to lan.
(none)
For DNAT, redirect matched incoming traffic to the specified internal host. For SNAT, match traffic directed at the given address.
yes for
SNAT
target
dest_ip
yes for ip address
DNAT
target
dest_port
port or range
no
(none)
For DNAT, redirect matched incoming traffic to the given port on the internal host. For SNAT, match traffic directed at the given ports.
ipset
string
no
(none)
If specified, match traffic against the given ipset. The match can be inverted by prefixing the value with an exclamation mark
(none)
If specified, match traffic against the given firewall mark, e.g. 0xFF to match mark 255 or 0x0/0x1 to match any even mark value. The match can be inverted by prefixing the value with an exclamation mark, e.g. !0x10 to match all but mark #16.
mark
string
start_date
date no (yyyy-mm-dd)
(always)
If specifed, only match traffic after the given date (inclusive).
stop_date
date no (yyyy-mm-dd)
(always)
If specified, only match traffic before the given date (inclusive).
start_time
time (hh:mm:ss)
no
(always)
If specified, only match traffic after the given time of day (inclusive).
stop_time
time (hh:mm:ss)
no
(always)
If specified, only match traffic before the given time of day (inclusive).
(always)
If specified, only match traffic during the given week days, e.g. sun mon thu fri to only match on sundays, mondays, thursdays and fridays. The list can be inverted by prefixing it with an exclamation mark, e.g. ! sat sun to always match but on saturdays and sundays.
weekdays
list of weekdays
no
no
monthdays
list of dates
no
(always)
If specified, only match traffic during the given days of the month, e.g. 2 5 30 to only match on every 2nd, 5th and 30rd day of the month. The list can be inverted by prefixing it with an exclamation mark, e.g. ! 31 to always match but on the 31st of the month.
utc_time
boolean
no
0
Treat all given time values as UTC time instead of local time.
target
string
no
DNAT
NAT target (DNAT or SNAT) to use when generating the rule
family
string
no
any
Protocol family (ipv4, ipv6 or any) to generate iptables rules for.
reflection
boolean
no
1
Activate NAT reflection for this redirect - applicable to DNAT targets.
reflection_src string
no
The source address to use for NAT-reflected packets if reflection is 1. This can be internal or external, internal specifying which interface’s address to use. Applicable to DNAT targets.
limit
string
no
(none)
Maximum average matching rate; specified as a number, with an optional /second, /minute, /hour or /day suffix. Example: 3/hour.
limit_burst
integer
no
5
Maximum initial number of packets to match, allowing a shortterm average above limit
extra
string
no
(none)
Extra arguments to pass to iptables. Useful mainly to specify additional match options, such as -m policy --dir in for IPsec.
On Attitude Adjustment, for NAT reflection to work, you must specify redirect section (even though we're using a DNAT target).
option dest lan in the
Rules Sections of the type rule can be used to define basic accept or reject rules to allow or restrict access to specific ports or hosts. Up to Firewall v2, version 57 and below the rules behave like redirects and are tied to the given source zone and match incoming traffic occuring there. In later versions the rules are defined as follows:
src and dest are given, the rule matches forwarded traffic If only src is given, the rule matches incoming traffic If only dest is given, the rule matches outgoing traffic If neither src nor dest are given, the rule defaults to an outgoing traffic rule If
start:stop, for instance 6666:6670. This is similar to the iptables
Port ranges are specified as syntax.
Valid options for this section are: Name
Type
Required
Default
Description
src
zone name
yes ( optional since Firewall (none) v2, version 58 and above)
src_ip
ip address
no
(none)
Match incoming traffic from the specified source ip address
src_mac
mac address
no
(none)
Match incoming traffic from the specified mac address
src_port
port or range
no
(none)
Match incoming traffic from the specified source port or port range, if relevant proto is specified.
Specifies the traffic source zone. Must refer to one of the defined zone names.
proto
protocol name or number
no
tcpudp
Match incoming traffic using the given protocol. Can be one of tcp, udp, tcpudp, udplite, icmp, esp, ah, sctp, or all or it can be a numeric value, representing one of these protocols or a different one. A protocol name from /etc/protocols is also allowed. The number 0 is equivalent to all.
dest
zone name
no
(none)
Specifies the traffic destination zone. Must refer to one of the defined zone names, or * for any zone. If specified, the rule applies to forwarded traffic; otherwise, it is treated as input rule.
dest_ip
ip address
no
(none)
Match incoming traffic directed to the specified destination ip address. With no dest zone, this is treated as an input rule!
dest_port
port or range
no
(none)
Match incoming traffic directed at the given destination port or port range, if relevant proto is specified.
ipset
string
no
(none)
If specified, match traffic against the given ipset. The match can be inverted by prefixing the value with an exclamation mark
(none)
If specified, match traffic against the given firewall mark, e.g. 0xFF to match mark 255 or 0x0/0x1 to match any even mark value. The match can be inverted by prefixing the value with an exclamation mark, e.g. !0x10 to match all but mark #16.
mark
mark/mask
start_date
date no (yyyy-mm-dd)
(always) If specifed, only match traffic after the given date (inclusive).
stop_date
date no (yyyy-mm-dd)
(always) If specified, only match traffic before the given date (inclusive).
start_time
time (hh:mm:ss)
no
(always)
If specified, only match traffic after the given time of day (inclusive).
stop_time
time (hh:mm:ss)
no
(always)
If specified, only match traffic before the given time of day (inclusive).
list of
no
If specified, only match traffic during the given week days, e.g. sun mon thu fri to only match on sundays, mondays, thursdays
weekdays
weekdays
no
(always) and fridays. The list can be inverted by prefixing it with an exclamation mark, e.g. ! sat sun to always match but on saturdays and sundays.
monthdays
list of dates
no
If specified, only match traffic during the given days of the month, e.g. 2 5 30 to only match on every 2nd, 5th and 30rd day of the (always) month. The list can be inverted by prefixing it with an exclamation mark, e.g. ! 31 to always match but on the 31st of the month.
utc_time
boolean
no
0
Treat all given time values as UTC time instead of local time.
target
string
yes
DROP
Firewall action (ACCEPT, REJECT, DROP, MARK, NOTRACK) for matched traffic
set_mark
yes for target
mark/mask
set_xmark
MARK
(none)
Zeroes out the bits given by mask and ORs value into the packet mark. If mask is omitted, 0xFFFFFFFF is assumed Zeroes out the bits given by mask and XORs value into the packet mark. If mask is omitted, 0xFFFFFFFF is assumed
family
string
no
any
Protocol family (ipv4, ipv6 or any) to generate iptables rules for.
limit
string
no
(none)
Maximum average matching rate; specified as a number, with an optional /second, /minute, /hour or /day suffix. Example: 3/hour.
limit_burst integer
no
5
Maximum initial number of packets to match, allowing a short-term average above limit
extra
no
(none)
Extra arguments to pass to iptables. Useful mainly to specify additional match options, such as -m policy --dir in for IPsec.
string
Includes It is possible to include custom firewall scripts by specifying one or more firewall configuration.
include sections in the
There is only one possible parameter for includes: Name
Type
Required
Default
Description
enabled boolean no
1
Allows to disable the corresponding include without having to delete the section
type
string
no
script
Specifies the type of the include, can be script for traditional shell script includes or restore for plain files in iptables-restore format
path
file name
yes
/etc/firewall.user Specifies a shell script to execute on boot or firewall restarts
family
string
no
any
Specifies the address family (ipv4, ipv6 or any) for which the include is called
reload
boolean no
0
Specifies whether the include should be called on reload - this is only needed if the include injects rules into internal chains
Includes of type script may contain arbitary commands, for example advanced iptables rules or tc commands required for traffic shaping. Since custom iptables rules are meant to be more specific than the generic ones, you must make sure to use -I (insert) instead of -A (append) so that the rules appear before the default rules.
IP Sets The UCI firewall version 3 supports referencing or creating ipsets [http://ipset.netfilter.org/] to simplify matching of huge address or port lists without the need for creating one rule per item to match, The following options are defined for ipsets: Name
enabled
Type boolean
Required no
Default
1
Description Allows to disable the declaration fo the ipset without the need to delete the section.
external
string
no
If the external option is set to a name, the firewall will simply reference an already existing ipset pointed to by the name. If the external option is unset, the firewall will create the ipset on start and destroy it on stop.
(none)
(none) if
external external is unset yes if
name
is unset no if
string
value of
external Specifies the firewall internal name of the ipset which is used to
external if is set external
reference the set in rules or redirects.
is set
family
string
ipv4
no
storage
string
match
list of direction/type yes tuples
no
varies
bitmap
IP range
Specifies the storage method (bitmap, hash or list) used by the ipset, the default varies depending on the used datatypes (see match option below). In most cases the storage method can be automatically inferred from the datatype combination but in some cases multiple choices are possible (e.g. bitmap:ip vs. hash:ip).
(none)
Specifies the matched data types (ip, port, mac, net or set) and their direction (src or dest). The direction is joined with the datatype by an underscore to form a tuple, e.g. src_port to match source ports or dest_net to match destination CIDR ranges.
(none)
Specifies the IP range to cover, see ipset(8) [http://ipset.netfilter.org/ipset.man.html]. Only applicable to the hash storage type.
(none)
Specifies the port range to cover, see ipset(8) [http://ipset.netfilter.org/ipset.man.html]. Only applicable to the hash storage type.
yes for storage type
iprange
Protocol family (ipv4 or ipv6) to create ipset for. Only applicable to storage types hash and list, the bitmap type implies ipv4.
with datatype
ip
yes for storage type
portrange Port range
bitmap with datatype
port netmask
integer
no
32
If specified, network addresses will be stored in the set instead of IP host addresses. Value must be between 1 and 32, see ipset(8) [http://ipset.netfilter.org/ipset.man.html]. Only applicable to the bitmap storage type with match ip or the hash storage type with match ip.
maxelem
integer
no
65536
Limits the number of items that can be added to the set, only applicable to the hash and list storage types.
hashsize
integer
no
1024
Specifies the initial hash size of the set, only applicable to the hash storage type.
timeout
integer
no
0
Specifies the default timeout for entries added to the set. A value of 0 means no timeout.
Possible Storage / Match Combinations The table below outlines the possible combinations of storage methods and matched datatypes as well as the usable IP address family. The order of the datatype matches is significant. Family Storage
Match
Notes
ipv4
bitmap ip
Requries iprange option
ipv4
bitmap ip mac
Requires iprange option
ipv4
bitmap port
Requires portrange option
any
hash
ip
-
any
hash
net
-
any
hash
ip port
-
any
hash
net port
-
any
hash
ip port ip
-
any
hash
ip port net -
-
list
set
Meta type to create a set-of-sets
IPv6 notes As described above, the option family is used for distinguishing between IPv4, IPv6 and both protocols. However the family is inferred automatically if IPv6 addresses are used, e.g. config rule option src wan option src_ip fdca:f00:ba3::/64 option target ACCEPT
… is automatically treated as IPv6 only rule. Similar, such a rule: config rule option src wan option dest_ip 88.77.66.55 option target REJECT
… is detected as IPv4 only. Rules without IP addresses are automatically added to iptables and ip6tables, unless overridden by the family option. Redirect rules (portforwards) are always IPv4 (for now) since there is no IPv6 DNAT support (yet).
Examples Opening ports The default configuration accepts all LAN traffic, but blocks all incoming WAN traffic on ports not currently used for connections or NAT. To open a port for a service, add a rule section: config rule option option option option
src dest_port target proto
wan 22 ACCEPT tcp
This example enables machines on the internet to use SSH to access your router.
Port forwarding for IPv4 (Destination NAT/DNAT) This example forwards http (but not HTTPS) traffic to the webserver running on 192.168.1.10: config redirect option src option src_dport option proto option dest option dest_ip
wan 80 tcp lan 192.168.1.10
This other example forwards one arbitrary port that you define to a box running ssh. config redirect
option option option option option option
src src_dport proto dest dest_ip dest_port
wan 5555 tcp lan 192.168.1.100 22
Port forwarding for IPv6 To open port 80 so that a local webserver at Internet: config rule option option option option option option option
src proto dest dest_ip dest_port family target
2001:db8:42::1337 can be reached from the
wan tcp lan 2001:db8:42::1337 80 ipv6 ACCEPT
To open SSH access to all IPv6 hosts in the local network: config rule option option option option option option
src proto dest dest_port family target
wan tcp lan 22 ipv6 ACCEPT
To open all TCP/UDP port between 1024 and 65535 towards the local IPv6 network: config rule option option option option option option
src proto dest dest_port family target
wan tcpudp lan 1024:65535 ipv6 ACCEPT
Source NAT (SNAT) Source NAT changes an outgoing packet so that it looks as though the OpenWrt system is the source of the packet. Define source NAT for UDP and TCP traffic directed to port 123 originating from the host with the IP address 10.55.34.85. The source address is rewritten to 63.240.161.99: config redirect option src option dest option src_ip option src_dip option dest_port option target
lan wan 10.55.34.85 63.240.161.99 123 SNAT
When used alone, Source NAT is used to restrict a computer's access to the internet, but allow it to access a few services by forwarding what appear to be a few local services, e.g. NTP [http://en.wikipedia.org/wiki/Network_time_protocol], to the internet. While DNAT hides the local network from the internet, SNAT hides the internet from the local network. Source NAT and destination NAT are combined and used dynamically in IP masquerading to make computers with private (192.168.x.x, etc.) IP address appear on the internet with the OpenWrt router's public WAN ip address.
True destination port forwarding Most users won't want this. Its usage is similar to SNAT, but as the the destination IP address isn't changed, machines on the destination network need to be aware that they'll receive and answer requests from a public IP address that isn't necessarily theirs. Port forwarding in this fashion is typically used for load balancing. config redirect option src option src_dport option dest option dest_port option proto
wan 80 lan 80 tcp
Block access to a specific host The following rule blocks all connection attempts to the specified host address. config rule option option option option
src dest dest_ip target
lan wan 123.45.67.89 REJECT
Block access to the Internet using MAC The following rule blocks all connection attempts from the client to the Internet. config rule option option option option
src dest src_mac target
lan wan 00:00:00:00:00:00 REJECT
Block access to the Internet for specific IP on certain times The following rule blocks all connection attempts to the internet from 192.168.1.27 on weekdays between 21:00pm and 09:00am. The package iptables-mod-ipopt must be installed to provide xt_time. config rule option option option option option
src dest src_ip extra target
lan wan 192.168.1.27 '-m time --weekdays Mon,Tue,Wed,Thu,Fri --timestart 21:00 --timestop 09:00' REJECT
Using firewall v3 and later the example becomes: config rule option option option option option option option
src dest src_ip start_time stop_time weekdays target
lan wan 192.168.1.27 21:00 09:00 'mon tue wed thu fri' REJECT
Restricted forwarding rule
The example below creates a forward rule rejecting traffic from lan to wan on the ports 1000-1100. config rule option option option option option
src dest dest_port proto target
lan wan 1000-1100 tcpudp REJECT
Simple output rule The example below creates an output rule which prevents the router from pinging the address 8.8.8.8. Only supported by the Firewall v2, version 58 and above config rule option option option option
dest dest_ip proto target
wan 8.8.8.8 icmp REJECT
Transparent proxy rule (same host) The rule below redirects all outgoing HTTP traffic from lan through a proxy server listening at port 3128 on the router itself. config redirect option src option proto option src_dport option dest_port option dest_ip
lan tcp 80 3128 192.168.1.1
Transparent proxy rule (external) The following rule redirects all outgoing HTTP traffic from lan through an external proxy at 192.168.1.100 listening on port 3128. It assumes the OpenWrt lan address to be 192.168.1.1 - this is needed to masquerade redirected traffic towards the proxy. config redirect option src option proto option src_ip option src_dport option dest_ip option dest_port option target
lan tcp !192.168.1.100 80 192.168.1.100 3128 DNAT
config redirect option dest option proto option src_dip option dest_ip option dest_port option target
lan tcp 192.168.1.1 192.168.1.100 3128 SNAT
Simple DMZ rule The following rule redirects all WAN ports for all protocols to the internal host 192.168.1.2. config redirect
option src option proto option dest_ip
wan all 192.168.1.2
IPSec passthrough This example enables proper forwarding of IPSec traffic through the wan. # AH protocol config rule option option option option
src dest proto target
wan lan ah ACCEPT
# ESP protocol config rule option option option option
src dest proto target
wan lan esp ACCEPT
For some configurations you also have to open port 500/UDP. # ISAKMP protocol config rule option src option dest option proto option src_port option dest_port option target
wan lan udp 500 500 ACCEPT
Zone declaration for non-UCI interfaces This example declares a zone which maches any Linux network device whose name begins with "ppp". Only supported by the Firewall v2, version 58 and above config zone option option option option option
name input output forward device
example ACCEPT ACCEPT REJECT 'ppp+'
Zone declaration for a specific subnet and protocol This example declares a zone which maches any TCP stream in the Only supported by the Firewall v2, version 58 and above config zone option option option option option option
name input output forward subnet extra
example ACCEPT ACCEPT REJECT '10.21.0.0/16' '-p tcp'
Zone declaration for a specific protocol and port
10.21.0.0/16 subnet.
This example declares a zone which maches any TCP stream from and to port
22.
Only supported by the Firewall v2, version 58 and above config zone option option option option option option
name input output forward extra_src extra_dest
example ACCEPT ACCEPT REJECT '-p tcp --sport 22' '-p tcp --dport 22'
Forwarding IPv6 tunnel traffic This example is for IPv6 tunnels only, and does not apply to native dual-stack interfaces. Unverified Information! From my experience all you need to do is just add the interface name of your ipv6 tunnel to the wan zone of your firewall. This worked for me Remove the information below if this is the correct way to proceed. Caveat: The above will only work if the tunnel is bringing IPv6 connectivity to the router itself. If you use the tunnel to route a prefix into your lan as well, you will additionally need to allow Inter-Zone Forwarding from wan to lan (not enabled by default). Creating a separate firewall zone (as described below) is a cleaner solution, though.
IPv6 packets are by default not forwarded from lan to your wan6 interface and vice versa. Make sure to add net.ipv6.conf.all.forwarding=1 in /etc/sysctl.conf to enable it permanently. Assuming your tunnel interface is called henet, add the following sections to /etc/config/firewall to create a new zone wan6, covering henet and allowing forwarding betweeen wan6 and lan in both directions: config zone option option option option option option
name wan6 network henet family ipv6 input ACCEPT output ACCEPT forward REJECT
config forwarding option dest lan option src wan6 #you don't need the below as you can a firewall rule to open the port that you need config forwarding option dest wan6 option src lan
family option ensures that the zone and all associated entries (rule, forwarding and redirect sections) are only added to ip6tables but not iptables. The
Manual iptables rules Traditional iptables rules, in the standard iptables unix command form, can be specified in an external file and included in the firewall config file. It is possible to include multiple files this way. config include option path /etc/firewall.user config include option path /etc/firewall.vpn
The syntax for the includes is Linux standard, and therefore different from UCI's; its documentation
can be found in netfilter.
Firewall management After a configuration change, firewall rules are rebuilt by executing /etc/init.d/firewall restart; calling /etc/init.d/firewall stop will flush all rules and set the policies to ACCEPT on all standard chains. To manually start the firewall, call /etc/init.d/firewall start. The firewall can be permananently disabled by executing /etc/init.d/firewall disable. Note that disable does not flush the rules, so it might be required to issue a stop before. Use enable to activate the firewall again.
Temporarily disable firewall Run /etc/init.d/firewall stop to flush all rules and set the policies to ACCEPT. To restart the firewall, run /etc/init.d/firewall start.
Hotplug hooks (8.09.2+) In addition to includes it is possible to let the firewall execute hotplug handlers when interfaces are added to a zone or removed from it. This is useful to create rules for interfaces with dynamic ip configurations (dhcp, pppoe) on the fly. Each time an interface is added or removed from a zone, all scripts in the /etc/hotplug.d/firewall/ directory are executed. Scripts must be named in the form with NN being a numeric index between 00 and 99. The name can be freely choosen.
NN-name
Once a handler script is invoked, the information about the event is passed through the environment. The table below lists defined variables and their meaning. Variable
Description
ACTION
Type of the event: add if an interface was added, remove if it was removed
ZONE
Name of the firewall zone the interface was added to
INTERFACE DEVICE
OpenWrt name of the interface, for example "lan" or "wan" - corresponds to the interfaces defined in
/etc/config/network
The physical interface involved, for example "eth0" or "ppp0"
Implications of DROP vs. REJECT The decision whether to drop or to reject traffic should be done on a case-by-case basis. Many people see dropping traffic as a security advantage over rejecting it because it exposes less information to a hypothetical attacker. While dropping slightly increases security, it can also complicate the debugging of network issues or cause unwanted side-effects on client programs. If traffic is rejected, the router will respond with an ICMP error message ("destination port unreachable") causing the connection attempt to fail immediately. This also means that for each connection attempt a certain amount of response traffic is generated. This can cause harm if the firewall is "attacked" with many simultaneous connection attempts; the resulting "backfire" of ICMP responses can clog up all available bandwidth and make the connection unusable (DoS). When connection attempts are dropped the client is not aware of the blocking and will continue to re-transmit its packets until the connection eventually times out. Depending on the way the client software is implemented, this could result in frozen or hanging programs that need to wait until a timeout occurs before they're able to continue. Also there is an interesting article which that claims dropping connections doesnt make you any
safer - Drop versus Reject [http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject]. DROP less information is exposed less attack surface client software may not cope well with it (hangs until connection times out) may complicate network debugging (where was traffic dropped and why) REJECT may expose information (like the ip at which traffic was actually blocked) client software can recover faster from rejected connection attempts network debugging easier (routing and firewall issues clearly distinguishable)
Notes on connection tracking NOTRACK By default, the firewall will disable connection tracking for a zone if no masquerading is enabled. This is achieved by generating NOTRACK firewall rules matching all traffic passing via interfaces referenced by the firewall zone. The purpose of NOTRACK is to speed up routing and save memory by circumventing resource intensive connection tracking in cases where it is not needed. You can check if connection tracking is disabled by issuing iptables -t raw -vnL, it will list all rules, check for NOTRACK target. NOTRACK will render certain ipables extensions unusable, for example the MASQUERADE target or the state match will not work! If connection tracking is required, for example by custom rules in /etc/firewall.user, the conntrack option must be enabled in the corresponding zone to disable NOTRACK. It should appear as option 'conntrack' '1' in the right zone in /etc/config/firewall. For further information see http://security.maruhn.com/iptables-tutorial/x4772.html [http://security.maruhn.com/iptables-tutorial/x4772.html] .
nf_conntrack_skip_filter Since r42048 [https://dev.openwrt.org/changeset/42048/trunk/package], there is a new setting activated by default which causes the packets with the established state, completely bypass iptables filter table. This is to help with network performance [https://dev.openwrt.org/ticket/17690#comment:6] and unless you need all packets to be counted by iptables filter or have some specific rules which would apply to already established connections, you should leave it active. This behavior can be disabled by editing /etc/sysctl.conf : net.netfilter.nf_conntrack_skip_filter=0
and then activating the new setting: sysctl -p
or be temporarily turned off untill the next reboot by issuing : sysctl -w net.netfilter.nf_conntrack_skip_filter=0
How to delete a rule
If you made a mistake you can delete a rule this way. First, issue this command to find the index of the rule: # iptables -L -t raw --line-numbers
Now to delete, e.g. the third rule from chain OUTPUT, execute: # iptables -t raw -D OUTPUT 3
Debug generated rule set It is possible to observe the iptables commands generated by the firewall program, this is useful to track down iptables errors during firewall restarts or to verify the outcome of certain uci rules. In order to see the rules as they're executed, run the variable set to 1 (one):
fw command with the FW_TRACE environment
# FW_TRACE=1 fw reload
To direct the output to a file for later inspection, use the command below: # FW_TRACE=1 fw reload 2>/tmp/iptables.log
If you are using the firewall3, you can enable debug mode using the
-d switch:
# fw3 -d reload 2>/tmp/iptables.log
Furthermore it is also possible to print the to-be generated ruleset using the conjunction with the -4 and -6 switches:
print command in
# fw3 -4 print > /tmp/ipv4.rules # fw3 -6 print > /tmp/ipv6.rules
Packet flow INPUT (destined to router) Table raw
mangle
nat
Chain
Type
Description
PREROUTING
system
notrack
internal Internal chain for NOTRACK rules
PREROUTING
system
fwmark
internal Internal chain for MARK rules
PREROUTING
system
delegate_prerouting
internal
Internal chain to hold toplevel prerouting rules, dispatches traffic to the corresponding zone_name_prerouting chains
prerouting_rule
user
Container chain for custom user prerouting rules (firewall.user)
zone_name_prerouting internal Per-zone container chains for DNAT (port forwarding) rules prerouting_name_rule user mangle INPUT
system
INPUT
system
Per-zone container chains for custom user prerouting rules (firewall.user)
Internal chain to hold toplevel input rules, dispatches traffic to the
filter
delegate_input
internal corresponding zone_name_input chains
input_rule
user
syn_flood
internal Internal chain to match and drop syn flood attempts
zone_name_input
internal Per-zone container chains for input rules
input_name_rule
user
Container chain for custom user input rules (firewall.user)
Per-zone container chains for custom user input rules (firewall.user)
OUTPUT (originating from router) Table
Chain
Type
raw
OUTPUT
system
mangle OUTPUT
system
OUTPUT
system
OUTPUT
system
delegate_output
internal
Internal chain to hold toplevel output rules, dispatches traffic to the corresponding zone_name_output chains
output_rule
user
Container chain for custom user output rules (firewall.user)
zone_name_output
internal Per-zone container chains for output rules
output_name_rule
user
nat
filter
Description
Per-zone container chains for custom user output rules (firewall.user)
mangle POSTROUTING
system
POSTROUTING
system
delegate_postrouting
internal
Internal chain to hold toplevel postrouting rules, dispatches traffic to the corresponding zone_name_postrouting chains
postrouting_rule
user
Container chain for custom user postrouting rules (firewall.user)
nat
zone_name_postrouting internal Per-zone container chains for postrouting rules (masq, snat) postrouting_name_rule user
Per-zone container chains for custom user postrouting rules (firewall.user)
FORWARD (relayed through router) Table raw
mangle
nat
mangle
filter
Chain
Type
PREROUTING
system
notrack
internal Internal chain for NOTRACK rules
PREROUTING
system
fwmark
internal Internal chain for MARK rules
PREROUTING
system
delegate_prerouting
internal
Internal chain to hold toplevel prerouting rules, dispatches traffic to the corresponding zone_name_prerouting chains
prerouting_rule
user
Container chain for custom user prerouting rules (firewall.user)
zone_name_prerouting
internal Per-zone container chains for DNAT (port forwarding) rules
prerouting_name_rule
user
FORWARD
system
mssfix
internal Internal chain to hold for TCPMSS rules (mtu_fix)
FORWARD
system
delegate_forward
internal
Internal chain to hold toplevel forward rules, dispatches traffic to the corresponding zone_name_forward chains
forwarding_rule
user
Container chain for custom user forward rules (firewall.user)
zone_name_forward
internal Per-zone container chains for output rules
forwarding_name_rule
user
mangle POSTROUTING
system
Description
Per-zone container chains for custom user prerouting rules (firewall.user)
Per-zone container chains for custom user forward rules (firewall.user)
POSTROUTING
system
delegate_postrouting
internal
Internal chain to hold toplevel postrouting rules, dispatches traffic to the corresponding zone_name_postrouting chains
postrouting_rule
user
Container chain for custom user postrouting rules (firewall.user)
nat
zone_name_postrouting internal Per-zone container chains for postrouting rules (masq, snat) postrouting_name_rule user
Per-zone container chains for custom user postrouting rules (firewall.user)
Do góry doc/uci/firewall.txt · ostatnio zmienione: 2014/09/08 16:30 przez hamy
License.
This text is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported
