Security
  Home arrow Security arrow Page 9 - Unix Host Security: Hacks 1-10
Dev Shed Forums  
Administration  
AJAX  
Apache  
BrainDump  
DHTML  
Flash  
Java  
JavaScript  
Multimedia  
MySQL  
Oracle  
Perl  
PHP  
Practices  
Python  
Reviews  
Security  
Smartphone Development  
Style-Sheets  
Web Services  
XML  
Zend  
Zope  
Mobile Linux  
App Generation ROI  
IBM® developerWorks  
Forums Sitemap  
E-Commerce Hosting  
Linux Web Hosting  
Managed Hosting  
Small Business Hosting  
VPS Hosting  
Weekly Newsletter

 
Developer Updates  
Free Website Content 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us Get Paid  
Request Media Kit
Contact Us  
Site Map  
Privacy Policy  
Support  
 USERNAME
 
 PASSWORD
 
 
  >>> SIGN UP!  
  Lost Password? 
Google.com  
SECURITY

Unix Host Security: Hacks 1-10
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: starstarstarstarstar / 37
    2004-05-04


    Table of Contents:
  • Unix Host Security: Hacks 1-10
  • Secure Mount Points Hack #1
  • Scan for SUID and SGID Programs Hack #2
  • Scan For World- and Group-Writable Directories Hack #3
  • Create Flexible Permissions Hierarchies w/ith POSIX ACLs Hack #4
  • Protect Your Logs from Tampering Hack #5
  • Delegate Administrative Roles Hack #6
  • Automate Cryptographic Signature Verification Hack #7
  • Check for Listening Services Hack #8
  • Prevent Services from Binding to an Interface Hack #9
  • Restrict Services with Sandboxed Environments Hack #10

  • Rate this Article: Poor Best 
      ADD THIS ARTICLE TO:
      error-file:tidyout.log Del.ici.ous error-file:tidyout.log Digg
      error-file:tidyout.log Blink error-file:tidyout.log Simpy
      error-file:tidyout.log Google error-file:tidyout.log Spurl
      error-file:tidyout.log Y! MyWeb error-file:tidyout.log Furl
    Email Me Similar Content When Posted
    Add Developer Shed Article Feed To Your Site
    Email Article To Friend
    Print Version Of Article
    PDF Version Of Article

     
     
    ADVERTISEMENT


    Unix Host Security: Hacks 1-10 - Check for Listening Services Hack #8
    ( Page 9 of 11 )


    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
     

       

    SECURITY ARTICLES

    - 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
    - What’s behind the curtain? Part I
    - Vectors
    - PKI: Looking at the Risks
    - A Quick Look at Cross Site Scripting
    - PKI Architectures: How to Choose One





    © 2003-2009 by Developer Shed. All rights reserved. DS Cluster 6 Hosted by Hostway
    For more Enterprise Application Development news, visit eWeek