DigitalOcean Kubernetes: new control plane is faster and free, enable HA for 99.95% uptime SLA

Question

Is it risky to post your apache site.conf files

  • Posted October 21, 2014

Occasionally on the forums people post their site.conf files. or I have asked people to post it to troubleshoot problems

I am wondering if there is security risks doing that. I cannot think of anything someone could take advantage of with that info.

Does anyone know if there is information in a typical site.conf file that could be exploited?

Subscribe
Share
Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Andrew SB • October 21, 2014

There’s very little sensitive information that could be exposed in an Apache site.conf. Some things like knowing that AllowOverride All is set on a directory could in theory provide an attacker something to probe, though following other best practices would thwart that. The attacker would already need write access to that directory to create an .htaccess file. Another theoretical piece of information that could be gleaned is whether SSL3 is enabled or not to take advantage of the “POODLE” vulnerability, though that is usally configured in /etc/apache2/mods-available/ssl.conf

If you follow general security best practices and apply security updates in a timely manner, sharing your Apache configuration won’t be a problem at all.

JonsJava • October 21, 2014

Not that I can think of. I even have a tool to automate the creation of those files for anybody.

http://YOUR_DOMAIN_OR_SUBDOMAIN.c.jonsjava.com (centos/rhel/fedora) http://YOUR_DOMAIN_OR_SUBDOMAIN.u.jonsjava.com (ubuntu/debian)

unless yours is highly configured (and thereby falling outside the “typical” part you spoke of), there’s nothing damaging in those.

One caveat: if you have a poorly performing or badly-coded server-side script, they can use it to simplify directory traversal after finding an XSS entrypoint, but that’s after it’s been hacked, so it’s still trivial.