-
Notifications
You must be signed in to change notification settings - Fork 36
Home
It should restrict DDOS attacks on HTTP level. So it proceeds HTTP request on a webserver/proxy and drops "bad" ones. It does not provide protection on lower layers (IP, TCP, ..), which should be solved elsewhere. Also does not directly use an application interaction, is transpanent.
Yes. It proceeds requests distribution etc. beside of just an absolute number of requests. And an algorithm can learn from a traffic.
Behavioral filtering is a buzzword, because non-behavioral approaches have no future.
Because it is quite fast and nginx provides many useful functions.
It consists of two parts. Request handler, which allow or deny clients requests by lookup to a hashtable. Learn filter which saves stats about each client and global server stats to the hashtable. Request handler has some limitations currently, so filtering can be done by generated IP list on a firewall.
I am excluding challenge cookie check, which is not too "smart" filtering.
An algorithm focuses on parameters provided in app server's response, which should be more credible than request headers.
- response's HTTP code - eg. 304 means, that client has a local cache (but sending if-modified-since param with timestamp in the future?)
- time taken by request processing - globally for an attack detection and clients making slow requests (?)
- web-pass steps sequence (or connection between requests by referrer (?))
- request division based on response mime-type
ANDDOS has several "runlevels", normal and under attack basically. It's filtering strategy depends on it's runlevel. A client is defined by IP address and user_agent HTTP header (+cookie), but clients can be aggregated, when necessary (all user_agents to IP and IP to IP range potencially).
Each client is allowed to send first n requests (exclude "attack" time). And after that client can be filtered or added to a client list. I case of attack, no new clients are added to the list, but they can be removed.
Each client get his own cookie and server requires its presence (and correct value) in next requests. The goal is to stop HTTP attacks, that does not wait for a server response, as cheap as possible.
Normal client downloads from server many files (images, css, js). Global server stats are kept and compared to each client stats. Normal client uses local cache, so some responses should be responsed with HTTP not-modified 304 code.
ANDDOS captured stats data http://cl.ly/2e1Z313T1c3r1P2m0V1l