• IPtables с выделенного на виртуальные серверы?

    @krosh
    Используйте цепочку FORWARD. Это сработает, если выделенный сервер является шлюзом для виртуальных.

    Хотя лучше все же уточнить вопрос.
    Ответ написан
    3 комментария
  • IPtables с выделенного на виртуальные серверы?

    Don_Andretti
    @Don_Andretti
    Product manager
    Для выполнения руководства нужно иметь два сервера. Исходный сервер, на котором находятся правила фаервола, называется в руководстве сервером A; целевой сервер – B.

    Также нужно иметь права sudo.
    Просмотр правил iptables

    Прежде чем приступить к переносу правил брандмауэра, нужно просмотреть их. Для этого выполните следующую команду на сервере A:

    s
    udo iptables -S
    Example output:
    -P INPUT ACCEPT
    -P FORWARD ACCEPT
    -P OUTPUT ACCEPT
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
    -A INPUT -s 15.15.15.51/32 -j DROP


    Теперь нужно перенести эти правила на другой сервер.

    Экспорт правил Iptables

    Команда iptables-save сохранит текущие правила брандмауэра в stdout, после чего его можно будет сохранить в файл.

    Используйте эту команду на сервере А, чтобы экспортировать правила в файл iptables-export.

    cd ~
    sudo iptables-save > iptables-export


    После этого в домашнем каталоге появится файл iptables-export, при помощи которого можно перенести правила фаервола на другой сервер.
    Просмотр файла (опционально)

    Проверьте, содержит ли новый файл все необходимые данные:

    cat iptables-export
    # Generated by iptables-save v1.4.21 on Tue Sep 1 17:32:29 2015
    *filter
    :INPUT ACCEPT [135:10578]
    :FORWARD ACCEPT [0:0]
    :OUTPUT ACCEPT [8364:1557108]
    -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
    -A INPUT -s 15.15.15.51/32 -j DROP
    COMMIT
    # Completed on Tue Sep 1 17:32:29 2015


    Как видите, данный файл содержит все текущие правила iptables, и теперь можно скопировать этот файл на целевой сервер.
    Перенос правил на целевой сервер

    Проще всего для этого использовать scp или же просто скопировать и вставить содержимое файла в новый файл на целевом сервере.

    Ниже показано, как при помощи scp скопировать файл по сети в каталог /tmp.

    Итак, запустите команду scp на сервере А, указав логин и IP-адрес сервера.

    scp iptables-export user@server_b_ip_address:/tmp


    Пройдя авторизацию, файл будет скопирован в каталог /tmp на сервер В.

    Примечание: Содержимое каталога /tmp будет удалено при перезагрузке системы. Не забудьте переместить файл в более надёжный каталог.

    Импорт правил

    Теперь можно загрузить перенесённые правила.

    Примечание: В случае необходимости сейчас можно обновить их, добавив данные нового сервера; отредактируйте файл /tmp/iptables-export, внеся всё необходимое.

    Когда правила будут соответствовать требованиям данного сервера, загрузите их из файла iptables-export при помощи команды iptables-restore.

    На сервере В запустите:

    sudo iptables-restore < /tmp/iptables-export


    Чтобы убедиться, что правила загружены успешно, используйте:

    sudo iptables -S


    Сохранение правил

    Несохранённые правила фаервола действительны только в течение одной сессии; чтобы сделать набор правил постоянным, нужно его сохранить. Убедитесь, что вы на сервере В, и следуйте соответствующему разделу.

    Сохранение правил в Ubuntu

    Для сохранения правил брандмауэра система Ubuntu предлагает пакет iptables-persistent. Чтобы установить этот пакет, введите команду:

    sudo apt-get install iptables-persistent


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

    В дальнейшем для сохранения новых или обновлённых правил используйте команду:

    sudo invoke-rc.d iptables-persistent save


    Сохранение правил в CentOS 6 и 7

    По умолчанию системы CentOS 6 и 7 используют фаервол FirewallD; чтобы сохранить правила iptables, используйте:

    sudo service iptables save


    Это сохранит текущие правила iptables в файл /etc/sysconfig/iptables, который загрузится после перезапуска системы.

    Перенос правил брандмауэра успешно завершён!
    Ответ написан
    1 комментарий
  • ДДос атака на nginx пакетами 1 байт?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    500 строк в секунду - это не мощно и, вероятно, даже не DDoS. Если адрес один, то просто закройте ему доступ брандмауэром, а если адреса разные, то настройте лимит запросов в Nginx.

    nginx.conf
    http {
        ...
        limit_req_zone $binary_remote_addr zone=reqlimit:10m rate=30r/s;
        ...
    }

    some_site.conf
    server {
        ...
        location / {
            ...
            limit_req zone=reqlimit burst=10 nodelay;
        }
    }

    После этого запросы с одного ip-адреса начиная с 31-го в секунду будут отбрасываться.

    Как вишенку на торт, можно добавить ещё фильтр для fail2ban:

    nginx-req-limit.conf
    [Definition]
    
    failregex = limiting requests, excess: .* by zone .*, client: <HOST>
    ignoreregex =

    и правило в jail.local
    [nginx-req-limit]
    enabled = true
    port = http,https
    filter = nginx-req-limit
    logpath = /var/www/*/*/logs/error.log # Здесь укажите свой путь к логам виртуального хоста
    findtime = 600
    maxretry = 10
    bantime = 7200

    После этого адреса DoS'еров будут автоматически блокироваться брандмауэром на два часа. Что разгрузит Nginx от обработки паразитного трафика.
    Ответ написан
    11 комментариев
  • ДДос атака на nginx пакетами 1 байт?

    opium
    @opium
    Просто люблю качественно работать
    Да просто баньте айпишники в фаеволе с такими запросами
    Ответ написан
    Комментировать
  • ДДос атака на nginx пакетами 1 байт?

    @younghacker
    Главная проблема в том что Ваш адрес уже засвечен и чтобы уйти под CDN нужно сразу сменить IP для бэкэнда, а старый, владельцу атономки, лучше отправить в blackhole.

    Если канал не забит (ssh нормально отвечает) пробуйте блокировать прямо в iptables регионами.
    А если nginx успевает отвечать таймаутом бэкэнда (узкое место движок сайта) - то можно блокировать в nginx.

    Первый шаг - хостер / датацентр. Спросите чем могут помочь, им по сути тоже нет резона держать хост под атакой.

    Затем вытяните из логов все запросы за время атаки отсортируйте по количеству и составьте список 100-300 самых активных и вычислите их сети автономки и регион. Если это одна страна и она не ваша целевая - блокируйте на время всю страну автономки и так далее. Для начала можете заблокировать просто около 300 конкретных хостов.
    Если сайт начнёт работать, контролируйте что происходит дальше. Атака может смещаться на другие IP.

    Если это не поможет переходите под защиту CDN с защитой от DoS.
    Сразу после этого меняйте IP так как этот уже спален.
    Кроме этого пропишите в iptables правила которые режут трафик отовсюду за исключением сетей CDN.
    Не отрежьте случайно свой ssh.

    CloudFlare имеет бесплатный вариант эккаунта. Но отмечу что нам заваливали 3 сайта которые находились на платном эккаунте. Атака велась из Вьетнама Кореи, Бразилии и Украины. Пытались блокировать по сетям прямо в CDN, но пакеты из заблокированных сетей всё равно долетали до наших серверов где мы их уже блокировали.

    По остальному смотрите что с бэкэнтом который готовит страници для nginx. Что с количеством процессов как они загружены сколько потребляют памяти и чего ждут. Атака это хороший случай чтобы над тем где бутылочное горло.
    Ответ написан
    Комментировать