Prevent slow loris attacks

zaphoyd / websocketpp

C++ websocket client/server library

http://www.zaphoyd.com/websocketpp

Other

6.88k stars 1.95k forks source link

Prevent slow loris attacks #789

Open erikzenkerLogmein opened 5 years ago

erikzenkerLogmein commented 5 years ago

Hi zaphoyd,

a default configured websocketpp server can be attacked very easily by a slow loris attack. To prevent this a little bit you can set the handshake open timeout. But I think this is not enough.

We would like to work on more mechanism to secure the websocketpp server. Are you willing to accept pull requests regarding this topic?

Best Erik

vinniefalco commented 5 years ago

Do you know if Boost.Beast websockets are vulnerable to this attack? https://github.com/boostorg/beast

erikzenkerLogmein commented 5 years ago

In general Boost.Beast is a much lower layer than websocketpp, right? So I guess, if you implement websockets based on Boost.Beast you have to implement a defence strategy by yourself e.g.: set the proper timeouts, restrict max number of sockets per source ip etc.

Boost.Beast has the advantage that you are able to implement strategies by your own. Websocketpp hides the internals and makes it hard to inject the code.

vinniefalco commented 5 years ago

Yes, it is a little bit lower level (not "much more"). The next version has buit-in timeouts: https://github.com/boostorg/beast/blob/develop/include/boost/beast/websocket/stream_base.hpp#L71

zaphoyd commented 5 years ago

@erikzenkerLogmein security related pull requests are certainly welcome. If you have a rough outline of the strategy you want to try I may be able to point you to the easiest areas of the code to make those sorts of changes.

erikzenkerLogmein commented 5 years ago

@vinniefalco Thats very cool! We are experimenting with the boost beast. Maybe, even more security related issues can be tackled. I made a list of defence strategies. I am not totally sure if some of them are already implemented and if all of them make sense:

Reject / drop connections with HTTP methods (verbs) not supported by the URL.
Limit the header and message body to a minimal reasonable length. Set tighter URL-specific limits as appropriate for every resource that accepts a message body.
Set an absolute connection timeout
Set an absolute request timeout (I think already implemented)
Define the minimum incoming data rate, and drop connections that are slower than that rate. Care must be taken not to set the minimum too low, or you risk dropping legitimate connections.
Limit each IP address to a maximum number of connections
Black list already rejected connections: after a number of failed connection attempts do not handle these ips anymore

vinniefalco commented 5 years ago

please open an issue in the repo with this list so it can be tracked