IT Baseline Protection Manual S 4.111 Secure configuration of the RAS system
S 4.111 Secure configuration of the RAS system
Initiation responsibility: Head of IT Section, IT Security Management Team
Implementation responsibility: Administrator
The functioning and security of a RAS system are essentially determined by the configuration parameter settings. However, since a RAS system does not consist of only one component which has to be configured, the overall configuration is naturally a lot more complex. Due to this complexity, configuration errors which could reduce the security of the system as a whole can easily occur. Uncoordinated changes of one configuration parameter on a component can thus interact with the other components in such a way as to prevent error-free operation. In extreme cases the security of the LAN could even be impaired.
Since the configuration of a RAS system is generally subject to changes over time (e.g. due to changes in personnel, new operational scenarios, system enhancements etc.), it cannot be assumed that there is only one secure (and static) configuration which is defined once and never changed afterwards. On the contrary, the configuration is likely to undergo a series of version changes. It is the job of the administrators who are responsible for the RAS system to ensure that only secure versions of the system configuration are defined and that when the system configuration settings are changed, the new configuration is also secure.
In general, the following configuration categories may be distinguished:
The default configuration comprises the default parameter settings defined by the vendor. This will normally not be secure enough and should therefore not be used.
After installation and prior to initial operation, the default configuration must be converted to a secure initial configuration by the administrators. Here the settings should be as restrictive as possible so that only authorised administrators can effect changes in order, for example, to define an initial operational configuration which implements the planned security concept.
The secure operational configurations are the result of configurations made during ongoing operations. Regular checks must be made here to see whether any new security weaknesses which have come to light inflict modifications (see also S 2.35 Obtaining information on security weaknesses of the system).
Finally, secure fallback configurations should be defined and documented as part of contingency planning. These are also used to maintain security where operational capability is reduced. Normally several emergency situations are defined during contingency planning. It is recommended that an appropriate fallback configuration is specified for each of the defined situations. In the simplest case the fallback configuration simply means that access to the RAS system is blocked.
To ensure that the configuration is secure, the following points should be noted when making the configuration settings.
On top of the RAS system configuration, dividing the network into subnets can also be useful for access control. For reasons of IT security it can therefore be appropriate to set up access networks (see also S 5.77 Creation of subnets).
The routing settings of the network switching elements within the RAS system should be used to restrict the flow of network traffic. Network packets should only be forwarded on permitted connections. In addition, the latest network switching elements allow selective forwarding of packets within permitted network connections (packet filter function). In this way it is possible, for example, to ensure that only connection requests are forwarded to the HTTP service of a server.
Restricting access to RAS clients is especially difficult to implement with mobile computers. With mobile RAS clients it is therefore especially important that users adhere strictly to the defined rules (e.g. to protect against theft; see also module 5.3 Laptop PCs).
The secure configuration of the RAS server software requires that the security settings which are offered by the software and are appropriate in the existing operational scenario are also enabled and can be used. The use of certain security settings may presuppose that other components of the RAS system also possess corresponding functions and/or can be correspondingly configured. Thus, for example, when the Calling Line Identification Protocol (CLIP) is used, it is important to ensure that this is also enabled for the selected connection. For example, user identification on access over the Internet using X.509 certificates requires that the storage location of the user certificates is known to the RAS system. So the RAS software must either support external authentication servers or else offer a certificate management module of its own.
It is therefore necessary to check in advance whether all the security mechanisms offered can also be used or whether different and/or additional hardware or software is necessary for this. Once the RAS system is up and running, regular checks must then be made in order to verify that the settings are correct.
The requirements which apply to the secure configuration of the RAS client software are similar to those which apply to the server software. In addition, care must be taken to ensure that passwords required for RAS access are not stored within the software, even though this option is frequently offered. If this cannot be technically prevented, all users must be forbidden from making use of the option. Moreover, all users must be informed of the problem.
In order that clients and server can communicate in a secure manner, care must be taken to ensure that the components involved are configured in a consistent manner (e.g. as regards the method used to protect communications).
The secure and consistent configuration of client and server can be supported by specifying a standard configuration for RAS clients (hardware and software) in the RAS concept and implementing it through appropriate organisational measures. The result of doing this is that only a fixed number of different client configurations are in use. This simplifies the overall job of configuration and also helps to maintain a secure and consistent configuration.
Changes to the RAS system configuration should undergo an organisational process which ensures that the RAS system only operates with tested configurations. All changes should be documented and approved. Note: the addition of new RAS users or deletion of existing ones generally does not require any change to the RAS system configuration as these changes are often effected using the user administration facilities of the operating system (e.g. Remote Access Service under Windows NT) or an authentication server (e.g. RADIUS, TACACS+).
The RAS configuration should be checked regularly. Care must be taken here to ensure that all the requirements contained in the RAS security guidelines are implemented and that the settings do not have any weak points.
Although the task performed by RAS systems is quite simple, their configuration and operation are as complex as, for example, those of a firewall system. The topics listed here should therefore always be elaborated, expanded and modified as part of RAS system planning and RAS operation.
Examples
Under Windows NT RAS access authorisation should be restricted after installation of the RAS, but this can only be performed at user level and when there are many users this is no longer efficient to administer via the User Manager. However, the RAS administration tool under Windows NT also allows dial-in permission to be taken away from all users at once.
Only dialling in should be allowed on a RAS server. Outgoing connections from the RAS server itself are generally not necessary and should therefore be prohibited. Under Windows NT this can be configured for each device which is suitable for remote access (e.g. modem, ISDN card, VPN adapter) from the Properties dialogue within Remote Access Service. The relevant data entry fields are accessed by selecting the following sequence of options: Control Panel, Network, Services, Remote Access Service, Attached Device, Configure.
When remote access services are used, only the protocols which are actually necessary should be allowed over RAS access. Any unnecessary protocols should accordingly be disabled. This is achieved under Windows NT by selecting Control Panel, Network, Services, Remote Access Service, Network, Server Settings. The configuration of the required protocols must comply with the security guidelines, for example as regards authentication, encryption, IP address area, local or network-wide access.
Additional controls:
Is the RAS client software configured so that passwords used for access are not stored?
Are measures in place to ensure that all RAS components are consistently configured?
