[...] >> Additionally, if you bind any further vhosts to specific IP addresses, e.g. >> <VirtualHost 192.0.2.1:80>, then that virtualhost will have precedence for >> requests to 192.0.2.1:80 over the *:80 virtualhost. > > In this case you'll have create separate default deny configuration for each > IP address, right? > >> Overall, I'd say that such a construct is more likely to increase the attack surface >> instead of reducing it. > > I don't think _denying_ something can _increase_ attack surface. However, in this example, you'd add a virtualhost that may expose globally configured resources without the individual access controls of the "real" vhosts. On top of that, the additional vhost may not see any significant testing in case of configuration changes. > But since > there's seemingly demand for this kind of configuration it'd be nice if > community helped make it better and more secure. What extra steps do you > think one should take to securely deny (and subsequently ban) clients > (mostly bots) that do not even know domain name they are accessing? Do _exactly_ that, e.g. with a RewriteRule to - and RewriteCond that checks the Host: header. I'd guess that httpd 2.4 has more elegant means to express this with actual "deny" directives, possibly combined with a SetEnvIf. If you're really serious, you'd also have to make sure that any error messages don't contain the hostname, and you'd have to set reverse DNS lookups to point to a useless name. Overall I'd say that the negligible gain in perceived security isn't worth the effort or the additional risks (both regarding security and availability). rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|