Main » 2011 » Март » 16 » Construct a cluster system of protection against ddos
12:24
Construct a cluster system of protection against ddos
This article was written by my friend, who is professionally engaged in the creation of heavy-networking solutions, including systems for DDoS atkam confrontation.
At his request, publish it on the Habre. If an article is like, he would be happy to address Invite hl.squirrel @ yahoo.com.

I'll try to briefly describe the scheme of solution of comprehensive protection from different types of DDoS attacks, high intensity. Such a solution is successfully tested and operated in the service stop-ddos.net
The scheme is based on the separation of the protection system (frontend) from the application server (backend).

There are 3 main types of DDoS attacks:


  • attacks directed at an overflow channel resources to the Internet;
  • attacks directed at the excess of the maximum number of concurrent server connections (SYN flood);
  • attack focused on the exhaustion of CPU capacity server (frequent solicitation of pages - HTTP flood).

The solution should provide protection against each type of attack.



Picture of the scheme described in this article.

Flooding the network


To date, the most effective means of dealing with the usual flooding the network is a wide canal. Channel to 10Gbps enough to repel most attacks of this type.
In order to once again not to load equipment at this attack, to screen out those extra packages to our address. For example, protected our service live on the 80-m port TCP. In this case, packets with destination port other than 80 can safely stateless filtering. To do this, it is quite suitable level of CISCO router 7600.
But do not forget about the backup channel, a width of at least 1Gbps.

SYN-flood


From the SYN flood protected through the use of firewalls statefull (SFFW).
In an ideal - a hardware firewall (eg, Juniper SRX 5800). Depending on the alleged power of attack chosen the right amount of firewalls. On the router, standing at the entrance to our protection, creates a route network protected by us (on the scheme is 2.1.1.0/24) with the next-hop address of each SFFW.
Each has a static SFFW Rout network 1.1.1.0 to the next router. It balances the load between the nodes of the last level of protection is a server with a UNIX system.
In this case it is convenient to use dynamic routing protocol BGP (when leaving one node fails the load is automatically distributed among the working nodes). Thus, each server is a router announces a route to network 1.1.1.0 with the next-hop self.

HTTP-flood


packages that have reached this level of protection, get on a reverse-proxy. It should be a proxy server that can differentiate a bot from a real client. For example, nginx with log analyzer, the number of simultaneous connections from addresses in combination with any other techniques invented or found you. Examples of such solutions have already been published on the Habre.
The proxy server is configured policy based routing as shown in the example. This can save queries to the backend of the secondary passage through statefull firewall.
Now for the backend. Address, which receives requests from the frontend, should differ from the one through which the management server. In the case of zasvechivaniya management addresses (for example, the letter generated by the application), you can always throw the management address in the Blackhole and it will not affect your application.
In reality there is no point in using such a large number of routers as shown in the diagram. Instead, the rational to use one device as a router with multiple routing tables (VRF, routing instances), or multiple logical routers.
Hardware stateful firewalls can also be excluded from the scheme, but instead on proxy servers to use the PF mode SYN Proxy (PF in this mode shows the best performance on the native OpenBSD, in the case of Linux better to abandon the PF, and simply protyuningovat sysctl as needed). However, the number of servers in this case have to be increased.

Post


incoming mail is most advantageous to extend guglovye MX (let someone try them zaddosit:)), and then take fetchmeylom back to the server. DNS is also best to keep not at home - large foreign registrars provide enough fault-tolerant cluster as the NS for the purchased domains. Also, for a fee, you can host your domain on their NS servers.



P.S. Ask throw a bit of karma to move the blog "Information Security".
Thank you moved!
UPD. Responses to the comments gives the author of the article.
Views: 455 | Added by: w1zard | Rating: 0.0/0
Total comments: 0
Имя *:
Email *:
Код *: