On Tue, 2013-05-07 at 00:52 +0800, Thomas Goirand wrote: > If the default config isn't hardened enough, fix the default config. > Adding a supplementary step to start the service doesn't fix the > problem anyway. I don't think this is only a question of hardened enough of not... simply supplying a service even if fully secure, may cause troubles if it starts out with defaults. So I agree with Vincent here... In my opinion, most of these servers are always potentially dangerous both, for the user himself as for the rest of the internet... of course one can never prevent people from doing stupid things, but ideally responsible admins should have the chance to first configure, then start. On Mon, 2013-05-06 at 17:22 +0200, Marco d'Itri wrote: > > The usually come only with a default config which may not be > > hardened enough for the local system, and that short time may > > already be enough for an attacker to attack. >  I think, security wise this ("show me a hole or nothing will happen") is the wrong approach. There are so many weird ideas to exploit things, and the policy should rather be lock as much as possible, even if it seems to be safe, in order to prevent those attacks one cannot think of. Remember that issue with PHP/Apache and open server-status pages? That's kind of an example for that. Why running something per default that may be attackable? If the admin really needs or misses it, he will take care to set it up. Cheers, Chris.
Description: S/MIME cryptographic signature