Internet Express Version 6.7 for Tru64 UNIX: Internet Express for Tru64 UNIX Administration Guide

Chapter 9 Network Security Administration

  Table of Contents

  Glossary

  Index

This chapter describes how to manage the following network security components:

TCP Wrapper Administration

TCP Wrapper lets you control access to network services. TCP Wrapper intercepts an incoming network connection, and verifies whether the connection is allowed before passing the connection to the actual network daemon. For example, you can restrict access to a network service, such as telnet, to exclude all hosts outside of a local domain. After you modify the access to a service, you can use the Administration utility to test the modification.

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.

Table 9-1 Network Services Wrapped by Internet Express

Network ServiceDefault Access Setting
bootpdAllows you to boot a remote system
cfgmgrWorks with the kernel load server, kloadsrv, to manage subsystems that are dynamically configured or loaded
fingerdDisplays information about users on a remote system
ftpdTransfers files to and from a remote system
imapdAllows you to run the IMAP (Internet Message Access Protocol Version 4) e-mail server
ntalkdNotifies a user, or callee, on a remote system that a client, or caller, wants to initiate a conversation with talk
pop2Allows you to run the POP2 (Post Office Protocol Version 2) e-mail server
poppassdAllows you to change passwords
popperAllows you to run the POP3 (Post Office Protocol Version 3) e-mail server
rexecdAllows you to execute commands on a remote system
rlogindAllows you to log in to a remote system
rpc.rwalldAllows you to broadcast a message to all users logged in to a remote system
rpc.rstatdAllows you to gather statistics on a remote host's operating system
rpc.rquotadReturns quotas for a user of a local file system that is mounted by a remote system over Network File System (NFS)
rpc.rusersdDisplays a list of users on a remote system
rpc.sprayd Records the packets sent in a one-way stream to a remote system, including the number of packets received on the remote system and the transfer rate
rshdRuns a shell on a remote system
sendmailAllows mail to be delivered between the local and remote systems
telnetdAllows you to communicate with a remote system by means of a virtual terminal
tftpdSupports the Trivial File Transfer Protocol (tftp), which transfers files to and from a remote system

 

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:

  1. Make sure an entry for the service exists in the /etc/inetd.conf file. The entry must not include the TCP Wrapper (/usr/sbin/tcpd).

  2. Add an entry for the service in the /usr/internet/security/config.tcp file to provide a name and description to use on the Display/Update Configuration form. The following example shows the entry for the fingerd service:

    The user information server for networks :fingerd
  3. Edit the /usr/internet/security/hosts.allow file to specify the access setting for the service. The following example is the entry in the /usr/internet/security/hosts.allow file for the fingerd service:

    fingerd:ALL:ALLOW
  4. Run the /usr/internet/security/install.sh script to add TCP Wrapper to the service's entry in the /etc/inetd.conf file, and to copy the modified /usr/internet/security/hosts.allow file to /etc/hosts.allow.

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:

  1. From the Internet Express Main menu, choose Manage Components.

  2. From the Manage Components Menu, under Network Security, choose TCP Wrapper.

  3. From the TCP Wrapper Administration menu, choose Display/Update Configuration to display a list of the services available on your system and the current access settings for each service.

  4. Select the service for which you want to modify access. The TCP Wrapper Service Management form shows the current security setting for the service you chose and offers the settings described in Table 9-2.

    Table 9-2 Network Service Access Options

    Access TypeDescription
    everybodyAnyone on the network is granted access to the service
    nobodyNo user on the network is granted access to the service
    local domainOnly those in the local domain are granted access to the service
    customizedAnyone on the network matching the domain name(s), hostname(s), IPv4 address(s), or IPv6 address(s) listed in the access list is granted or denied access to the service, depending on the access control keyword (ALLOW or DENY) that you specify. See the hosts_access(5) reference page for information on access list syntax.

     

  5. Select the access setting you want to apply to the service and click on Submit.

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

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:

  1. Under Network Security on the Manage Components menu, choose TCP Wrapper.

  2. From the TCP Wrapper Administration menu, choose Test Configuration to display the Test Configuration form.

  3. Select a service from the Service to Test list box.

  4. Enter a domain name, IPv4 address, or IPv6 address in the Requesting Client field, using the syntax defined in the hosts_access(5) reference page.

  5. Click Submit.

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

Access to service-name from
client is state

where:

service-name is the name of the service being tested.
client is the user and host for which the security is being tested.
state is either denied or granted.

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

FireScreen Administration

The FireScreen menus and forms lead you through the process of installing, configuring, and enabling the FireScreen firewall. An Internet Protocol (IP) packet arriving at a gateway is routed by the system's routing daemon to the kernel for forwarding through a particular network interface. FireScreen filters routed packets by inhibiting the kernel IP forwarding functionality the based on screening rules stored in its configuration file.

Use the FireScreen Administration menu to perform the following tasks:

Under Network Security on the Manage Components menu, choose FireScreen to access the FireScreen Administration menu, shown in Figure 9-2.

Note:

Initially, the FireScreen Administration menu displays only one option, Install FireScreen. After installing FireScreen, the additional options shown in Figure 9-2 are displayed.

Figure 9-2 FireScreen Administration Menu

FireScreen Administration Menu
Note:

The AltaVista Firewall and FireScreen software cannot coexist on the same system. If you plan to use the AltaVista Firewall software, do not install FireScreen. The Administration utility will not allow you to install FireScreen if it detects the presence of the AltaVista Firewall software.

See Tuning Compaq Tru64 UNIX for Internet Services at the following URL for system tuning information that applies to gateways, routers, and systems performing packet filtering (in this case, FireScreen):

http://www.tru64unix.compaq.com/docs/internet/TITLE.HTM

Installing FireScreen

To install FireScreen, follow these steps:

  1. From the FireScreen Administration menu, choose Install FireScreen.

    The FireScreen installation checks that your system meets the following prerequisites:

    • The Additional Networking Services subset (OSFINETxxx) must be installed, where xxx is the version of Tru64 UNIX installed on your system.

    • The Internet Express administration subset (IAEADMxxx) must be installed.

    • The AltaVista Firewall subset (DFWBASExxx) must not be installed.

    If any of the previous prerequisites are not met, the FireScreen installation terminates.

    Although it is not an installation prerequisite, your system's network hardware must be installed before starting FireScreen.

    During FireScreen installation, your system is examined to determine whether a routing daemon (routed or gated) has been configured. If you have not configured a routing daemon before installing FireScreen, you receive a warning message to configure the network hardware and software (Figure 9-3). Run the netconfig utility (recommended) or netsetup utility (releases prior to Tru64 UNIX Version 5.0 only) on the command line to configure your network hardware and software.

    Note:

    If the system's routing daemon is running before FireScreen is configured and running, your network is vulnerable to unauthorized access in the interim.

    If you do not have the FireScreen reference pages installed, the FireScreen installation generates a warning message but continues with the installation.

    Figure 9-3 shows the results of the prerequisite-checking phase of the FireScreen installation.

    Figure 9-3 Checking FireScreen Installation Prerequisites

    Checking FireScreen Installation
Prerequisites
  2. Click on Install.

  3. At this point in the FireScreen installation, the following startup variables are added to the /etc/rc.config file:

    • SCREEND

      Indicates whether the FireScreen daemon is to be started when the system is booted.

    • SCREEND_FLAGS

      Indicates which options are to be used when the FireScreen daemon is started on the system.

    • SCREEND_MODE

      Indicates whether screening is on.

    • SCREEND_KERNEL

      Specifies the name of the kernel that contains support for the FireScreen daemon.

    The FireScreen installation installs a startup script (/sbin/init.d/firescreen) to run the FireScreen daemon when the system boots, and it links /sbin/rc3.d/S11firescreen to /sbin/init.d/firescreen.

    Note:

    The FireScreen daemon and the system's routing daemon are started, in that order, when the system boots. This guarantees that no IP packets are forwarded across the gateway before FireScreen starts.

    The /etc/inittab file is modified to set the default screening mode (on).

    Finally, the default FireScreen configuration file, /etc/firescreen.conf, is installed and the FireScreen reference pages are linked (assuming the OSFMANOS reference pages subset is installed).

    The default system configuration file and kernel are displayed.

  4. You can specify a different system configuration file, a different kernel, or both, before proceeding with the installation (Figure 9-4).

    Note:

    Modifications that FireScreen makes to your system's kernel configuration file are not preserved when you update the Tru64 UNIX operating system. You must reinstall FireScreen after updating the operating system to replace these modifications and to ensure that the kernel is built with the option required by FireScreen.

    All FireScreen files that had been customized before updating the operating system are saved during the FireScreen installation with the .bck file extension (including the default FireScreen configuration file, /etc/firescreen.conf). To return FireScreen to its original configuration, you must move the saved customization files (with the .bck extension) back to their original file names (without the .bck extension).

    Figure 9-4 Install FireScreen Form for Specifying the System Configuration File and Kernel

    Install FireScreen Form for Specifying
the System Configuration File and Kernel
  5. Click on Continue Install.

    At this point in the FireScreen installation, the kernel you specified is examined to determine whether gateway screening is enabled. (FireScreen checks for GATED, GATED_OLD, or ROUTED in the /etc/rc.config file.) If gateway screening is not enabled, the FireScreen installation updates your system configuration file to enable gateway screening.

    The FireScreen installation then runs the doconfig program to make a backup copy of your original system configuration file and to rebuild the kernel using the updated system configuration file. The rebuilt kernel is then copied into place and you are asked to shutdown and reboot the operating system.

  6. Shut down or reboot the operating system. See Section : Accessing Web-Based System Management Tools.

    Figure 9-5 shows how the Install FireScreen page appears after successfully completing the FireScreen installation when gateway screening was enabled in the kernel before installing FireScreen. After you complete the FireScreen installation, you must configure FireScreen (see Section : Configuring FireScreen).

    Figure 9-5 Install FireScreen Page with Gateway Screening Enabled

    Install FireScreen Page with Gateway
Screening Enabled

    Figure 9-6 shows how the Install FireScreen page appears after the FireScreen installation with gateway screening was disabled in the kernel before installing FireScreen. Follow the link from the Web-Based Management page to the page for shutting down or rebooting the operating system before configuring FireScreen (Section : Accessing Web-Based System Management Tools). Change the number of minutes to wait from 30 to 1.

    Figure 9-6 Install FireScreen Installation Page with Gateway Screening Disabled

    Install FireScreen Installation Page
with Gateway Screening Disabled

Configuring FireScreen

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

Figure 9-7 Configure FireScreen Menu

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-8. These command-line options are passed to FireScreen when it is started.

    Figure 9-8 Default Command-Line Options for FireScreen

    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-9.

    Figure 9-9 Set Options Confirmation Page

    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-13), 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.

Setting the Screening Mode

To set the screening mode for FireScreen, follow these steps:

  1. From the Configure FireScreen menu, choose Set Screening Mode.

    Figure 9-10 shows the Set Screening Mode form.

    Figure 9-10 Set FireScreen Screening Mode Form

    Set FireScreen Screening Mode Form

    The settings on this form vary, depending on whether screening mode is enabled or disabled.

  2. To change the screening mode or boot-time screening mode, click on the appropriate checkbox.

  3. Click on Submit.

As long as screening mode is enabled, your system is protected from unauthorized access.

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-11). 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-11 Add New Screening Rule Form

    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-12. Note the order in which the screening rules are listed in the FireScreen configuration file.

Figure 9-12  New Screening Rule Confirmation Page

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-13 shows the Check Screening Rules confirmation page.

Figure 9-13 Checking Screening Rules

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.

Deleting a Screening Rule

To delete a screening rule from the FireScreen configuration file, follow these steps:

  1. From the Configure FireScreen menu, choose Delete Screening Rules.

    Screening rules and their corresponding line numbers are displayed, as shown in Figure 9-14.

  2. Select the screening rule you want to delete from the Screening Rules list box, as shown in Figure 9-14.

    Figure 9-14 Delete Screening Rules Form

    Delete Screening Rules Form
  3. Click on Delete.

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-15. To start FireScreen, click on Submit.

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

    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-16), then click on Submit.

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

    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-17).

Figure 9-17 Start/Stop FireScreen Confirmation Page

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-18).

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

    Start/Stop FireScreen Form with Stop
Option Enabled

  3. Click on Submit.

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

Figure 9-19 Stop FireScreen Confirmation Page

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-20).

Figure 9-20 View Screening Rules Page

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-21). 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-21 View Log File Page

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-22).

Figure 9-22 View Statistics Page

View Statistics Page

Snort Intrusion Detection System

Snort is an intrusion detection system which enables you to log packets, and track network activity on IP networks. Snort files are installed in the following directories:

DirectoryContentsSubset
/usr/internet/securitySnort executable Snort configuration file IAESNORT
/usr/internet/docs/snortSnort documentationIAESNORT

On Tru64 UNIX, Snort runs in two different modes: sniffer, packet logger, and network intrusion detection. Network intrusion detection currently does not work on Tru64 UNIX. In sniffer mode, Snort will continually read packets from the network and display them on the console. In packet logger mode, it will write the packets to a log file on disk.

  • Sniffer Mode — display TCP/IP packet headers

    ./snort -v (show IP and TCP/UDP/ICMP headers)
    ./snort -vd (include packet data)
    ./snort -vde (include the data link layer headers)

  • Packet Logger Mode — log TCP/IP packet headers to disk

    Use the previous snort commands along with the -l switch and a log directory name to automatically go into packet logger mode.

    ./snort -vd -l ./log

    You must have an existing directory by that name to prevent Snort from exiting with an error. You should also specify the local host address, using the -h ipaddress switch.

    Other switches in packet logger mode include the following:

    -b (log the packets in binary mode)
    -r (followed by name of binary log will run the log through Snort in sniffer mode)

There are several ways in which you may configure the Snort output. See the Snort Users Manual for details.

Use the Internet Express Administration utility to perform the following actions with Snort:

Configuring Snort Decoder

Follow these steps to configure the Snort decoder.

  1. From the Manage Components menu, choose Snort.

  2. From the Configure Snort menu, choose Configure Snort Decoder.

    The Configure Menu is displayed.

  3. Click in a checkbox to select the desired decoder option:

    OptionDescription
    Disable Decode AlertTurns of the alerts generated by the decode phase of Snort.
    Disable Alerts on Invalid IP options Disables IP option validation alerts.
    Disable Alerts on obsolete TCP optionsTurns off alerts generated by obsolete TCP options.

  4. Click on Submit.

Configuring Snort Preprocessor

Follow these steps to configure the Snort preprocessor:

  1. From the Manage Components menu, choose Snort.

  2. From the Configure Snort menu, choose Configure Snort Preprocessor.

    The Configure Menu is displayed.

  3. Click in a checkbox to select the preprocessor desired option:

    OptionDescription
    Perform IP defragmentationThe IP defragmentation preprocessor uses memory management routines that are used in other parts of Snort. It uses the default memory limit of 4194304 bytes (4 MB) and a timeout period of 60 seconds. The timeout period is used to determine a length of time that a unassembled fragment should be discarded.
    Perform RPC TrafficNormalizes rpc multiple fragmented records into a single unfragmented record. It does this by normalizing the packet into the packet buffer. if stream4 is enabled, it will only process client side traffic. It defaults to running on ports 111 and 32771I.
    Normalize Telnet Negotiation stingsAllows Snort to normalize Telnet control protocol characters from the session data. It accepts a list of ports to run on as arguments. Also, it normalizes into a separate data buffer from the packet itself so that the raw data may be logged or examined with the raw bytes content.

  4. Click on Submit.

Running Snort

Follow these steps to run Snort:

  1. From the Manage Components menu, choose Snort.

  2. From the Configure Snort menu, choose Run Snort.

    The statistics for the operation are displayed.

Viewing Alert Messages

Follow these steps to view Snort alert messages.

  1. From the Manage Components menu, choose Snort.

  2. From the Configure Snort menu, choose View Alert Messages.

    All the alert messages are displayed.

    Use the standard navigation features to advance page by page, go to a specific page, or search for a particular text string.

FreeRADIUS Server Administration

The FreeRadius User Authentication tool scales from embedded systems with small amounts of memory, to systems with millions of users. It is configurable, and supports more authentication protocols than many commercial servers.

This section describes the following FreeRADIUS Server Administration information:

For information on FreeRADIUS server, see the FreeRADIUS Web site:

http://www.freeradius.org

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.

  1. From the Manage Components menu, choose FreeRADIUS Server Administration.

  2. From the FreeRADIUS Server Administration menu, choose Start/Stop FreeRADIUS Server.

    The current status of the server is displayed (either Running or Stopped).

  3. To start a stopped server, click on the Start button

  4. If the server is running, click on Stop to stop the server or Restart to stop and restart the 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.

  1. libdir – Specifies the location of rlm_* modules.

    This should be automatically set at configuration time. If the server builds and installs, but fails at execution time with an undefined symbol error, then you can use the libdir directive to work around the problem.

    The cause is usually that a library has been installed on your system in a place where the dynamic linker cannot find it. When executing as root (or another user), your personal environment may be set up to allow the dynamic linker to find the library. When executing as a daemon, FreeRADIUS may not have the same personalized configuration.

    To work around the problem, determine which library contains that symbol, and add the directory containing that library to the end of libdir, with a colon separating the directory names. No spaces are allowed. For example:

    libdir = /usr/local/lib:/opt/package/lib

    You can also try setting the LD_LIBRARY_PATH environment variable in a script which starts the server.

    If that does not work, then you can re-configure and re-build the server to not use shared libraries, using the following:

    ./configure --disable-shared make make install

  2. pidfile: Specifies where to place the PID of the RADIUS server.

    The server may be signalled while it is running by using this file. This file is written when only running in daemon mode. kill

    -HUP 'cat /var/run/radiusd/radiusd.pid'

  3. user/group: The name (or #number) of the user/group as which to run radiusd.

    If these are commented out, the server will run as the user/group that started it. In order to change to a different user/group, you must be root (or have root privleges ) to start the server. HP recommends that you run the server with as few permissions as possible. That is, if you are not using shadow passwords, the user and group items below should be set to nobody.

    On SCO (ODT 3) use user = nouser and group = nogroup. Note that some kernels refuse to setgid(group) when the value of (unsigned)group is above 60000. Do not use group nobody on these systems. On systems with shadow passwords, you might have to set group = shadow for the server to be able to read the shadow password file. If you can authenticate users while in debug mode, but not in daemon mode, it may be that the debugging mode server is running as a user that can read the shadow info, and the user listed below cannot. user = nobody group = nobody

  4. max_request_time: The maximum time (in seconds) to handle a request.

    Requests which take more time than this to process may be killed, and a REJECT message is returned.

    Warning:

    If you notice that requests take a long time to be handled, then this may indicate a bug in the server, in one of the modules used to handle a request, or in your local configuration.

    This problem is most often seen when using an SQL database. If it takes more than a second or two to receive an answer from the SQL database, then it probably means that you haven't indexed the database. See your SQL server documentation for more information.

    Useful range of values: 5 to 120

    max_request_time = 30

  5. bind_address: Make the server listen on a particular IP address, and send replies out from that address. This directive is most useful for machines with multiple IP addresses on one interface.

    This directive can either contain *, or an IP address, or a fully qualified Internet domain name. The default is *.

    As of Version 1.0, you can also use the listen directive. See the following for more information. bind_address = *.

  6. port: Allows you to bind FreeRADIUS to a specific port.

    The default port that most NAS boxes use is 1645, which is historical. RFC 2138 defines 1812 to be the new port. Many new servers and NAS boxes use 1812, which can create interoperability problems.

    The port is defined here to be 0 so that the server will use the machine's local configuration for the radius port, as defined in /etc/services.

    If you want to use the default RADIUS port as defined on your server, (usually through grep radius /etc/services) set this to 0 (zero).

    A port given on the command line using the -p option overrides this one.

    As of Version 1.0, you can also use the listen directive. See the following for more information.

    port = 0

    Other modules in the radiud.conf include authorize, authenticate and instantiate. For information, see /usr/local/etc/raddb/radiusd.conf.

Viewing FreeRADIUS Log File

The FreeRADIUS Server logs information in the /usr/local/var/log/radius/radius.log file. View the contents of this log file from the Administration Utility, as follows:

  1. From the Manage Components menu, choose FreeRADIUS.

    The FreeRADIUS menu is displayed.

  2. On the FreeRADIUS menu, choose View the FreeRADIUS Log.

    The contents of the log file are displayed.

    Use the standard navigation features to advance page by page, go to a specific page, or search for a particular text string.