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.
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?
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.
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.
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.
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.
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.
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
cronandat. - 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:
-
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
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.
