2005-07-11
Article continued from Page 1
Your Apache server will need to support SUEXEC, Mod_Perl, and Mod_Userdir. Once you have modified the Apache configuration restart your Apache server. For more details on the IPAudit-Web installation, refer to the INSTALL file located in the installation directory of that package. It contains more information about the required Perl module Time::ParseDate, SUEXEC, and password protecting your IPADUIT-Web installation. Since is requires just moderate Google hacking skills to find other peoples IPAudit installations, protecting IPAudit with a password would be a very good idea.
Step 8 - Check your installation
Open a web browser and go to:
http://<your web server>/~ipaudit/
If your installation was successful you should now see a screen like the one shown below in Figure 1.
Figure 1. Running IPAudit's web interface for the first time.
You should make certain that the time on the server running IPAudit is correct and being kept up to date using NTP. Without accurate time, IPAudit will get confused if the time on the packets differs greatly from that of the system time.
After the first half hour mark, IPAudit will begin to graph all of your traffic and generate some reports. The screen should then look similar to the one in Figure 2.
Figure 2. First graph appears after 30 minutes.
The graphs will get more interesting as time goes on and as IPAudit sees more traffic. A "spike" in the graph typically denotes an indication of a problem, such as a host sending out a DoS (Denial of Service) attack.
General reporting
IPAudit's "Network Reports" are useful for many reasons. The thirty-minute and daily reports are exactly the same, except of course for the timeframe. By clicking on the link labeled "-last-" next to the "30min" link you will see the report for the last 30 minutes. At the top of the screen you can see general network statistics, which is good if you are trying to keep tabs on your total bandwidth utilization. This is followed by the busiest local hosts report, which is good way to keep an eye on who is transferring the most data into or out of your organization, as shown in Figure 3.
Figure 3. Displaying the busiest hosts on the local network.
Your servers, such as SMTP mail servers, will typically be close to the top of this list (in addition to your P2P hosts, if you allow that application). Over time you will develop a baseline of your busiest hosts. When checked everyday, you may notice a new host occupying the top busiest host and this would be cause for you to investigate.
The busiest remote hosts report tells you who on the Internet you are transferring the most data to and from.
Figure 4. Displaying the busiest remote hosts.
Typically these tend to be Akamai caching servers, Windows Update IP addresses, and other popular web sites like Google or Yahoo. If one of the sites listed resolves to something unfamiliar like www.evil.com, it should be cause for alarm.
The next report is the, "Possible Incoming Scan Hosts," which shows the IP addresses of the hosts that connected, or tried to connect, to the most unique IP addresses on the local subnet. This report is useful to see who is scanning your network, and what ports they are scanning for.
Figure 5. Top remote IP addresses scanning your network.
It is good to check this table everyday when monitoring a network. It is useful to take the most common ports that the network is being scanned for and research them. The following web sites are useful when determining what applications correspond to the ports attackers are scanning for:
- SANS - From the main page you will find a port search function. This reads from the Dshield database. This page also offers the most up-to-date information on port-scanning trends and general blackhat activity.
- The official port assignments database.
- Google - When in doubt, use Google to find information about ports, for example "tcp port 6881" to check for known Trojans that frequently use a given port.
Port-scanning activity is sometimes due to a new network scanning tool being released (like scannssh), or a new virus or worm that is being circulated. Having this information, it is good to warn the user population if the threat warrants that level of notification. An administrator can then target his notifications towards specific groups. For example, if the network is being scanned for MySQL instances, you should notify the server group and tell them to make certain they have applied all relevant patches and to not expose their servers to the Internet if it can possibly be helped. Oftentimes, you can correlate vulnerability or exploit releases with the portscanning attacks on your network. While you probably have a firewall that blocks these attempts, what if the firewall becomes mis-configured because of a firewall policy change? These reports allow you to react to threats against your network in an informed manner, adding another layer to your network security infrastructure.
Possible outgoing scan hosts are listed next. While the possible incoming scan hosts can be used for proactive measures, the following outgoing scan hosts report is more useful for reactive measures.
Figure 6. Outgoing scan hosts are useful for discovering Trojaned machines.
If I find hosts that are on the inside of the network scanning outwards, it is usually an indication that a machine has become compromised with a worm or virus, and in some cases an actual attacker has taken control of the host and is using to scan for other machines. When you begin to check the reports on a regular basis you will be able to develop a baseline and know what is normal on your network with regards to the number of hosts contacted in a given day. Some hosts need to contact numerous other unique hosts, such as SMTP relay and DNS servers. However, a typical user's workstation usually does not normally contact upwards of 1,000 different hosts on the Internet.
