Перейти к содержанию
  • Блокировка IP по геопризнаку Nginx


    anomal3

    Всем привет народ, я тут новенький.

    Почитав тему

    решил немного дополнить, точнее раскрыть свою тему.

    Почему тут конфиги для Nginx а не для apache расскажу под спойлером в истории.

    Рекомендую прочесть, чтобы понять что к чему.

    и вот немного отступления.

     

    История...

    Спойлер

    Больше полу года назад, работая в проектной компании, мы решили обзавестись собственным файлообменником с заказчиками. Почитав мануалы и статьи, я пришёл к выводу что будет логично развернуть собственное облако на Linux системе а именно Ubuntu 16.04.3LTS.
    За основу я взял знаменитый ownCloud. Развернуть облако не составило никакого труда, всё легло как по маслу.
    И наше облако начали активно использовать заказчики похлопывая в ладоши, и говоря как же это удобно.

    Развернул я облако на связке Apache + PHP7.0 + MySQL. С этими "демонами" я уже встречался ранее, но как новичок, не имея плотного знакомства мне хватало справляться с поставленными задачами, да и плюс в интернете полным полно мануалов. Я говорю про (пример) изменение портов, подключение HTTPS, и т.п.

    Но месяца 1,5 назад, с нашим облаком да и вообще с сетью, началась твориться магия. Облако периодически начало подвисать, то доступно то нет, сеть интернет тоже начала шалить. Первым делом я конечно же связался с провайдером, кто нас кормит интернетом. После многочисленных проверок мне сказали, мол все у вас в порядке, дело не в линии, а в вашем оборудовании. Ну ладно, пробуем методом исключений. Перезагружаем роутер, и о чудо, интернет появляется минут на 5 и снова такая вакханалия. Значит дело в другом. Посмотрев конфиги апача, ведь именно он отвечает за наше облако, я увидел что добавились какие то дополнительные конфиги. Я начал гуглить информацию, и как оказалось Apache обновился до версии 2.4.18 (видимо apt update сделал своё дело). Почитал как посмотреть ошибки

    
    
     
    
    apache2 -t

    и как их пофиксить. Вроде сделал, но проблема не ушла, а значит дело не в Апаче. Долго изучая конфиги, и читая статьи, понял что решать данную проблему придется изучая логи, лоооги, лоо-о-о-оги, о боже, только не их. Я в них нефига не понимаю и их так много. Но делать было нечего. Сел за изучение логов, пытаясь дойти до чего-нибудь логичного своим мозгом. Ну Вы представьте, за пол года читать логи, УЖАС!.

    Но спустя N-ное количество времени я заметил подозрительную активность

    
    [Mon Jun 18 21:25:29.021638 2018] [mpm_prefork:notice] [pid 3593] AH00163: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
    [Mon Jun 18 21:25:29.021722 2018] [core:notice] [pid 3593] AH00094: Command line: '/usr/sbin/apache2'
    [Mon Jun 18 21:41:24.850827 2018] [mpm_prefork:notice] [pid 3593] AH00169: caught SIGTERM, shutting down
    [Mon Jun 18 21:41:26.033616 2018] [mpm_prefork:notice] [pid 6733] AH00163: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
    [Mon Jun 18 21:41:26.033694 2018] [core:notice] [pid 6733] AH00094: Command line: '/usr/sbin/apache2'
    [Mon Jun 18 21:43:17.328967 2018] [mpm_prefork:notice] [pid 6733] AH00169: caught SIGTERM, shutting down
    [Mon Jun 18 21:43:18.443306 2018] [mpm_prefork:notice] [pid 7172] AH00163: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
    [Mon Jun 18 21:43:18.443383 2018] [core:notice] [pid 7172] AH00094: Command line: '/usr/sbin/apache2'
    [Mon Jun 18 23:05:33.572588 2018] [:error] [pid 9356] [client 203.195.132.58:1905] script '/var/www/html/wuwu11.php' not found or unable to stat
    [Mon Jun 18 23:05:34.055989 2018] [:error] [pid 9399] [client 203.195.132.58:1984] script '/var/www/html/xw.php' not found or unable to stat
    [Mon Jun 18 23:05:34.570828 2018] [:error] [pid 9385] [client 203.195.132.58:2064] script '/var/www/html/xx.php' not found or unable to stat
    [Mon Jun 18 23:05:35.084697 2018] [:error] [pid 8945] [client 203.195.132.58:2104] script '/var/www/html/s.php' not found or unable to stat
    [Mon Jun 18 23:05:35.581628 2018] [:error] [pid 8863] [client 203.195.132.58:2210] script '/var/www/html/w.php' not found or unable to stat
    [Mon Jun 18 23:05:36.048029 2018] [:error] [pid 9355] [client 203.195.132.58:2278] script '/var/www/html/db.init.php' not found or unable to stat
    [Mon Jun 18 23:05:36.549565 2018] [:error] [pid 8856] [client 203.195.132.58:2452] script '/var/www/html/db_session.init.php' not found or unable to stat
    [Mon Jun 18 23:05:37.046265 2018] [:error] [pid 9358] [client 203.195.132.58:2519] script '/var/www/html/sheep.php' not found or unable to stat
    [Mon Jun 18 23:05:37.582546 2018] [:error] [pid 9354] [client 203.195.132.58:2629] script '/var/www/html/index.php' not found or unable to stat
    [Mon Jun 18 23:05:43.230844 2018] [:error] [pid 9354] [client 203.195.132.58:2629] script '/var/www/html/mysql/index.php' not found or unable to stat
    [Tue Jun 19 06:37:17.184153 2018] [:error] [pid 9400] [client 116.204.103.129:25543] script '/var/www/html/mysql/index.php' not found or unable to stat
    [Tue Jun 19 11:44:15.078641 2018] [:error] [pid 8856] [client 223.105.4.250:17113] script '/var/www/html/index.php' not found or unable to stat

    Вот так вот брут ищет уязвимости.
    Запросил информацию по ip и удивился, ЧАЙНА.

    Но так как я раньше не сталкивался с таким чудом, я создал тему на форуме, и спросил что это за активность.
    Знающие гуру (СПАСИБО им больше) подтвердили мои догадки, это была DDOS АТАКА.
    Дос атакой нас грузили на протяжении 1,5 месяца, заказчики нервничали, и начальство тоже, а моя пятная точка горела всё больше и больше.

    Опять изучение статей. Разные попытки заглушить атаку не увенчались успехом.
    Я пробовал на главной странице index.php методом геопризнака, переадресовывать клиентов не из России в попенгаген.

    Но опять неудача.

     

    Рассуждая что лучше Апач или Нджинкс вычитал.

    Но мне попалась хорошая статься сравнений этих демонов
    https://habr.com/post/267721/

    И было принято решение полностью отказаться от apache.
    Сделав резервную копию базы и сайта /var/www/html
    Я поставил систему с нуля, и запустил на нём Nginx. Так же подключил php и mysql.
    И тут началось самое интересное. Настройки

     

    После того как Nginx запущен и сделаны первоначальные настройки(они расписаны в любой статье), он никак не может распознать php.
    В интернете полно статей о том как настроить конфиг.

    location ~ \.php$ { 
    		try_files $uri =404; 
    		include /etc/nginx/fastcgi.conf;
    		fastcgi_pass unix:/run/php/php7.0-fpm.sock; 
    
    }

    Данный код подключает php, но в следствии за ним ещё куча настроек, таких как время ожидания, Максимальный размер файла и прочих. Благо на ownCloud есть уже готовый пример, правда пришлось немного его править.
    В итоге получил полностью рабочий конфиг который хранится в /etc/nginx/sites-avalible/default

    server {
    listen 80;
    server_name _;
    
          error_page 404 /custom_404.html;
    location = /custom_404.html {
    root /usr/share/nginx/html;
    internal;
    }
    
    root /var/www/html;
    
    access_log /var/log/nginx/ng.access.log;
    error_log /var/log/nginx/ng.error.log;
    
    index index.php index.html index.htm;
    
            error_page 403 /core/templates/403.php;
            error_page 404 /core/templates/404.php;
    
    
    
    client_max_body_size 100M; # set max upload size
    fastcgi_buffers 64 4K;
    
    rewrite ^/caldav(.*)$ /remote.php/caldav$1 redirect;
    rewrite ^/carddav(.*)$ /remote.php/carddav$1 redirect;
    rewrite ^/webdav(.*)$ /remote.php/webdav$1 redirect;
    location / {
                    # The following 2 rules are only needed with webfinger
                    rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
                    rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
    
                    rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
                    rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
    
                    rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
    
                    try_files $uri $uri/ index.php;
    }
    location ~ ^(.+?\.php)(/.*)?$ {
                    try_files $1 =404;
    
                    include fastcgi_params;
                    fastcgi_param SCRIPT_FILENAME $document_root$1;
                    fastcgi_param PATH_INFO $2;
                    fastcgi_keep_conn on;
    
                    fastcgi_pass unix:/var/run/php/php7.0-fpm.sock;
    }
    
    }

    Теперь всё работает, и время распаковать ранее сохраненные бэкапы.
    После того как я всё вернул на круги своя, сменив апач на нджикс, я решил оставить все как есть, проверить будет ли дос атака. И спустя время дос опять начался.

    Ну раз я уже начитан, и знаю что дальше делать, я принялся менять конфиги и защищать себя от доса по геопризнаку.
    Мне известно, что все наши клиенты из России, так же по логам я видел, что злоумышленник не просто караулит меня, а делает это с изыском. С помощью API сайта https://proxycheck.io/ гореть им в аду за это, я понимал, что клиентам из других стран нечего делать в нашем облаке.

    А посему было принято решение на уровне демона определять страну и отсылать уже в выше упомянутою страну ПОПЕНГАГЕН.

    Первым делом, вооружившись гайдам, я скачать от сюда http://www.maxmind.com/app/geolitecountry latest GeoLite Country Binary Format (это бесплатный вариант базы стран и соответствующих им блоков IP адресов).
    Распаковываем архив и кидаем файл GeIP.dat в папку

    /usr/local/etc/nginx/conf/geo

    если такой папки нет, создайте её или их.
    Далее нужно отредактировать файл /etc/nginx/nginx.conf
    секцию http в любом месте секции, вписываем

     geoip_country /usr/local/etc/nginx/conf/geo/GeoIP.dat; # подключаем GeIP базу
        map $geoip_country_code $bad_country { # модуль map создает переменные, значения которых зависят от других переменных, очень полезная штука
        	default 1; # значение по умолчанию
        	include /usr/local/etc/nginx/conf/geo/good_countries; # инклудим файл, его нужно будет создать чуть позже
        }

    Этот блок map, означает, что все страны находящиеся в базе данных, являются запрещенными по умолчанию, а в файле good_countries, будут перечислены разрешенные страны.

    Теперь в файл настроек (мой это ) /etc/nginx/sites-avalible/default вписываем после

    server {
    	listen       IP:80;
    	server_name  testhost.com;

     

    вот этот код

    if ($bad_country){ # если данная переменная установлена, то есть если страна не перечислена в файле good_countries
    		return 444; # выдаем клиенту пустой ответ ( незачем отдавать 403 ошибку или еще какую-либо )
    	}

    Теперь создадим "тот файл", если хотяб краем глазом смотрели что вписываете, то увидели подключаемый файл
    good_countries. Создаем его в директории /usr/local/etc/nginx/conf/geo/
    И вписываем значения

    UZ 0;
    RU 0;

    То есть тем самым разрешая вход на ваш сервер Узбекам и Русским. Ограничивать, точнее разрешать можно кому угодно, страны по двум буквам можно найти в гугле.
    После того как все сделали, просто перезагружаем демон nginx.
    Ну и собсно проверяем, зайдём через какой-нибудь веб прокси. И о чудо! действительно! Всё работает как надо.

    И теперь спустя уже почти 2 месяца, тормозов замечено небыло. Всё работает как часы, тьфу тьфу тьфу.



    Обратная связь

    Рекомендуемые комментарии

    2 часа назад, chinya сказал:

    сударь а не проще локать IP через iptables? или через CF  ???? что за извращение с nginx?

    Iptables не защитит Вас от UDP атак. Так же iptables не способен противостоять syn атакам. Этот способ был опробован в первую очередь, я просто это не написал.

    Поделиться этим комментарием


    Ссылка на комментарий
    Поделиться на другие сайты

    я

    3 минуты назад, anomal3 сказал:

    Iptables не защитит Вас от UDP атак. Так же iptables не способен противостоять syn атакам. Этот способ был опробован в первую очередь, я просто это не написал.

    я говорю реально это бред в нгинкс всё прописывать, ещё скажите то, извращение это добавлять что то лишнее в иптайблес! https://adminvps.ru/blog/syn-flood-ataka-ili-kompleksnaja-zashhita/

    https://suricata-ids.org/

    cloudflare

    incapsula

    грамотно настроеный сервер OS hardendBSD,centos 7

    но не глючная убунту сервер или дебиан

    Поделиться этим комментарием


    Ссылка на комментарий
    Поделиться на другие сайты
    24 минуты назад, chinya сказал:

    я

    я говорю реально это бред в нгинкс всё прописывать, ещё скажите то, извращение это добавлять что то лишнее в иптайблес! https://adminvps.ru/blog/syn-flood-ataka-ili-kompleksnaja-zashhita/

    https://suricata-ids.org/

    cloudflare

    incapsula

    грамотно настроеный сервер OS hardendBSD,centos 7

    но не глючная убунту сервер или дебиан

    Нет простого syn flood. Ибо он бессмысленен , только школьники  для баловства. спуфнутые syn используют. Говорю Вам, с иптаблес первое было опробовано.

     

    Но iptables не помешает, в этом соглашусь. А использовать это как защиту, то только до первого падения.

    Поделиться этим комментарием


    Ссылка на комментарий
    Поделиться на другие сайты
    11 минут назад, anomal3 сказал:

    Нет простого syn flood. Ибо он бессмысленен , только школьники  для баловства. спуфнутые syn используют. Говорю Вам, с иптаблес первое было опробовано.

     

    Но iptables не помешает, в этом соглашусь. А использовать это как защиту, то только до первого падения.

    при атаке в потоке 4-5Tb/sec ни какая защита вам не поможет, лично сам валил супер пупер защищённые сайты, а если идёт syn flood+udp flood то и nginx не поможет

    Поделиться этим комментарием


    Ссылка на комментарий
    Поделиться на другие сайты


    Для публикации сообщений создайте учётную запись или авторизуйтесь

    Вы должны быть пользователем, чтобы оставить комментарий

    Создать учетную запись

    Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

    Регистрация нового пользователя

    Войти

    Уже есть аккаунт? Войти в систему.

    Войти


×