3:37 PM -- Remember when IT security was like a piece of candy -- a hard, crunchy shell and a soft, chewy center? It used to be that security was all about protecting the perimeter -- usually with firewall rules that only allow inbound traffic to the VPN, Web, and mail servers. There might be a few exceptions for other services, but that was pretty much it. The crown jewels were kept tucked safely away, usually without any external access.

Today, however, many applications are becoming Web-based and information-rich, which means those Web application servers need access to the database servers that used to be hidden from outside eyes. Sure, the application server can be segregated into a DMZ, with strict firewall rules that define which inbound ports can talk to it and which ports it can use to talk to the internal database server. But is that enough?

If you have any experience with the Web security "weapons" I've featured in previous blog entries, then you know it isn't. Even if you don't understand those tools, just take a look at the huge uptick of Web application vulnerabilities that are currently on Dark Reading or Bugtraq. Right now, three quarters of the messages on the first page of Bugtraq's vulnerability archive are Web-related.

Recently, while hanging out with some students from a SANS class that is being taught locally by a friend of mine, we began a discussion of how to detect different Web attacks. Surprisingly, no one piped up with "stop them before they occur with proper input validation and sanitization." The consensus was logs, logs, and more logs. Logs from the Web server. Logs from the application. Heck, log all network traffic if you can, just so you can have better context for what you see in the logs.

About eight months ago, I investigated a case for a friend where one of his developers had noticed a strange table in a PostgreSQL database. He and his team had looked through all of the PostgreSQL logs without finding the source of the problem.

I asked for the logs for both the database and the Apache server. Within about three minutes, I emailed him the entries from the Apache log showing the attack. Because they didn't understand quite how SQL injection works, my friend and his team didn't realize they needed to be looking in the Web server logs, also.

Do your in-house developers -- or the developers of the commercial Web applications you use -- create detailed logs, both for access and errors? If not, you should work with them to get that logging process going. Once it is, though, you must (note that I said "must" and not "should") review them for anomalies that may indicate an attack. Remember, many developers have not been trained in secure coding practices. They may think their code is impenetrable, but the logs will keep them honest.

Log all of the traffic sourced and destined to both your Web and database servers, too. Sure, it seems like it might be a hassle, but I guarantee that you'll be thankful you did when you have to investigate later. If you're familiar with network security monitoring (NSM) as evangelized by Richard Beijtlich and practiced by sguil, then you understand why this is important. If it's a new concept, check out Richard's book and blog.

Now, go forth, log, review -- and be happy.

– John H. Sawyer is a security geek on the IT Security Team at the University of Florida. He enjoys taking long war walks on the beach and riding pwnies. When he's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading