IBM Systems Administration Toolkit: Network scanning

출처: http://www.ibm.com/developerworks/aix/library/au-satnetworkscan/



Summary
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.


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

• Use an RSS feed to request notification for the upcoming articles in this series. (Find out more about RSS feeds of developerWorks content.)
  
  
• System Administration Toolkit: Check out other parts in this series.
  
  
• "System Administration Toolkit: Standardizing your UNIX command-line tools" (Martin Brown, developerWorks, May 2006): Read this article to learn how to use the same command across multiple machines.
  
  
• "System Administration Toolkit: Time and event management" (Martin Brown, developerWorks, May 2006): This article covers the creation and organization of time scripts using cron and at.
  
  
• For an article series that teaches you how to program in bash, see:
  • "Bash by example, Part 1: Fundamental programming in the Bourne again shell (bash)" (Daniel Robbins, developerWorks, March 2000)
  • "Bash by example, Part 2: More bash programming fundamentals" (Daniel Robbins, developerWorks, April 2000)
  • "Bash by example, Part 3: Exploring the ebuild system" (Daniel Robbins, developerWorks, May 2000)
  
  
• "Making UNIX and Linux work together" (Martin Brown, developerWorks, April 2006): Use this article as a guide to getting traditional UNIX distributions and Linux working together.
  
  
• IBM® Redbooks® : Different systems use different tools, and Solaris to Linux Migration: A Guide for System Administrators helps you identify some key tools.
  
  
• " Exploring the Linux memory model" (Vikram Shukla, developerWorks, January 2006): This article helps you understand how Linux uses memory, swap space, and exchanges pages and processes between the two.
  
  
• Popular content: See what AIX and UNIX content your peers find interesting.
  
  
• Check out other articles and tutorials written by Martin Brown:
  • Across developerWorks and IBM
  
  
• AIX and UNIX: The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
  
  
• New to AIX and UNIX?: Visit the "New to AIX and UNIX" page to learn more about AIX and UNIX.
  
  
• AIX Wiki: A collaborative environment for technical information related to AIX.
  
  
• Search the AIX and UNIX library by topic:
  • System administration
  • Application development
  • Performance
  • Porting
  • Security
  • Tips
  • Tools and utilities
  • Java™ technology
  • Linux
  • Open source
  
  
• Safari bookstore: Visit this e-reference library to find specific technical resources.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  
• Podcasts: Tune in and catch up with IBM technical experts.
  
  

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

• Participate in the developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in the AIX and UNIX forums:
  • AIX —technical forum
  • AIX 6 Open Beta
  • AIX for Developers Forum
  • Cluster Systems Management
  • IBM Support Assistant
  • Performance Tools—technical
  • Virtualization—technical
  • More AIX and UNIX forums
  
  

About the author

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.