- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Всем привет.
Имеется cloud server. centos 5
Суть проблемы: долбят 80-й порт, syn flood с ip spoofing на 70к pps (DoS идет скорее всего с VDS с 100мбит каналом)
в iptables
iptables -I INPUT -m conntrack --ctstate NEW,INVALID -p tcp --tcp-flags SYN,ACK SYN,ACK -j REJECT --reject-with tcp-reset
в sysctl
net.ipv4.conf.default.rp_filter = 1
Как можно защититься от подобной атаки?
Какие бы лимиты в iptables не прокатывают, я как понимаю поможет только аппаратный фильтр?
Поставьте
echo '1'>/proc/sys/net/ipv4/tcp_syncookies # включить синкуки
echo '1'>/proc/sys/net/ipv4/tcp_synack_retries # Слать только один овет synack
Лучше в правилах iptables ставить -j DROP, а не -j REJECT
Покажите кусок
tcpdump -n -c 50
Это всё у меня стояло, куки отправлять смысла нет, ip каждый раз - разный.
sysctl
---------- Добавлено 22.04.2012 в 22:04 ----------
tcpdump
pps летит жестко 😡
покажите лучше
vnstat -i ethХ --live
60к не смертельно, как вариант рассмотрите переезд на дедик если текущий сервер не справляется.
Думаю вообще отказаться от цепочек правил в iptables, ибо от них толку - 0 когда спуфят ip
эти 2 правила создают дикую нагрузку)
Переехать конечно же я всегда успею, разобраться бы как с этим бороться ;)
Думаю вообще отказаться от цепочек правил в iptables, ибо от них толку - 0 когда спуфят ip
Вам это волшебная фея рассказала? Никакого спуффинга IP в упор не видно. Обычный HTTP-флуд, только и всего.
Фильтруйте IP ботов по логам вебсервера, заносите на файервол iptables/ipset. Ничего необычного.
PS: И зачем вам -j REJECT --reject-with tcp-reset, интересно узнать?
Вам это волшебная фея рассказала? Никакого спуффинга IP в упор не видно. Обычный HTTP-флуд, только и всего.
Фильтруйте IP ботов по логам вебсервера, заносите на файервол iptables/ipset. Ничего необычного.
PS: И зачем вам -j REJECT --reject-with tcp-reset, интересно узнать?
На грубости не надо переходить ;)
Как вы можете судить о спуффинге судя по 50 записям tcpdump?
hping3 --flood --rand-source -S -p 80 dest_ip
и сервак лежит. никаких правил и sysctl не поможет. можете проверить на своих серверах на досуге ;)
Судя по логам IP там бесконечно, и если бы реально шел HTTP флуд то уж точно не на 31.04 Mbit/s и 73571 p/s
Вас спасут люди которые могут настроить такое ПО при котором проблем не будет с атаками
;)
А что, хостер не может помочь и отрубить аплингк по которому флудят?
покажите лучше
vnstat -i ethХ --live
60к не смертельно, как вариант рассмотрите переезд на дедик если текущий сервер не справляется.
Хороший способ защиты от спуфингово син флуда.
Я хочу прикупить у вас парочку таких волшебных дедиков.
p.s. Ты хоть сам понял что ерунду сморозил?
Для ТС. Вообще такую хрень надо фильтровать на вышестоящем узле, так как в лоб сервер такую атаку не переварит. И причин может быть
несколько.
Хороший способ защиты от спуфингово син флуда.
Я хочу прикупить у вас парочку таких волшебных дедиков.
мы синфлуд спуфленый для клиентов вычищаем.