firewall - Configure the firewall
[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>]]]]]]]]]]
[2] firewall [(external | web | rweb | antivirus | admin | mon | file | peer | auxiliary | vpnipsec) [move:(-|+)<rule-name> <rule-name> | move:<position>]]
[3] firewall [(external | web | rweb | antivirus | admin | mon | file | peer | auxiliary | vpnipsec) [del <rule-name>]]
[4] firewall [(external | web | rweb | antivirus | admin | mon | file | peer | auxiliary | vpnipsec) [raz]]
[5] firewall [(external | web | rweb | antivirus | admin | mon | file | peer | auxiliary | vpnipsec) [((on | off) <rule-name>)+]]
[6] firewall dos [(tcpflood | udpflood | webflood | rwebflood) [default | set <limit-per-second> [<limit-burst>]]]
[7] firewall dos [(piptcp | pipweb | piprweb | pipdns | pipocsp) [default | set <max-limit>]]
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. 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 mode command), 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 are specified for a zone. Once at least one rule is defined for a given zone, any traffic that does not match one of the specified rules is denied by default. Therefore, there is no need to add an explicit deny rule at the end of a rule set. The default rules are based on the following principles:
• New connections originating from the external zone are denied.
• New connections originating from the internal zone (or the web zone only when VLAN mode is activated) and destined for other zones are allowed.
• New connections originating from an auxiliary zone are denied.
• In VLAN mode (see the mode and vlan commands), new connections originating from the rweb, antivirus, admin, mon, file, and peer zones are denied. Otherwise, these zones are all considered part of the internal zone and therefore follow the principles applied to the internal zone.
• New connections originating from the vpnipsec zone and destined for the internal zone (or the web zone when VLAN mode is activated) are allowed. New connections originating from the vpnipsec zone and destined for any other zone are denied.
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 3478-3481). 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. 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). 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 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 set 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>.
• 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.
access(1), apply(1), mode(1), vlan(1), vpnipsec(1)
CacheGuard Technologies <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2026 CacheGuard Technologies - All rights reserved