Home arrow Security arrow Page 9 - Unix Host Security: Hacks 1-10

Check for Listening Services Hack #8 - Security

Security isn't a noun, it's a verb; not a product, but a process. Today, learn the hacks involved in reducing the risks involved in offering services on a Unix-based system. This the first part of chapter one in Network Security Hacks, by Andrew Lockhart (ISBN 0-596-00643-8, O'Reilly & Associates, 2004).

TABLE OF CONTENTS:
  1. Unix Host Security: Hacks 1-10
  2. Secure Mount Points Hack #1
  3. Scan for SUID and SGID Programs Hack #2
  4. Scan For World- and Group-Writable Directories Hack #3
  5. Create Flexible Permissions Hierarchies w/ith POSIX ACLs Hack #4
  6. Protect Your Logs from Tampering Hack #5
  7. Delegate Administrative Roles Hack #6
  8. Automate Cryptographic Signature Verification Hack #7
  9. Check for Listening Services Hack #8
  10. Prevent Services from Binding to an Interface Hack #9
  11. Restrict Services with Sandboxed Environments Hack #10
By: O'Reilly Media
Rating: starstarstarstarstar / 37
May 04, 2004

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement


Find out whether unneeded services are listening and looking for possible backdoors.

One of the first things that should be done after a fresh operating system install is to see what services are running, and remove any unneeded services from the system startup process. You could use a port scanner (such as nmap [Hack #42]) and run it against the host, but if one didn’t come with the operating system install, you’ll likely have to connect your fresh (and possibly insecure) machine to the network to download one. Also, nmap can be fooled if the system is using firewall rules. With proper firewall rules, a service can be completely invisible to nmap unless certain criteria (such as the source IP address) also match. When you have shell access to the server itself, it is usually more efficient to find open ports using programs that were installed with the operating system. One program that will do what we need is netstat, a program that will display various network-related information and statistics.

To get a list of listening ports and their owning processes under Linux, run this:

# netstat -luntp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1679/sshd
udp 0 0 0.0.0.0:68 0.0.0.0:* 1766/dhclient

From the output, you can see that this machine is probably a workstation, since it just has a DHCP client running along with an SSH daemon for remote access. The ports in use are listed after the colon in the Local Address column (22 for sshd and 68 for dhclient). The absence of any other listening processes means that this is probably a workstation, and not a network server.

Unfortunately, the BSD version of netstat does not let us list the processes and the process IDs (PIDs) that own the listening port. Nevertheless, the BSD netstat command is still useful for listing the listening ports on your system.

To get a list of listening ports under FreeBSD, run this command:

# netstat -a -n | egrep 'Proto|LISTEN'
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 *.587 *.* LISTEN
tcp4 0 0 *.25 *.* LISTEN
tcp4 0 0 *.22 *.* LISTEN
tcp4 0 0 *.993 *.* LISTEN
tcp4 0 0 *.143 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN

Again, the ports in use are listed in the Local Address column. Many seasoned system administrators have memorized the common port numbers for popular services, and can see that this server is running SSH, SMTP, DNS, IMAP, and IMAP+SSL services. If you are ever in doubt about which services typically run on a given port, either eliminate the -n switch from netstat (which tells netstat to use names but can take much longer to run when looking up DNS addresses) or manually grep the /etc/services file:

# grep –w 993 /etc/services
imaps 993/udp # imap4 protocol over TLS/SSL
imaps 993/tcp # imap4 protocol over TLS/SSL

Also notice that, unlike the output of netstat on Linux, we don’t get the PIDs of the daemons themselves. You might also notice that no UDP ports were listed for DNS. This is because UDP sockets do not have a LISTEN state in the same sense that TCP sockets do. In order to display UDP sockets, you must add udp4 to the argument for egrep, thus making it 'Proto|LISTEN|udp4'. However, due to the way UDP works, not all UDP sockets will necessarily be associated with a daemon process.

Under FreeBSD, there is another command that will give us just what we want. The sockstat command performs only a small subset of what netstat can do, and is limited to just listing information on both Unix domain sockets and Inet sockets.

To get a list of listening ports and their owning processes with sockstat, run this command:

# sockstat -4 -l
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root sendmail 1141 4 tcp4 *:25 *:*
root sendmail 1141 5 tcp4 *:587 *:*
root sshd 1138 3 tcp4 *:22 *:*
root inetd 1133 4 tcp4 *:143 *:*
root inetd 1133 5 tcp4 *:993 *:*
named named 1127 20 tcp4 *:53 *:*
named named 1127 21 udp4 *:53 *:*
named named 1127 22 udp4 *:1351 *:*

Once again, we see that sshd, SMTP, DNS, IMAP, and IMAP+SSL services are running, but now we have the process that owns the socket plus its PID. We can now see that the IMAP services are being spawned from inetd instead of standalone daemons, and that sendmail and named are providing the SMTP and DNS services.

For most other Unix-like operating systems you can use the lsof utility (ftp://ftp.cerias.purdue.edu/pub/tools/unix/sysutils/lsof/). lsof is short for “list open files” and, as the name implies, allows you to list files that are open on a system, in addition to the processes and PIDs that have them open. Since sockets and files work the same way under Unix, lsof can also be used to list open sockets. This is done with the -i command-line option.

To get a list of listening ports and the processes that own them using lsof, run this command:

# lsof -i -n | egrep 'COMMAND|LISTEN'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
named 1127 named 20u IPv4 0xeb401dc0 0t0 TCP *:domain (LISTEN)
inetd 1133 root 4u IPv4 0xeb401ba0 0t0 TCP *:imap (LISTEN)
inetd 1133 root 5u IPv4 0xeb401980 0t0 TCP *:imaps (LISTEN)
sshd 1138 root 3u IPv4 0xeb401760 0t0 TCP *:ssh (LISTEN)
sendmail 1141 root 4u IPv4 0xeb41b7e0 0t0 TCP *:smtp (LISTEN)
sendmail 1141 root 5u IPv4 0xeb438fa0 0t0 TCP *:submission (LISTEN)

Again, you can change the argument to egrep to display UDP sockets. However, this time use UDP instead of udp4, which makes the argument 'COMMAND|LISTEN|UDP'. As mentioned earlier, not all UDP sockets will necessarily be associated with a daemon process.

Buy the book!If you've enjoyed what you've seen here, or to get more information, click on the "Buy the book!" graphic. Pick up a copy today!

Visit the O'Reilly Network http://www.oreillynet.com for more online content.



 
 
>>> More Security Articles          >>> More By O'Reilly Media
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

SECURITY ARTICLES

- Secure Your Business for Data Privacy Day
- Google Testing Security Fob Password Alterna...
- Security News Highlights Concerns
- Going to Extremes for Data Security
- Skipfish Website Vulnerability Scanner
- Critical Microsoft Visual Studio Security Pa...
- US Faces Tech Security Expert Deficit
- LAN Reconnaissance
- An Epilogue to Cryptography
- A Sequel to Cryptography
- An Introduction to Cryptography
- Security Overview
- Network Security Assessment
- Firewalls
- What’s behind the curtain? Part II

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: