4 ms·

Would it be possible to limit these via an outbound filter? I'm thinking something like a 'do not respond before' header and a web server plugin. That would be

Would it be possible to limit these via an outbound filter? I'm thinking something like a 'do not respond before' header and a web server plugin. That would be relatively expensive, but if you just do it for login/registration/password resets it might go a fair way towards mitigating those sorts of attacks.

angelbob 14y ago
How is your "do not respond before" implemented? Does it sleep? Or busy-wait? Either is basically detectable because it affects (or doesn't) the performance of everything else on the machine (such as pings, other web requests, SSH login, etc). But yes. Every layer you add (maybe) makes it a bit harder for an attacker. You simply can't stop a dedicated attacker, reasonably speaking. "Do not respond before" would at least make an attacker have to use a (somewhat) less reliable second channel to find out. Expensive, but it would do you a bit of good against casual attackers. Beyond that, you can't really block unless you block all the channels -- i.e. add a "do not respond before" to everything, not even just web requests. Also, when you say "do not respond before" is a header, I assume you mean set by your reverse proxy before the back en handles it. Clearly setting that from the client won't do you any good at all :-)
- anthonyb 14y ago
  I have no idea how it would be implemented (other than "some sort of web server plugin"), and I was thinking from the PoV of a web app, so ssh would (might?) be out of scope. The concept was just that no request for paths related to logins or passwords would take less than an amount of time, eg. 0.1s or 0.5s. It could even just be a config option. Configuring it at the firewall/web server side would be an easy way to make life harder for an attacker, without having to fiddle with (or even understand) the internals of a web app.
  - angelbob 14y ago
    SSH isn't out of scope for your attacker. If it's out of your scope as a defender, that's a problem. That's why this is hard. You don't get to control what channels of information the attacker looks at.
    - anthonyb 14y ago
      I'm not sure how attacking SSH would help you crack a web app (the users in the app won't be unix accounts), but I'll take your word for it :)
      - angelbob 14y ago
        If the web app uses extra memory or CPU, SSH response time may be affected. So delaying in the web app doesn't do a good job of concealing CPU and memory use by the web app, because it's a shared-resource system.

angelbob 14y ago

How is your "do not respond before" implemented? Does it sleep? Or busy-wait? Either is basically detectable because it affects (or doesn't) the performance of everything else on the machine (such as pings, other web requests, SSH login, etc). But yes. Every layer you add (maybe) makes it a bit harder for an attacker. You simply can't stop a dedicated attacker, reasonably speaking. "Do not respond before" would at least make an attacker have to use a (somewhat) less reliable second channel to find out. Expensive, but it would do you a bit of good against casual attackers. Beyond that, you can't really block unless you block all the channels -- i.e. add a "do not respond before" to everything, not even just web requests. Also, when you say "do not respond before" is a header, I assume you mean set by your reverse proxy before the back en handles it. Clearly setting that from the client won't do you any good at all :-)

anthonyb 14y ago
I have no idea how it would be implemented (other than "some sort of web server plugin"), and I was thinking from the PoV of a web app, so ssh would (might?) be out of scope. The concept was just that no request for paths related to logins or passwords would take less than an amount of time, eg. 0.1s or 0.5s. It could even just be a config option. Configuring it at the firewall/web server side would be an easy way to make life harder for an attacker, without having to fiddle with (or even understand) the internals of a web app.
- angelbob 14y ago
  SSH isn't out of scope for your attacker. If it's out of your scope as a defender, that's a problem. That's why this is hard. You don't get to control what channels of information the attacker looks at.
  - anthonyb 14y ago
    I'm not sure how attacking SSH would help you crack a web app (the users in the app won't be unix accounts), but I'll take your word for it :)
    - angelbob 14y ago
      If the web app uses extra memory or CPU, SSH response time may be affected. So delaying in the web app doesn't do a good job of concealing CPU and memory use by the web app, because it's a shared-resource system.