Several months ago, we replaced our aging firewall with a newer, much improved version. Almost everything about the new version was easier to work with, especially the log files. The logs on the old version of the firewall were almost unreadable in their native form. Even when filtered to remove unwanted entries, the old logs were pretty useless in trying to determine whether an attack from the outside was taking place. Thus, we had high hopes for the logging capability of the new firewall.

For the next four months, we went through the logs looking for suspicious activity. Of course, we had to set up new filters for the events, since there were thousands of entries every day. We were able to filter them by info, notes, warning, critical, emergency, and unknown entries. Generally, we set up the filters to exclude info and notes, since it would take us a week to go through a single daily log if we left all of those in.

For the most part, things were pretty uneventful. Every once in a while, a hint of something suspicious would show up, but not much. As a result, we began to get the feeling that all was not right in the way we were reading or filtering the logs.

Enter Snort
That’s when we learned about Snort. Snort is an open source network intrusion detection system (IDS) that it is supported by a loyal band of volunteer programmers. We first read about Snort a couple of years ago in a technical publication, where it was mentioned along with other IDS software. The thing that stood out about Snort was that it was free, compared to the thousands of dollars for the other software packages, and it was recommended as a good way to start learning about IDS.

Originally, Snort was written for the various flavors of Linux/UNIX, but it was eventually ported to Windows as well. There’s even a solid GUI for it now. The latest version can be downloaded from the Snort Web site or from SiliconDefense.com. We used the Windows download from Silicon Defense since the site offered clear instructions on how to get Snort and its various plug-ins installed and working.

The first mistake we made was trying to get it to run on a test Windows XP machine. Even though the documentation says it will work on XP, it didn’t work for us, so we put it on a Windows NT 4.0 test machine, where it installed exactly like the instructions said it would.

The next step was to install it on a firewall-protected laptop that we have hanging on the Internet outside the corporate firewall. We let Snort run all night and then shut it down when we came in the next morning. To our horror, we found it had generated an alert file with over 4,000 entries. As we started to wade through the entries, it seemed that most of them were a false-positive alert for DNS on port 53. As we continued to scan through the entries, we saw a few for oversize ICMP packets but not much else to break the tedium.

This changed when we came to 3:03 A.M. Here, we found a number of entries for some computer on the other side of the country pounding on the firewall looking for Code Red 2 back doors. With that, we jumped over to the firewall and set it up to drop out any traffic from the attacker’s IP address. It was fascinating to look at the logs and watch how the attacker went probing various ports and trying different methods to gain access. As far as we could tell, the firewall rejected them all. Continuing through the logs, we came up with 11 more of the same attacks from the same IP address. We gathered up some evidence and e-mailed it to our ISP to see if it could do anything about it, but we’re not holding our breath on that.

Tweaking the intrusion detection
This first attempt at using Snort was an eye-opener for us. It first showed we were reading the firewall logs incorrectly. The data we were really after was to be found in the info entries, not in any of the others we had been checking. It also showed us that without Snort, looking for suspicious entries in the info logs would have been like trying to find the proverbial needle in a haystack. Without the time stamp/attacker IP address from Snort, the attacks would have been just about impossible to find.

The experience also showed us that there had to be a better way than going through thousands of Snort alerts to find attacks. Our solution was to use SnortSnarf (also from Silicon Defense). SnortSnarf consolidates all the alert entries generated by Snort into an easy-to-read HTML format.

While one of the instructions on the Silicon Defense Web site is for installing Snort and SnortSnarf on Windows NT or 2000 using IIS, we installed it on the laptop mentioned above, which was running Windows 98 and Personal Web Server. It is a CPU-intensive operation for SnortSnarf to compile all the data, and the old laptop drags to a crawl while doing it. However, apart from a few problems using the MS-DOS prompt with some of the very long command-line entries (we solved this by using the Windows Run command instead), everything went as indicated in the instructions. The next day, we had a nice HTML display of all the activity from the night before. While none of the alerts were as intense as the Code Red incident the first night, they were still interesting and gave us a sense of being on top of our network security.

The next step for us will be to tweak the configuration file to eliminate the thousands of false-positive alerts we are getting. We also plan to hook up a Snort monitor inside the firewall to see if it spots anything suspicious. In addition, we are looking into LANguard Security Event Log Monitor (S.E.L.M.) from GFI Software. (Its free LANguard Network Scanner is also a nice tool.) S.E.L.M. is a host-based intrusion detection system (HIDS). HIDS such as S.E.L.M are often used in conjunction with a network IDS (such as Snort) to give a more complete view of the security of a network.

Final analysis
Our journey into intrusion detection has been almost accidental. Like so many businesses, we had not been as diligent as we should have been when it came to security. We pretty much figured that we had a firewall and antivirus apps on our workstations and servers and that was good enough. How wrong we were.

We had been working pretty hard as part of a fast-growing company, and we didn’t think we had time for patches, virus updates, detailed event log reading, and other security-conscious activities. By plain dumb luck, we installed Trend Micro’s ScanMail on our Exchange server just two weeks before Melissa hit. ScanMail turned out to be one of the best investments we have ever made. It has caught thousands of viruses trying to get in via e-mail in its time protecting our network. This experience, along with attending a few seminars and reading numerous IT books and articles, finally pried our eyes open to the extent of the threats against our network, from both inside and outside.

Things have gotten a lot better for us, but we still have a long way to go. The more we learn about security and intrusion detection, the more we still feel wet behind the ears. The scary thing is that we believe we know more than over 70 percent of the general business population, especially small businesses.

We recently delivered a brief security talk at a Chamber of Commerce meeting with information taken from articles, books, seminars, and our own security experiences. When we finished, we were told it was one of the most enlightening talks the Chamber had ever received. Considering we are still neophytes at this security stuff, this was a frightening statement indeed.


Have a comment or a question?

We look forward to getting your input and hearing about your experiences regarding this topic. Post a comment or a question about this article.