Four Reasons Why Companies Remain Vulnerable to Cyber Attacks


Over the past year, since the release of our IPS product, we have spent many hours talking to resellers and businesses regarding Internet security. Below are our observations about security investment, and more importantly, non-investment.

1) By far the number one reason why companies are vulnerable is procrastination.

Seeing is believing, and many companies have never been hacked or compromised.

Some clarification here, most attacks do not end in something being destroyed or any obvious trail of data being lifted. This does not mean they do not happen; it’s just that there was no immediate ramification in many cases hence, business as usual.

Companies are run by people, and most people are reactive, and furthermore somewhat single threaded, thus they can only address a few problems at a time. Without a compelling obvious problem, security gets pushed down the list. The exception to the procrastination rule would be verticals such as financial institutions, where security audits are mandatory (more on audits in a bit). Most companies, although aware of  risk factors, are reluctant to spend on a problem that has never happened. In their defense, a company that reacts to all the security FUD, might find itself hamstrung and out of business. Sometimes, to be profitable, you have to live with a little risk.

2) Existing security tools are ignored.

Many security suites are just too broad to be relevant. Information overload can lead to a false sense of coverage.

The best analogy I can give is the Tornado warning system used by the National Weather Service. Their warning system, although well-intended, has been so diffuse in specificity that after a while people ignore the warnings. The same holds true with security tools. In order to impress and out-do one another, security tools have become bloated with quantity, not quality. This overload of data can lead to an overwhelming glut of frivolous information. It would be like a stock analyst predicting every possible outcome and expecting you to invest on that advice. Without a specific, targeted piece of information, your security solution can be a distraction.

3) Security audits are mandated formalities.

In some instances, a security audit is treated as a bureaucratic mandate. When security audits are mandated as a standard, the process of the audit can become the objective. The soldiers carrying out the process will view the completed checklist as the desired result and thus may not actually counter existing threats. It’s not that the audit does not have value, but the audit itself becomes a minimum objective. And most likely the audit is a broad cookie-cutter approach which mostly serves to protect the company or individuals from blame.

4) It may just not be worth the investment.

The cost of getting hacked may be less than the ongoing fees and consumption of time required to maintain a security solution. On a mini-scale, I followed this advice on my home laptop running Windows. It was easier to re-load my system every 6 months when I got a virus rather than mess with all the security virus protection being thrown at me, slowing my system down. The same holds true on a corporate scale. Although nobody would ever come out and admit this publicly, or make it deliberately easy, but it might be more cost-effective to recover from a security breach than to proactively invest in preventing it. What if your customer records get stolen, so what? Consumers are hearing about the largest banks and government security agencies getting hacked every day. If you are a mid-sized business it might be more cost-effective to invest in some damage control after the fact rather than jeopardize cash flow today.

So what is the future for security products? Well, they are not going to go away. They just need to be smarter, more cost-effective, and turn-key, and then perhaps companies will find the benefit-to-risk more acceptable.

<Article Reference:  Security Data overload article >

Web Security Breaches and Accountability


By Zack Sanders – Security Expert – APconnections

If this recent story about a breach of medical information in Utah is any indication of how organizations will now handle security breaches, technology managers everywhere should be shaking in their boots. After a breach that exposed personal information of 780,000 people, the Utah state technology director was relieved of his position by the governor, and several others are under investigation.

Details of the actual attack are scarce, but it appears as though a medicaid server (possibly hosted in the cloud) was vulnerable to a security misconfiguration at the password authentication level. This could mean a few different things – including SQL injection issues, exposed configuration files, or that content was accessible without actually logging in. Regardless of how it really occurred, it certainly could have been prevented with proper proactive assessments.

The larger issue at hand that the article touches on is accountability in data security. Personally, I think you are going to have a hard time finding organizations that will guarantee their solutions are totally secure. It’s just not realistic. You can never be 100% protected against an attack, and because software solutions often rely on other technologies and people, the amount of ways in are many and proving exactly how someone got in and who is to blame will be difficult considering that vulnerabilities are often leveraged against each other. For example, say you have a server that has a third party web application, a back-end database, and blog software installed. The web application itself is secure, but the blog software is not. It is breached by an attacker, and the database for the web application is stolen. User data in the database was not encrypted, and wide-spread fraud occurs. Who is to blame? The blog maker? The web application developer? The system administrator?

In truth, the answer is everyone – to varying degrees. The system administrator should not have these two software packages running on the same system. The blog developers should have built a better solution. The web application programmer should have encrypted data at rest. Blame can even shift further up the chain. The IT director should have budgeted more money for security. The board members should have demanded proactive actions be taken.

So, it is likely the firings in the Utah Medicaid breach were mostly political in that someone has to fall on the sword, but in truth, the blame should fall on many individuals and companies.

One thing is clear, if you are a technology director or manager, you don’t want this to happen to you – but there are actions you can take. The most important thing is to BE PROACTIVE about security. How many breaches do you have to read about every day before you take charge in your own environment. If you’ve never been hacked, ask someone who has. It is a very painful process and costs reputation, money, and time. Start taking steps today to better your chances against attack. Some options to consider:

– Have quarterly security assessments conducted.

– If major changes to the application or server are made, have those changes reviewed for security.

– Discuss your security controls with an expert.

– Audit your existing infrastructure and start making changes now. Even though this will take time and resources, it does not compare to the time and resources required if a breach occurs.

Apconnections Backs up Security Device Support with an unusual offer, “We’ll hack your network”


What gets people excited about purchasing an intrusion detection system? Not much. Certainly, fear can be used to sell security devices. But most, mid sized companies are spread thin with their IT staff, they are focused on running their business operations. To spend money to prevent something that has never happened to them would be seen as somewhat foolish. There are a large number of potential threats to a business, security being just one of them.

One expert pointed out recently:

“Sophisticated fraudsters are becoming the norm with data breaches, carder forums, and do it yourself (DIY) crime kits being marketed via the Internet.” Excerpt from fraudwar blog spot.

Thus, getting data stolen happens so often that it can be considered a survivable event, it is the new normal. Your customers are not going to run for the hills, as they have been conditioned to roll with this threat. But there still is a steep cost for such an event. So our staff put our heads together and asked the question… there must be an easy, quantifiable, minimum investment way to objectively evaluate data risk without a giant cluster of data security devices in place, spewing gobs of meaningless drivel.

One of our internal, white knight, hackers pointed out, that in his storied past, he had been able to break into almost any business at will (good thing he is a white knight and does not steal or damage anything). While talking to some of our channel resellers we have also learned that most companies, although aware of outside intrusion, are reluctant to throw money and resources at a potential problem that they can’t easily quantify.

Thus arose an idea for our new offer. For a small refundable retainer fee, we will attempt to break into a customers data systems from the outside. If we can’t get in, then we’ll return the retainer fee. Obviously, if we get in, we can then propose a solution with indisputable evidence of the vulnerability, and if we don’t get in, then the customer can have some level of assurance that their existing infrastructure thwarted a determined break in.

Case Study: A Successful BotNet-Based Attack


By Zack Sanders – Security Expert – APconnections

In early 2012, I took on a client who was a referral from someone I had worked with when I first got out of school. When the CTO of the company initially called me, they were actually in the process of being attacked at that very moment. I got to work right away using my background as both a web application hacker and as a forensic analyst to try and solve the key questions that we briefly touched on in a blog post just last week. Questions such as:

– What was the nature of the attack?

– What kind of data was it after?

– What processes and files on the machine were malicious and/or which legitimate files were now infected?

– How could we maintain business continuity while at the same time ensuring that the threat was truly gone?

– What sort of security controls should we put in place to make sure an attack doesn’t happen again?

– What should the public and internal responses be?

Background

For the sake of this case study, we’ll call the company HappyFeet Movies – an organization that specializes in online dance tutorials. HappyFeet has three basic websites, all of which help sell and promote their movies. Most of the company’s business occurs in the United States and Europe, with few other international transactions. All of the websites reside on one physical server that is maintained by a hosting company. They are a small to medium-sized business with about 50 employees locally.

Initial Questions

I always start these investigations with two questions:

1) What evidence do you see of an attack? Defacement? Increased traffic? Interesting log entries?

2) What actions have you taken thus far to stop the attack?

Here was HappyFeet’s response to these questions:

1) We are seeing content changes and defacement on the home page and other pages. We are also seeing strange entries in the Apache logs.

2) We have been working with our hosting company to restore to previous backups. However, after each backup, within hours, we are getting hacked again. This has been going on for the last couple of months. The hosting company has removed some malicious files, but we aren’t sure which ones.

Looking For Clues

The first thing I like to do in cases like this is poke around the web server to see what is really going on under the hood. Hosting companies often have management portals or FTP interfaces where you can interact with the web server, but having root access and a shell is extremely important to me. With this privileged account, I can go and look at all the relevant files for evidence that aligns with the observed behavior. Keep in mind, at this point I have not done anything as far as removing the web server from the production environment or shutting it down. I am looking for valuable information that really can only be discovered while the attack is in progress. The fact that the hosting company has restored to backup and removed files irks me, but there is still plenty of evidence available for me to analyze.

Here were some of my findings during this initial assessment – all of them based around one of the three sites:

1) The web root for one of the three sites has a TON of files in it – many of which have strange names and recent modification dates. Files such as:

db_config-1.php

index_t.php

c99.php

2) Many of the directories (even the secure ones) are world writable, with permissions:

drwxrwxrwx

3) There are SQL dumps/backups in the web root that are zipped so when visited by a web browser the user is prompted for a download – yikes!

4) The site uses a content management system (CMS) that was last updated in 2006 and the database setup interface is still enabled and visible at the web root.

5) Directory listings are enabled, allowing a user to see the contents of the directories – making discovery of file names above trivial task.

6) The Apache logs show incessant SQL injection attempts, which when ran, expose usernames and passwords in plain text.

7) The Apache logs also show many entries accessing a strange file called c99.php. It appeared to be some sort of interface that took shell commands as arguments, as is evident in the logs:

66.249.72.41 – – “GET /c99.php?act=ps_aux&d=%2Fvar%2Faccount%2F&pid=24143&sig=9 HTTP/1.1″ 200 286

Nature of the Attack

There were two basic findings that stood out to me most:

1) The c99.php file.

2) The successful SQL injection log entries.

c99.php

I decided to do some research and quickly found out that this is a popular PHP shell file. It was somehow uploaded to the web server and the rest of the mayhem was conducted through this shell script in the browser. But how did it get there?

The oldest log data on the server was December 19, 2011. At the very top of this log file were commands accessing c99.php, so I couldn’t really be sure how it got on there, but I had a couple guesses:

1) The most likely scenario I thought was that the attacker was able to leverage the file upload feature of the dated CMS – either by accessing it without an account, or by brute forcing an administrative account with a weak password.

2) There was no hardware firewall protecting connections to the server, and there were many legacy FTP and SSH accounts festering that hadn’t been properly removed when they were no longer needed. One of these accounts could have been brute forced – more likely an FTP account with limited access; otherwise a shell script wouldn’t really be necessary to interact with the server.

The log entries associated with c99.php were extremely interesting. There would be 50 or so GET requests, which would run commands like:

cd, ps aux, ls -al

Then there would be a POST request, which would either put a new file in the current directory or modify an existing one.

This went on for tens of thousands of lines. The very manual and linear nature of the entries seemed to me very much like an automated process of some type.

SQL Injection

The SQL injection lines of the logs were also very exploratory in nature. There was a long period of information gathering and testing against a few different PHP pages to see how they responded to database code. Once the attacker realized that the site was vulnerable, the onslaught began and eventually they were able to discover the information schema and table names of pertinent databases. From there, it was just a matter of running through the tables one at a time pulling rows of data.

What Was The Attack After?

The motives were pretty clear at this point. The attacker was a) attempting to control the server to use in other attacks or send SPAM, and b) gather whatever sensitive information they could from databases or configuration files before moving on. Exploited user names and passwords could later be used in identity theft, for example. Both of the above motives are very standard for botnet-based attacks. It should be noted that the attacker was not specifically after HappyFeet – in fact they probably knew nothing about them – they just used automated probing to look for red flags and when they returned positive results,  assimilated the server into their network.

Let the Cleanup Begin

Now that the scope of the attack was more fully understood, it was time to start cleaning up the server. When I am conducting this phase of the project, I NEVER delete anything, no matter how obviously malicious or how benign. Instead, I quarantine it outside of the web root, where I will later archive and remove it for backup storage.

Find all the shell files

The first thing I did was attempt to locate all of the shell files that might have been uploaded by c99.php. Because my primary theory was that the shell file was uploaded through a file upload feature in the web site, I checked those directories first. Right away I saw a file that didn’t match the naming convention of the other files. First of all, the directory was called “pdfs” and this file had an extension of PHP. It was also called broxn.php, whereas the regular files had longer names with camel-case that made sense to HappyFeet. I visited this file in the web browser and saw a GUI-like shell interface. I checked the logs for usage of this file, but there were none. Perhaps this file was just an intermediary to get c99.php to the web root. I used a basic find command to pull a list of all PHP files from the web root forward. Obviously this was a huge list, but it was pretty easy to run through quickly because of the naming differences in the files. I only had to investigate ten or so files manually.

I found three other shell files in addition to broxn.php. I looked for evidence of these in the logs, found none, and quarantined them.

What files were uploaded or which ones changed?

Because of the insane amount of GET requests served by c99.php, I thought it was safe to assume that every file on the server was compromised. It wasn’t worth going through the logs manually on this point. The attacker had access to the server long enough that this assumption is the only safe one. The less frequent occurrences of POST requests were much more more manageable. I did a grep through the Apache logs for POST requests submitted by c99.php and came up with a list of about 200 files. My thought was that these files were all either new or modified and could potentially be malicious. I began the somewhat pain-staking process of manually reviewing these files. Some had been overwritten back to their original state by the hosting company’s backup, but some were still malicious and in place. I noted these files, quarantined them, and retested website functionality.

Handling the SQL injection vulnerabilities

The dated CMS used by this site was riddled with SQL injection vulnerabilities. So much so, that my primary recommendation for handling it was building a brand new site. That process, however, takes time, and we needed a temporary solution. I used the log data that I had to figure out which pages the botnet was primarily targeting with SQL attacks. I manually modified the PHP code to do basic sanitizing on all inputs in these pages. This immediately thwarted SQL attacks going forward, but the damage had already been done. The big question here was how to handle the fact that all usernames and passwords were compromised.

Improving Security

Now that I felt the server was sufficiently cleaned, it was time to beef up the security controls to prevent future attacks. Here are some of the primary tasks I did to accomplish this:

1) Added a hardware firewall for SSH and FTP connections.

I worked with the hosting company to put this appliance in front of the web server. Now, only specific IPs could connect to the web server via SSH and FTP.

2) Audited and recreated all accounts.

I changed the passwords of all administrative accounts on the server and in the CMS, and regenerated database passwords.

3) Put IP restrictions on the administrative console of the CMS.

Now, only certain IP addresses could access the administrative portal.

4) Removed all files related to install and database setup for the CMS.

These files were no long necessary and only presented a security vulnerability.

5) Removed all zip files from the web root forward and disabled directory listings.

These files were readily available for download and exposed all sorts of sensitive information. I also disabled directory listings, which is helpful in preventing successful information gathering.

6) Hashed customer passwords for all three sites.

Now, the passwords for user accounts were not stored in plain text in the database.

7) Added file integrity monitoring to the web server.

Whenever a file changes, I am notified via email. This greatly helps reduce the scope of an attack should it breach all of these controls.

8) Wrote a custom script that blocks IP addresses that put malicious content in the URL.

This helps prevent information gathering or further vulnerability probing. The actions this script takes operate like a miniature NetGladiator.

9) Installed anti-virus software on the web server.

10) Removed world-writable permissions from every directory and adjusted ownership accordingly.

No directory should ever be world writable – doing so is usually just a lazy way of avoiding proper ownership. The world writable aspect of this server allowed the attack to be way more broad than it had to be.

11) Developed an incident response plan.

I worked with the hosting company and HappyFeet to develop an internal incident response policy in case something happens in the future.

Public Response

Due to the fact that all usernames and passwords were compromised, I urged HappyFeet to communicate the breach to their customers. They did so, and later received feedback from users who had experienced identity theft. This can be a tough step to take from a business point of view, but transparency is always the best policy.

Ongoing Monitoring

It is not enough to implement the above controls, set it, and forget it. There must be ongoing tweaking and monitoring to ensure a strong security profile. For HappyFeet, I set up a yearly monitoring package that includes:

– Manual and automated log monitoring.

– Server vulnerability scans once a quarter, and web application scans once every six months.

– Manual user history review.

– Manual anti-virus scans and results review.

Web Application Firewalls

I experimented with two types of web application firewalls for HappyFeet. Both of which took me down the road of broken functionality and over-robustness. One had to be completely uninstalled, and the other is in monitoring mode because protection mode disallowed legitimate requests. It also is alerting to probing attempts about 5,000 times per day – most of which are not real attacks – and the alert volume is unmanageable. Its only value is in generating data for improving my custom script that is blocking IPs based on basic malicious attempts.

This is a great example of how NetGladiator can provide a lot of value to the right environment. They don’t need an intense, enterprise-level intrusion prevention system – they just need to block the basics and not break functionality in their web sites. The custom script, much like NetGladiator, suits their needs to a T and can also be configured to reflect previous attacks and vulnerabilities I found in their site that are too vast to manually patch.

Lessons Learned

Here are some key take-aways from the above project:

– Being PROACTIVE is so much better than being REACTIVE when it comes to web security. If you are not sure where you stack up, have an expert take a look.

– Always keep software and web servers up to date. New security vulnerabilities arrive on the scene daily, and it’s extremely likely that old software is vulnerable. Often, security holes are even published for an attacker to research. It’s just a matter of finding out which version you have and testing the security flaw.

– Layered security is king. The security controls mentioned above prove just how powerful layering can be. They are working together in harmony to protect an extremely vulnerable application effectively.

If you have any questions on NetGladiator, web security, or the above case study, feel free to contact us any time! We are here to help, and don’t want you to ever experience an attack similar to the one above.

What to Do If Your Organization Has Been Hacked


By Zack Sanders – Security Expert – APconnections

It’s a scary scenario that every business fears; a successful attack on your web site that results in stolen information or embarrassing defacement.

From huge corporations, to mom-and-pop online shops, data security is (or should be) a keystone consideration. As we’ve written about before, no one is immune to attack – not even local businesses with small online footprints. I, personally, have worked with many clients whom you would not think would be targeted by hackers, and they end up being the victims of reasonably intricate and damaging attacks that cost many thousands of dollars to mitigate.

Because no set of security controls or solutions can make you truly safe from exploitation, it is important to have a plan in place in case you do get hacked. Having a documented plan ready BEFORE an attack occurs allows you to be calm and rational with your response. Below are some basic steps you should consider in an incident response plan and/or follow in case a breach occurs.

1) Stay calm.

An attack, especially one in progress, naturally causes panic. While understandable, these feelings will only cause you to make mistakes in handling the breach. Stay calm and stick to your plan.

2) DO NOT unplug the system.

Unplugging the affected system, deleting malicious files, or restoring to a backup are all panic-driven responses to a security incident. When you take measures such as these, you potentially destroy key evidence in determining what, if anything, was taken, how it was taken, and when. Leave the system in place and call an expert as soon as possible.

3) Call an expert.

There are many companies that specialize in post-breach analysis, and it is important to contact these folks right away. They can help determine how the breach occurred, what was taken, and when. They can also help implement controls and improve security so that the same attack does not happen again. If you’ve been hacked, this is the most important step to take.

4) Keep a record.

For possible eventual legal action and to simply keep track of system changes, always keep a record of what has happened to the infected system – who has touched it, when, etc.

5) Determine the scope of the attack, stop the bleeding, and figure out what was taken.

The expert you phoned in will analyze the affected system and follow the steps above. Once the scope is understood, the system will be taken offline and the security hole that caused the problem will be discovered and closed. After that, the information that was compromised will be reviewed. This step will help determine how to proceed next.

6) Figure out who to tell.

Once you’ve determined what kind of information was compromised, it is very important to communicate that to the right people. If it was internal documents, you probably don’t need to make that public. If it was usernames and passwords, you must let your users know.

7) Have a security assessment performed and improve security controls.

Have your expert analyze the rest of your infrastructure and web applications for security holes that could be a problem in the future. After this occurs, the expert can recommend tools that will vastly improve your security layering.

Of course, many of these tasks can be performed proactively to greatly reduce the likelihood of ever needing this process. Contact an expert now and have them analyze your systems for security vulnerabilities.

Do We Really Need SSL?


By Art Reisman, CTO, www.netequalizer.com, www.netgladiator.net.

Art Reisman CTO www.netequalizer.com

I know that perception is reality, and sometimes it is best to accept it, but when it comes to security, FUD, I get riled up.

For example, last year I wrote about the un-needed investment surrounding the IPV4 demise, and, as predicted, the IPv6 push turned out to be mostly vendor hype motivated by a desire to increase equipment sales. Today, I am here to dispel the misplaced fear around the concept of having your data stolen in transit over the Internet. I am referring to the wire between your residence and the merchant site at the other end. This does  not encompass the security of data once it is stored on disk drive at its final location, just the transit portion.

To get warmed up, let me throw out some analogies.

Do you fear getting carjacked going 75 mph on the interstate?

Most likely not, but I bet you do lock your doors when stopped.

Do you worry about encrypting your cell phone conversations?

Not unless you are on security detail in the military.

As with my examples, somebody stealing your credit card while it is in transit, although possible, is highly impractical; there are just better ways to steal your data.

It’s not that I am against VPN’s and SSL, I do agree there is a risk in transport of data. The problem I have is that the relative risk is so much lower than some other glaring security holes that companies ignore because they are either unaware, or more into perception than protecting data. And yet, customers will hand them financial data as long as their web site portal provides SSL encryption.

To give you some more perspective on the relative risk, let’s examine the task of stealing customer information in transit over the Internet.

Suppose for a moment that I am a hacker. Perhaps I am in it for thrills or for illegal financial gain, either way, I am going to be pragmatic with my approach and maximize my chances of finding a gold nugget.

So how would I go about stealing a credit card number in transit?

Option 1: Let’s suppose I parked in the alley behind your house and had a device sophisticated enough to eaves drop your wireless router and display all the web sites you visited. So now what? I just wait there, and hope perhaps in a few days or weeks you’ll make an online purchase and I’ll grab your cc information, and then I’ll run off and make a few purchases.  This may sound possible, and it is, but the effort and exposure would not be practical.

Option 2: If I landed a job at an ISP, I could hook up a sniffer that eaves drops on every conversation between the ISP customers and the rest of the Internet. I suppose this is a bit more likely than option 1;  but there is just no precedent for it – and ISPs often have internal safeguards to monitor and protect against this. I’d still need very specialized equipment and time to work unnoticed to pull this off. I’d have to limit my thefts to the occasional hit and run so as not to attract suspicion. The chances of economic benefit are slim, and the chances of getting caught are high, and thus the risk to the customer is very low.

For the criminal intent on stealing data, trolling the internet with a bot looking for unsecured servers, or working for a financial company where the data resides, and stealing thousands of credit cards is far more likely. SSL does nothing to prevent the real threats, and that is why you hear about hacking intrusions in the headlines everyday. Many of these break-ins could be prevented, but it takes a layered approach, not just a feel good SSL layer that we could do without.

Common NetGladiator Questions Explained


Since our last security-related blog post, The Truth About Web Security (And How to Protect Your Data), we’ve received many inquiries related to NetGladiator and best-practice security in general. In the various email and phone conversations thus far, we’ve encountered some recurring questions that many of you might also find useful. The purpose of this post is to provide answers to those questions.

1) Could an attacker circumvent NetGladiator by slowly probing the targets as not to be detected by the time anomaly metrics?

The NetGladiator detects multiple types of anomalies. Some are time-frequency based, and some are pattern based.

For instance, a normal user won’t be hitting 500 pages/minute, and a normal user will never be putting SQL in the URL attempting an injection. If a malicious user was slowly running a probing robot, it would likely still be attempting patterns that the NetGladiator would detect, and the NetGladiator would immediately block that IP. There are directory brute force tools that won’t hit on any patterns, but they will hit on the time frequency settings. If the attacker were to slow it down to a normal user click-rate, it’s possible they could go undetected, but these brute force lists rely on trying millions of common page and directory names quickly. It would not be worth it to run through this list at that pace.

2) Could a hacker change their IP address often enough so that NetGladiator would not think the source of the attack was the same?

The amount of IP addresses you’d need to spoof would make this a tiresome effort for the attacker, and in an automated attack by a botnet, the probe is more likely to just move on to a new target. In a targeted attack, IP spoofing, while possible, would also likely be more of a hassle than it’s worth. But, even if it were worth it for the attacker, the NetGladiator alerts admins to intrusion attempts, so you can proactively deal with the threat. You can also block by IP Range/Country so that if you notice someone spoofing IP addresses from a specific IP range, you can drop all those connections for as long as you like.

Also with regard to IP addresses, the NetGladiator only bans them for a set amount of time. This is because bots probe from new IP addresses all the time. A real user might eventually end up with that IP and you wouldn’t want to block it forever. That being said, if there was a constantly malicious IP, you can permanently block it.

3) Why is there a maximum number of patterns you can input into NetGladiator?

One of NetGladiator’s key differentiating factors is its “robustlessness” and its custom configuration. This may sound like a detriment, but it actually will make you better off. Not only will you be able to exclusively detect threats pertinent to your web application, you also will not break functionality – regardless of poor programming or setup on the back end. Many intrusion prevention systems are so robust in their blocking of requests that there are too many false positives to deal with (usually based on programming “errors” or infrastructure abnormalities). This often ends with the IPS being disabled – which helps no one. NetGladiator has a maximum number of patterns for one main reason:

Speed and efficiency.

We don’t want to hamper your web connections by inspecting packets for too many regular expressions. We’d rather quickly check for key patterns that show malicious intent under the assumption that those patterns will be tried eventually by an attacker. This way, data can seamlessly pass through, and your users won’t incur performance problems.

4) What kind of environments benefit from NetGladiator?

NetGladiator was built to protect web applications from botnets and hackers – it won’t have much use for you at the network level or the user level (email, SPAM, anti-virus, etc.). There are other options for security controls that focus on these areas. Every few years, the Open Web Application Security Project (OWASP), releases their Top 10 – which is a list of the most common web application security vulnerabilities facing sites today. NetGladiator helps protect against issues of this type, so any web application that has even a small amount of interactivity or backend to it will benefit from NetGladiator’s features.

We want to hear from you!

Have some questions about NetGladiator or web security in general? Visit our website, leave a comment, or shoot us an email at ips@apconnections.net.

%d bloggers like this: