Назад | Перейти на главную страницу

Nginx, ModSecurity, IP-таблицы, блокирующие атаки WordPress dos / ddos

За последние 14 дней мой веб-сайт был поражен миллионами установок WordPress по всему миру, с которыми вроде бы справляется .htaccess, но я пытаюсь найти что-нибудь, чтобы их выгнать до встречи с htaccess. (RewriteCond %{HTTP_USER_AGENT} ^WordPress [NC,OR])

Я попытался вставить код в свою конфигурацию nginx, чтобы заблокировать пользовательские агенты WordPress, из-за которых apache не мог загружаться, поэтому я вернул код.

Это конфигурация:

user nobody;
#noneedformoreworkersintheproxymode
worker_processes  2;
error_log  /var/log/nginx/error.loginfo;
worker_rlimit_nofile 20480;

events {
   worker_connections 5120;#increaseforbusierservers
   useepoll;#youshoulduseepollhereforLinuxkernels 2.6.x
}

http {
    server_name_in_redirectoff;
    server_names_hash_max_size 10240;
    server_names_hash_bucket_size 1024;
    include   mime.types;
    default_type application/octet-stream;
    server_tokensoff;
    #remove/commentoutdisable_symlinksif_not_owner;ifyougetPermissiondeniederror
    #disable_symlinksif_not_owner;
    sendfileon;
    tcp_nopushon;
    tcp_nodelayon;
    keepalive_timeout  5;

    gzipon;
    gzip_varyon;
    gzip_disable "MSIE [1-6]\.";
    gzip_proxiedany;
    gzip_http_version 1.0;
    gzip_min_length  1000;
    gzip_comp_level  6;
    gzip_buffers  16 8k;

    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;
    fastcgi_connect_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_read_timeout 300;

    #Youcanremoveimage/pngimage/x-iconimage/gifimage/jpegifyouhaveslowCPU
    gzip_types   text/plaintext/xmltext/cssapplication/x-javascriptapplication/xmlapplication/javascriptapplication/xml+rsstext/javascriptapplication/atom+xml;
    ignore_invalid_headerson;

    client_header_timeout  3m;
    client_body_timeout 3m;
    send_timeout     3m;
    reset_timedout_connectionon;
    connection_pool_size  256;
    client_header_buffer_size 256k;
    large_client_header_buffers 4 256k;
    client_max_body_size 200M; 
    client_body_buffer_size 128k;
    request_pool_size  32k;
    output_buffers   4 32k;
    postpone_output  1460;
    proxy_temp_path  /tmp/nginx_proxy/;
    proxy_cache_path /var/cache/nginxlevels=1:2keys_zone=microcache:5mmax_size=1000m;
    client_body_in_file_onlyon;
    log_formatbytes_log "$msec $bytes_sent .";
    log_formatcustom_microcache '$remote_addr - $remote_user [$time_local] '
            '"$request" $status $body_bytes_sent '
            '"$http_referer" "$http_user_agent"nocache:$no_cache';
    include "/etc/nginx/vhosts/*";
}

У нас есть Mod Security, и это конфиг.

http://pastebin.com/raw.php?i=Z5Lx3WkH (слишком длинный для вставки)

Скажите, пожалуйста, знаете ли вы, как заблокировать пользовательский агент WordPress? Это мне очень поможет. ModSecurity в настоящее время блокирует несколько, но недостаточно, 251+ IP каждую секунду, и они продолжают меняться.

CentOS 6.5 преобразован в CloudLinux 6.5 x86_64

Создайте файл в каталоге nginx со всеми необходимыми UserAgents, которые вам не нравятся.

/etc/nginx/conf/blockuseragent.conf:

 if ($http_user_agent ~* ("Wordpress|w0RdPress|multipleitemsexample") ) {
            return 403; #Return anything you want. 
    }

В вашем файле виртуального хоста добавьте следующее после открывающего блока 'server {':

include /etc/nginx/conf/blockuseragent.conf;

И перезагрузите.

(Я предпочитаю подход iptables, на который ответил Джо, но это заблокирует UserAgents в nginx, которые можно развернуть на нескольких внешних серверах nginx)

Вы можете иметь iptables соответствует строке, содержащейся в пакете .. эта строка может быть заголовком пользовательского агента.

Проблема в том, что HTTP-запрос может охватывать несколько пакетов. Если это произойдет, он сделает две вещи ... он все равно ударит по вашему серверу и установит TCP-соединение, что может помешать вашим попыткам заблокировать следующий запрос.

Есть несколько способов обойти это. Один из способов - потребовать User-agent для первоначального открытия соединения.

Рассмотрим что-нибудь вроде следующего: 

# allow already established connections
iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

# send brand new connections to the WORDPRESS chain
iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW -j WORDPRESS

# drop everything else (ie INVALID or RELATED)
iptables -A INPUT -p tcp --dport 80 -j DROP


#### WORDPRESS chain. Only handles brand new connections to TCP 80

# drop anything with the offending user-agent
# optionally duplicate this line to bludgeon additional UAs
iptables -A WORDPRESS -m string --string "User-Agent: WordPress" --algo bm --to 65535 -j DROP

# allow that which has a user-agent. (that wasn't the offending ua)
iptables -A WORDPRESS -m string --string "User-Agent:" --algo bm --to 65535 -j ACCEPT

# drop that which has no user-agent, such as a 2nd packet within an HTTP request
# not a problem for legit traffic, since the first packet would have had a UA and
# thereby established the connection and avoided the whole WORDPRESS chain..
iptables -A WORDPRESS -j DROP

Конечно, есть и другие подходы ..

Например: вы можете сопоставить строку UA, войти в журнал и затем отбросить. Затем вы можете передать журнал в fail2ban. И т.д..