Chapter 15 Access Control
15.1 WebWall
15.1.1 Overview
The WebWall functionality of the FortiBalancer appliance allows you to create permit/deny rules to filter packets passing through your network infrastructure. The WebWall supports the filtering of TCP, UDP and ICMP packets that are using the IPv4 or IPv6 address. To use access lists you will define these “permit” and “deny” rules and apply them to access groups. Once the access lists are configured, you may apply or bind the group to an interface within the network.
The steps for basic WebWall configurations are explained in this section, along with some advanced features and general knowledge of how WebWall works. For the OS, the WebWall feature can independently control each interface.
WebWall permits TCP and UDP health check traffic, but cannot permit ICMP health check traffic automatically.
15.1.2 Understanding WebWall
WebWall is a full-fledged stateful Firewall. It bridges the gap between speed and security. The FortiBalancer appliance houses and integrates the WebWall feature into a single platform, along with many of other features such as Layer 4-7 load balancing, caching, SSL acceleration, authentication and authorization.
Figure 15-1 WebWall
WebWall contains several security mechanisms to protect Web servers from attack, including:
- ACL (Access Control List) filtering
- Protection against Syn-Flood, Fragmentation and DoS (Denial Of Service) attacks
- Stateful packet inspection
- Single packet attack prevention
ACL Filtering provides tight control over who may and may not enter the network by utilizing FortiBalancer’s ultra-fast rules engine. WebWall access control list filtering mechanism ensures virtually no performance loss with up to 1,000 ACL rules, while never consuming more than one percent of OS capability.
In addition to ACL filtering, the WebWall provides stateful packet inspection and protects against Syn-Flood, fragmentation, DoS and single packet attacks.
The WebWall is a default-deny firewall. Default-Deny refers to the notion that if you do not have any permit rules in your access control lists, no packets will be allowed to pass through the appliance. During the initial installation of the box it might be helpful to leave the WebWall in the off or disengaged state until your total configuration is complete.
Note: By default the WebWall is turned off. The WebWall function will remain disabled until it is activated via the “webwall on” command.
15.1.3 WebWall Configuration
15.1.3.1 Configuration Guidelines
Let’s start with the basic step for configuring the WebWall. To better assist you with configuration strategies that maximize the power of the FortiBalancer appliance, please take a moment to familiarize yourself with basic network architecture.
Figure 15-2 WebWall Configuration
Then we must define what we want to deny and permit. Since “example.com” is a relatively small site, let’s begin with the following:
- Permit port 80 to our VIP (10.10.0.10).
- Permit port 22 to the Management IP of the FortiBalancer appliance (for SSH access).
- Permit port 8888 to the Management IP of the FortiBalancer appliance for web UI access.
- Deny network 10.10.20.0/255.255.255.0, since that network has been abusing its privileges.
- Allow all inside hosts to ping the IP address of the interface “port2” (inside interface). Initially we will define our access groups as follows:
- 50 All miscellaneous rules
- 100 All Management IP related rules
- 150 All VIP (Virtual IP) related rules
Table 15-1 General Settings of WebWall
| Operation | Command |
| Configure access group | accessgroup <accesslist_id> <interface> |
| Configure ACL
rules |
accesslist permit icmp echoreply <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist permit icmp echorequest <source_ip>
<source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist permit tcp <source_ip> <source_mask|source_prefix> <source_port> <destination_ip> <destination_mask|destination_prefix> <destination_port> <accesslist_id> accesslist permit udp <source_ip> <source_mask|source_prefix> <source_port> <destination_ip> <destination_mask|destination_prefix> <destination_port> <accesslist_id> accesslist permit esp <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist permit ah <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist deny icmp echoreply <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist deny icmp echorequest <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist deny tcp <source_ip> <source_mask|source_prefix> <source_port> <destination_ip> <destination_mask|destination_prefix> <destination_port> <accesslist_id> accesslist deny udp <source_ip> <source_mask|source_prefix> <source_port> <destination_ip> <destination_mask|destination_prefix> <destination_port> <accesslist_id> accesslist deny esp <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> accesslist deny ah <source_ip> <source_mask|source_prefix> <destination_ip> <destination_mask|destination_prefix> <accesslist_id> |
| Enable/Disable WebWall | webwall <interface> on [mode] webwall <interface > off |
| View WebWall configurations | show interface show accesslist show accessgroup |
15.1.3.2 Configuration Example via CLI
15.1.3.2.1 Configuring Access Groups
We may define any number of access groups and apply multiple groups to a designated interface via CLI. Pertaining to our example model, the command should be executed as such:
FortiBalancer(config)#accessgroup 100 port1
FortiBalancer(config)#accessgroup 150 port1
FortiBalancer(config)#accessgroup 50 port1
You might have noticed that we also have specified what interfaces these access groups will be applied to.
15.1.3.2.2 Configuring ACL Rules
Now we define the “permit” and “deny” rules based on these assumptions.
The first entry allows a single host with IP 10.10.10.30 to connect to the server using port 22:
FortiBalancer(config)#accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100
The second entry allows a C class subnet to connect to the server via port 8888.
FortiBalancer(config)#accesslist permit tcp 10.10.10.0 255.255.255.0 0 10.10.10.10 255.255.255.255 8888 100
The third allows any host to connect to the server using port 80.
FortiBalancer(config)#accesslist permit tcp 0.0.0.0 0.0.0.0 0 10.10.10.20 255.255.255.255 80
150
The first three rules are fairly straightforward, and they permit all TCP traffic to the destination IP/port specified and are tied to the access group (via the last argument to the command).
With the fourth entry, we are excluding one host from gaining access through the subnet. It is in access group 50 since it does not allow access to a specific destination IP. Logically the deny rule could fit into both access group 100 and 150, so for administrative ease we will make another group.
FortiBalancer(config)#accesslist deny tcp 10.10.10.33 255.255.255.255 0 10.10.10.10 255.255.255.255 0 50
The last two rules allow the inside hosts on the network to ping the “port2” interface when the WebWall function is on.
FortiBalancer(config)#accesslist permit icmp echorequest 192.168.10.0 255.255.255.0
192.168.10.1 255.255.255.255 50
FortiBalancer(config)#accesslist permit icmp echoreply 192.168.10.1 255.255.255.255 192.168.10.0 255.255.255.0 50
Note: The IP address is not an IP on the FortiBalancer appliance. It is the IP of the default gateway.
The priority of the command “accesslist deny” is higher than “accesslist permit”. If we configure
“permit” and “deny” rules for the port 22 to the Management IP of the FortiBalancer appliance (for SSH access) at the same time as follows:
FortiBalancer(config)#accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100
FortiBalancer(config)#accesslist deny tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100
When the administrators attempt to access the FortiBalancer appliance via the management IP through SSH, the access will be denied.
15.1.3.2.3 Configuring WebWall
At last once you complete the configuration of the other features of the FortiBalancer appliance, and you should turn the WebWall feature back on by issuing the command:
FortiBalancer(config)#webwall port2 on
FortiBalancer(config)#webwall port1 on
Notes:
- You should exercise with caution when adjusting the WebWall rules. It is possible to deny yourself from accessing the appliance if you are logged in remotely through SSH or the web UI and your session can be interrupted before configuration is completed.
- If you configure the DNS servers and have WebWall turned on for the destination interface through which the DNS requests/replies go, you need to add the corresponding accesslist rules to allow that traffic.
- If WebWall is turned on for the interface for which the “synconfig” command uses to synchronize with peer(s), you will need to add the corresponding accesslist rules to allow that traffic to come in through SSH port 22 on the Fortinet machines (FortiBalancer appliance and the sync peers).
15.1.3.3 Verification and Troubleshooting of the WebWall
After adding all the rules it is helpful to display the current lists and groups. To do this, employ the following commands.
| FortiBalancer(config)#show accesslist
accesslist deny tcp 10.10.10.33 255.255.255.255 0 10.10.10.10 255.255.255.255 0 50 accesslist permit tcp 10.10.10.30 255.255.255.255 0 10.10.10.10 255.255.255.255 22 100 accesslist permit tcp 10.10.10.0 255.255.255.0 10.10.10.10 255.255.255.255 8888 100 accesslist permit tcp 0.0.0.0 0.0.0.0 0 10.10.10.20 255.255.255.255 80 150 accesslist permit icmp echorequest 10.10.10.0 255.255.255.0 10.10.10.10 255.255.255.255 50 accesslist permit icmp echoreply 0.0.0.0 0.0.0.0 10.10.10.10 255.255.255.255 50
FortiBalancer(config)#show accessgroup accessgroup 50 port1 accessgroup 100 port1 accessgroup 150 port1 |
If you run into problems with access lists, keep your configurations simple. With multiple access groups, you can apply them once at a time and see which access list is causing problems. Of course you can turn the WebWall completely off to determine if the WebWall itself is indeed causing the problem.
To check the status of the firewall use the “show interface” command:
| FortiBalancer(config)#show interface
port1(port1): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500 inet 10.3.20.100 netmask 0xffff0000 broadcast 10.3.255.255 inet 10.3.20.56 netmask 0xffffffff broadcast 10.3.20.56 ether 00:30:48:82:81:7a media: autoselect (100baseTX <full-duplex>) status: active webwall status: OFF Hardware is i82547gi Input queue: 435/512 (size/max) total: 19376 packets, good: 19376 packets, 2053879 bytes broadcasts: 19130, multicasts: 2 11317 64 bytes, 4282 65-127 bytes,3242 128-255 bytes 522 255-511 bytes,13 512-1023 bytes,0 1024-1522 bytes 0 input errors 0 runts, 0 giants, 0 Jabbers, 0 CRCs 0 Flow Control, 0 Fragments, 0 Receive errors 0 Driver dropped, 0 Frame, 0 Lengths, 0 No Buffers |
| 0 overruns, Carrier extension errors: 0 Output queue: 0/512 (size/max)
total: 18444 packets, good: 18444 packets, 7182692 bytes broadcasts: 17, multicasts: 0 48 64 bytes, 6018 65-127 bytes,7512 128-255 bytes 785 255-511 bytes,1014 512-1023 bytes,3067 1024-1522 bytes 0 output errors 0 Collsions, 0 Late collisions, 0 Deferred 0 Single Collisions, 0 Multiple Collisions, 0 Excessive collsions 0 lost carrier, 0 WDT reset packet drop (not permit): 0 tcp 0 udp 0 icmp 0 ah 0 esp 0 packet drop (deny): 0 tcp 0 udp 0 icmp 0 ah 0 esp 0 5 minute input rate 2160 bits/sec, 2 packets/sec 5 minute output rate 80 bits/sec, 0 packets/sec port2(port2): flags=8843<UP,BROADCAST,RUNNING,SIMPLEX> mtu 1500 inet 10.4.20.100 netmask 0xffff0000 broadcast 10.4.255.255 ether 00:30:48:82:81:7b media: autoselect (100baseTX <full-duplex>) status: active webwall status: OFF Hardware is i82541gi Input queue: 71/512 (size/max) total: 38464 packets, good: 38464 packets, 9320519 bytes broadcasts: 18751, multicasts: 2 10779 64 bytes, 11545 65-127 bytes,10749 128-255 bytes 1305 255-511 bytes,1019 512-1023 bytes,3067 1024-1522 bytes 0 input errors 0 runts, 0 giants, 0 Jabbers, 0 CRCs 0 Flow Control, 0 Fragments, 0 Receive errors 0 Driver dropped, 0 Frame, 0 Lengths, 0 No Buffers 0 overruns, Carrier extension errors: 0 Output queue: 0/512 (size/max) total: 2094 packets, good: 2094 packets, 207035 bytes broadcasts: 396, multicasts: 0 399 64 bytes, 1681 65-127 bytes,0 128-255 bytes 0 255-511 bytes,14 512-1023 bytes,0 1024-1522 bytes 0 output errors 0 Collsions, 0 Late collisions, 0 Deferred 0 Single Collisions, 0 Multiple Collisions, 0 Excessive collsions 0 lost carrier, 0 WDT reset packet drop (not permit): 0 tcp 0 udp 0 icmp 0 ah 0 esp 0 packet drop (deny): 0 tcp 0 udp 0 icmp 0 ah 0 esp 0 5 minute input rate 2336 bits/sec, 3 packets/sec 5 minute output rate 224 bits/sec, 0 packets/sec |
This command will also show if the interface is up and running and those IP addresses assigned to it. More detailed network information is also included, such as input queue and output queue information.
The following explains the terms and phrases used in the output:
- Input queue size: the current occupied input.
- Input queue max: the maximum items of input.
- The numbers of different sizes: the counts of the packages of each size.
- Runt: the number of received frames that have passed address filtering that are less than the minimum size (64 bytes from <Destination Address> through <CRC>, inclusively), and have a valid CRC.
- Giant: the number of received frames with valid CRC field that have passed address filtering and are larger than the maximum size.
- Jabber: the number of received frames that have passed address filtering that are greater than the maximum size and have a bad CRC. It may be the result of a bad NIC or electronic interfering.
- CRC: the number of received packets with alignment errors.
- Flow Control: the number of the received, unsupported flow control frames.
- Fragments: the number of received frames that have passed address filtering, are less than the minimum size and have a bad CRC.
- Frame: the number of received packets with alignment errors (the packet is not an integer number of bytes in length).
- Lengths: the number of received length error events.
- No Buffers: the number of times that frames are received when there are no available buffers in host memory to store those frames.
- Overruns: the number of missed packets. Packets are missed when the received FIFO has insufficient space to store the incoming packets. This can be caused by too few allocated buffers, or insufficient bandwidth on the PCI bus.
- Carrier extension errors: the number of received packets where the carrier extension error is signaled across the internal PHY interface.
- Collisions: the total number of collisions that are not late collisions as seen by the transmitter.
- Late collisions: late collisions are collisions that occur after 64-byte time into the transmission of the packet while working in 10-100 Mb/s data rate, and after 512-byte time into the transmission of the packet while working in the 1000 Mb/s data rate.
- Deferred: a deferred event occurs when the transmitter cannot immediately send a packet because the medium is busy or another device is transmitting.
- Single Collisions: the number of times that a successfully transmitted packet has encountered only one collision.
- Multiple Collisions: the number of times that a successfully transmitted packet has encountered more than one collision but less than 16.
- Excessive collisions: the number of times that 16 or more collisions have occurred on a packet.