2951 Security 5

Securing Linux
Systems for the

Enterprise
a Jupiterweb Security eBook

™
Securing Linux Systems for the Enterprise
he Linux operating system is a cornerstone of most modern enterprise computing environments. The power,
T flexibility, and stability of enterprise-focused Linux distributions such as Red Hat, SUSE, and Ubuntu are well
known and respected. Unfortunately, the flexibility and power of Linux has a downside -- the fact that Linux
systems can support most known network protocols and services can leave them open to attack unless correctly
configured and deployed.
The dependence of modern business on Web-based interaction and Internet-oriented applications and execution
environments puts increasing demands on networking infrastructure. High-volume data requirements and new net-
work services mean that more devices and data must always be available on the network, 24x7. This constant avail-
ability is a modern business fundamental that, unfortunately, isn't limited to authorized users. Those same systems
are now always available for attacks from online intruders and other malicious users.
Modern computer systems must export an increasingly wide network profile, but only that profile. Most enterprise
Linux distributions are delivered with most network ports and services disabled, so that services must be turned on
rather than off. Regardless, double-checking some standard aspects of the network and general security configura-
tion of your systems can substantially increase system security and will certainly increase your comfort level with the
safety and security of the systems on your network.
Note
One of the problems with providing general security suggestions that apply to multiple Linux distributions is that
different Linux distributions provide different administrative tools. This guide focuses on command-line tools that
can be found, or are at least available for, any Linux distribution.
Identifying Open Network Ports

and Associated Daemons
Any open network port on your system indicates a potential entry point. In this context, an open network port is a
port on which some server is listening for and responding to requests. Two common ways of listing open ports
when logged in on a machine are by using the lsof and netstat commands.
The lsof (list open files) command lists all open files on a Linux system. Its -i option tells the command to list all IP
(Internet protocol) related files, while the -n option suppresses trying to map IP addresses to host names for any
established connection. (Avoiding these improves the speed with which results are returned.) We then pipe the out-
put of this command to the egrep command, only selecting results that contain COMMAND (which gives us the
headings for the various columns), TCP (a daemon listening using the TCP protocol), and UDP (a daemon that is lis-
tening using the UDP protocol). The following is sample output from the lsof command on a Red Hat Enterprise
Linux (RHEL) 4 system:
# lsof -i -n | egrep 'COMMAND|TCP|UDP'

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
portmap 871 rpc 3u IPv4 4428 UDP *:sunrpc
portmap 1871 rpc 4u IPv4 4431 TCP *:sunrpc (LISTEN)
rpc.statd 1891 rpcuser 4u IPv4 4468 UDP *:32768
rpc.statd 1891 rpcuser 5u IPv4 4457 UDP *:795
rpc.statd 1891 rpcuser 6u IPv4 4471 TCP *:32769 (LISTEN)
sshd 2082 root 3u IPv6 4945 TCP *:ssh (LISTEN)
xinetd 2097 root 5u IPv4 5007 TCP *:auth (LISTEN)
xinetd 2097 root 6u IPv4 5008 TCP *:telnet (LISTEN)
xinetd 2097 root 8u IPv4 5009 TCP *:vnc (LISTEN)
ntpd 2113 ntp 4u IPv4 5108 UDP *:ntp
1 Securing Linux Systems for the Enterprise, a JupiterWeb Security eBook. Copyright 2006, Jupitermedia Corp.
ntpd 2113 ntp 5u IPv6 5109 UDP *:ntp

ntpd 2113 ntp 6u IPv4 5110 UDP 127.0.0.1:ntp
ntpd 2113 ntp 7u IPv4 5111 UDP 192.168.6.233:ntp
sendmail 2132 root 3u IPv4 5136 TCP 127.0.0.1:smtp (LISTEN)
cupsd 3427 root 0u IPv4 10857 TCP 127.0.0.1:ipp (LISTEN)
cupsd 3427 root 2u IPv4 10858 UDP *:ipp
This output shows that the daemons running directly on this systems are portmap (RPC port mapper), rpc.statd
(RPC status monitoring), sshd (secure shell), ntpd (network time protocol), sendmail (mail server), and cupsd (CUPS
print daemon). In addition, the xinetd Internet services daemon is running the auth (remote identification daemon),
telnet (network terminal), and vnc (virtual network computing) servers.
The netstat (network statistics) command provides very similar output when run on the same system. The -t option
produces output for all TCP/IP ports, and the -u option produces output for all UDP ports. The -l option restricts the
output to ports that are actively listening for connections. The -p option shows the program and process ID that
owns the network connection. The following is sample output from the lsof command on a Red Hat Enterprise Linux
(RHEL) 4 system:
# netstat -tulp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Addr State PID/Program name
tcp 0 0 *:32769 *:* LISTEN 1891/rpc.statd
tcp 0 0 *:sunrpc *:* LISTEN 1871/portmap
tcp 0 0 *:auth *:* LISTEN 2097/xinetd
tcp 0 0 *:vnc *:* LISTEN 2097/xinetd
tcp 0 0 localhost.localdomain:ipp *:* LISTEN 3427/cupsd
tcp 0 0 *:telnet *:* LISTEN 2097/xinetd
tcp 0 0 localhost.localdomain:smtp *:* LISTEN 2132/sendmail: acce
tcp 0 0 *:ssh *:* LISTEN 2082/sshd
udp 0 0 *:32768 *:* 1891/rpc.statd
udp 0 0 *:795 *:* 1891/rpc.statd
udp 0 0 *:sunrpc *:* 1871/portmap
udp 0 0 *:ipp *:* 3427/cupsd
udp 0 0 rhel4.vonhagen.org:ntp *:* 2113/ntpd
udp 0 0 localhost.localdomain:ntp *:* 2113/ntpd
udp 0 0 *:ntp *:* 2113/ntpd
udp 0 0 *:ntp *:* 2113/ntpd
This list provides a bit more detail, but shows the same open ports and associated services as the lsof command.
A machine's internal view of the services that it provides should match those that an outside machine would see. To
verify this, you can use the nmap (network mapping) command from another system. The -sT option does a TCP
port scan, while the -sU option does a UDP port scan. Scanning the same machine from another system produces
output like the following:
# nmap -sTU 192.168.6.233

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-07-30 16:42 EDT
Interesting ports on rhel4.vonhagen.org (192.168.6.233):
(The 3131 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
111/tcp open rpcbind
111/udp open|filtered rpcbind

113/tcp open auth Assuming you're safe from viruses and other malware
123/udp open|filtered ntp just because you are on a non-Windows platform is a big
631/udp open|filtered unknown mistake, as the number of Linux-based malware doubled
795/udp open|filtered unknown in 2005, according to a report from Kaspersky Labs.
32768/udp open|filtered omad
MAC Address: 00:E0:18:76:C0:B4 (Asustek In a report titled "2005: *nix Malware Evolution," the
Computer) Russian antivirus software developer pointed out that the
number of Linux-based malicious programs -- viruses,
Nmap finished: 1 IP address (1 host up)
Trojans, back-doors, exploits, and whatnot -- doubled
scanned in 1475.249 seconds from 422 to 863.
Though the nmap command can't identify the services associ- Numerically, that pales compared to the 11,000
ated with ports 631 and 795, the local machine output from the Kaspersky found for Windows in the second half of 2005
lsof and nmap commands shown previously identifies these as alone. However, it could be more devastating because
a print daemon and the rpc.statd command, respectively. many non-Windows users assume malware is only a
Windows problem and don't take any precautions.
Kaspersky said Linux users are careful, but one security
Given that all of this output agrees, the next step is to analyze
expert disagrees.
the services that are available to determine whether they are all
necessary and, if not, what to do about them: "With Linux users, there's a very vigilant effort to make
sure the system is as secure as possible, mostly because
• First, the cupsd (print) and sendmail (mail server) daemons Linux people are very aware of security dangers and the
shown in the netstat and lsof output not visible in the nmap security that needs to be put in place," said Shane
output. The netstat and lsof output confirms that they are Coursen, senior technical consultant with Kaspersky's
only listening on the local loopback interface, and are there- U.S. office in Woburn, Mass.
fore not accessible from outside the machine and should not
"The other thing is that there are people who have transi-
pose a security problem. If performance is an issue for the
tioned from Windows to Linux, thinking Linux would pro-
machine you're analyzing, sendmail is useful for local mail vide them more security, and they make sure their new
delivery, but you may want to terminate the CUPS daemon if Linux system is secured," he added.
no one will be printing from this machine.
But Tom Ferris, researcher with Security Protocols, a
• The ssh (secure shell) daemon provides a secure mecha- computer security research firm in Mission Viejo, Calif.,
nism for remote logins and supports encrypted communica- said the opposite. "In people's minds, if it's non-Windows,
tion, so that's fine. it's secure, and that's not the case," he said. "They think
nobody writes malware for Linux or OS X. But that's not
necessarily true, as that report showed."
• The telnet daemon (network terminal) represents an older
protocol used to establish remote connections, and typically The growth in Linux malware is simply due to its increas-
uses unencrypted communications. Some newer versions of ing popularity, particularly as a desktop operating system,
telnet support secure authentication and communication said Coursen.
mechanisms such as Kerberos, but regardless, this is an
unnecessary service because SSH is also supported, and we "The use of an operating system is directly correlated to
should therefore shut this down. the interest by the malware writers to develop malware
for that OS," he added.
• The rpcbind (port mapper) and rpc.statd (port 795) dae-
The Kaspersky report said that the Unix picture mirrors
mons are only useful in NFS environments. If the machine
that on the Win32 front. The biggest problems are exploits
we're analyzing is not an NFS client, these should be shut and back doors designed to steal information. There are
down. also sniffers, flooders and other hack tools. While rootkits
get all the headlines, Coursen said the biggest problems
• The auth daemon can be useful in analyzing problems net- will still be exploits and Trojans.
work clients, but can also provide intruders with information
about the users of your systems. However, some FTP and --Andy Patrizio, InternetNews.com
other network clients essentially require it. It should either be
disabled or started with its -n option, which causes it to display numeric user IDs rather than user names.
• The ntp (network time) daemon is used to synchronize the clock across systems on a network, but has been
exploited in the past. We'll replace this daemon with running the ntp -q command once at boot time, which
queries and synchronizes with a time service once and then exits.
• The omad daemon on port 32768 is initially puzzling, but cross-checking against the lsof and netstat output
shows that port 32768 is actually being used for rpc.statd queries, and therefore should be eliminated by shutting
down the rpc.statd daemon. This daemon is being misidentified by nmap.
The next step in this process is to go to the machine that we're analyzing and determine where and when these
daemons are being started, so that we can terminate any we have identified as being extraneous (cupsd, portmap,
rpc.statd, telnet, vnc), and modify the behavior of any others (authd, ntpd) whose behavior we want to modify.
Locating Start-Up Scripts Associated with

Extraneous Network Services
Network daemons are generally started in one of two ways on a modern Linux system -- either as part of the sys-
tem start-up process or in response to incoming network requests that are detected by a general network services
daemon. This section focuses on the former; the latter are discussed in the next section. Right now we're trying to
determine where the cupsd, ntpd, portmap, and rpc.statd daemons are being started.
Note
Red Hat Enterprise Linux systems, such as the one being used as an example in this guide, provide a command
(chkconfig) that identifies the run levels at which various services are being started. This guide focuses on more
generic, distribution-independent mechanisms for deriving that information.
Most modern Linux systems use what is known as the SysVInit mechanism to start different systems at different run
levels. A central collection of scripts that start all available system services is stored in the directory /etc/init.d. The
services associated with different run levels, typically 0 through 6, are identified in each of the directories /etc/rc0.d
through /etc/rc6.d, and are actually started and stopped via symbolic links to the main scripts stored in the
/etc/init.d directory. The symbolic links for scripts that start services when a run level is entered begin with the letter
'S' (start), followed by a sequence number that reflects the order in which they are started (in ascending order). The
symbolic links for scripts that stop services when a run level is entered begin with the letter 'K' (kill), followed by a
sequence number that reflects the order in which they are stopped (in descending order). This mechanism is known
as "Sys V Init" because the ancestor of this system start-up approach was first introduced on AT&T System V Unix
machines.
To locate the scripts that are used to start various services, change to the directory /etc/init.d and list its contents.
You will see something like the following:
# ls
acpid FreeWnn mysqld rpcidmapd
amd functions named rpcsvcgssd
anacron gpm netdump rstatd
apmd haldaemon netdump-server rusersd
arptables_jf halt netfs rwhod
arpwatch hidd netplugd saslauthd
atd hpoj network sendmail
auditd httpd NetworkManager single
autofs iiim nfs smartd

bgpd innd nfslock smb
bluetooth ip6tables nscd snmpd
bootparamd iptables ntpd snmptrapd
canna irda ospf6d spamassassin
cpuspeed irqbalance ospfd squid
crond isdn pand sshd
cups kadmin pcmcia syslog
cups-config-daemon killall portmap sysstat
cyrus-imapd kprop postfix tux
dc_client krb524 postgresql vncserver
dc_server krb5kdc psacct vsftpd
dhcp6r kudzu radiusd winbind
dhcp6s ldap radvd xfs
dhcpd lisa rawdevices xinetd
dhcrelay lm_sensors readahead ypbind
diskdump mailman readahead_early yppasswdd
dovecot mdmonitor rhnsd ypserv
dund mdmpd ripd ypxfrd
exim messagebus ripngd zebra
firstboot microcode_ctl rpcgssd
Looking through this list, it's easy to spot start-up scripts for services such as cups, ntpd, and portmap, since the
names of the start-up scripts are evocative of their associated services. However, it's unclear which script is associ-
ated with the rpc.statd daemon. We can use grep to determine this:
# grep rpc.statd *
nfslock:[ -x /sbin/rpc.statd ] || exit 0
nfslock: daemon rpc.statd "$STATDARG"
nfslock: killproc rpc.statd
nfslock: status rpc.statd
nfslock: /sbin/pidof rpc.statd >/dev/null 2>&1; STATD="$?"
We therefore need to disable the cups, nfslock, and portmap scripts so that they are not executed when we reboot
our system. We will also want to modify the ntpd script so that it executes ntpd differently.
A system's default run level, which is a way of referring to the specific collection of scripts and services that it starts
when it boots normally, is determined by the line containing the initdefault keyword in the file /etc/inittab. On a RHEL
system, this line looks like the following:
$ grep ':initdefault:' /etc/inittab

id:5:initdefault:
Different Linux distributions associate different logical meanings with the run levels 2 through 6, but the mechanism
is the same regardless of the services that are started at various run levels. For example, the default run level on a
Ubuntu Linux server is run level 2, as shown by the following:
$ grep 'initdefault:' /etc/inittab

id:2:initdefault:
Once you know your system's default run level, you can go to its associated directory and remove the symbolic
links that are associated with the services that you no longer want to start. In this example, this is the directory
/etc/rc5.d, because this sample RHEL system boots tom run level 5 by default.
Though these are only symbolic links, it's a good idea to keep track of which services you have manually disabled,
to make it easy for other system administrators to see the changes that you have made to a given machine from its
default configuration. To simplify this, create a directory called DISABLED and move the symbolic links to this direc-
tory, rather than just deleting them.
# mkdir DISABLED
# ls *nfslock *portmap *cups
S13portmap S14nfslock S55cups
# mv *nfslock *portmap *cups DISABLED
You should repeat this process for other run levels that may start these same services. Here's how you can find a
complete list:
# cd /etc
# find {init,rc}.d -name "*nfslock*"
rc.d/init.d/nfslock
rc.d/rc0.d/K86nfslock
rc.d/rc5.d/DISABLED/S14nfslock
rc.d/rc5.d/S14nfslock
rc.d/rc5.d/S14nfslock
This shows that the nfslock script is also being called at run levels 3 and 4, where you should disable it using the
same mechanism. You would then run this same command to identify other run levels at which the cups and
portmap scripts were called and disabled those using the same mechanism.
If you are using a system such as RHEL that provides a run level configuration tool, you will also want to use that
tool to disable the system's notion of what services are associated with various run levels. In this case, you would
execute that command to disable the specified service at all run, as in the following example:
# chkconfig nfslock off

# chkconfig cups off
# chkconfig portmap off
Other Linux distributions, such as Ubuntu and Debian, provide similar tools such as the BootUp Manager (BUM).
Modifying System Start-up Behavior

Note
This section uses ntpd, the network time protocol daemon, as an example of a process that you still want to run
regularly, but not run continuously, as a daemon, for security reasons. Some networked environments require
extremely tight synchronization between all participating systems. In those cases, this specific example may be
inappropriate, but still illustrates how to replace a daemon with regularly scheduled processes.
As mentioned earlier, we want to modify the behavior of the network time protocol daemon, ntpd, so that it only
executes a single query when you boot the system rather than running the daemon continuously, and then synchro-
nizes daily thereafter. To do this, we'll either want to modify the /etc/init.d/ntpd script or any associated data files, or
change how the system invokes the ntpd daemon. We'll do the latter, which is a bit cleaner.
First follow the instructions in the previous section to remove the ntpd command from all run levels. Next, edit the file
/etc/rc.local, which is a start-up script that is executed as the last step of the boot process. Add the line
/usr/sbin/ntpd -q before the last line of the file so that it looks something like this (it will be different depending on
your distribution):
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/usr/sbin/ntpd -q
touch /var/lock/subsys/local
Your system will now execute the /usr/sbin/ntpd -q command as essentially the last command in its start-up
process each time you reboot this system.
Next, we want to make sure that the system runs the same command once a day after it has been booted, so that
the system clock never gets too far from the real time. To do this, we'll use the cron command to schedule regular
execution of the ntpd -q command, in this example on a daily basis. To do this, execute the crontab -e command to
edit the table of command scheduled for regular execution and add the following line to the file:
5 0 * * * echo `date`: `/usr/sbin/ntpd -q` >> /var/log/cron_ntpd.log
Note: All of the quotes in this example are single back-quotes, which cause the command enclosed between
each pair of them to be executed.
This entry will execute the /usr/sbin/ntpd -q command at five minutes after midnight every day, and will append an
entry to the file /var/log/cron_ntpd.log that consists of a timestamp and the output of this command. We can then
monitor this log file to see how much readjustment was necessary and increase the frequency of this command, if
necessary. (You can consult the online reference page for the crontab command for more information about the for-
mat of a crontab file by executing the command man 5 crontab.)
Disabling xinetd-Based Network Services

The lsof and netstat output shown in the first section of this guide identified the auth, telnet, and vnc services as
being run by the xinetd Internet services daemon. This daemon is a general-purpose network daemon that waits for
incoming requests on selected ports and then starts the services associated with those ports. The xinetd daemon is
an enhanced, more secure, and more flexible descendent of a similar daemon (known as inetd) that was used on
many earlier Linux and Unix systems.
One of the capabilities originally introduced with xinetd are known as TCP wrappers. This is a library that is transpar-
ent to the end user but provides system administrators with fine-grained control over the hosts that can (or cannot)
access a specific network service and associated daemon. The TCP wrappers library does this by checking the files
/etc/hosts.allow and /etc/hosts.deny for any restrictions on the hosts that can access a service before allowing a
connection to be established. The TCP wrappers concept has proven to be so useful that most modern Linux dis-
tributions compile all network daemons, including standalone daemons such as sshd and NFS daemons such as
portmap, with the TCP wrappers library.
The configuration files for all daemons that are managed by the xinetd daemon are located in the directory
/etc/xinetd.d. This directory contains the following files on a sample RHEL system:
# ls
amanda daytime gssftp rexec tftp
amandaidx daytime-udp klogin rlogin time
amidxtape dbskkd-cdb krb5-telnet rsh time-udp
auth echo krb5-telnet.rpmsave rsync vnc
chargen echo-udp kshell swat
chargen-udp eklogin ktalk talk
cups-lpd finger ntalk telnet
The files in this directory are text files that contain start-up instructions for each associated service. Each of these
files contains an entry that identifies whether the associated service is disabled on the target machine. To double-
check which of these services are actually enabled, you would execute commands like the following:
# cd /etc/xinetd.d
# grep disable * | grep no
auth: disable = no
krb5-telnet: disable = no
vnc: disable = no
The output will be different on your system, but should look fairly similar. This shows that the auth daemon, a
Kerberos-enhanced version of the telnet daemon, and the vnc server are all started in response to incoming
requests on the ports that they are associated with. As noted earlier, we want to disable the telnet and vnc servers,
and modify the behavior of the auth daemon. This section explains the former; modifying the behavior of the auth
daemon is explained in the next section.
To disable services so that they are not started by the xinetd, simply edit each file in a text editor and change "no" to
"yes" in each disable entry. After doing so, the control file for the auth daemon should be the only file in this directory
that will be managed by xinetd after a reboot.
# grep disable * | grep no

auth: disable = no
The next section explains how to modify an xinetd control file so that the command is still executed on-demand, but
works differently.
Modifying the Behavior of xinetd-Based Network

Services
As discussed earlier, we still want to run the auth daemon, but we want to change it so that it returns numeric user
identifiers rather than actually exposing the log-in names of the users on our systems. The auth daemon's xinetd
control file looks like the following (with comments removed):
service auth
{
disable = no
socket_type = stream
wait = no
user = ident
cps = 4096 10
instances = UNLIMITED
server = /usr/sbin/in.authd
server_args = -t60 --xerror --os -E
}
In this example, we simply want to add the -n option to the authd command line, which you would do using your
favorite text editor, so that the modified file would look something like the following:
service auth
{
disable = no
socket_type = stream
wait = no
user = ident
cps = 4096 10
instances = UNLIMITED
server = /usr/sbin/in.authd
server_args = -n -t60 --xerror --os -E
}
After saving this file, the next time that the xinetd is restarted, authd requests will no longer return and display user
names, but will return and display numeric user identifiers instead. The same functionality will still be present, but
less information about your system will be exposed over the network.
Verifying Changes in Network Services

After making changes to your system's start-up process and available services, the best test is to reboot the system
and then examine it using the same commands that we used earlier to explore its capabilities. After rebooting the
system, the lsof command displays the following information:
# lsof -i -n | egrep 'COMMAND|TCP|UDP'

COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 2040 root 3u IPv6 4808 TCP *:ssh (LISTEN)
xinetd 2055 root 5u IPv4 4950 TCP *:auth (LISTEN)
sendmail 2074 root 3u IPv4 4914 TCP 127.0.0.1:smtp (LISTEN)
Now that's more like it: a lean, mean, networked machine. To verify how remote systems see this example host,
probing the system from another machine using nmap confirms that a much more limited set of services are now
available to other machines:
# nmap -sTU 192.168.6.233

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2006-07-31 01:31 EDT
Interesting ports on rhel4.vonhagen.org (192.168.6.233):
(The 3139 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
113/tcp open auth
MAC Address: 00:E0:18:76:C0:B4 (Asustek Computer)
Nmap finished: 1 IP address (1 host up) scanned in 1462.945 seconds
This verifies that the sample system is much less exposed to the network. Reducing the number of available servic-
es on a given system also has the fringe benefit of returning the amount of memory required by those services to
the pool that is available to the system itself.
Summary
The biggest step that you can make towards ensuring the security of a networked system is to reduce the number
of open ports and associated services that the system makes available over the network. This guide provided a
number of examples of how to eliminate extraneous services that are started as part of the system start-up process
and which are managed by other daemons on a machine, such as the xinetd.
This guide was written by Bill von Hagen. Copyright 2006, Jupitermedia Corp.
JupiterWeb eBooks bring together the best in technical information, ideas and coverage of important IT trends
that help technology professionals build their knowledge and shape the future of their IT organizations. For more
information and resources on IT security, visit any of our category-leading sites:
www.esecurityplanet.com
www.antionline.com
www.internetnews.com/security
www.earthwebnews.com/security
www.enterpriseitplanet.com/security
www.insideid.com
www.smallbusinesscomputing.com
www.linuxtoday.com/security/
For the latest live and on-demand Webcasts on IT security, visit: www.jupiterwebcasts.com/security

2951 Security 5

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2951 Security 5

Uploaded by

Copyright:

Available Formats

Securing Linux

Systems for the

a Jupiterweb Security eBook

Identifying Open Network Ports

# lsof -i -n | egrep 'COMMAND|TCP|UDP'

ntpd 2113 ntp 5u IPv6 5109 UDP *:ntp

# nmap -sTU 192.168.6.233

111/udp open|filtered rpcbind

Locating Start-Up Scripts Associated with

autofs iiim nfs smartd

$ grep ':initdefault:' /etc/inittab

$ grep 'initdefault:' /etc/inittab

# chkconfig nfslock off

Modifying System Start-up Behavior

5 0 * * * echo `date`: `/usr/sbin/ntpd -q` >> /var/log/cron_ntpd.log

Disabling xinetd-Based Network Services

# grep disable * | grep no

Modifying the Behavior of xinetd-Based Network

Verifying Changes in Network Services

# lsof -i -n | egrep 'COMMAND|TCP|UDP'

# nmap -sTU 192.168.6.233

You might also like