We've been blind to attacks on our Web sites

As a security manager, I can't afford a false sense of security, so I recently took some steps to find out just what was going on within our Web servers' network traffic

Our Web sites are under attack! And my company's firewall and intrusion-detection systems seem to have been giving a lot of people around here a false sense of security.

Of course, as the security manager, I can't afford a false sense of security, so I recently took some steps to find out just what was going on within our Web servers' network traffic. And it turns out that many attacks have been getting through our firewalls undetected. We'll never know how long this has been going on.

It isn't always easy to know just how effective our security measures are. We are always guessing what threats are facing us and where they're coming from, but we can't always know how accurate those guesses are and what we might be overlooking.

Trouble Ticket

* At issue: Web scraping and other attacks against the company's Web sites have been going on.

* Action plan: Better security measures are needed. And certainly it pays to be informed.

My company's front-end Web servers, which directly receive connections from the Internet through our firewalls, are definitely a hot spot in our network. The firewalls and IDS allow us to see some of what's going on, but can they really detect active content-based attacks? To find out, I installed a Web application firewall in my company's DMZ to tell us about active attacks that may not be identified by our other devices. I set the device up in monitor mode, though it can be set up to block attacks, because my goal was just to see what was going on. I wanted to know more about what's inside the connections to those Web servers.

What I discovered is that our Web sites are being "scraped" by other companies -- our competitors! Some of the information on our sites is valuable intellectual property. It is provided online, in a restricted manner (passwords and such), to our customers. Such restrictions aren't very difficult to overcome for the Web crawlers that our competitors are using, because webmasters usually don't know much about security. They make a token attempt to put passwords and restrictions on sensitive files, but they often don't do a very good job.

What to Do

Evidence in hand, I went to see our CIO. Our legal department is now considering what action to take, although it sounds as if legal action might be deemed too difficult and expensive, given our economic straits. But it is clear that our Web developers need to do a better job of blocking access to sensitive information. We're examining the nature of the problem to determine how things could be done better. Everyone is pulling together to help fix the issue, and that gives me a real sense of satisfaction.

Our Web application firewall found some other problems as well. We experience hundreds of SQL injection attack attempts every day. So far, none has been successful, but I'm amazed at the sheer volume. I can't imagine anyone having the time to sit around trying SQL injection attacks against random Web servers, so I have to assume that these attacks are coming from automated scripts. In any case, they are textbook examples of SQL injection, each one walking through various combinations of SQL code embedded in HTML. It looks like we've done a good job of securing our Web applications against these attacks, but it's always a little disconcerting to hear invaders pounding on the door.

We're also seeing a smattering of other content-based attacks, but none of them appears to be getting through our defenses. Still, it makes me better appreciate the dangers of relying solely on port-based firewall rules that are not application-aware and on signature-based intrusion-detection systems that are blind to certain types of malicious traffic. As my recent exercise has shown, it's hard to defend against problems you don't know about.

This week's journal is written by a real security manager, "J.F. Rice," whose name and employer have been disguised for obvious reasons. Contact him at jf.rice@engineer.com.

Join the newsletter!

Error: Please check your email address.

Tags security

More about etwork

Show Comments