4 ms·

so, what you're saying here is that if you skip the ease and convenience of .htaccess files, you can get better performance? as in, if you get slasdotted (ha!

by m3mnoch 13y ago

so, what you're saying here is that if you skip the ease and convenience of .htaccess files, you can get better performance? as in, if you get slasdotted (ha! i'm old!) your site will stay up either way as long as you're getting less than 215 rps. and it goes down either way if you're getting more than 245 rps. that's a pretty tiny window in the grand scheme of things. yeah... i'd rather my personal site be easier to maintain. and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure. just sayin'.

laumars 13y ago
> as in, if you get slasdotted (ha! i'm old!) your site will stay up either way as long as you're getting less than 215 rps. and it goes down either way if you're getting more than 245 rps. that's a pretty tiny window in the grand scheme of things. 12% performance boost is actually quite a significant jump when you're pushing heavy traffic and looking to shave any fat from the stack you can find. Also your comment about "and it goes down either way if you're getting more than 245 rps" doesn't really make a whole lot of sense as the webfarm isn't going to magically crash the moment you get one request more. I suspect you're not really understanding what those ab results are representing, but that doesn't really matter as I wouldn't trust those figures for any real world usage anyway. As I pointed out in another post in this thread, the actual performance penalty will be subject to a considerable number variables. > and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure. You have things completely backwards there. httpd.conf is more secure than .htaccess because httpd.conf can only be amended and actioned by root where as .htaccess will have lower security permissions and is loaded on demand (ie an attacker doesn't need to restart the Apache daemon to action any changes).
- m3mnoch 13y ago
  > I suspect you're not really understanding what those ab results are representing ah. no, no. i'm not adequately explaining where i was going with that. lemme try again. 1) it's not 12% on a web farm. it's 12% on one server. 2) that 12% manifests in a slowly degrading experience. so, it takes 4 seconds to return during peak traffic instead of 3 and a half. meh. whatever. therefore, if you get hit by something that will actually make a difference, it's not going to be within 12%. it's going to be like 12,000%. so, it's not going to make a whit of difference at that point whether you have httpd.conf or .htaccess. >You have things completely backwards there again, i'm not explaining myself well. i fully understand that, in theory, httpd.conf is more secure. i'm not talking about that. if you have access to httpd.conf, you also probably have access to /etc/ssh/sshd_config -- did you configure that securely? does your server allow root logins? what about your mysql config? what about the latest security update to the distro? i'm just saying, if you've got access to httpd.conf, you've got the whole server. that means you've probably got bigger fish to fry as to worrying about security than a pretty harmless, defaulted as secure, .htaccess file.
  - laumars 13y ago
    > 1) it's not 12% on a web farm. it's 12% on one server. Same difference. 12% on 1 server is 12%. But if you have a dozen servers with the same 12% gain then it's still 12%. Such is the nature of percentages. > therefore, if you get hit by something that will actually make a difference, it's not going to be within 12%. it's going to be like 12,000%. so, it's not going to make a whit of difference at that point whether you have httpd.conf or .htaccess. I manage a data centre for a number of high profile sites. If I can improve throughput by 12% then that means I need one less server in the farm. It means less strain on the db as connections are clearing down quicker. And it also means the likelihood of visitors hitting 'refresh' due to slow load times is reduced, which in turns slows the exponential growth that happens shortly before a site buckles. So trust me when I say 12% does matter if you're building busy sites - I know this because I wouldn't be doing my day job properly if I didn't load test this stuff and implement any free optimisations I can. > i'm just saying, if you've got access to httpd.conf, you've got the whole server. that means you've probably got bigger fish to fry as to worrying about security than a pretty harmless, defaulted as secure, .htaccess file. Yes, I'd already said the former point myself, however your latter point is still ignoring the simple fact that you don't need to be root to edit a .htaccess file. I repeat, you do /NOT/ need to be root to edit a .htaccess file! Someone can edit your .htaccess file even when they don't have permissions to edit httpd.conf (and thus ssh_config nor anything else in /etc nor other root-owned config hierarchies). Thus if your http docs are writeable (and they typically are for personally web servers as you don't have a dedicated network storage such as a SAN shared across your web servers, so your content is stored on the web server itself) then a bug in your website could allow an attacker access to write to the disk in the web docs directory. In short, attackers could create and edit their own .htaccess files. We're not talking about root access here, these are not attacks that have permissions to write to httpd.conf; we're talking about a http-owned (eg 'www-data' on Debian) users who shouldn't have ability to write files having that ability to edit the Apache config because .htaccess is not typically root owned. If you want the convenience of a .htaccess file but the security of a httpd.conf, then change all your .htaccess files to be root owned: sudo find / -name ".htaccess" -exec chown root:root {} \; -exec chmod 644 {} \; -print

by m3mnoch 13y ago

laumars 13y ago

> as in, if you get slasdotted (ha! i'm old!) your site will stay up either way as long as you're getting less than 215 rps. and it goes down either way if you're getting more than 245 rps. that's a pretty tiny window in the grand scheme of things. 12% performance boost is actually quite a significant jump when you're pushing heavy traffic and looking to shave any fat from the stack you can find. Also your comment about "and it goes down either way if you're getting more than 245 rps" doesn't really make a whole lot of sense as the webfarm isn't going to magically crash the moment you get one request more. I suspect you're not really understanding what those ab results are representing, but that doesn't really matter as I wouldn't trust those figures for any real world usage anyway. As I pointed out in another post in this thread, the actual performance penalty will be subject to a considerable number variables. > and, as to the security of it -- if you have access to the httpd.conf file, i GUARANTEE you've got bigger holes in your own hodge-podge, whole-system security than something like an .htaccess file on which you'd have to work really hard and explicitly make insecure. You have things completely backwards there. httpd.conf is more secure than .htaccess because httpd.conf can only be amended and actioned by root where as .htaccess will have lower security permissions and is loaded on demand (ie an attacker doesn't need to restart the Apache daemon to action any changes).

m3mnoch 13y ago
> I suspect you're not really understanding what those ab results are representing ah. no, no. i'm not adequately explaining where i was going with that. lemme try again. 1) it's not 12% on a web farm. it's 12% on one server. 2) that 12% manifests in a slowly degrading experience. so, it takes 4 seconds to return during peak traffic instead of 3 and a half. meh. whatever. therefore, if you get hit by something that will actually make a difference, it's not going to be within 12%. it's going to be like 12,000%. so, it's not going to make a whit of difference at that point whether you have httpd.conf or .htaccess. >You have things completely backwards there again, i'm not explaining myself well. i fully understand that, in theory, httpd.conf is more secure. i'm not talking about that. if you have access to httpd.conf, you also probably have access to /etc/ssh/sshd_config -- did you configure that securely? does your server allow root logins? what about your mysql config? what about the latest security update to the distro? i'm just saying, if you've got access to httpd.conf, you've got the whole server. that means you've probably got bigger fish to fry as to worrying about security than a pretty harmless, defaulted as secure, .htaccess file.
- laumars 13y ago
  > 1) it's not 12% on a web farm. it's 12% on one server. Same difference. 12% on 1 server is 12%. But if you have a dozen servers with the same 12% gain then it's still 12%. Such is the nature of percentages. > therefore, if you get hit by something that will actually make a difference, it's not going to be within 12%. it's going to be like 12,000%. so, it's not going to make a whit of difference at that point whether you have httpd.conf or .htaccess. I manage a data centre for a number of high profile sites. If I can improve throughput by 12% then that means I need one less server in the farm. It means less strain on the db as connections are clearing down quicker. And it also means the likelihood of visitors hitting 'refresh' due to slow load times is reduced, which in turns slows the exponential growth that happens shortly before a site buckles. So trust me when I say 12% does matter if you're building busy sites - I know this because I wouldn't be doing my day job properly if I didn't load test this stuff and implement any free optimisations I can. > i'm just saying, if you've got access to httpd.conf, you've got the whole server. that means you've probably got bigger fish to fry as to worrying about security than a pretty harmless, defaulted as secure, .htaccess file. Yes, I'd already said the former point myself, however your latter point is still ignoring the simple fact that you don't need to be root to edit a .htaccess file. I repeat, you do /NOT/ need to be root to edit a .htaccess file! Someone can edit your .htaccess file even when they don't have permissions to edit httpd.conf (and thus ssh_config nor anything else in /etc nor other root-owned config hierarchies). Thus if your http docs are writeable (and they typically are for personally web servers as you don't have a dedicated network storage such as a SAN shared across your web servers, so your content is stored on the web server itself) then a bug in your website could allow an attacker access to write to the disk in the web docs directory. In short, attackers could create and edit their own .htaccess files. We're not talking about root access here, these are not attacks that have permissions to write to httpd.conf; we're talking about a http-owned (eg 'www-data' on Debian) users who shouldn't have ability to write files having that ability to edit the Apache config because .htaccess is not typically root owned. If you want the convenience of a .htaccess file but the security of a httpd.conf, then change all your .htaccess files to be root owned: sudo find / -name ".htaccess" -exec chown root:root {} \; -exec chmod 644 {} \; -print