Chapter 9 Network Security Administration
» Table of Contents |  | | » Glossary | | | » Index | | |
| | |
| ||
| ||
Table of Contents
This chapter describes how to manage the following network security components:
TCP Wrapper (Section : TCP Wrapper Administration)
FireScreen Firewall (Section : FireScreen Administration)
Snort Intrusion Detection System (Section : Snort Intrusion Detection System )
FreeRADIUS Server Administration (Section : FreeRADIUS Server 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.
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:
|
|
|
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 |
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:
fingerd:ALL:ALLOW
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.
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
Access Type Description 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.
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. |
| |
| |
| |
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.
Click Submit.
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. |
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:
Install FireScreen (Section : Installing FireScreen)
Configure FireScreen (Section : Configuring FireScreen)
Start and stop FireScreen (Section : Starting and Stopping FireScreen)
View FireScreen status (Section : Viewing FireScreen Status)
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. |
| |
| |
| |
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
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-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.
Click on Install.
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.
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).
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-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-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.
To configure FireScreen, on the FireScreen Administration menu, choose Configure FireScreen. Figure 9-7 shows the Configure FireScreen menu.
Use the Configure FireScreen menu to perform the following tasks:
Set command-line options (Section : Setting Command-Line Options)
Set the screening mode (Section : Setting the Screening Mode)
Add a screening rule (Section : Adding a Screening Rule)
Check the syntax of screening rules (Section : Checking Syntax of Screening Rules)
Delete a screening rule (Section : Deleting a Screening Rule)
| |
| |
| |
| Note: You must restart FireScreen for configuration file changes to take effect (Section : Starting and Stopping FireScreen). |
| |
| |
| |
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-8. These command-line options are passed to FireScreen when it is started.
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.)
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.
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-9.
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. |
| |
| |
| |
To set the screening mode for FireScreen, follow these steps:
From the Configure FireScreen menu, choose Set Screening Mode.
Figure 9-10 shows the Set 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:
|
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:
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-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.
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.
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-12. Note the order in which the screening rules are listed in the FireScreen configuration file.
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.
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.
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.
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-14.
Select the screening rule you want to delete from the Screening Rules list box, as shown in Figure 9-14.
Click on Delete.
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-15. To start FireScreen, click on Submit.
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.
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).
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-18).
Click on Submit.
The confirmation page indicates that FireScreen is stopped (Figure 9-19).
Using the View FireScreen Status menu, you can view the following:
Screening rules (Section : Viewing FireScreen Screening Rules)
Log file (Section : Viewing the FireScreen Log)
Statistics (Section : Viewing FireScreen Statistics)
To access this menu, choose View FireScreen Status from the FireScreen Administration menu.
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).
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.
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
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.
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).
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:
| Directory | Contents | Subset |
|---|---|---|
| /usr/internet/security | Snort executable Snort configuration file | IAESNORT |
| /usr/internet/docs/snort | Snort documentation | 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.
Use the Internet Express Administration utility to perform the following actions with Snort:
Configure the Snort Decoder (see Section : Configuring Snort Decoder)
Configure the Snort Preprocessor (Section : Configuring Snort Preprocessor)
Run Snort (see Section : Running Snort)
View alert messages (Section : Viewing Alert Messages)
Follow these steps to configure the Snort decoder.
From the Manage Components menu, choose Snort.
From the Configure Snort menu, choose Configure Snort Decoder.
The Configure Menu is displayed.
Click in a checkbox to select the desired decoder option:
Option Description Disable Decode Alert Turns 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 options Turns off alerts generated by obsolete TCP options. Click on Submit.
Follow these steps to configure the Snort preprocessor:
From the Manage Components menu, choose Snort.
From the Configure Snort menu, choose Configure Snort Preprocessor.
The Configure Menu is displayed.
Click in a checkbox to select the preprocessor desired option:
Option Description Perform IP defragmentation The 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 Traffic Normalizes 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 stings Allows 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. Click on Submit.
Follow these steps to run Snort:
From the Manage Components menu, choose Snort.
From the Configure Snort menu, choose Run Snort.
The statistics for the operation are displayed.
Follow these steps to view Snort alert messages.
From the Manage Components menu, choose Snort.
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.
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:
Considerations while installing FreeRADIUS (Section : Considerations While Installing FreeRADIUS)
Starting and Stopping the FreeRADIUS Server (Section : Starting and Stopping the FreeRADIUS Server)
Understanding Configuration files (Section : Understanding FreeRADIUS Configuration Files)
Viewing FreeRADIUS log file (Section : Viewing FreeRADIUS Log File)
For information on FreeRADIUS server, see the FreeRADIUS Web site:
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.
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.
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 :
|
|
|
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:
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.
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.
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
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.
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.