[3amOpsGuy]

>> Configuring a server correctly is both 1) hard and 2) critical.

It's not hard, you won't get breathless! ;-)

By the configuration stage, the mental tax can often be as low as checking off items on a checklist.

It is a whole different skill set though and it's trickier in some ways e.g. a developer can often depend on his compiler to tell him if he's messed up the basics.

You could go-live with a host having most attack surfaces battened down tighter than a crab's harris at 50 fathoms, but because nothing told you about DNS tunnelling... (feel free to insert A.N. other rarely talked about but trivial attack)

>> Are directories only writeable by the web server user?

The web server user shouldn't be able to write anywhere except perhaps an upload directory inside its chroot. At no point should it be serving files from that dir (a common mistake).

With tools like SELinux around you can often help cover yourself from midnight mistakes down the line.

A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php scripts.

>> Is PHP installed on your Python server?

Another common one is GCC installed. Often when building perl / python / ruby / nodejs modules or whatever, these will be built on the prod server in small shops. That often means a full compiler suite laying around.

[jamessocol]

>> Are directories only writeable by the web server user?

NB: The next point is "Do all of them even need to be? Are you sure?"

> A blisteringly common one not mentioned is database authentication details inside .pl, .py or .php scripts.

I am not sure that's so obvious. Most web servers will serve a .ini or .yml file as plain text, if it's in the wrong spot. On the other hand, a PHP file like https://gist.github.com/3177788, even if it's in the web directory, can't leak the data without some other compromise--and the type of compromise required would generally give you access to any of the values in the .ini file, anyway.

But, see also #5: "Are your firewall rules restrictive enough?" If I can even connect, let alone authenticate, to your database from the web, you have bigger problems.

GCC is an excellent point, though.

[3amOpsGuy]

I get the impression you're thinking "secure" is a boolean, if anything it's a floating point. By that I mean "is it secure?" could be viewed as a naive question, a better question could be "how secure is it?".

>> NB: The next point is

Yes but I didn't want to write a counter point to each point. I'd taken the view from the listing of possible problems presented that the basics weren't being considered. It reads as a list of random points in a large space rather than a comprehensive listing.

To give a specific example, the article talks about writable concerns when really we want to be ensuring readable gets the same treatment.

>> even if it's in the web directory, can't leak the data without some other compromise

Or a config error (a botched upgrade disabling mod_php could do the trick, or more obscurely a content negotiation oversight), or a leaked backup (another common one - storing random backups under www root)... There's more than one way to skin a cat as they say.

>> If I can even connect

You're often better to view security as something you provide in layers. I wouldn't expect to be able to hit port 3306 from here, but if you're not expecting me to ever be inside your network, then priviledge escalation is going to be fairly quick for me once i surprise you by getting in.