How to enable DDoS protection?

Question

Are DDoS (distributed denial of service attacks) usually blocked at the server level right?

Is there a way to block it at the PHP level, or at least reduce it?

If not, what is the fastest and most common way to stop DDoS attacks?

Answer 1

DDOS is a family of attacks that suppress key systems in the data center, including:

• Network connection of a hosting to the Internet
• Internal Hosting Network and Routers
• Your firewall and load balancing
• Your web servers, application servers and database.

Before embarking on DDOS protection, consider what is the worst risk scenario. For non-critical, free use for a small community, the total cost of risk may be peanuts. For a paid, community-oriented, critical system to create a multi-billion dollar business, the cost can cost the company. In this last case, you should not use StackExchange :) In any case, to protect against DDOS, you need an in-depth protection approach:

• Work with your hosting center to understand the services they offer, including filtering IP and ports when they are connected to the Internet and the firewall services they offer. This is very important: many sites are pulled out of the Internet by the hosting company, since the hosting company is engaged in a data center rupture caused by DDOS for one client. In addition, during a DDOS attack, you will work very closely with the staff of the hosting center, so find out their emergency numbers and be on good terms with them :) They should be able to block entire international regions, completely block certain services or a network of protocols and other broad-spectrum safeguards or, alternatively, only allow whitelisting of IP addresses (depending on your business model).
• In the hosting center, use the Content Delivery Network to distribute (mostly static) services close to your end users and to hide real servers from DDOS architects. The full CDN is too large for DDOS to list all nodes in all countries; if DDOS focuses on one country, at least other users are still fine.

• Keep all your system and software packages with the latest security fixes - and I mean everything:

  • Managed switches - sometimes they need updates
  • Routers
  • Firewalls
  • Load balancers
  • Operating Systems
  • Web servers
  • Languages ​​and their libraries

• Make sure you have a good firewall or security device and it is checked regularly by a qualified security professional. Strong firewall rules are a good defense against many simple attacks. It is also useful to be able to control the bandwidth available for each open service.

• You have good network monitoring tools - this can help you understand:

  • So that you are attacked, and not just under heavy load
  • Where the attack occurs (which may include countries that you usually don’t work with) and
  • Actually attack (ports, services, protocols, IP addresses and packet contents)

• An attack may simply be an excessive use of legitimate website services (for example, hitting “legitimate” URI requests that perform requests or inserting / updating / deleting data) - thousands or millions of requests from tens to millions of different IP addresses will bring the website to knees. Alternatively, some services may be so expensive to run that only a few requests invoke DOS — read a really expensive report. So, you need good application level monitoring of what is happening:

  • What services were called and what arguments / data were sent (i.e. logging in your application)
  • Which users make calls and from which IP addresses (i.e. register in your application)
  • What queries and inserts / updates / deletions does the database perform
  • Average load, processor load, disk I / O, network traffic on all computers (and virtual machines) in your system.
  • Make sure that all this information is easily retrieved and that you can map logs from different computers and services (i.e. ensure that all computers are synchronized using ntp).

• Reasonable restrictions and restrictions in the application . For example, you can:

  • Use the QoS feature in the load balancer to send all anonymous sessions to separate the application servers in your cluster, and the logged in users use a different set. This prevents anonymous application-level DDOS applications that receive valuable clients.
  • Using strong CAPCHA to protect anonymous services
  • Session Timeouts
  • You have a session limit or speed limit for certain types of queries, such as reports. Make sure you can disable anonymous access if necessary.
  • Make sure the user has a limit on the number of concurrent sessions (to prevent a hacked account from writing a million times)
  • Different services (for example, using transactions and using reports) use different database application users and use database resource management to prevent all types of web requests from being suppressed by one type.
  • If possible, these restrictions are dynamic, or at least customizable. Thus, while you are under attack, you can set aggressive time limits in place (“throttle” the attack), for example, only one session per user and lack of anonymous access. This, of course, is not very convenient for your customers, but much better than not having services at all.

• Finally, write a DOS Response Plan document and receive internal review by all interested parties: business, management, SW development team, IT team and security expert. The process of writing a document will force you and your team to think through problems and help you prepare if the worst happens at 3 a.m. on a weekend day. The document should cover (among other things):

  • What is at stake and the value of the business.
  • Asset Protection Measures
  • How the attack is detected
  • Scheduled Reaction and Escalation Procedure
  • Processes for updating the system and this document.

So, the preamble aside, here are some specific answers:

DDOS are usually blocked at the server level, right?

Not really - most of the worst DDOS attacks are low-level (at the IP packet level) and are handled by routing rules, firewalls, and security devices designed to handle DDOS attacks.

Is there a way to block it at the PHP level, or at least reduce it?

Some DDOS attacks target the application itself by sending valid URIs and HTTP requests. When the speed of requests increases, your server begins to fight, and you will have a rejection of the SLA. In this case, there are things you can do at the PHP level:

• Application Level Monitoring. Ensure that each service / page log request is such that you can see what is happening (so that you can take action to mitigate the attack). Some ideas:

  • Have a log format that can be easily loaded into a log tool (either Excel or similar) and analyzed using command line tools (grep, sed, awk). Remember that DDOS will generate millions of log lines. You will most likely need to cut your logs (especially with regard to URI, time, IP and user) in order to work out what is happening, and you need to create data such as:

    • URI Access
    • That the URI is not working at high speed (a likely indicator of the specific URIs that attack the attackers)
    • Which users access the service
    • How many IP addresses does each user access the service from
    • Which URIs are anonymous users accessing
    • What arguments are used for this service
    • Audit specific user actions.

  • Record the IP address of each request. DO NOT OPEN DNS it is - ironically, the cost of this makes DDOS easier for attackers

  • Record the entire URI and HTTP method, for example, "GET http://example.com/path/to/service?arg1=ddos "
  • Enter the user ID, if any
  • Register important HTTP arguments

• Sensitive speed limits: you can use restrictions on the number of requests a given IP address or user can make over a certain period of time. Can a legitimate client make more than 10 requests per second? Can anonymous users access expensive reports?

• CAPTCHA for anonymous access: run CAPTCHA for all anonymous requests to ensure that the user is human and not the DDOS bot.

What is the fastest and most common way to stop DDOS attacks?

The fastest should probably succumb to blackmail, although this may not be desirable.

Otherwise, the first thing you need to do is contact your hosting and / or CDN provider and work with them (if they have not contacted you, you are already asking what the hell is going on ...). When DDOS occurs, this is likely to indirectly affect other clients of the hosting provider, and the provider may experience significant pressure to close their site simply to protect their resources. Be prepared to share your magazines (any information and information) with the supplier; these logs, combined with their network monitors, can together provide sufficient information to block / mitigate the attack.

If you expect DDOS, it is a very good idea to qualify your hosting provider for the level of protection that they can provide. They should have DDOS experience and tools to mitigate it - understand their tools, processes and escalation procedures. Also ask about the support provided by the hosting provider for your providers. These services may mean more upfront or monthly costs, but consider this as an insurance policy.

During the attack, you will need to capture your logs and get them - try to develop an attack pattern. You should consider disabling anonymous access and throttling services under attack (i.e., reduce the transmission rate limit for a service).

If you are lucky and have a small fixed client base, you can determine your actual client IP addresses. If so, you can switch to a whitelist approach for a short time. Make sure all your customers know this is happening so they can call if they need to access from a new IP :)

---

Doug McClean has some great advice: https://stackoverflow.com/a/167189/

Answer 2

Regarding the PHP question,

Although I do not rely on PHP for this, it can be implemented, but must take into account all these possibilities or more;

• Attacker can change IP for each request
• An attacker can pass parameters to a URI so that the target site does not care about these parameters
• An attacker can restart a session before expiration ...

Simple pseudo;

<?php // Assuming session is already started $uri = md5($_SERVER['REQUEST_URI']); $exp = 3; // 3 seconds $hash = $uri .'|'. time(); if (!isset($_SESSION['ddos'])) { $_SESSION['ddos'] = $hash; } list($_uri, $_exp) = explode('|', $_SESSION['ddos']); if ($_uri == $uri && time() - $_exp < $exp) { header('HTTP/1.1 503 Service Unavailable'); // die('Easy!'); die; } // Save last request $_SESSION['ddos'] = $hash; ?> 

Answer 3

The php level is too late in the request chain.

Putting your apache server behind an open source device might be a good option for you.

http://tengine.taobao.org/ has some documentation and source code more modules designed to prevent DDOS. This is a nginx extension, so you can easily configure it as a reverse proxy for your apache instance.

See: http://blog.zhuzhaoyuan.com/2012/01/a-mechanism-to-help-write-web-application-firewalls-for-nginx/ for how to deal with collisions, there are DoS attacks.

I also completely forgot that http://www.cloudflare.com is one of the best web application firewalls, they have free and paid plans and will save your ass from DDOS, we use it for many of our sites with high traffic just for it caching capabilities, it's easy!

Answer 4

DDoS is best for handling very expensive specialized network devices. Owners usually do not know how to protect DDoS, because they are subject to relatively low productivity, fatigue, limited bandwidth, etc. Using iptables, apache mods, and similar services can help in some situations if you do not have access to DDoS mitigation equipment or the DDoS mitigation service, but it is far from ideal and still leaves you under attack.

Answer 5

How about something like this on the PHP side:

 //if user does not change IP, then ban the IP when more than 10 requests per second are detected in 1 second $limitps = 10; if (!isset($_SESSION['first_request'])){ $_SESSION['requests'] = 0; $_SESSION['first_request'] = $_SERVER['REQUEST_TIME']; } $_SESSION['requests']++; if ($_SESSION['requests']>=10 && strtotime($_SERVER['REQUEST_TIME'])-strtotime($_SESSION['first_request'])<=1){ //write the IP to a banned_ips.log file and configure your server to retrieve the banned ips from there - now you will be handling this IP outside of PHP $_SESSION['banip']==1; }elseif(strtotime($_SERVER['REQUEST_TIME'])-strtotime($_SESSION['first_request']) > 2){ $_SESSION['requests'] = 0; $_SESSION['first_request'] = $_SERVER['REQUEST_TIME']; } if ($_SESSION['banip']==1) { header('HTTP/1.1 503 Service Unavailable'); die; } 

Answer 6

You cannot do this at the PHP level. DDOS is a kind of attack that sends too many requests to your web server. Your web server will reject the request before it calls your PHP script.

If you are using Apache, here are some tips from Apache: http://httpd.apache.org/docs/trunk/misc/security_tips.html

Answer 7

There are plugins that you can use in apache for ddos ​​/ dos. A good start is here http://www.debianadmin.com/how-to-protect-apache-against-dosddos-or-brute-force-attacks.html

If you are on LEMP, you can check here. http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

These are good low-cost starting points.

Answer 8

Do NOT use PHP-based protection, this is terrible and is unlikely to have an effect at all! Configure your web server for speed limit requests, for example, in Nginx using the limit_req module ( http://nginx.org/en/docs/http/ngx_http_limit_req_module.html )

Although, I would recommend using CloudFlare to deal with levels 4, but not with levels at level 7 if you are not willing to pay.

Answer 9

Anti DDOS :

• The most important thing is to first determine the ddos ​​attack. Identifying a ddos ​​attack earlier means your server will be better.
• Getting the best bandwidth for your server. Always save more than enough bandwidth needed for your server. This will not prevent a DDOS attack, but it will take longer. By means of which you will get extra time to act.
• If you have your own web server, you can protect the speed limit of your router by the network parameter, add filters to drop packets to different sources of attacks, while more than half open connections are more aggressive. Also set lower drop thresholds for SYN, ICMP, and UDP.
• If you do not have a big idea of ​​these things, then quickly and quickly contact your hosting providers. They can try their best to prevent DDOS attacks.
• There are also special DDOS mitigation services provided by Cloudflare and many other companies. This way they can help you prevent DDOS attacks. Many companies also offer cheap ddos protection and dos protection .

Answer 10

DDOS is usually blocked at the server level. Enable DDOS protection at the server level. Please see the notes below to protect DDOS.

Apache HTTP server configuration settings that can help prevent problems with DDOS:

The RequestReadTimeout directive allows you to limit the time that a client can take to send a request.

Allow 10 seconds to receive the request, including headers, and 30 seconds to receive the request body:

 RequestReadTimeout header=10 body=30 

Allow at least 10 seconds to receive the request body. If the client sends data, increase the timeout by 1 second for each received 1000 bytes without an upper limit for the timeout (with the exception of the limitation specified indirectly by LimitRequestBody):

 RequestReadTimeout body=10,MinRate=1000 RequestReadTimeout header=10-30,MinRate=500 RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500 

The KeepAliveTimeout directive can also be reduced on sites prone to DoS attacks. Some sites even completely disable keepalives through KeepAlive, which, of course, has other performance flaws. You need to check the values ​​of the various timeout directives provided by other modules.

The directives LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine and LimitXMLRequestBody must be carefully configured to limit resource consumption caused by client input. Configure the MaxRequestWorkers directive to allow the server to handle the maximum number of concurrent connections without running out of resources.