firewall

NAME
SYNOPSIS
DESCRIPTION
INTERNAL RULES
SEE ALSO
AUTHOR
COPYRIGHT

NAME

firewall - Configure the firewall

SYNOPSIS

[1] firewall [(external | web | rweb | antivirus | admin | mon | file | peer | auxiliary | vpnipsec) [(add | add:<rule-name> | insert:<rule-name>) <rule-name> (deny | allow) [<protocol> [<src-ip>[/<mask-prefix>] [<destination-zone> [<dst-ip>[/<mask-prefix>] [<dst-port1>[:<dst-port2>] [(<src-nat-ip> | nil) [<dst-nat-ip> [<dst-pat-port>]]]]]]]]]]

[6] firewall dos [(tcpflood | udpflood | webflood | rwebflood) [default | set <limit-per-second> [<limit-burst>]]]

DESCRIPTION

When the modes router and firewall are activated (see the command mode), the appliance acts as a stateful firewall filtering IP traffic crossing the system. The firewall command allows you to manage firewall rules. Please note that the command firewall allows you to filter traffic crossing the appliance but not destined to the appliance itself. To filter traffic destined to the appliance itself use the command access.

To the appliance, networks are divided to four main zones: the external, the internal, the auxiliary and the vpnipsec zones. Each zone is connected to the appliance via a network interface such that the external zone is connected via the external network interface and the auxiliary zone is connected via the auxiliary network interface. As the internal network interface may be configured with tagged vlans (see the command mode), possible internal zones are web, rweb, antivirus, admin, mon, file and peer. When the appliance works without tagged VLANs, these zones are not differentiated (and setting a firewall rule for one of them is applied to the others). When the IPsec VPN mode is activated (mode vpnipsec on), the vpnipsec zone refers to private networks inside connected IPsec VPN tunnels.

The firewall filters the traffic according to the incoming zone from which a new connection is sent. Each firewall rule is attached to a zone and can allow or deny incoming new connections from that zone and outgoing to another zones (<destination-zone>). A firewall rule should specify the source IP address, the destination IP address and possibly the destination port number. Optionally the rule may specify to NAT (Network Address Translation) the source and/or destination IP address of the traffic. In case of a NAT for the destination IP address the destination port may also be translated to another port number. The translation of destination port number is called PAT (Port Address Translation).

It is IMPORTANT to note that in rules, destination and source NAT are always applied AFTER the filtering.

Default rules are applied when no rules is specified for a zone. When at least one rule is specified for a given zone, any traffic other than those specified by that rule are denied by default and there is no need to add a deny rule at the end of a rule set. Default rules are base on the principals below:

• New connections incoming from the external zone and destined to the internal, auxiliary and vpnipsec zones are denied.

• New connections incoming from the internal zone (the web zone only if the vlan mode is activated) and destined to other zones are allowed.

• New connections incoming from the auxiliary zone are denied by default (to allow traffic you should explicitly specify rules).

• If the vlan mode is activated, new connections incoming from the rweb, antivirus, admin, mon, file and peer zones are denied by default. Otherwise, they are all considered as being the internal zone and therefore follow the principals applied to the internal zone.

• New connections incoming from the vpnipsec zone and destined to the internal zone (the web zone only if the vlan mode is activated) are allowed. Incoming connections from the vpnipsec zone and destined to other zones are denied by default.

The first [1] usage form allows you to add or insert a firewall rule to a firewall rule set. There are as many rule sets as there are network interfaces. Each firewall rule is identified by an identifier (<rule-name>) in a rule set. A <rule-name> must begin with an alpha character and may contains alpha numeric characters as well as the characters "_" and "-". To add a rule at the end of a all rules in a set, use the keyword add. To add a rule after a given rule, use the keyword add: followed by the rule name after which the new rule have to be inserted. To insert a rule before a given rule, use the keyword insert: followed by the rule name before which the new rule have to be inserted.

To allow a traffic use the keyword allow. To deny a traffic use the keyword deny.

Supported protocols are as follows:

• ah (IPsec AH - IP Authentication Header)

• esp (IPsec ESP - IP Encapsulating Security Payload)

• etherip (Ethernet within IP encapsulation)

• fc (Fiber Channel)

• ftp_active (Active File Transfer Protocol )

• ftp_passive (Passive File Transfer Protocol )

• ftp_trivial (TFTP or Trivial File Transfer Protocol)

• sip (Session Initiation Protocol for VoIP)

• gre (GRE tunneling)

• icmp (Internet Control Message Protocol - Ping)

• igmp (Internet Group Management Protocol - Multicast)

• ipv6 (Internet Protocol Version 6)

• mtp (Multicast Transport Protocol)

• ospfigp (Open Shortest Path First IGP)

• tcp (Transmission Control Protocol)

• tlsp (Transport Layer Security Protocol)

• udp (User Datagram Protocol)

• visa (VISA Protocol)

The source or destination may be a single IP address or an IP address range using the CIDR ( Classless Inter-Domain Routing) notation. CIDR notation uses a combination of an IP address and its associated network mask prefix separated with the ’/’ character. The network mask prefix is the number of (leftmost) ’1’ bits in the mask. For example 10.0.10.0/24 is a CIDR notation where the network mask 255.255.255.0 is applied to the 10.0.10.0 network. This notation represents the IP address range 10.0.10.0 - 10.0.10.255. The port specification may be a unique port number or a port range. A port range is specified by giving two port numbers separated by a colon (:) character (for instance 7510:7529). The keyword any can be used to specify an undefined protocol, IP address or port number.

The second [2] usage form allows you to move a rule from one position to another in a firewall rule set. To move a rule before or after another denoted rule use the keyword move: followed by the sign - (for before) or + (for after), the rule name of the denoted rule and the rule name of the rule to move. Please note that white spaces are not allowed between the keyword move:, the signs - or + and the rule name of the denoted rule. To move a rule to an absolute position use the move: followed by the position number and the rule name of the rule to move (the first position is the position number 1). Please note that white spaces are not allowed between the keyword move: and the position number.

The third [3] usage form allows you to delete a firewall rule identified by a <rule-name> in a rule set. The fourth [4] usage form allows you to erase all firewall rules in a rule set.

The fifth [5] usage allow you to activate or deactivate a firewall rule in a rule set. You can activate or deactivate several rules at the same time be giving several rule name preceded by on or off.

There are a bunch of built-in firewall rules that protect against known attacks such as Denial of Service (DoS) attacks. Built-in firewall rules and the tags that identify them in logs are described in the INTERNAL RULES section below. Regarding DoS attacks, it is important to properly tune the system in order to distinguish between high loads and attacks. During the OS installation, DoS limits are automatically configured according to the number of supported users. Usage forms [6] and [7] allow you to modify those limits if necessary. To modify the limits for a given DoS attack, use the keyword dos followed by the DoS attack name, the keyword set and the required limits. To apply default values, use the default keyword instead of fBset without any further arguments.

DoS attack for which limits can be configured are given below:

• tcpflood: protects against TCP SYN and RST flood attacks routed via the system (not destined to services running on the system). Two limit values could be specified for this DoS type: <limit-per-second> and <limit-burst>. The first value is mandatory and specifies the number of allowed TCP SYN/RST per second. The second value is optional and specifies the maximum number of TCP SYN/RST per second to reach before beginning to block TCP SYN/RST connections.

• udpflood: protects against UDP flood attacks routed via the system (not destined to services running on the system). Two limit values could be specified for this DoS type: <limit-per-second> and <limit-burst>. The first value is mandatory and specifies the number of allowed UDP requests per second. The second value is optional and specifies the maximum number of UDP requests per second to reach before beginning to block requests.

• webflood: protects against TCP SYN and RST flood and UDP flood attacks destined to services running on the system except the reverse web service (see the rweb command). Two limit values could be specified for this DoS type: <limit-per-second> and <limit-burst>. The first value is mandatory and specifies the number of allowed TCP SYN/RST or UDP requests per second. The second value is optional and specifies the maximum number of TCP SYN/RST or UDP requests per second to reach before beginning to block TCP SYN/RST connections or UDP requests. Even if the name of this DoS type includes the web word, it concerns non only Web services such as the forwarding Web proxy but also all other services used by protected end-users such as the embedded DNS and OCSP servers.

• rwebflood: protects against TCP SYN and RST flood attacks destined to the reverse web service (see the rweb command). Two limit values could be specified for this DoS type: <limit-per-second> and <limit-burst>. The first value is mandatory and specifies the number of allowed TCP SYN/RST per second. The second value is optional and specifies the maximum number of TCP SYN/RST per second to reach before beginning to block TCP SYN/RST connections. Setting this value to 0 allows you to disable this protection.

• piptcp: protects against an abusive number of TCP SYN incoming from the same source IP address and routed via the system. One limit value should be specified for this DoS type: <max-limit>. The <max-limit> is the maximum number of parallel TCP SYN incoming from the same source IP address. Setting this value to 0 allows you to disable this protection.

• pipweb: protects against an abusive number of new (TCP SYN) Web requests incoming from the same source IP address and destined to the system itself except the reverse proxy (see the rweb command). One limit value should be specified for this DoS type: <max-limit>. The <max-limit> is the maximum number of parallel TCP SYN incoming from the same source IP address. Setting this value to 0 allows you to disable this protection. Disabling this protection can be useful when the system is accessed by remote end-users having all the same IP address (for instance in a public cloud configuration).

• piprweb: protects against an abusive number of new (TCP SYN) requests on cloaked websites (rWeb websites) incoming from the same source IP address). One limit value should be specified for this DoS type: <max-limit>. The <max-limit> is the maximum number of parallel TCP SYN incoming from the same source IP address. Setting this value to 0 allows you to disable this protection. Disabling this protection can be useful when the system is accessed by remote end-users having all the same IP address.

• pipdns: protects against an abusive number of new (TCP SYN) DNS requests per source IP address. One limit value should be specified for this DoS type: <max-limit>. The <max-limit> is the maximum number of parallel TCP SYN incoming from the same source IP address. Setting this value to 0 allows you to disable this protection. Disabling this protection can be useful when the system is accessed by remote end-users having all the same IP address.

• pipocsp: protects against an abusive number of new (TCP SYN) OCSP requests per source IP address. One limit value should be specified for this DoS type: <max-limit>. The <max-limit> is the maximum number of parallel TCP SYN incoming from the same source IP address. Setting this value to 0 allows you to disable this protection. Disabling this protection can be useful when the system is accessed by remote end-users having all the same IP address.

If no <limit-burst> is specified, it is set to the same value as <limit-per-second>.

INTERNAL RULES

• AllState: TCP connection with all states set.

• BruteForce: SSH brute force attack.

• ConLimit: more than a specified number of TCP SYN from the same source IP (see the seventh usage form).

• IllegalSyn: synchronise packets with illegal state.

• InvalidState: TCP/UDP traffic with invalid states.

• LoopbackIP: 127.0.0.0/8 IP addresses.

• MulticastIP: multicast IP addresses other than 224.0.0.1 and VRRP in HA mode.

• NullState: TCP connection without any state.

• Policy: no defined rule matches found.

• ReservedIP: 240.0.0.0/4, 169.254.0.0/16 and 255.255.255.255/32 IP addresses.

• ResetFlood: TCP reset (RST) packet flooding (see the sixth usage form).

• SelfSpoof: spoofing of an IP address assigned to the appliance.

• SmurfPing: smurf DoS attack.

• SynFlood: TCP SYN (synchronise) packet flooding (see the sixth usage form).

• TraceRoute: route tracing.

• UDPFlood: UDP packet flooding (see the sixth usage form).

• UpTime: time left from the last reboot.

• XMasTCP: TCP connection with all states to detect the running OS.

• ZeroIP: 0.0.0.0/8 IP addresses.

AUTHOR

CacheGuard Technologies Ltd <www.cacheguard.com>

Send bug reports or comments to the above author.