Chapter 9 Network Security Administration
This chapter describes how to manage the following network security components:
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 Service||Default Access Setting|
|bootpd||Allows you to boot a remote system|
|cfgmgr||Works with the kernel load server, kloadsrv, to manage subsystems that are dynamically configured or loaded|
|fingerd||Displays information about users on a remote system|
|ftpd||Transfers files to and from a remote system|
|imapd||Allows you to run the IMAP (Internet Message Access Protocol Version 4) e-mail server|
|ntalkd||Notifies a user, or callee, on a remote system that a client, or caller, wants to initiate a conversation with talk|
|pop2||Allows you to run the POP2 (Post Office Protocol Version 2) e-mail server|
|poppassd||Allows you to change passwords|
|popper||Allows you to run the POP3 (Post Office Protocol Version 3) e-mail server|
|rexecd||Allows you to execute commands on a remote system |
|rlogind||Allows you to log in to a remote system|
|rpc.rwalld||Allows you to broadcast a message to all users logged in to a remote system|
|rpc.rstatd||Allows you to gather statistics on a remote host's operating system|
|rpc.rquotad||Returns quotas for a user of a local file system that is mounted by a remote system over Network File System (NFS) |
|rpc.rusersd||Displays 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|
|rshd||Runs a shell on a remote system|
|sendmail||Allows mail to be delivered between the local and remote systems|
|telnetd||Allows you to communicate with a remote system by means of a virtual terminal|
|tftpd||Supports 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:
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).
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
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:
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:
From the Internet Express Main menu, choose Manage Components.
From the Manage Components Menu, under Network Security, choose TCP Wrapper.
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.
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
|everybody||Anyone on the network is granted access to the service|
|nobody||No user on the network is granted access to the service|
|local domain||Only those in the local domain are granted access to the service|
|customized||Anyone 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. |
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
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:
In this example, any user in either the foo.fsu.edu or abc.company.com domain is allowed to log in remotely.
Testing TCP Security Modifications
After you modify access to a service, follow these steps to test the modification:
Under Network Security on the Manage Components menu, choose TCP Wrapper.
From the TCP Wrapper Administration menu, choose Test Configuration to display the Test Configuration form.
Select a service from the Service to Test list box.
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.
After you complete the procedure, the utility displays a message of the following form:
Access to service-name from
client is state
|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.
Internet Express provides a set of security tools that help you reduce your system's vulnerability to Denial of Service (DoS) attacks. This chapter provides the following information:
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.
Ingress and Egress Filtering
Ingress filtering filters out any IP packets with untrusted source addresses before they have a chance to enter and affect your system or network. Egress filtering prevents IP packets with randomly generated source addresses from exiting your system or network, when one of your systems has been compromised and when the system is being used to perpetrate an attack against other systems.
Ingress and Egress filtering are used to deter DoS attacks by eliminating and logging IP packets containing spoofed source addresses that arrive at a system from untrusted upstream or downstream network sources. These filtering methods do not protect against DoS attacks with IP packets that originate from trusted sources. They can, however, assist you in tracing the true source of the IP packets from a DoS attack, because an attacker must use a valid source address to reach your system or network when Ingress and Egress filtering is in effect.
For detailed analyses of these filtering methods, see the following online documents:
Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing
Help Defeat Denial of Service Attacks: Step-by-Step
Most Distributed DoS attacks attempt to hide the origin of the IP packets to disrupt service by using a randomly generated address for the source address of each IP packet (that is, forging the address). Others allow the attacker to control the IP packet source address that is created, potentially implicating innocent parties as the originators of the attack.
Ingress and Egress filtering is implemented using Access filtering on Tru64 UNIX. (Section : Access Filtering).
The FireScreen component can provide further IP packet logging and filtering capabilities on your gateways, routers, and firewalls. On systems with multiple interfaces, you can filter IP packets as they are routed between interfaces based on protocol, port number, and so forth. See Section : FireScreen Administration for more information on FireScreen.
On Tru64 UNIX, Access filtering is the preferred means of filtering IP packets at a system, router, gateway, or firewall. This capability is provided with Tru64 UNIX Version 4.0F or later in the OSFCLINETxxx subset, where xxx represents the operating system version.
Internet Express provides a user interface to access filtering. The interface is installed with the IAEADMxxx subset, where xxx represents the Internet Express version number.
Use Access filtering to detect and prevent spoofed or forged IP packet attacks from accessing your system or network. When you enable Access filtering, the source address of each IP packet arriving at an interface is checked against filters defined in the ifaccess.conf file, and the action associated with the first matching filter is taken. If no filters are defined in the ifaccess.conf file, a default filter permits access to all IP packets on the interface. See the ifaccess.conf(4) reference page for information.
Access filtering is enabled on each network interface on a system using the ifconfig command's filter and -filter options, respectively. See the ifconfig(8) reference page for information.
Logging is performed by syslogd whenever a packet matches a filter with a denylog action specified in its filter definition. (See the syslogd(8) reference page.) Filtered packets are discarded and logged to a file specified by the kern.debug entry in the /etc/syslog.conf file. The default log file is /var/adm/syslog.dated/date/kern.log. See Section : Adding and Deleting Access Filters for information on adding (or deleting) Access filters and Section : Enabling and Disabling Access Filtering for information on enabling (or disabling) Access filters.
Accessing Denial of Service Tools
Access the Denial of Service tools from the Administration utility as follows:
From the Internet Express Administration utility main menu, choose Manage Components.
From the Manage Components menu, under Network Security, choose Denial of Service Tools. The Denial of Service Tools Administration menu is displayed (Figure 9-2).
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.
Use the Add Access Filters form to add Access filters:
Choose Denial of Services Tools from the Manage Components menu.
From the Denial of Service Tools Administration menu, choose Add Access Filters. The Add Access Filters form (Figure 9-3) is displayed, listing the filters currently defined for the system.
Figure 9-3 Add Access Filters Form
Select an existing filter in the Filters list to indicate where you want to add a new filter. The new filter will be added to the list above the filter you choose. Because packets are filtered by the first filter matched in the list, the order is significant. By default, the form initializes the list of filters with a filter that permits access to all packets on each inet network interface.
Define a filter by specifying options in the New Filter fields. Specify these options:
From the interface list, select the network interface (or device) that applies to the filter (for example, tu1).
In the address field, enter the host name (for example, udhcp235.ash.com), network name, network address, or host address of the filtered source in dotted decimal form (for example, 126.96.36.199).
In the mask field, enter the associated network mask of the filtered source. The mask can be expressed in dotted decimal notation, hexadecimal format, or beginning with a name (for example, 255.255.255.255).
In the action list, select one of the following actions to take when an IP packet from the filtered source arrives at the interface:
Permit –Permit packets matching the specified source.
Deny – Deny packets matching the specified source.
Denylog – Deny and log packets matching the specified source.
When you finish entering the options for the new filter, click the Add button at the bottom of the form to add the filter to the list of filters.
Depending on your networking environment, consider adding individual filters to deny access to source addresses listed in Table 9-3.
Table 9-3 Potential Source Addresses to be Denied
|10.0.0.0/8||RFC 1918 Private Network|
|169.254.0.0/16||Link Local Networks|
|172.16.0.0/12||RFC 1918 Private Network|
|192.168.0.0/16||RFC 1918 Private Network|
|188.8.131.52/4||Class D Multicast|
|240.0.0.0/5||Class E Reserved|
Use the Delete Access Filters form to remove obsolete or syntactically incorrect filters created with the Add Access Filters form. You cannot enable Access filtering on an interface for syntactically incorrect filters or for network interfaces not configured and running.
To delete Access filters:
Choose Denial of Services Tools from the Manage Components menu.
From the Denial of Service Tools Administration menu, choose Delete Access Filters. The Delete Access Filters form (Figure 9-4) is displayed, listing the filters currently defined for the system.
Figure 9-4 Deleting Access Filters Form
Select the filter you want to remove from the Filters list.
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.
To enable (or disable) Access filtering:
Choose Denial of Services Tools from the Manage Components menu.
From the Denial of Service Tools Administration menu, choose Enable/Disable Access Filtering. The Enable/Disable Access Filtering form (Figure 9-5) is displayed.
Figure 9-5 Enable or Disable Access Filtering Form
To enable Access filtering, select a network interface from the list (for example, tu1). When you select an interface, its current status is displayed. For an enabled interface, a Disable button appears at the bottom of the form (Figure 9-6). For a disabled interface, an Enable button appears.
Figure 9-6 Access Filtering Enabled
Click Enable or Disable to either enable or disable Access filtering on the chosen interface.
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.
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-7.
Figure 9-7 FireScreen Administration Menu
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):
To install FireScreen, follow these steps:
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-8). 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.
If you do not have the FireScreen reference pages installed, the FireScreen installation generates a warning message but continues with the installation.
Figure 9-8 shows the results of the prerequisite-checking phase of the FireScreen installation.
Figure 9-8 Checking FireScreen Installation Prerequisites
Click on Install.
At this point in the FireScreen installation, the following startup variables are added to the /etc/rc.config file:
Indicates whether the FireScreen daemon is to be started when the system is booted.
Indicates which options are to be used when the FireScreen daemon is started on the system.
Indicates whether screening is on.
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.
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.
You can specify a different system configuration file, a different kernel, or both, before proceeding with the installation (Figure 9-9).
Figure 9-9 Install FireScreen Form for Specifying the System Configuration File and Kernel
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.
Shut down or reboot the operating system. See Section : Accessing Web-Based System Management Tools.
Figure 9-10 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-10 Install FireScreen Page with Gateway Screening Enabled
Figure 9-11 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-11 Install FireScreen Installation Page with Gateway Screening Disabled
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:
Setting Command-Line Options
To set the command-line options for FireScreen, follow these steps:
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).
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.
Screening events will be logged using the /usr/sbin/syslogd daemon. (This corresponds to the -s option.)
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.)
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.
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.
Setting the Screening Mode
To set the screening mode for FireScreen, follow these steps:
From the Configure FireScreen menu, choose Set Screening Mode.
Figure 9-15 shows the Set Screening Mode form.
Figure 9-15 Set FireScreen Screening Mode Form
The settings on this form vary, depending on whether screening mode is enabled or disabled.
To change the screening mode or boot-time screening mode, click on the appropriate checkbox.
Click on Submit.
As long as screening mode is enabled, your system is protected from unauthorized access.
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:
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:
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.
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
Enter the new screening rule, using the correct syntax, in the New Screening Rule field.
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.
Deleting a Screening Rule
To delete a screening rule from the FireScreen configuration file, follow these steps:
From the Configure FireScreen menu, choose Delete Screening Rules.
Screening rules and their corresponding line numbers are displayed, as shown in Figure 9-19.
Select the screening rule you want to delete from the Screening Rules list box, as shown in Figure 9-19.
Figure 9-19 Delete Screening Rules Form
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.
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
To stop FireScreen, follow these steps:
Choose Start/Stop FireScreen from the FireScreen Administration menu.
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
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
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:
|/usr/internet/security||Snort executable Snort configuration file ||IAESNORT|
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.
The FreeRadiusUser 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:
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.
From the Manage Components menu, choose FreeRADIUS Server Administration.
From the FreeRADIUS Server Administration menu, choose Start/Stop FreeRADIUS Server.
The current status of the server is displayed (either Running or Stopped).
To start a stopped server, click on the Start button
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.
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"
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:
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.
This file contains values for multiple directives used by FreeRADIUS. Some of the directives are explained in the following sections.
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
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'
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
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.
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
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 = *.
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:
From the Manage Components menu, choose FreeRADIUS.
The FreeRADIUS menu is displayed.
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.