Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.
Denis Denisov edited this page Jul 3, 2016 · 14 revisions

Q&A

What would ANDDOS solve and what not?

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.

Does ANDDOS use a behavioral approach?

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.

Why is the filter implemented as a nginx module?

Because it is quite fast and nginx provides many useful functions.

What is the architecture of ANDDOS module?

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.

Which parameters are considered for filtering?

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

How does it filter requests?

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.

Cookie based

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.

Statisics/deviation based

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.

Historical behavior based

Examples

ANDDOS captured stats data http://cl.ly/2e1Z313T1c3r1P2m0V1l

anddos_stats_2