Enabling User Access to Services

  

Figure 4.29: The Gatewayed/Proxied Service Setup Screen

The Gatewayed/Proxied Service Setup Screen (Figure 4.29) allows you to choose whether you want to edit the (bidirectional) TCP application proxies, or the transparent outgoing gateways. It also allows you to access the TCP Service Map Setup screen, to specify how physical ports should be mapped to logical services (if accessing services on non-standard ports), and the HTML Filter Setup Screen, to specify what types of HTML embedded scripts and banner ads should be filtered out of web pages.

The available keys are:

F1

Return to the Access Control screen (same as F8)

F2

View/Edit the TCP proxies (bidirectional)

F3

View/Edit the transparent gateways (outgoing only)

F5

View/Edit the TCP service map (physical to logical mapping)

F6

View/Edit the HTML content filtering settings

F7

View help

F8

Return to the Access Control screen (same as F1)

  

Figure 4.30: TCP Proxy Setup Screen

  

Figure 4.31: TCP Gateway Setup Screen

  

Figure 4.32: UDP Gateway Setup Screen

The screens for setting up service access are shown in Figures 4.30, 4.31 and 4.32. The screens are similar in each case, except that the TCP Proxy Setup Screen includes three extra fields at the bottom.

The fields are:

Service/Port

The name of the service, or the port number, that the firewall should listen on for this service. If services are specified by name rather than port number, the name must match an entry in the /etc/services file to be recognised (you can add your own entries to this file by putting them in the file /usr/local/etc/services. Pressing `?' will present a drop-down list of common services.

User/Group

The user to whom this service is restricted, if any. A user group can be specified for multiple users, in which case the user group name must be enclosed in square brackets. Pressing `?' will allow the user or group to be selected from a drop-down list of defined users or user groups. A value of `*' can be used in conjunction with NetBIOS or ident indentification, to request attempted identification, as opposed to forced authentication.

Authenticate Using

Specifies the means that will be used for user authentication. The choices are `None', `ident' (for UNIX clients), `NetBIOS' (for Windows clients in a DHCP environment), `S/Key', `RSA', `DSA' or `X.509' (for strong authentication using the citauth program on Windows hosts). For HTTP and FTP proxy access, you can also specify HTTP authentication, which will pop up a username and password prompt in the client's web browser.

Source Address

The network or host address from which the request is allowed, if this is restricted;

Bits

The number of bits of the source address which must match the requesting client address. This allows you to specify network and subnetwork addresses in the source address field. For example, setting bits to 32 means that the source address field specifies a host address; 24 means the source address field specifies a network with a netmask of 255.255.255.0 (equivalent to a class C network), and specifying zero means the source address field is ignored (more precisely, any address is successfully matched).

Source Ports

The range of ports from which the client can connect. This can be a comma-separated list of port numbers or hyphen-separated port ranges, or one of the special shorthand characters `<' (equivalent to `1-1023'), `>' (equivalent to `1024-65535'), or `*' (any port). An empty field is treated as an `>'; that is, the connection may come from any port above 1023. In most cases you will not need to use any other value.

When Allowed

The times of day/days of week that access is allowed. See Section 4.7.1 for details on how this is specified. If left empty then access will be allowed at any time.

The additional fields for TCP proxies are:

Relay To Host

The server to which the request should be relayed.

Port

The port to which the request should be relayed. If left empty it will be the same as the service port.

IPSec Only

If this is set to Yes, then the service will be usable only for IPsec transport mode connections. IPsec and non-IPsec proxies cannot both be used on the same port on the outside interface of the firewall.

The Relay To Host address should be specified for all TCP proxies, except for:

• `telnet' and `ftp', for which the relay host address is optional; if not specified, users will be able to choose the host they want to connect to.
• `socks', which has its own mechanism for silently specifying the destination hosts.
• Services that are being handled by the caching proxy server, if enabled; for example, HTTP and gopher.
• the remote administration services `webadmin (the CEQURUX WWW administration service), `keyadmin' (the CEQURUX remote key management service), `remadmin' (the CEQURUX remote administration service), `telnet2fw' (the telnet service on the firewall itself), and `ssh' (the secure shell server on the firewall itself), for which any relay host address entered is ignored as these services run on the firewall.
• `pop3', when setting up a POP3 server on the firewall itself (as opposed to a POP3 relay).

You can have multiple entries for a single service. The firewall will search the entries for those matching the requested service, the requesting address and port, and the time-of-day/day-of-week restrictions. If a match is found which requires no user identification, it will be granted immediately; if no matches are found the request will be denied. If one or more matches are found which require user authentication, each of the possible authentication types will be tried in turn, and the request will be granted or denied based on the result (but see below how the Bits field can affect this).

If User Authentication is set to `None', but a user name is specified, then that user name will be used for logging purposes when the service entry is matched.

If User Authentication is selected, an empty user field denotes no users (service denial), while a single asterisk denotes any user (service acceptance). The latter may only be used with NetBIOS or ident-based identification. These two special values for the User field can be used to get the firewall to do user identification for logging purposes only.

Each unique user who can use authentication should be assigned a unique name; no two users should be allocated the same name (unless they are to be considered as a single entity; that is, they have the same passwords, access rights, and so on).

If a service request matches more than one entry, then ambiguity may result. The Bits field can be used to help prevent this, as it acts as an implicit `priority' value. If more than one entry matches a service request, and one entry has a higher value for the bits field than some other matching entry, the one with the lower number of bits will be ignored and won't be considered as a match.

  

Figure 4.33: The Gateway Setup Screen

In order to get to the TCP and UDP Gateway Setup screens, you need to access the Gateway Setup Screen (Figure 4.33). This screen also allows you to configure a number of attributes relating to the operation of the transparent gateway program cdsgw.

The first three fields let you specify the size of the session tables used for each protocol by the transparent gateway. These set an upper limit on the number of simultaneous connections per protocol. There are three entries, one for ICMP (ping), one for UDP, and one for TCP.

Note that session table entries do not correspond one-to-one to applications using the gateway. For example, an FTP application will typically use two TCP sessions, one for the data and one for the commands. A web browser could use multiple (mostly short-lived) TCP sessions when fetching web pages. Furthermore, as ICMP does not use port numbers, the limit here is for hosts using ping. For example, setting this to two will allow at most two internal hosts to do `ping's at the same time (although each of these host could be doing multiple `ping's).

The remaining fields in this screen are:

Allow Outgoing Ping

If this is set to YES, then users on the inside will be able to use the ICMP-based utility `ping'; otherwise no outgoing pings will be allowed.

Allow Outgoing Traceroute

If this is set to YES, then users on the inside will be able to use the `traceroute' utility. More precisely, the firewall will allow outgoing UDP packets with destination ports in the range 33435 through 33466.

Allow IP Fragment Gatewaying

If this is set to YES, the firewall will gateway IP fragments provided the fragment's IP header matches an active session; if set to NO all fragments will be discarded.

Allow Internal Routing

By default, the firewall will assume that any packets received on its internal interface that are not actually addressed to it are intended for some external host, and will treat them as such. If you want the firewall to check whether the destination address is an internal host, and forward such packets on the internal network, you need to enable this option. This can be useful to simplify the routing configuration of your internal network. The drawback is that every packet received on the internal interface needs to be checked, which will slow down the processing of packets by the firewall.

If you enable this option, you can specify whether the firewall should log such forwarding or not. Logging can be useful if you do not usually want the firewall to forward such packets but are trying to diagnose routing problems in your internal networks. If you are using this facility intentionally, to simplify your internal configurations, then it is recommended that you disable the logging.

Allow FTP Callback Address Change

Less common is the practice of having FTP data callbacks from an address other than the FTP server address (some sites use this as a security measure to force registration before allowing downloads; other sites use it as a way of load-balancing their FTP servers). This toggle specifies whether such address changes in callbacks should be allowed. The usual setting is NO.

TCP Stateful Filtering

The transparent gateway can emulate the probable TCP state machine states for both client and server sides of a gatewayed connection, and use this information to drop packets which are considered `out-of-state'. Setting this toggle to `Strict' will result in this behaviour. If set to `Loose', then no TCP state checking other than checking for TCP connection closes or resets will be done. The usual setting is `Strict'; if you have poor quality lines or saturated bandwidth you may find that strict filtering exacerbates the problem and `Loose' may be a better choice.

Max % Gateway Sessions per Host

To prevent hosts from monopolising the transparent gateway session table entries, you can specify a percentage value here. Each internal client host will then be restricted to using at most that percentage of the available gateway sessions. The default value is 10%; to disable the restriction enter a value of 100.

This also affects the percentage of pending DNS lookups that are allowed from any particular host at one time. The splitdns proxy DNS server allows a maximum of 4096 pending DNS requests at a time, so with the default value, any one particular host can have at most about 400 pending requests.

Disable NAT for NetBIOS

While the gateway program performs NAT on all outgoing connections, NetBIOS is an exception - it is possible to disable NAT by setting this toggle to Yes. If this is set, then incoming sessions can also be created (subject to the normal authentication and source address restrictions). This allows NetBIOS clients to be outside the firewall and servers to be inside, and vice versa, but requires that external hosts that use NetBIOS through the firewall know how to route to the internal hosts with which they wish to communicate.

An alternative is to apply NAT to NetBIOS as with all other services. The advantage is that external hosts don't need to be able to route to behind the firewall; the disadvantage is that external hosts cannot initiate sessions (thus clients must be inside and servers outside).

The available keys are:

F1

Discard changes and return to the Main Setup screen

F2

View/Edit the gateway logging configuration

F3

View/Edit the transparent TCP gateways

F3

View/Edit the transparent TCP gateway packet filters

F5

View/Edit the transparent UDP gateways

F6

View/Edit the transparent UDP gateway packet filters

F7

View help

F8

Save changes and return to the Access Control screen