Seven Things to Look for When Choosing an Intrusion Prevention System

The following list was submitted by the APconnections technical staff.

APconnections is a company that specializes in turn-key bandwidth control and intrusion prevention system (IPS) products.

1) Don’t degrade your network speed. Make sure your IPS system is not going to slow down your network. If you have a T1 or smaller sized network, chances are just about any tool you choose will not slow down your connection; however with links approaching 10 megabits and higher,  it is worth investing in a tool whose throughput speeds can be quantified. Higher speeds generally will require a tool specifically designed and tested as an IPS device and rated for your link speed. Problems can arise if you buy a software add-on module for your web server. A stand-alone physical device specifically designed to prevent intrusion is likely your best option. A good IPS system is very CPU intensive, and lower-end routers, switches, and heavily utilized web servers generally do not have the extra CPU cycles to support an IPS system. For example, IT managers are aware that large web server sites must use multiple servers to handle large volumes of HTTPS pages, which are also CPU intensive.  The same metrics will apply to an IPS system on a smaller scale,  so make sure you are not underpowered.

2) Watch out for high license fees. Try to get a tool with a one-time cost and a small licensing fee. Many vendors sell their equipment below cost with the hopes of getting a monthly fee on per seat license. Yes, you should expect to pay a yearly support fee, but it should be a small fraction of the tool’s original cost.

3) More features is not necessarily better when it comes stopping intrusion from hackers.  You may not realize that large, robust “all-in-one” IPS solutions can be rendered useless by alerting you thousands of times a day, as you will ignore their alerts at that volume.  They can also block legitimate requests (“false positives”), and can break web
functionality. They can also block legitimate requests (“false positives”), and can break web functionality.

You should consider solutions that are not as fully-featured but are targeted to your security concerns, so that you receive meaningful alerts on real potential intrusion attempts.  More features can just introduce clutter, where you are not able to sift through your alerts to find what you really care about.  Also, doing everything can dilute the mission of the toolset, so instead of doing one thing well, it does everything poorly.

Remember, the biggest threat to your enterprise is a person that breaks into your internal systems and attains access to your customer data.  A typical PC virus or Denial of Service (DoS) attack does not pose this type of threat.  Although it may be counter-intuitive to your experience, it is a good idea to make sure you have a solid intrusion detection system before investing in things like virus prevention, web-filters and reporting.  Yes, viruses are a pain and can bring down systems, but the damage will likely not compare in real cost to a hacker that steals your customer records.

4) Block first ask questions later.  An intruder usually behaves oddly when compared to a normal visitor. Your intrusion detection device should block first and ask questions later. It is better to accidentally block a small number of friendlies than to let one hacker into your network. You will get feedback if legitimate visitors are locked out from your website, and it won’t take long to hear from them if your intrusion device is accidentally blocking a friendly visitor.

5) Don’t rely on manpower for detection. Let the device do the work. If you are relying on a reporting system and a human to make a final decision on what to block, you will get hacked. Your device must be automated and on the job 24/7. There is nothing wrong with an analyst doing the follow-up.

6) Use a white knight to expose your security risks. There was an article in the Wall Street Journal today on how anybody can hire a professional hacker. What they failed to mention is that you can also hire a white knight to test your armor and let you know if you have any weaknesses. Most weaknesses are common back doors in web servers that can easily be remedied once exposed by a white knight.

7) Use a combination of techniques. The only way to 100 percent secure your enterprise is to block all outside access, and with the silo mentality of a some security zealots you could end up with this TSA mentality solution if not careful. Given the reality that you must have a public portal for your customers, the next best thing to locking them out is a combination of white knight testing, plugging holes in web servers and entry points and a permanent watch dog intrusion prevention system – this should keep you safe from a hacker.

Some good intrusion prevention links:



NetGladiator  (our product)

Solera Networks


Confessions of a Hacker

By Zack Sanders, NetEqualizer Guest Columnist

It’s almost three in the morning. Brian and I have been at it for almost sixteen hours. We’ve been trying to do one seemingly simple task for a while now: execute a command that lists files in a directory. Normally this would be trivial, but the circumstances are a bit different. We have just gotten into EZTrader’s blog and are trying to print a list of files in an unpublished blog post. Accomplishing this would prove that we could run any command we wanted to on the Web server, but it’s not working.

There must be something wrong with the syntax – there always is, right? We have to write the command into an ASP user control file, upload it via the attachment feature in the blog engine, and then reference it in a blog post. It’s ugly, but we are so close to piecing it all together.

I think it’s time for another cup of coffee.

EZTrader is a fictitious online stock trading company. Their front end is relatively basic, but their backend is complex. It allows users to manage their entire portfolio and has access to personal information and other types of sensitive data.

EZTrader came to us with an already strong security profile, but wanted to really put their site through the ringer by having us conduct an actual attack. They run automated scans regularly, have clean, secure code for their backend infrastructure with great SEO, and validate every request both on the client side and the server side. It really was impressive.

In the initial meeting with EZTrader, we were given a login and password for a generic user account so that we could test the authenticated portion of the site. We focused a lot of time and energy there because it is where the highest level of security is needed.

After days of trying to exploit this section of the website with no results, frustration was growing in each of us. Surely there must be some vulnerability to find, some place where they failed to properly secure the data.


So what do you do when the front door is locked? Try a window.

We started looking around for possible attack vectors outside of the authenticated area. That’s when we came across the blog. Nobody writes a custom blog engine anymore. They use WordPress or some other open-source blog software. It’s almost always the right choice. These platforms have large communities of developers and testers that look for security holes and patch existing ones right away.

If you stay diligent on keeping your software up to date, you can’t go wrong with choosing an open-source blog platform. Problems arise when keeping this software current falls too low on the priority list. The primary reason this is so dangerous is that all of the bugs and security holes from your dated version are published for the world to see. That was precisely the case with EZTrader. They had an old version of OpenBlogger running on their website. We had finally found a chink in the armor.

We ran a few brute-force password crackers against the blog login form but they weren’t succeeding – access denied. Hmm, maybe it’s simpler.

Let’s do a quick Google search: “OpenBlogger default username and password.”

I’m feeling lucky.

The result: “Administrator/password.” This never seems to work, but it’s worth a shot…“Welcome back Administrator!” Wow. Now we are getting somewhere!

Many of the published vulnerabilities for open-source blog platforms reside in authenticated portions of the blog engine. Logging in with the default credentials was a major step, and now all we have to do is look for security weaknesses associated with that version. Back to Google.

“OpenBlogger 3.5.1 vulnerabilities.” Interesting.

What we find is that you can write code in the blog post itself and have it access any file on the system – even if it is outside of the Web root. This was billed as a “feature” of OpenBlogger. Haha, okay, thanks!

We already knew that the file upload feature of the blog puts files outside the Web root (we had tried accessing an uploaded file directly through the Web browser earlier, but that wasn’t possible due to this segregation). The key was to upload our custom code and reference it through code in the blog post. Once we figured out the path to the uploaded file, we just had to call that path in the blog post and our code would run. Our uploaded file had a simple job. If executed, it would run the “dir” command on the C:\ drive and print out the contents of the directory in a blog post. If we got this to work, the server was ours.

Maybe it’s the coffee, but suddenly I don’t feel so tired. I think we finally have the syntax right. Time to see if this dog will hunt.

Boom! There it is. The entire contents of the C:\ drive. If we can run the “dir” command, what else can we run? Let’s try to FTP one file off of their Web server to our Web server.

Okay, that worked. Let’s now try the entire C:\ drive.

That worked, too.

We now have the source code and supporting files for the entire Web server. This is where a molehill becomes a mountain. First, let’s upload a file that will give me persistent shell access to the drive so we can remove our shady looking blog post and poke around at will. Let’s also upload a file that will send me a text message when an administrator logs into the Web server. At that time, we’ll steal the authentication token and try it on other hosts connected to the network. Maybe it will work on the database server. While we are waiting for the administrator to log in, we’ll review all of our newly acquired source code for security holes that might have eluded us before.

The possibilities from here are endless. We could completely ruin EZTrader’s reputation by destroying their front page, their backend code, or their blog. We could upload more backdoors for access and sell them on the black market. We could sell their source code to E-Trade. We could compromise their other servers that are attached to that subnet.

We could run them out of business.

But luckily, our hats are white. When the CEO sees our report, she is astounded but relieved that we found these issues before the bad guys exploited them.

There are a few lessons that come out of an assessment like this:

It is important to be diligent with security EVERYWHERE. EZTrader’s great infrastructure was rendered obsolete because of one tiny oversight.
Security should exist in layers, and monitoring is crucial. Even if we were able to access the blog, some other process should have thwarted our advances. McAfee or Tripwire should have prevented us from uploading executables or FTPing files off of the server.

In short, security for an online business is paramount. Unlike a breach in the physical world, customers have little tolerance for digital break-ins. Reputation is everything.

In the end, EZTrader’s proactive decisions may have saved their company. It is much easier to prevent an attack than to deal with one after the fact. The cleanup can be messy and expensive. It is increasingly important for all executives and IT personnel to have this mindset, and putting public facing sites to tests like this can be the difference between prosperity and peril.

About the Author(s)

Zack Sanders and Brian Sax are Web Application Security Specialists with Fiddler on the Root (FOTR). FOTR provides web application security expertise to any business with an online presence. They specialize in ethical hacking and penetration testing as a service to expose potential vulnerabilities in web applications. The primary difference between the services FOTR offers and those of other firms is that they treat your website like an ACTUAL attacker would. They use a combination of hacking tools and savvy know-how to try and exploit your environment. Most security companies  just run automated scans and deliver the results. FOTR is for executives that care about REAL security.

%d bloggers like this: