Linux – Preventing an Apache 2 Server from Logging Sensitive Data

apache-2.2linuxSecurity

Apache 2 by default logs the entire request URI including query string of every request.

What is a straight forward way to prevent an Apache 2 web server from logging sensitive data, for example passwords, credit card numbers, etc., but still log the rest of the request?

I would like to log all log-in attempts including the attempted username as Apache does by default, and prevent Apache from logging the password directly.

I have looked through the Apache 2 documentation and there doesn't appear to be an easy way to do this other than completely preventing logging of these requests (using SetEnvIf).

How can I accomplish this?

Best Answer

Apache 2 by default logs the entire request URI including query string of every request.

What is a straight forward way to prevent an Apache 2 web server from logging sensitive data, for example passwords, credit card numbers, etc., but still log the rest of the request?

Am I reading right, that you are sending sensitive information in URI as QueryString ? I would suggest changing the application so it does do so in the first place.

Then, there would be no requirement to change apache, since, it does not do any such thing by default.

Related Solutions

Ssl – Apache SSL Log Incomplete SSL Handshake

SSL connections have extra options for CustomLog but they're not going to break down the step-by-step connection status. You'll probably want to try LogLevel debug, but that will get you plenty of extra junk to wade through.

Honestly, a better idea for this class would be to demonstrate using the openssl s_server command, since it can be configured to show the step-by-step progress of the SSL state machine, you'll be able to see exactly at what step the client dropped the connection.

Something like

openssl s_server -key [somekey.pem] -cert [somecert.pem] -accept 443 -state -www

When someone connects it'll print off the steps of the connection:

SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data

the -www option makes it print some information when someone actually connects to it with a webbrowser. If the user navigates away without accepting the fake cert, then I'm guessing the connection will be broken somewhere in the middle there.

You can use the openssl s_client command in a similar fashion, though I'm not certain how flexible it is about accepting or not accepting invalid certificates.

Security – Our security auditor is an idiot. How to give him the information he wants

First, DON'T capitulate. He is not only an idiot but DANGEROUSLY wrong. In fact, releasing this information would violate the PCI standard (which is what I'm assuming the audit is for since it's a payment processor) along with every other standard out there and just plain common sense. It would also expose your company to all sorts of liabilities.

The next thing I would do is send an email to your boss saying he needs to get corporate counsel involved to determine the legal exposure the company would be facing by proceeding with this action.

This last bit is up to you, but I would contact VISA with this information and get his PCI auditor status pulled.

Best Answer

Related Solutions

Ssl – Apache SSL Log Incomplete SSL Handshake

Security – Our security auditor is an idiot. How to give him the information he wants

Related Topic