1

Here is the part of my current apache config that refers to cgi-bin stuff. This info was included in the default configuration in debian. Should this be removed on a live/production machine?

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>

3 Answers 3

1

If you're not running any CGI from /usr/lib/cgi-bin/, then it's unnecessary. That said, it's a production machine, so tread carefully.

1

Yes, it should be removed on a production system - unless (of course) you are actually using it. If you're not sure, it probably means that you're not using it.

Here is why: With this configuration, cgi-bin/ points to /usr/lib/cgi-bin and whatever is in there can be executed. It's a system directory, so what's in there usually depends on what you've installed using the system's package management system. Any software with a web interface (like some sort of monitoring or management software) might have a cgi script file there. This means that simply installing such a program is enough so that ANYONE who has access to this web server (in the case of a public web server: everyone) can access that web interface.

Suppose you've just installed some sort of system management software which has a web interface, in the shape of a cgi file in /usr/lib/cgi-bin and it has something like "1234" as default password. To make things worse, this is on a public web server. Now, everyone can open http://www.yourserver.com/cgi-bin/foowebadmin, log in using "1234" and change the system configuration of your PRODUCTION server.

Of course, if you're using this feature on purpose, you will have taken care of proper security/authentication and so on, everything will be fine.

0

Personally I always remove the default vhost that comes with debian from the sites-enabled directory. I also replace the apache.conf with something that is sensible for our environment.

Those a are config files and dpkg (backend to apt-get) should expect them to be changed. Tools like puppet run apt-get in a way that will keep the "old config" in case a package updates it's configuration, and if you run apt-get interactively it will ask you what to do if it detects a change in the configuration files.

That is any change not just a conflict that can't be merged automagically. After all even if it could be merged it could yield some configuration you don't really want in your system.

To break of a flamewar (sorry, that should really be discussed elsewhere but I just need to say it): My opinion is that even upon installing a daemon it must not be started automatically. For any decent site the default config is almost always wrong. (Yes I know that I can set dpkg options so that it won't be started, I'd rather like it to be the default)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .