Systems Administration Toolkit: Network scanning

Discover how to scan your network for services and how to regularly monitor your services to keep uptimes to a maximum. A key way of ensuring the security of your network is to know what is on your network and what services individual machines are at risk of exposure. Unauthorized services, such as Web servers or file sharing solutions, not only degrade performance, but others can use these services as routes into your network. In this article, learn how to use these same techniques to ensure that genuine services remain available.

Martin Brown (mc@mcslp.com), Freelance Writer, Consultant

Martin Brown has been a professional writer for more than seven years. He is the author of numerous books and articles across a range of topics. His expertise spans myriad development languages and platforms—Perl, Python, Java™, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows®, Solaris, Linux, BeOS, Mac OS X and more—as well as Web programming, systems management, and integration. He is a Subject Matter Expert (SME) for Microsoft® and regular contributor to ServerWatch.com, LinuxToday.com, and IBM developerWorks. He is also a regular blogger at Computerworld, The Apple Blog, and other sites. You can contact him through his Web site.



04 December 2007

Also available in Chinese Russian

About this series

The typical UNIX® administrator has a key range of utilities, tricks, and systems he or she uses regularly to aid in the process of administration. There are key utilities, command-line chains, and scripts that are used to simplify different processes. Some of these tools come with the operating system, but a majority of the tricks come through years of experience and a desire to ease the system administrator's life. The focus of this series is on getting the most from the available tools across a range of different UNIX environments, including methods of simplifying administration in a heterogeneous environment.

Types of network scanning

Scanning your network enables you to build a quick picture of exactly what is going on, configuration options, and what is available on your network. Different network scans look for and record different information. And you can also employ them in different ways to determine various types of information about your network.

One of the key elements of any network environment is to be able to identify what is on your network. Network hacks, unauthorized equipment, and bad or misconfigured hosts can all lead to potential problems on your network.

The first type of network scanning you should use is one that finds and locates the Internet Protocol (IP) addresses in use on the network. Since an IP address is comparatively useless without also having the network port on which you communicate (for example, the ports that Hypertext Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP) protocols use), you must find out which of these ports others actively listened to for connections.

The other type of scanning involves actually looking at the information contained within the raw packets that go past on your network. Raw network scanning provides a wealth of information, such as understanding the precise nature of exchanged information over the network and the performance of the network as a whole.

By combining the information you know about hosts and ports on the network with the information you gain from the raw network scanning, you can get a much better understanding of what is actually going on within the network.

For example, during a network scan, you might find that a particular host is listening on a non-standard port, but it can be difficult to determine the use of the host and port without raw network scanning to understand what type of date and information.

Is someone using the host and port for a genuine purpose, such as HTTP, or is it something more subversive, such as a network hack, an open SSH, or other port that one can use for a security breach?

Scanning for hosts

Determining what hosts exist on your network is the most basic of network scanning tasks, and it can be the greatest way of understanding what is going on within your network. The information on its own can be useful, but it can be even more beneficial to combine the information that you have determined and discovered with the information that you should technically already know—that is, the list of hosts configured on your network and their IP address.

When scanning for network IPs, there are a few things that you should keep in mind:

  • You can change the IP addresses and, if you use Dynamic Host Configuration Protocol (DHCP) on your network, then the list of IP addresses currently in use is probably incomplete.
  • A single scan is unlikely to tell you everything you need to know. When scanning for IP addresses, you can only identify the IP address of a host that is on and running an operating system. Systems that are off or asleep do not show up. Therefore, you often need multiple scans to be able to identify all the hosts on the network that you know are valid.
  • The fact that you can find a host indicates that it is configured on your network, but it doesn't tell you if it is authorized. You need to compare the information with data that you know to ensure that the host is valid on your network.

The nmap tool provides the ability to scan for hosts across your network. It also identifies which hosts are accessible, their IP and MAC addresses, and scans and checks the open ports, protocols used, and the host operating system.

To perform a basic ping test and identify all of the hosts configured on the network, use the -sP command-line option and provide the IP address specification that you want to scan. The IP address specification supports a number of different formats, including the IP address and netmask, network specification, and even IP address ranges.

For example, to scan all of the hosts in the 192.168.0.0 network, you could use Listing 1.

Listing 1. Scanning all the hosts in the 192.168.0.0 network
$ nmap -sP 192.168.0.0/24

Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-14 19:15 GMT
Host gendarme.mcslp.pri (192.168.0.1) appears to be up.
MAC Address: 00:0F:B5:30:42:60 (Netgear)
Host 192.168.0.31 appears to be up.
MAC Address: 00:02:11:90:15:31 (Nature Worldwide Technology)
Host 192.168.0.50 appears to be up.
MAC Address: 00:61:CA:28:0C:23 (Unknown)
Host 192.168.0.66 appears to be up.
MAC Address: 00:08:7B:05:D1:52 (RTX Telecom A/S)
Host 192.168.0.68 appears to be up.
MAC Address: 00:18:4D:59:AB:B5 (Netgear)
Host 192.168.0.101 appears to be up.
MAC Address: 00:16:CB:A0:3B:CB (Apple Computer)
Host 192.168.0.103 appears to be up.
MAC Address: 00:0D:93:4E:61:2A (Apple Computer)
Host nautilus.mcslp.pri (192.168.0.108) appears to be up.
MAC Address: 00:16:CB:8F:04:0B (Apple Computer)
Host narcissus.mcslp.pri (192.168.0.110) appears to be up.
MAC Address: 00:16:CB:85:2D:15 (Apple Computer)
Host airong.wireless.mcslp.pri (192.168.0.210) appears to be up.
MAC Address: 00:0F:B5:0D:82:FC (Netgear)
Host gentoo2.vm.mcslp.pri (192.168.0.230) appears to be up.
Nmap finished: 256 IP addresses (11 hosts up) scanned in 20.758 seconds

The output gives you a very clear list of the hosts discovered, the IP and MAC addresses registered, and a brief determination of the probable host provider. Since individual manufacturers are given blocks of MAC addresses, you can obtain this information.

What this information doesn't tell you is what ports these hosts are potentially listening for connections on. Listening ports can tell you what sort of traffic the host is using and, if the host is not one you are aware of, what that host might be doing so that you can identify it.

Scanning for ports

When a machine is running a particular service, for example, a Web server, e-mail server, or peer-to-peer service, the machine must listen on a specific port. Some of these ports are well-known (for example, port 80 is used for HTTP). You can do a port scan on all hosts that you check or just an individual host.

For example, if you perform a port scan on a single host, then you can get a very good idea of what the machine is doing. You can see here in Listing 2 when you scan the ports for a server.

Listing 2. Scanning the ports for a server
$ nmap -sT narcissus

Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-14 19:45 GMT
Interesting ports on narcissus.mcslp.pri (192.168.0.110):
Not shown: 1674 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
25/tcp   open  smtp
53/tcp   open  domain
80/tcp   open  http
106/tcp  open  pop3pw
110/tcp  open  pop3
111/tcp  open  rpcbind
143/tcp  open  imap
311/tcp  open  asip-webadmin
389/tcp  open  ldap
427/tcp  open  svrloc
443/tcp  open  https
548/tcp  open  afpovertcp
625/tcp  open  unknown
749/tcp  open  kerberos-adm
1011/tcp open  unknown
1014/tcp open  unknown
1015/tcp open  unknown
2049/tcp open  nfs
3306/tcp open  mysql
3689/tcp open  rendezvous
5900/tcp open  vnc
MAC Address: 00:16:CB:85:2D:15 (Apple Computer)

Nmap finished: 1 IP address (1 host up) scanned in 22.399 seconds

The scan output only shows the active Transmission Control Protocol (TCP) and IP ports. If you also want to scan the User Datagram Protocol (UDP) ports, you must specify the -sU options, as shown here in Listing 3.

Listing 3. Specifying the -sU options
$ nmap -sU -sT narcissus

Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-14 20:05 GMT
Interesting ports on narcissus.mcslp.pri (192.168.0.110):
Not shown: 3150 closed ports
PORT     STATE         SERVICE
21/tcp   open          ftp
22/tcp   open          ssh
25/tcp   open          smtp
53/tcp   open          domain
80/tcp   open          http
106/tcp  open          pop3pw
110/tcp  open          pop3
111/tcp  open          rpcbind
143/tcp  open          imap
311/tcp  open          asip-webadmin
389/tcp  open          ldap
427/tcp  open          svrloc
443/tcp  open          https
548/tcp  open          afpovertcp
625/tcp  open          unknown
749/tcp  open          kerberos-adm
1011/tcp open          unknown
1014/tcp open          unknown
1015/tcp open          unknown
2049/tcp open          nfs
3306/tcp open          mysql
3689/tcp open          rendezvous
5900/tcp open          vnc
53/udp   open|filtered domain
67/udp   open|filtered dhcps
88/udp   open|filtered kerberos-sec
111/udp  open|filtered rpcbind
123/udp  open|filtered ntp
427/udp  open|filtered svrloc
464/udp  open          kpasswd5
989/udp  open|filtered unknown
990/udp  open|filtered unknown
1008/udp open|filtered ufsd
1021/udp open|filtered unknown
5353/udp open|filtered zeroconf
MAC Address: 00:16:CB:85:2D:15 (Apple Computer)

Nmap finished: 1 IP address (1 host up) scanned in 78.605 seconds

You can repeat this process across all the hosts in your network.

Recording the information

As described earlier, a single pass of either the host or port scanning information is only useful for the instant in time when the scan was executed. Hosts might be down, services might be temporarily unavailable and, in a very busy network, the scanning packets simply might not have gone through.

You should be running the scan regularly and then comparing (and even combining) the output from multiple executions. The easiest way to do this is to run nmap, record the output, and then use a tool like diff to compare the output and report the changes.

You can see an example of this in Listing 4, where you are comparing the output of two executions of nmap on the same host.

Listing 4. Comparing the output of two executions of nmap on the same host
$ diff narcissus.20070526 narcissus.20070924
26c26
< 2049/tcp open     nfs
---
> 3306/tcp open     mysql
27a28
> 5900/tcp open     vnc

Lines begin with a '<' or '>', according to which file the line is different. In this case, you can see that the Network File System (NFS) protocol is in the first file but not the second, while both the mysql and vnc ports have been open during the latter scan.

Scanning raw packets

The nmap tool is great for finding IP hosts and open hosts; however, nmap doesn't tell you the content of the actual traffic running over the network. Capturing raw packets enables you to see which hosts are communicating with a given host, what information is being exchanged, and which are being used.

You can get the raw packet information and find out what information is being transferred with the right settings (for example, which users are logging in to a particular mail server from which host). You can even use it to identify the type of exchanged traffic on an otherwise unidentified port.

If you want to scan the raw data information that goes past on the network, you need to use a tool other than nmap, which only scans, hosts, and ports. There are many different tools available, including tools that come with different operating systems and third-party solutions. See the Resources section for some examples.

On AIX®, you can use the iptrace tool to scan the network. On Solaris, the snoop tool performs a similar purpose, while third-party tools like Ethereal also provide the scanning ability.

Each tool uses the same premise. For example, with the Ethernet, network standard packets are echoed to all physical ports and, by scanning all the packets that go past on the network, you can examine the content. With Ethernet switches, packets are not echoed to all ports, but many modern switches provide a management port where the information is echoed. Even on switched networks, you can gain some valuable information by running the packet-scanning tool on the host you want to investigate.

The methods for using these tools and the information they can provide differ slightly, but the fundamentals are the same. With AIX, the iptrace is a background daemon, so you must explicitly start and stop the tool to switch the process on and off. For example, to start, type:

# startsrc -s iptrace -a "-i tr0 /home/user/iptrace/log1"

To stop, type:

# stopsrc -s iptrace

On Solaris, the snoop tool is an application that you can execute at will:

# snoop

Because the quantity of information passing by on the network can be considerable, you can select to only obtain a limited set of information by limiting the host, ports, or protocols that you want to scan. For example, to only examine the exchanged data to or from a particular host, try:

# snoop narcissus

Furthermore, because most display devices are unable to keep up with the display of the raw data information, it is best to export the information directly to a file:

# snoop -o /tmp/netdata narcissus.mcslp.pri

To read back the information from the file, use the -i command-line option to specify the input source:

# snoop -v -i /tmp/netdata

In the above example, verbose mode has also been switched—this ensures that the full contents of the raw packets are recorded, instead of just the summary information that snoop provides by default.

When you examine the raw data, snoop automatically formats and parses the content of the packet for you, even down to the individual protocol level. For example, Listing 5 shows the output during an NFS data exchange.

Listing 5. Output during an NFS data exchange
ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 31 arrived at 10:00:2.70371
ETHER:  Packet size = 174 bytes
ETHER:  Destination = 0:2:11:90:15:31, 
ETHER:  Source      = 0:16:cb:85:2d:15, 
ETHER:  Ethertype = 0800 (IP)
ETHER:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:         .... ..0. = not ECN capable transport
IP:         .... ...0 = no ECN congestion experienced
IP:   Total length = 160 bytes
IP:   Identification = 14053
IP:   Flags = 0x4
IP:         .1.. .... = do not fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 64 seconds/hops
IP:   Protocol = 6 (TCP)
IP:   Header checksum = 8195
IP:   Source address = 192.168.0.110, narcissus.mcslp.pri
IP:   Destination address = 192.168.0.31, ultra3
IP:   No options
IP:   
TCP:  ----- TCP Header -----
TCP:  
TCP:  Source port = 2049
TCP:  Destination port = 1022 (Sun RPC)
TCP:  Sequence number = 1812746020
TCP:  Acknowledgement number = 1237063652
TCP:  Data offset = 20 bytes
TCP:  Flags = 0x18
TCP:        0... .... = No ECN congestion window reduced
TCP:        .0.. .... = No ECN echo
TCP:        ..0. .... = No urgent pointer
TCP:        ...1 .... = Acknowledgement
TCP:        .... 1... = Push
TCP:        .... .0.. = No reset
TCP:        .... ..0. = No Syn
TCP:        .... ...0 = No Fin
TCP:  Window = 65535
TCP:  Checksum = 0x48da
TCP:  Urgent pointer = 0
TCP:  No options
TCP:  
RPC:  ----- SUN RPC Header -----
RPC:  
RPC:  Record Mark: last fragment, length = 116
RPC:  Transaction id = 2490902676
RPC:  Type = 1 (Reply)
RPC:  This is a reply to frame 29
RPC:  Status = 0 (Accepted)
RPC:  Verifier   : Flavor = 0 (None), len = 0 bytes
RPC:  Accept status = 0 (Success)
RPC:  
NFS:  ----- Sun NFS -----
NFS:  
NFS:  Proc = 3 (Look up file name)
NFS:  Status = 2 (No such file or directory)
NFS:  Post-operation attributes: (directory)
NFS:    File type = 2 (Directory)
NFS:    Mode = 0770
NFS:     Setuid = 0, Setgid = 0, Sticky = 0
NFS:     Owner's permissions = rwx
NFS:     Group's permissions = rwx
NFS:     Other's permissions = ---
NFS:    Link count = 13, User ID = 1025, Group ID = 1026
NFS:    File size = 442, Used = 4096
NFS:    Special: Major = 0, Minor = 0
NFS:    File system id = 234881046, File id = 22
NFS:    Last access time      = 14-Oct-07 16:45:50.000000000 GMT
NFS:    Modification time     = 11-Oct-07 12:48:53.000000000 GMT
NFS:    Attribute change time = 11-Oct-07 12:48:53.000000000 GMT
NFS:  
NFS:

Each line is prefixed with the protocol level within the packet that was scanned. In this case, you can see the raw Ethernet, IP, and TCP packet data, including the source and destination host information and packet options.

At the Remote Procedure Call (RPC) level, you get the record information for the NFS request, and then at the NFS file, you get the actual data that was exchanged. In this case, you are looking at the examination of a file (during a directory listing, most likely), and you can see the file's type, permissions, and modification time information as well.

Listing 6 shows the output during a Domain Name Server (DNS) lookup for a hostname.

Listing 6. Output during a DNS lookup for a hostname
ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 2 arrived at 10:05:19.05284
ETHER:  Packet size = 155 bytes
ETHER:  Destination = 0:2:11:90:15:31, 
ETHER:  Source      = 0:16:cb:85:2d:15, 
ETHER:  Ethertype = 0800 (IP)
ETHER:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:         .... ..0. = not ECN capable transport
IP:         .... ...0 = no ECN congestion experienced
IP:   Total length = 141 bytes
IP:   Identification = 53767
IP:   Flags = 0x0
IP:         .0.. .... = may fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 64 seconds/hops
IP:   Protocol = 17 (UDP)
IP:   Header checksum = 267b
IP:   Source address = 192.168.0.110, narcissus.mcslp.pri
IP:   Destination address = 192.168.0.31, ultra3
IP:   No options
IP:   
UDP:  ----- UDP Header -----
UDP:  
UDP:  Source port = 53
UDP:  Destination port = 46232 
UDP:  Length = 121 
UDP:  Checksum = 0C31 
UDP:  
DNS:  ----- DNS Header -----
DNS:  
DNS:  Response ID = 55625
DNS:  AA (Authoritative Answer) RA (Recursion Available) 
DNS:  Response Code: 0 (OK)
DNS:  Reply to 1 question(s)
DNS:      Domain Name: www.mcslp.pri.
DNS:      Class: 1 (Internet)
DNS:      Type:  28 (IPv6 Address)
DNS:  
DNS:  2 answer(s)
DNS:      Domain Name: www.mcslp.pri.
DNS:      Class: 1 (Internet)
DNS:      Type:  5 (Canonical Name)
DNS:      TTL (Time To Live): 86400
DNS:      Canonical Name: narcissus.mcslp.pri.
DNS:  
DNS:      Domain Name: narcissus.mcslp.pri.
DNS:      Class: 1 (Internet)
DNS:      Type:  28 (IPv6 Address)
DNS:      TTL (Time To Live): 86400
DNS:      IPv6 Address: fe80::216:cbff:fe85:2d15
DNS:  
DNS:  1 name server resource(s)
DNS:      Domain Name: mcslp.pri.
DNS:      Class: 1 (Internet)
DNS:      Type:  2 (Authoritative Name Server)
DNS:      TTL (Time To Live): 86400
DNS:      Authoritative Name Server: narcissus.mcslp.pri.
DNS:  
DNS:  1 additional record(s)
DNS:      Domain Name: narcissus.mcslp.pri.
DNS:      Class: 1 (Internet)
DNS:      Type:  1 (Address)
DNS:      TTL (Time To Live): 86400
DNS:      Address: 192.168.0.110
DNS:

You can see in this example that snoop has decoded the contents of the DNS protocol to show the raw data returned by the lookup.

In Listing 7, you can see the packets transferred when accessing a Web site; in this case, it is the header information returned by the Web site but, by looking at other packets, you can also see the original request information and even the data returned.

Listing 7. Packets transferred when accessing a Web site
ETHER:  ----- Ether Header -----
ETHER:  
ETHER:  Packet 10 arrived at 10:05:19.05636
ETHER:  Packet size = 563 bytes
ETHER:  Destination = 0:2:11:90:15:31, 
ETHER:  Source      = 0:16:cb:85:2d:15, 
ETHER:  Ethertype = 0800 (IP)
ETHER:  
IP:   ----- IP Header -----
IP:   
IP:   Version = 4
IP:   Header length = 20 bytes
IP:   Type of service = 0x00
IP:         xxx. .... = 0 (precedence)
IP:         ...0 .... = normal delay
IP:         .... 0... = normal throughput
IP:         .... .0.. = normal reliability
IP:         .... ..0. = not ECN capable transport
IP:         .... ...0 = no ECN congestion experienced
IP:   Total length = 549 bytes
IP:   Identification = 53771
IP:   Flags = 0x4
IP:         .1.. .... = do not fragment
IP:         ..0. .... = last fragment
IP:   Fragment offset = 0 bytes
IP:   Time to live = 64 seconds/hops
IP:   Protocol = 6 (TCP)
IP:   Header checksum = e4e9
IP:   Source address = 192.168.0.110, narcissus.mcslp.pri
IP:   Destination address = 192.168.0.31, ultra3
IP:   No options
IP:   
TCP:  ----- TCP Header -----
TCP:  
TCP:  Source port = 80
TCP:  Destination port = 48591 
TCP:  Sequence number = 150680669
TCP:  Acknowledgement number = 1315156336
TCP:  Data offset = 20 bytes
TCP:  Flags = 0x18
TCP:        0... .... = No ECN congestion window reduced
TCP:        .0.. .... = No ECN echo
TCP:        ..0. .... = No urgent pointer
TCP:        ...1 .... = Acknowledgement
TCP:        .... 1... = Push
TCP:        .... .0.. = No reset
TCP:        .... ..0. = No Syn
TCP:        .... ...0 = No Fin
TCP:  Window = 65535
TCP:  Checksum = 0x7ca4
TCP:  Urgent pointer = 0
TCP:  No options
TCP:  
HTTP: ----- HyperText Transfer Protocol -----
HTTP: 
HTTP: HTTP/1.1 200 OK
HTTP: Date: Mon, 15 Oct 2007 09:05:02 GMT
HTTP: Server: Apache/2.2.4 (Unix) DAV/2 PHP/5.2.1 SVN/1.4.3 mod_ssl/2.2.4 
                     OpenSSL/0.9.7l mod_auth_tkt/2.0.0rc2 mod_fastcgi/2.4.2
HTTP: Accept-Ranges: bytes
HTTP: Connection: close
HTTP: [...]
HTTP:

Remember that the information exchanged is encrypted (for example, the Secure Sockets Layer (SSL) protocol used with HTTP and other protocols) so that the system cannot decrypt the data.

Summary

Knowing what is on your network and what exchanged information is on your network can go a long way to resolving a number of issues, including potential security issues and network performance problems.

In this article, you've examined methods for scanning your network to find hosts and open ports and how to record and compare that information over time. As you've seen though, network scanning can only do so much. For real detail, you need to examine the content of the exchanged packets. You also learned that a variety of tools are available for the different platforms to get detailed information about the exchanged data.

Using these tools collectively is a good habit to get into, as it ensures that you know what is on your network and what it is doing, and it helps you to isolate problems and potentially malicious or unauthorized hosts and practices.

Resources

Learn

Get products and technologies

  • Ethereal: This tool scans a network and provides raw output of the packets that have been exchanged.
  • nmap: This tool scans network hosts and ports and provides you information about potential unauthorized hosts and services.
  • IBM trial software: Build your next development project with software for download directly from developerWorks.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=272806
ArticleTitle=Systems Administration Toolkit: Network scanning
publish-date=12042007