Connection Limits

You may wish to control the spread of services that are used at any one time through the firewall. For example, an FTP transfer can consume most of your network bandwidth, making interactive services such as telnet sluggish. There are two ways this can be addressed: firstly, by restricting bandwidth hungry services to particular times of day or days of the week, or alternatively, by limiting the number of concurrent sessions of particular services. For example, using the latter approach, you could restrict the firewall to allow only a single FTP session at any one time.

These limits can be configured from the Connection Limits Setup Screen (see Figure 4.40). The fields in this screen are:

Service

The name of the service to be restricted (or its port number)

Limit

The maximum number of simultaneous connections allowed

When

When the limit applies

Note that the restrictions apply separately to the proxies and the gateways. For example, if you set a limit of four telnet connections, then up to four proxy (incoming) connections are allowed, and, at the same time, up to four gatewayed (outgoing) connections are allowed (this assumes, of course, that you have both a transparent telnet gateway and a telnet application proxy configured).

You can restrict the number of concurrent anonymous FTP users by specifying the service `ftp2fw'. This is useful in conjunction with the anonymous FTP disk space constraints to prevent anonymous FTP users from filling up the hard disk space on the firewall. On their own, the disk space constraints are insufficient. For example, if the starting disk space available for anonymous FTP is 500Mb, and the session constraint is 20Mb, then a user need only open 26 or more simultaneous sessions (without doing any transfers until they are all open) to exceed the disk space restriction.

The reason for this is that the FTP proxy and the anonymous FTP server are both run chrooted in separate directories. The space is handled by the anonymous FTP server, while the restrictions are managed by the proxy. When the proxy starts up, it determines the amount of free space available to the server before doing a chroot; after the chroot it has only this initial figure to work with. It thus grants the user a fixed amount of space for the session, given by the session limit or the total limit less the initial free space, whichever is smaller. In the example, all 26 sessions will be granted the full session limit of 20Mb. Once this limit has been determined, it is not changed, even when the actual disk space available to the anonymous FTP server drops below it.

Thus it is a good idea to limit the number of anonymous FTP sessions. If the allowed number of sessions is s, and the session space limit is l, then such an attack could exceed the total FTP disk space restriction by at most $(s-1) \times l$. Going back to the example, if you use a limit of 5 simultaneous FTP sessions, then in the worst case the most disk space that can be filled up by someone attacking the anonymous FTP server would be $500 + 4 \times 20$ or 580Mb. To do this, the attacker would have to make all five connections at a time when the disk space useage is 480Mb (that is, as full as possible but with enough space left to grant a full session limit of 20Mb).

Anonymous FTP connections are done via the regular FTP proxy which relays connections to the FTP server on port 1021 (service `ftp2fw'). Thus, the firewall first makes an `ftp' session, and then changes this to a `ftp2fw' session if the user is not authorised to use FTP or the user logs in as `ftp'. If you place a limit on the number of FTP sessions, and all of these are in use, no-one will be able to connect to the anonymous FTP server even if no-one is using it at the time.

  

Figure 4.40: The Connection Limits Setup Screen