Securing AIX Network Services

Sandor W. Sklar <>

$Id: net-sec.html,v 1.18 2001/11/12 06:36:25 ssklar Exp ssklar $

Stolen from

Section: Introduction

Should I take this tutorial?

This tutorial is designed for administrators of AIX systems who wish to better understand the network services in AIX and the impact on system security each one has. If you are responsible for any number of RS/6000s connected it some way to a public network, the information presented within will help you to achieve the necessary balance between functionality and security.

No third-party tools will be used in this presentation; only the components available to all AIX systems will be explored and addressed. While a true security model takes much more then just turning off services and modifying configuration files, this tutorial provides a solid foundation to build upon as you reach for the goal of complete system integrity.

About the examples in this tutorial

The system used for the examples in this tutorial is an IBM RS/6000, running a complete installation of AIX 4.3.3, Maintenance Level 08. No software beyond that available on the AIX installation media was placed on the host.

It is important to understand the potential impact of any change made to a system's configuration; this is especially true when dealing with security-related concerns. Before making any modifications to a production system, be sure that the changes have first been tested in a suitable development environment. Always backup your systems, wear your seat belt, and close cover when striking.

About the author

Sandor W. Sklar is a Unix Systems Administrator at Stanford University, in beautiful Northern California. When not poking through his systems for real or imagined security holes, he enjoys spending time with his wife and two children.

Understanding Security

What is the problem?

A normal installation of AIX (or almost any operating system) includes a dizzying array of services. Some of these services are critical: without a telnetd daemon active, there would be no way to remotely log in to the system. Many of those services, though, were developed at a time when the Internet was much smaller, and the perceived danger from "crackers" and other people trying to gain unauthorized access was considered less than the benefits of easy remote access and simple authentication methods.

Today's computing environment is a much more "dangerous" place: the number of hosts connected to the Internet has grown exponentially, and with that growth, attempts to access and subvert computers have become commonplace events. Systems that are not sufficiently secure are quickly compromised; once an attacker has gained access to a system, information stored there is no longer private, and its contents can not be trusted.

How does it happen?

All systems that are compromised by remote attackers have had, by definition, their own network connection used against them. Some of these attacks take advantage of bugs in a particular version of a network daemon. Other attacks are successful because they exploit a known weakness in a particular protocol, common to all systems running that service.

It is important to ensure that all active network services are evaluated for not only their usefulness in fulfilling a necessary task, but also that any shortcomings or vulnerabilities in the service are understood. Balancing the "good" and "bad" in each service can be difficult, but it is a critical part of keeping your system safe.

Barbarians At The Sockets (or, "Services that run on a default installation")

A default AIX installation offers numerous services, each responsible for listening on at least port. The below table details each open port, the system daemon that is bound to the port, and the configuration file from which that daemon is started by.

Protocol Well-Known Name Daemon/Application Started from
7 tcp echo /usr/sbin/inetd /etc/inetd.conf
7 udp echo /usr/sbin/inetd /etc/inetd.conf
9 tcp discard /usr/sbin/inetd /etc/inetd.conf
9 udp discard /usr/sbin/inetd /etc/inetd.conf
13 tcp daytime /usr/sbin/inetd /etc/inetd.conf
13 udp daytime /usr/sbin/inetd /etc/inetd.conf
19 tcp chargen /usr/sbin/inetd /etc/inetd.conf
19 udp chargen /usr/sbin/inetd /etc/inetd.conf
21 tcp ftp /usr/sbin/ftpd /etc/inetd.conf
23 tcp telnet /usr/sbin/telnetd /etc/inetd.conf
25 tcp smtp /usr/sbin/sendmail /etc/rc.tcpip
37 tcp time /usr/sbin/inetd /etc/inetd.conf
37 udp time /usr/sbin/inetd /etc/inetd.conf
67 udp bootps /usr/sbin/bootpd /etc/inetd.conf
111 tcp sunrpc /usr/sbin/portmap /etc/rc.tcpip
111 udp sunrpc /usr/sbin/portmap /etc/rc.tcpip
161 udp snmp /usr/sbin/snmpd /etc/rc.tcpip
177 udp xdmcp /usr/dt/bin/dtlogin (spawned by /etc/rc.dt) /etc/inittab
199 tcp smux /usr/sbin/dpid2 /etc/rc.tcpip
512 tcp exec /usr/sbin/rexecd /etc/inetd.conf
513 tcp login /usr/sbin/rlogind /etc/inetd.conf
514 tcp shell /usr/sbin/rshd /etc/inetd.conf
514 udp syslog /usr/sbin/syslogd /etc/rc.tcpip
518 udp ntalk /usr/sbin/talkd /etc/inetd.conf
543 tcp klogin /usr/sbin/krlogind /etc/inetd.conf
544 tcp kshell /usr/sbin/krshd /etc/inetd.conf
1001 tcp rpc.statd /usr/sbin/rpc.statd /etc/rc.nfs
1001 udp rpc.statd /usr/sbin/rpc.statd /etc/rc.nfs
1002 tcp rpc.statd /usr/sbin/rpc.statd /etc/rc.nfs
1002 udp rpc.statd /usr/sbin/rcp.statd /etc/rc.nfs
1234 tcp instsrv /home/netinst/bin/instsrv /etc/inetd.conf
2401 tcp writesrv /usr/sbin/writesrv /etc/inittab
6000 tcp X11 /usr/lpp/X11/bin/X (spawned by /etc/rc.dt) /etc/inittab
6112 tcp dtspc /usr/dt/bin/dtspcd /etc/inetd.conf
32768 tcp dtlogin /usr/dt/bin/dtgreet (spawned by /etc/rc.dt) /etc/inittab
32769 tcp rpc.ttdbserver /usr/dt/bin/rpc.ttdbserver /etc/inetd.conf
32772 tcp dpid2 /usr/sbin/dpid2 /etc/rc.tcpip
32785 udp cmsd /usr/dt/bin/rpc.cmsd /etc/inetd.conf
49213 tcp httpd /usr/IMNSearch/httpdlite/httpdlite /etc/inittab

What can be done?

There are two basic steps in hardening the networking of an AIX system:

Of course, it is not possible to turn off every service. (If it is possible, then your organization needs to rethink its use of information technologies.) It is, however, possible to mitigate potential risks by configuring those active services to operate in a secure fashion. In a perfect world, default configurations would also be secure configurations. Sadly, the world is not perfect.

Section: Disabling Unnecessary Services

Where are services started?

On an AIX system, network services are usually started in four ways:

Each of the above methods must be checked for insecure or unnecessary services if the system is to be protected from network-originating attacks.

The services in /etc/inittab: Overview

The following text, an excerpt from the default /etc/inittab, has items that are network-related displayed in red.

brc::sysinit:/sbin/rc.boot 3 >/dev/console 2>&1 # Phase 3 of system boot
powerfail::powerfail:/etc/rc.powerfail 2>&1 | alog -tboot > /dev/console # Power Failure Detection
mkatmpvc:2:once:/usr/sbin/mkatmpvc >/dev/console 2>&1
atmsvcd:2:once:/usr/sbin/atmsvcd >/dev/console 2>&1
load64bit:2:wait:/etc/methods/cfg64 >/dev/console 2>&1 # Enable 64-bit execs
rc:2:wait:/etc/rc 2>&1 | alog -tboot > /dev/console # Multi-User checks
fbcheck:2:wait:/usr/sbin/fbcheck 2>&1 | alog -tboot > /dev/console # run /etc/firstboot
srcmstr:2:respawn:/usr/sbin/srcmstr # System Resource Controller
rcnetw:2:wait:/etc/rc.netware #start Netware
cnsview:2:wait:/usr/bin/cnsview -c "daemon start" >/dev/console 2>&1 # Start cnsview daemon
rctcpip:2:wait:/etc/rc.tcpip > /dev/console 2>&1 # Start TCP/IP daemons
rcnfs:2:wait:/etc/rc.nfs > /dev/console 2>&1 # Start NFS Daemons
piobe:2:wait:/usr/lib/lpd/pio/etc/pioinit >/dev/null 2>&1  # pb cleanup
qdaemon:2:wait:/usr/bin/startsrc -sqdaemon
writesrv:2:wait:/usr/bin/startsrc -swritesrv
logsymp:2:once:/usr/lib/ras/logsymptom # for system dumps
httpdlite:2:once:/usr/IMNSearch/httpdlite/httpdlite -r /etc/IMNSearch/httpdlite/httpdlite.conf & >/dev/console 2>&1
diagd:2:once:/usr/lpp/diagnostics/bin/diagd >/dev/console 2>&1
imnss:2:once:/usr/IMNSearch/bin/imnss -start imnhelp >/dev/console 2>&1
imqss:2:once:/usr/IMNSearch/bin/imq_start >/dev/console 2>&1
pmd:2:wait:/usr/bin/pmd > /dev/console 2>&1 # Start PM daemon
cons:0123456789:respawn:/usr/sbin/getty /dev/console
l2:2:wait:/etc/rc.d/rc 2
l3:3:wait:/etc/rc.d/rc 3
l4:4:wait:/etc/rc.d/rc 4
l5:5:wait:/etc/rc.d/rc 5
l6:6:wait:/etc/rc.d/rc 6
l7:7:wait:/etc/rc.d/rc 7
l8:8:wait:/etc/rc.d/rc 8
l9:9:wait:/etc/rc.d/rc 9

Unlike most configuration files in AIX, entries in /etc/inittab can NOT be disabled by placing a pound sign ("#") at the beginning of the line. To disable an inittab entry, it must either be deleted from the file, have a colon (":") as the first character of the line, or have the value of the "action" field set to "off". Changes to /etc/inittab may also be made via the "chitab" command; entries may be deleted with the "rmitab" command.

Before making changes to this file, ensure that there is a good backup copy available, as problems with the inittab file can prevent a system from starting up.

Dealing with the /etc/inittab entries

The services in /etc/rc.tcpip: Overview

The following excerpt from the script /etc/rc.tcpip indicates the services that are started or disabled in a default AIX installation. Items that are displayed in red will be explored further in this tutorial.

echo "Starting tcpip daemons:"
trap 'echo "Finished starting tcpip daemons."' 0

# Start up dhcpcd daemon 
#start /usr/sbin/dhcpcd "$src_running"

# Start up autoconf6 process
#start /usr/sbin/autoconf6 "" 

# Start up ndpd-host daemon
#start /usr/sbin/ndpd-host "$src_running"

# Start up the ndpd-router daemon
#start /usr/sbin/ndpd-router "$src_running"

# Start up syslog daemon (for error and event logging)
start /usr/sbin/syslogd "$src_running"

# Start up print daemon 
#start /usr/sbin/lpd "$src_running"

# Start up routing daemon (only start ONE)
#start /usr/sbin/routed "$src_running" -q
#start /usr/sbin/gated "$src_running"

# Start up the sendmail daemon.

qpi=30m  # 30 minute interval

start /usr/lib/sendmail "$src_running" "-bd -q${qpi}"

# Start up Portmapper
start /usr/sbin/portmap "$src_running"

# Start up socket-based daemons
start /usr/sbin/inetd "$src_running"

# Start up Domain Name daemon
#start /usr/sbin/named "$src_running"

# Start up time daemon
#start /usr/sbin/timed "$src_running"

# Start up Network Time Protocol (NTP) daemon
#start /usr/sbin/xntpd "$src_running"

# Start up rwhod daemon (a time waster)
#start /usr/sbin/rwhod "$src_running"

# Start up the Simple Network Management Protocol (SNMP) daemon
start /usr/sbin/snmpd "$src_running"

# Start up the DHCP Server
#start /usr/sbin/dhcpsd "$src_running"

# Start up the DHCP Relay Agent
#start /usr/sbin/dhcprd "$src_running"

# Start up the DPID2 daemon
start /usr/sbin/dpid2 "$src_running"

# Start up the mrouted daemon
#start /usr/sbin/mrouted "$src_running"
# Start up the atm subagnet daemon muxatmd
#start /usr/sbin/muxatmd "$src_running"
/usr/lpp/x_st_mgr/bin/x_st_mgrd -b /usr/lpp/x_st_mgr/bin/ -s x_st_mgrd
Since /etc/rc.tcpip is a Korn shell script, items may be disabled by placing a pound sign ("#") at the beginning of the line, or by deleting the line entirely.

Dealing with the services in /etc/rc.tcpip

The services in /etc/inetd.conf: Overview

The following excerpt from /etc/inetd.conf lists all of the services that are active in the default installation of AIX.

ftp     stream  tcp6    nowait  root    /usr/sbin/ftpd         ftpd
telnet  stream  tcp6    nowait  root    /usr/sbin/telnetd      telnetd -a
shell   stream  tcp6    nowait  root    /usr/sbin/rshd         rshd
kshell  stream  tcp     nowait  root    /usr/sbin/krshd        krshd
login   stream  tcp6    nowait  root    /usr/sbin/rlogind      rlogind
klogin  stream  tcp     nowait  root    /usr/sbin/krlogind     krlogind
exec    stream  tcp6    nowait  root    /usr/sbin/rexecd       rexecd
bootps  dgram   udp     wait    root    /usr/sbin/bootpd       bootpd /etc/bootptab
tftp     dgram  udp6    SRC     nobody  /usr/sbin/tftpd         tftpd -n
ntalk   dgram   udp     wait    root    /usr/sbin/talkd         talkd
rstatd   sunrpc_udp     udp     wait    root    /usr/sbin/rpc.rstatd rstatd 100001 1-3
rusersd sunrpc_udp      udp     wait    root    /usr/lib/netsvc/rusers/rpc.rusersd rusersd 100002 1-2
rwalld   sunrpc_udp     udp     wait    root    /usr/lib/netsvc/rwall/rpc.rwalld rwalld 100008 1
sprayd   sunrpc_udp     udp     wait    root    /usr/lib/netsvc/spray/rpc.sprayd sprayd 100012 1
pcnfsd   sunrpc_udp     udp     wait    root    /usr/sbin/rpc.pcnfsd pcnfsd 150001 1-2
echo    stream  tcp     nowait  root    internal
discard stream  tcp     nowait  root    internal
chargen stream  tcp     nowait  root    internal
daytime stream  tcp     nowait  root    internal
time    stream  tcp     nowait  root    internal
echo    dgram   udp     wait    root    internal
discard dgram   udp     wait    root    internal
chargen dgram   udp     wait    root    internal
daytime dgram   udp     wait    root    internal
time    dgram   udp     wait    root    internal
ttdbserver      sunrpc_tcp      tcp     wait    root    /usr/dt/bin/rpc.ttdbserver rpc.ttdbserver 100083 1
ssalld  sunrpc_tcp      tcp     wait    root    /usr/sbin/rpc.ssalld rpc.ssalld 300667 1
instsrv stream  tcp     nowait  netinst /home/netinst/bin/instsrv instsrv -r /tmp/netinstalllog /home/netinst/scripts
dtspc   stream  tcp     nowait  root    /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd
cmsd    sunrpc_udp      udp     wait    root    /usr/dt/bin/rpc.cmsd cmsd 100068 2-5

To disable a service listed in the /etc/inetd.conf file, delete the line or place a pound sign ("#") as the first character of the line. Changes to inetd.conf will not take effect until the inetd daemon is restarted by either sending a HUP signal to the PID of the process or by executing the command "refresh -s inetd" as root.

Dealing with the /etc/inetd.conf entries

Securing Remaining Services

The syslogd daemon: Introduction

The key to ensuring that your system remains secure is through constant monitoring of messages posted by the various system daemons and other programs. Most of these programs report errors and other messages through the syslogd daemon, which is responsible for dispatching these messages based on their severity and their facility (or "source".) While the syslogd daemon is active by default in AIX, the configuration of syslogd does no logging of any messages it receives, silently discarding them.

Facilities, priorities, and destinations

The configuration file "/etc/syslog.conf" determines how messages from a particular source and of a set priority will be dealt with. Every system program that uses syslogd will transmit messages at a pre-defined "facility". Those facilities are:

kern kernel messages
user various user-level programs
mail sendmail
daemon system daemons, including ftpd
auth authorization messages
authpriv authorization messages whose viewing should be restricted to root
syslog messages generated internally by the syslog daemon
lpr lpd (printer subsystem)
news nntp (news) server messages
uucp uucp subsystem messages
cron crond messages
local0 - local7 facilities available for administrator-defined use

Each "message" sent to syslogd also has a severity or priority attached to it. Those priorities, in order of severity from highest to lowest, are:

emerg daemon or subsystem failure has occurred or is pending
alert immediate action is required to prevent failure
crit a critical condition has occurred
err an error has occurred
warning a warning has occurred
notice a normal, but significant event has occurred
info informational messages
debug debug-level messages

The syslogd daemon dispatches the message to a given destination, based upon the configuration in the "/etc/syslogd.conf" configuration file. Destinations may be:

File name records the message in the log file specified
@hostname transmits the message to the syslogd daemon running on the specified hostname
user writes the message to the terminal of the specified user name
* writes the message to the terminals of all logged-in users
errlog transmits the message to the AIX error logging facility (errdemon) for inclusion in the errpt

Configuration of the syslog.conf file

There is no single "correct" way to configure the syslogd daemon; the administrator needs to determine their site's configuration based upon the standard practices used by their organization. The following example, however, will provide a good "starting point".

## /etc/syslog.conf                                                  ##

# record messages from all facilities at severity "alert" or higher in
# the AIX errlog ...

*.alert                                       errlog

# record messages from all facilities at severity "err" or higher in
# the log file /var/adm/errorlog

*.err                                         /var/adm/errorlog

# record messages from the "mail" facility at severity "info" or
# higher in the log file /var/adm/mail.log                                   /var/adm/mail.log

# record messages from the "auth" and "authpriv" facilities at 
# severity "info" or higher in the log file /var/adm/auth.log

auth,                           /var/adm/auth.log

# record messages from the "daemon" facility at severity "info" or
# higher in the log file /var/adm/daemon.log                                  /var/adm/daemon.log


The syslogd daemon will not write to a file if it does not already exist, so make sure that you "touch" any log files that have been specified. Ensure that the permissions on log files are set so that only authorized users can view their contents. After making changes to the syslog.conf file, the syslogd daemon must be restarted, with the "refresh -s syslogd" command. It is important that the log files are "pruned" on a regular basis, or they will grow until the filesystem is filled up. Pruning or rotating of log files should be handled by a daily "cleanup" script.

Hardening sendmail: Introduction

The sendmail mail transport program has a reputation of being the "swiss cheese" of software, filled with exploitable vulnerabilities. In fact, the first ever advisory released by the Computer Emergency Response Team (CERT) in 1997 dealt with a problem with sendmail and ftpd.

Fortunately, current versions of sendmail have a much better track record of security, and any issues that are found are dealt with promptly by the developers of the sendmail application and by IBM. While AIX 4.3.3 does not ship with the latest available version, sendmail 8.9.3, part of the "" is stable and relatively secure.

In order to truly secure the sendmail service, however, there are some configuration changes that need to be changed from those in the default installation.

Disabling SMTP service

The first step in securing sendmail is to decide if it is even necessary to run sendmail on the particular host at all. Many organizations centralize their e-mail service so that all incoming mail is routed to a small number of systems that are dedicated to receiving and routing incoming mail. If this is the case, then sendmail should not be running as a daemon on other hosts.

Sendmail is started from the file /etc/rc.tcpip; if you have been following the steps in this tutorial, its automatic startup should already be disabled, by commenting out the line:

start /usr/lib/sendmail "$src_running" "-bd -q${qpi}"

in /etc/rc.tcpip. Ensure that it is not running by issuing the command "lssrc -s sendmail"; the output of that command should be similar to:

Subsystem        Group        PID        Status 
sendmail         mail                    inoperative

After disabling sendmail, the host will no longer accept connections on port 25. E-mails generated from this system, though, will no longer be sent to their destination; they will remain in the spool directory until the mail queue is manually processed. The following lines should be added to root's crontab file:

# process the outgoing mail queue twice an hour.                 
10,40 * * * * /usr/lib/sendmail -q > /dev/null 2>&1

The above cron job will invoke sendmail twice an hour, at ten minutes and forty minutes past the our, in "queue-processing" mode. Sendmail will not accept incoming network connections in this mode, but it will go through the mail queue and dispatch any messages it finds.

Closing the open relay

It is probably not feasible to disable incoming mail service on every system within an organization. If this RS/6000 has been designated as a mail server, there are steps that can be taken to ensure that the system is not used to route mail not generated by or destined for your organization.

The default behaviour of sendmail in AIX 4.3.3 permits what is known as "open relaying." Basically, this means that the mail server will accept and process mail sent from outside your organization to addresses that are also outside your organization. Exploiting open relays is the most common technique used by "spammers" to send e-mail to thousands of addresses, all originating from your mail server.

Before enabling sendmail in daemon mode (assuming it was disabled per the instructions earlier in this tutorial), the sendmail configuration file must be modified to prevent this misuse of your system. The following steps detail the process of generating the updated "" configuration file.

  1. Ensure that the filesets and boos.adt.base are installed.
  1. Change the current working directory to /usr/samples/tcpip/sendmail/cf, and create a backup of the file ""
  1. Edit the file, making the changes detailed in the following table:
This line should not be changed.
This line contains an error; change the text within the parenthesis from "aix43" to "aix433"
This line should be deleted unless the genericstable feature is required.
This line should be deleted unless the mailertable feature is required.
This line should be deleted unless the virtualusertable feature is required.
This line should be deleted unless the domaintable feature is required.
This line should be deleted unless the allmasquerade feature is required.
Delete this line to disable open relaying.
Delete this line to increase security.
Delete this line to increase security.
Unless you have an organization-specific domain.m4 file, this line should not be changed.
This line should not be changed.
This line should not be changed.
This line should be deleted unless the routing of mail via UUCP is required.

After making the above changes and saving the file, the contents of the file should be similar to:





  1. Build a new sendmail configuration file by executing the command:

    m4 ../m4/cf.m4 > /tmp/

  2. Often, several mail hosts will receive incoming mail for all of the other systems within the organization, through the use of mail exchange ("MX") records in the domain name server configuration ("DNS"). If this is the case, you will need to create the file "/etc/" and add to that file the hostname of each system for which this host will be processing incoming mail for. Note that if this host has multiple hostnames (due to aliases or multiple IP addresses), each of those names must be listed in this file as well, or mail sent to addresses at those hostnames will be bounced.

    If there are no hostnames in the file, create the file anyway (leaving it empty), or edit the /tmp/ file and comment out with a pound sign ("#") the line:


  1. If there are specific domains for which relaying needs to be permitted, create the directory "/etc/mail", and create the file "/etc/mail/relay-domains", adding the names of those domains to that file.

    If there are no domains for which relaying will be permitted, edit the /tmp/ file and comment out with a pound sign ("#") the line:

FR-o /etc/mail/relay-domains

  1. Confirm that there are no errors in the new sendmail configuration file, by running the command:

sendmail -C/tmp/ -bt < /dev/null

echo $?

If the sendmail command exited with a "0" code (reflected in the output of the "echo $?" command), then the new configuration file is ready to be used.

  1. Make a backup of the file "/etc/", and copy the file /tmp/ to /etc/
  1. Start sendmail in daemon mode by running the command:

startsrc -s sendmail -a "-bd -q30m"

  1. Re-enable the starting of sendmail at system boot time by uncommenting the sendmail entry in /etc/rc.tcpip.

Sendmail will no longer allow the relaying of mail from hosts outside of your domain to addresses not in your domain.

Improving FTP security

Along with sendmail, File Transfer Protocol daemons (FTP) is the most commonly exploited application on UNIX servers. Unlike sendmail, though, vulnerabilities in the ftpd leading to complete system compromise have been found in the version included in AIX 4.3.3. For this reason (and others), unless it is absolutely necessary to offer FTP service, it should be completely disabled in /etc/inetd.conf.

If your service requirements mandate the available of FTP, there are a number of steps that can be taken that can reduce, if not eliminate, the risks inherent in this protocol.

  1. Ensure that the AIX fix "IY04477" is fully installed on the system by running the command:

    instfix -ik IY04477

    This fix closes the vulnerability that has been widely reported, as noted in the IBM Emergency Response Service Security Vulnerability Alert number ERS-SVA-E01-1999:004.1. This APAR is included in Maintenance Level 02, and so should be installed on any system at that level or later.

  2. Ensure that the user names of those accounts that are NOT permitted to use the ftp service are listed in the file "/etc/ftpusers". This list (with one user name per line) should include root, as well as all of the pre-defined administrative accounts: daemon, bin, sys, adm, uucp, guest, nobody, lpd, invscout, imnadm, ipsec, nwroot, nwuser, nwprint, nwldap, ldap, nuucp, and netinst.
  1. Modify the entry for the ftpd server in /etc/inetd.conf, adding the following arguments:
    ftp     stream  tcp6    nowait  root    /usr/sbin/ftpd   ftpd -l -u077

    The "-l" enables logging by the ftpd daemon, to the facility "daemon" at the priority "info", while the "-u077" changes the permissions of uploaded files from the default of 027.

Providing anonymous FTP service is highly advised against. However, if this service is required, use the shell script /usr/samples/tcpip/anon.ftp (installed as part of the fileset) to properly set up the anonynoums FTP user account and directories.

Setting Network Options

Though not specific to a particular service, there are options that can be set to control how certain network protocols behave on an AIX system. These network options are displayed and set using the "no" command. Several of these network options should be changed from their default settings on any system that is connected to a public network (such as the Internet).

Network options need to be set at each system boot, as they do not "stick". There is no "official" method of setting these options; presented below is one possible method.

  1. Create the following script and save it as "/etc/"
    	  # ---------------------------------------------------------------------
    	  # /etc/ : sets network options to improve performance and security
    	  # ---------------------------------------------------------------------
    	  echo "Setting network options"
    	  # protection against SYN flood attacks ...
    	  /usr/sbin/no -o clean_partial_conns=1
    	  # protection against ICMP redirects ...
    	  /usr/sbin/no -o ipignoreredirects=1
    	  # protection against illegal access via source routing ...
    	  /usr/sbin/no -o ipsendredirects=0
    	  /usr/sbin/no -o ipsrcroutesend=0
    	  /usr/sbin/no -o ipsrcrouteforward=0
    	  /usr/sbin/no -o ip6srcrouteforward=0
    	  /usr/sbin/no -o tcp_pmtu_discover=0
    	  /usr/sbin/no -o udp_pmtu_discover=0

mkitab -i brc no:2:once:"/etc/ > /dev/console 2>&1"

Securing AIX Network Services: Summary

Reviewing the hardened system

On the example system used for this tutorial, these changes have been made:

As a result of those changes, the number of open ports on the system were reduced significantly:

Protocol Well-Known Name Daemon/Application Started from
21 tcp ftp /usr/sbin/ftpd /etc/inetd.conf
23 tcp telnet /usr/sbin/telnetd /etc/inetd.conf
25 tcp smtp /usr/sbin/sendmail /etc/rc.tcpip
111 tcp sunrpc /usr/sbin/portmap /etc/rc.tcpip
111 udp sunrpc /usr/sbin/portmap /etc/rc.tcpip
514 udp syslog /usr/sbin/syslogd /etc/rc.tcpip

Am I secure now?

Unfortunately, the answer to that question is "no". It is not enough to simply turn off some services and hope that what remains is secure. Constant monitoring of system logs and network services is required to guard against attempts at compromise, and to check for signs of successful intrusion.

The steps outlined in this tutorial cover only what is possible with the tools provided by the operating system. No advantage was taken of the many open-source and other free tools available. These software applications include OpenSSH, which provides secure replacements for so many of the insecure default services, and other tools like "nmap", useful in determining the "network footprint" of your system and detecting unauthorized services that may be active.

Security can not be achieved by just keeping outsiders at bay from the network. A truly safe system must have safeguards against illligitimate user activity, improper file access control, and a host of other issues addressed. The steps outlined in this tutorial provide a necessary start to the never ending process of developing a safe, secure, and productive computing environment.

A footnote on network security.

Within the six days that the example system used in this tutorial was up and running, there were four distinct attempts at unauthorized access. If you don't believe you are under attack, you are not monitoring your logs close enough.


AIX-Specific Resources

UNIX and General Security Resources

Security Tools

$Id: net-sec.html,v 1.18 2001/11/12 06:36:25 ssklar Exp ssklar $