0

I'm going to get straight to the point, NGINX doesn't seem to handle any HTTP requests during a DDoS attack using XML-RPC.

The server only uses about 1% of the CPU during an XML-RPC DDoS attack.

The server uses 12 cores and NGINX is set to use 12 worker processes.

Here are my current configs

nginx.conf:

user              nginx;
worker_processes  12;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /var/run/nginx.pid;

events {
    worker_connections  12288;
}

http {
    server_names_hash_bucket_size 64;
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    limit_conn_zone $binary_remote_addr zone=one:10m;
    limit_req_zone $binary_remote_addr zone=two:10m rate=5r/s;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  30;
    server_tokens off;

    include /etc/nginx/conf.d/*;
}

default.conf:

server {
    listen       80 default_server;
    server_name  _;
    include /etc/nginx/default.d/*.conf;

    limit_conn one 10;
    limit_req zone=two burst=10 nodelay;

    if ($http_user_agent ~* (wordpress))
    {
        return 444;
    }
    if ($http_user_agent = "")
    {
        return 444;
    }

    client_body_buffer_size  1K;
    client_header_buffer_size 1k;
    client_max_body_size 1k;
    large_client_header_buffers 2 1k;

    client_body_timeout   10;
    client_header_timeout 10;
    keepalive_timeout     5 5;
    send_timeout          10;

    access_log off;

    location / {
        root   /var/www/html;
        index  index.php index.html index.htm;
    }

    error_page  404              /404.html;
    location = /404.html {
        root   /var/www/html;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /var/www/html;
    }

    location ~ \.php$ {
        root           /var/www/html;
        try_files      $uri =404;
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME   $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
    location /status/ {
        stub_status on;
    }
}

sysctl.conf:

net.ipv4.ip_forward = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

I'm not looking to block the attacks to the point which NGINX won't even receive the requests, I'm just looking to keep my NGINX up during the attacks to monitor the requests per second.

Many thanks.

2
  • If CPU isn't the bottleneck then something else is. Look at IO, available RAM, file descriptors, etc. Commented Oct 6, 2015 at 0:14
  • They're all pretty much idle.
    – M. Griffin
    Commented Oct 6, 2015 at 6:43

1 Answer 1

0

That is the point of a DDos attack is to completely use up all resources. There is no magic config that someone can say set this option and nginx will respond. You have to block inbound traffic.

Then if you block inbound traffic on the webserver what could then happen is your downstream gets saturated to the point that real requests can't come through. So you'd then need to work with your uplink to get them to block.

3
  • The server is still fully responsive during attacks though.
    – M. Griffin
    Commented Oct 3, 2015 at 13:55
  • The server allows nginx to use almost all, not all, of the resources. The server keeps a little bit free to allow management and other stuff.
    – x13
    Commented Oct 3, 2015 at 23:13
  • So it keeps 99-98% of it free?
    – M. Griffin
    Commented Oct 4, 2015 at 9:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .