Chapter 9 Network Security Administration

Network Services Wrapped by Internet Express

During installation, the TCP service entries in the /etc/inetd.conf file that match the service entries specified in the /usr/internet/security/config.tcp file are modified to include the TCP Wrapper (tcpd) daemon. The syntax of service entries in the /etc/inetd.conf file is:

ServiceName SocketType ProtocolName Wait/NoWait UserName ServerPath ServerArgs 

On Tru64 UNIX Version 5.1 or later, the ProtocolName field for TCP services can be tcp or tcp6, depending on the type of socket that the network service is using (that is, AF_INET or AF_INET6). For example, the following entry appears in the /etc/inetd.conf file for the telnetd service after installation:

telnet  stream  tcp6    nowait  root    /usr/bin/tcpd    /usr/sbin/telnetd

Notice the placement of the TCP Wrapper daemon, /usr/bin/tcpd, in this entry. Also notice that the ProtocolName field is tcp6. Services that specify tcp6 respond to both IPv4-enabled and IPv6-enabled clients over either network protocol. For more information, see the inetd.conf(4) reference page.

Table 9-1 lists the network services that are wrapped by the Internet Express installation and the default access setting for each service. (Section  explains how to modify access settings.)

To see a list of the services that are wrapped on your system, select Display/Update Configuration from the TCP Wrapper Administration menu. The service name and description on this form are retrieved from the /usr/internet/security/config.tcp file. Depending on which services were installed on your system, you might not see all the services listed in this table.

Controlling Access to Other Network Services

You can use TCP Wrapper to control access to network services other than those wrapped by Internet Express, and include these additional services in the list displayed on the Display/Update Configuration form, as follows:

You can use the /usr/internet/security/deinstall.sh script to remove the TCP wrapper from all services in the inetd.conf file.

Modifying Access to a Wrapped Network Service

To modify the access setting for a network service, follow these steps:

Figure 9-1 shows the TCP Wrapper Service Management form for the remote login server (rlogind). To deny access to rlogind for all users on your system, select the option button for “Access is allowed for nobody” and click Submit.

Figure 9-1 Remote Login Server Dialog

To customize access to a service, select the option button for “Access is customized” and enter the access specification string in the accompanying field. For example:

foo.fsu.edu abc.company.com:ALLOW

In this example, any user in either the foo.fsu.edu or abc.company.com domain is allowed to log in remotely.

	Note: The access specification string must conform to the syntax described in the hosts_options(5) reference page, except that you do not specify the daemon_list argument.

Testing TCP Security Modifications

After you modify access to a service, follow these steps to test the modification:

After you complete the procedure, the utility displays a message of the following form:

Access to service-name from
client is state

where:

For more information, see the tcpdmatch(8) reference page.

Denial of Service Concepts

Internet Express provides Denial of Service (DoS) tools that improve network security by detecting and preventing DoS attacks.

A DoS attack is an attack against a Web site, a network, a system, or other service provider intended to disrupt its ability to provide services to its users. Software that performs a DoS attack overloads the service provider with requests for service until its capacity to respond to new service requests is exceeded. Legitimate requests for service are cannot access to the service until the attack is stopped.

The Denial of Service Tools component provides a set of security tools for preventing and detecting DoS attacks. Although DoS attacks are not new to administrators, recent Distributed Denial of Service (Distributed DoS) attacks against well-known E-commerce sites (for example, Yahoo.com and Amazon.com) demonstrate the need for solutions.

Distributed DoS attacks are characterized by the distributed nature of the attack. False requests for service are generated from a set of DoS agents or servers installed on multiple systems and networks, all working together to saturate the service provider with requests. These attacks are much harder to stop once they are initiated, because they make it much more difficult to identify the source of the attack.

At present, there is no way to completely stop DoS and Distributed DoS attacks. Internet Express DoS tools, however, help you greatly reduce the possibility of DoS attacks.

	Note: Additional DoS tools are available. Refer to the following URL for the latest information on other DoS tools: http://staff.washington.edu/dittrich/misc/ddos/

Accessing Denial of Service Tools

Access the Denial of Service tools from the Administration utility as follows:

Figure 9-2 Denial of Service Tools Administration Menu

Adding and Deleting Access Filters

To add or delete Access filters, you must create Access filters for each network interface on your gateway, router, firewall, or system. You can use the Add Access Filters option to define the Ingress and Egress filtering that protects your administrative domain from DoS attacks originating from untrusted sources. The filters are defined in the ifaccess.conf file.

Enabling and Disabling Access Filtering

Use the Enable/Disable Access Filtering form to enable and disable Access filtering on each network interface.

You must use the Add Access Filters form and Delete Access Filters form to define filters for the interface before Access filtering can be enabled on the interface. (See Section : Adding Access Filters and Section : Deleting Access Filters, respectively.) In addition, the interface must be of type inet, it must be configured, and it must be in an UP state for Access filtering to be enabled on the network interface.

	Note: Before you can enable an Access filter, you must configure its network interface and the network interface must be running. If an Access filter contains a host name or network name, the host name must be defined in /etc/hosts and the network name must be defined in /etc/networks. If the network interface is not running, or the host name or network name is not defined, you might not be able to enable the Access filter. Further, the Access filter might become disabled when the system is rebooted. Use the sysman network command to define network names and host names. Access filters that contain host addresses or network addresses can be enabled without configuring the host name or network name, but the network interface must still be configured and running.

To enable (or disable) Access filtering:

If you add new filters with the Add Access Filters form after enabling Access filtering on an interface, before the new filters can take effect, you must disable and reenable existing Access filtering on that interface. If any filters are syntactically incorrect, you cannot enable Access filtering until the filter is correctly defined or deleted.

Installing FireScreen

To install FireScreen, follow these steps:

Configuring FireScreen

To configure FireScreen, on the FireScreen Administration menu, choose Configure FireScreen. Figure 9-12 shows the Configure FireScreen menu.

Figure 9-12 Configure FireScreen Menu

Use the Configure FireScreen menu to perform the following tasks:

	Note: You must restart FireScreen for configuration file changes to take effect (Section : Starting and Stopping FireScreen).

Setting Command-Line Options

To set the command-line options for FireScreen, follow these steps:

1. From the Configure FireScreen menu, choose Set Options.

   The current command-line options are displayed, as shown in Figure 9-13. These command-line options are passed to FireScreen when it is started.

   Figure 9-13 Default Command-Line Options for FireScreen

   The default command-line options specify that:

   • The /etc/firescreen.conf file is used to store screening rules and other configuration information. (This corresponds to the -f option.)

     To change the default configuration file for FireScreen, make sure the Configuration File check box is selected and enter the full pathname of the configuration file you want to use in the field provided.

   • Screening records will be logged in the /var/adm/syslog.dated/$DATE/daemon.logfile (where the value of $DATE is incremented every 24 hours based on the time that the system was last booted).

2. When the syslog.conf file does not contain a daemon entry, the /var/adm/firescreen.log file is used to log screening events. (This corresponds to the -L option.)

   By default, screening records are logged with other daemons' log records (in the file specified by the daemon entry in the /etc/syslog.conf file) by syslog. To specify a separate file in which only screening records will be logged, make sure the Log File check box is selected and enter the full pathname of the log file you want to use in the field provided.

3. Screening events will be logged using the /usr/sbin/syslogd daemon. (This corresponds to the -s option.)

   	Note: FireScreen uses the syslogd daemon to log screening errors, regardless of whether or not the Syslog Logging (-s) or Log File (-L) command-line options are enabled.

4. To log all packets, ensure that the Log All Packets check box is selected. If the check box is not selected, packets are not logged. (This corresponds to the -l option.)

5. Logging records will include the line number from the /etc/firescreen.conf configuration file corresponding to the rule that caused the event to be logged. This information is useful for debugging configuration file problems. (This corresponds to the -r option.)

   To omit screening rule line numbers from log file entries, ensure that the Log Rule Numbers check box is not selected.

6. Click on Submit.

   The Set Options confirmation page shows you the command-line options for FireScreen, as shown in Figure 9-14.

   Figure 9-14 Set Options Confirmation Page

   You must restart FireScreen for the default command-line option changes to take effect (Section : Starting and Stopping FireScreen). However, if you specify a configuration file or log file other than the default, the file you specify is modified and read by the FireScreen Administration pages immediately, without restarting FireScreen.

For more information on specifying command-line options for FireScreen, see the screend(8) reference page.

	Notes: The -c option performs the same function as Check Screening Rules form (Figure 9-18), so this option is not available on the Set Options form. The -d option is also not available on the Set Options form. If you want to use the -d option to debug FireScreen, you must set this option on the command line.

Adding a Screening Rule

Screening rules determine which IP packets are allowed to pass through the gateway to your network and which packets are to be rejected. By default, all IP packets are rejected.

You can add screening rules to the FireScreen configuration file to allow certain packets to be passed to your network. Screening rules are not checked for correct syntax at the time you add them; you must use the Check Screening Rules option on the Configure FireScreen menu to verify that the syntax of screening rules is correct.

FireScreen searches screening rules in the order that the rules appear in the FireScreen configuration file, from first to last. Because action is taken on each packet as soon as a matching rule is found, place specific rules before general rules. If no matching rule is found, the action specified by the default rule is taken. The FireScreen Administration utility forces the default rule to be the last rule in the configuration file; you cannot add screening rules after the default rule.

If the FireScreen configuration file contains conflicting screening rules, the IP packet is accepted or rejected based on the first rule encountered in the file that applies to that packet.

You can also delete screening rules from the FireScreen configuration file.

You must restart FireScreen for screening rule changes to take effect (Section : Starting and Stopping FireScreen).

Before setting up your firewall using FireScreen Administration, you should read the following technical report on implementing TCP/IP security policies:

http://www.research.compaq.com/nsl/publications/TN-2.html#TN-2

This report explains how FireScreen (which is based on the screend daemon) operates, what FireScreen can and cannot do to protect your network, and how to use screening rules to implement firewall security policies.

To add a screening rule, follow these steps:

1. From the Configure FireScreen menu, choose Add New Screening Rule.

   The first time you add a screening rule, the only rule defined is the default rule.

2. Select one of the lines displayed in the Screening Rules list box on the Add New Screening Rule form (Figure 9-16). Each entry in the list box consists of a line number in the FireScreen configuration file and the corresponding screening rule. (The first time you add a new screening rule, you must select the default rule.) If you do not first select a rule, you will receive an error message when you click on Submit, stating that no line number was selected.

   Figure 9-16 Add New Screening Rule Form

   	Note: Screening rules can span multiple lines and must always end in a semicolon (;). If a screening rule spans multiple lines, each part of the rule and the line number it appears on is displayed in the list box. Be careful not to add a screening rule in the middle of a multiline rule.

3. Enter the new screening rule, using the correct syntax, in the New Screening Rule field.

4. Click on Add.

The Add New Screening Rule confirmation page confirms that the new screening rule has been added to the FireScreen configuration file and displays all screening rules, as shown in Figure 9-17. Note the order in which the screening rules are listed in the FireScreen configuration file.

Figure 9-17  New Screening Rule Confirmation Page

To return to the Add New Screening Rule form, use the navigation bar at the top of the screen.

To check the syntax of screening rules, see Section : Checking Syntax of Screening Rules.

Checking Syntax of Screening Rules

To check the syntax of screening rules in the FireScreen configuration file, on the Configure FireScreen menu, choose Check Screening Rules.

The existing screening rules are displayed and checked for syntax errors. Figure 9-18 shows the Check Screening Rules confirmation page.

Figure 9-18 Checking Screening Rules

If screening errors are reported, you must use the Delete Screening Rules option on the Configure FireScreen menu to remove the offending rule from the FireScreen configuration file and then add the rule using correct syntax. For more information, see Section : Deleting a Screening Rule and Section : Adding a Screening Rule.

Starting and Stopping FireScreen

When you make changes to the FireScreen configuration file, you must restart FireScreen for the changes to take effect (Section : Starting FireScreen).

When you stop FireScreen with screening mode enabled, all IP forwarding is rejected until FireScreen starts again (Section : Stopping FireScreen).

The contents of the Start/Stop FireScreen form reflect the current state of the FireScreen daemon; the form updates immediately whenever the daemon's state changes.

Starting FireScreen

To start (or restart) FireScreen, choose Start/Stop FireScreen from the FireScreen Administration menu. The Start/Stop FireScreen form is displayed.

The contents of the Start/Stop FireScreen form depend on the current state of the FireScreen daemon.

• If the FireScreen daemon is currently stopped, the only option is to start it, as shown in Figure 9-20. To start FireScreen, click on Submit.

  Figure 9-20 Start/Stop FireScreen Form with Start Option Enabled

• To restart the FireScreen daemon when it is currently running, ensure that the Restart option button is set (as shown in Figure 9-21), then click on Submit.

  Figure 9-21 Start/Stop FireScreen Form with Restart Option Enabled

To protect your system from unauthorized access, the Administration utility starts a new FireScreen process, which reads the latest FireScreen configuration file, and then stops any FireScreen process that was previously running, as shown in the confirmation page (Figure 9-22).

Figure 9-22 Start/Stop FireScreen Confirmation Page

Stopping FireScreen

To stop FireScreen, follow these steps:

1. Choose Start/Stop FireScreen from the FireScreen Administration menu.

2. On the Start/Stop FireScreen form, ensure that the Stop option button is set on (as shown in Figure 9-23).

   Figure 9-23 Start/Stop FireScreen Form with Stop Option Enabled

3. Click on Submit.

The confirmation page indicates that FireScreen is stopped (Figure 9-24).

Figure 9-24 Stop FireScreen Confirmation Page

Viewing FireScreen Status

Using the View FireScreen Status menu, you can view the following:

To access this menu, choose View FireScreen Status from the FireScreen Administration menu.

Viewing FireScreen Screening Rules

To view FireScreen screening rules in the FireScreen configuration file, from the View FireScreen Status menu, choose View Screening Rules.

The screening rules and the line numbers they occupy in the FireScreen configuration file are displayed (Figure 9-25).

Figure 9-25 View Screening Rules Page

If you need to modify a screening rule, you must first delete the rule and then add the modified rule. See Section : Checking Syntax of Screening Rules for information on the syntax for screening rules.

Viewing the FireScreen Log

To view the FireScreen log file, choose View Log from the View FireScreen Status menu.

The contents of the FireScreen log file are displayed (Figure 9-26). When the log file requires more than one page, buttons are displayed at the top of the page to allow you to navigate through the log file

Figure 9-26 View Log File Page

To specify the types of events to be recorded in the FireScreen log file, access the Configure FireScreen menu and choose Set Options. See Section : Setting Command-Line Options for more information.

Viewing FireScreen Statistics

FireScreen invokes the /usr/sbin/screenstat command to display statistics for IP packet handling.

To view FireScreen statistics, choose View Statistics from the View FireScreen Status menu.

The statistics are displayed (Figure 9-27).

Figure 9-27 View Statistics Page

Considerations While Installing FreeRADIUS

The installation procedure includes the build, install of the IAEFRAD subset. For more details, refer the Installation Guide.

FreeRadius is installed in the /usr/local/radius directory. The configuration files exist in /usr/local/etc/raddb directory.

When you install FreeRadius, all the necessary directories are created. You can run tests by using existing UNIX system accounts.

Starting and Stopping the FreeRADIUS Server

Follow these steps to start or stop the FreeRADIUS Server.

The status message is displayed after each action.

Understanding FreeRADIUS Configuration Files

Important functions of FreeRADIUS are controlled by configuration directives in the users file, radiusd.conf and clients.conf.

Users File

This file contains authentication security and configuration information for each user. Accounting requests are not processed through this file. Instead, see acct_users in the same directory.

The first field is the user's name and can be up to 253 characters in length. This is followed (on the same line) with the list of authentication requirements for that user. This can include password, comm server name, comm server port number, protocol type (perhaps set by the hints file), and huntgroup name (set by the huntgroups file).

If you are not sure why a particular reply is being sent by the server, then run the server in debugging mode (radiusd -X), and you will see which entries in this file are matched.

When an authentication request is received from the comm server, these values are tested. Only the first match is used unless the Fall-Through variable is set to Yes.

A special user named DEFAULT matches on all user names. You can have several DEFAULT entries. All entries are processed in the order they appear in this file. The first entry that matches the login-request will stop processing unless you use the Fall-Through variable.

If you use the database support to turn this file into a .db or .dbm file, the DEFAULT entries have to be at the end of this file. You cannot have multiple entries for one user name.

You do not need to specify a password if you set Auth-Type += System on the list of authentication requirements. The RADIUS server will then check the system password file.

Indented (with the tab character) lines following the first line indicate the configuration values to be passed back to the comm server to allow the initiation of a user session. This can include things like the PPP configuration values or the host onto which the user will log on.

You can include another users file with $INCLUDE users.other.

The following example shows a typical users file entry format :

"Robert Auth-Type := Local, User-Password == "me66med"

Service-Type = Callback-Login-User,

Login-IP-Host = 0.0.0.0,

Callback-Number = "9,5551212",

Login-Service = Telnet,

Login-TCP-Port = Telnet" 

clients.conf file

This file defines a RADIUS client (usually a NAS). The information given here over rides anything given in the clients file, or in the naslist file. The configuration here contains all of the information from those two files, and allows for more configuration items.

The shortname is be used for logging. The nastype, login and password fields are mainly used for checkrad and are optional.

This defines a RADIUS client. The format is as follows:

client[hostname|ip-address]

127.0.0.1 is another name for localhost. It is enabled by default, to allow testing of the server after an initial installation. If you are not going to be permitting RADIUS queries from localhost, you need to comment it out.

Refer to /usr/local/etc/raddb/clients.conf for more information.

radiusd.conf file

This file contains values for multiple directives used by FreeRADIUS. Some of the directives are explained in the following sections.