Pull to refresh

Comments 55

класс, статья призвана научить я так понимаю.

1. было бы неплохо комментарии хотя бы на блоки конфигов зачем оно все.
2. вкратце обьяснить для чего нужен софт.

я понимаю что можно пойти и почитать все в гугле или мануале. ну раз можно — зачем тогда ваша статья ?:)
полностью согласен.
ИМХО, в сфере безопасности howto типа «напишите это и кликните тут» совершенно неуместны.
А если, к примеру, 50к хостов атакует, этот способ поможет?
Да, но нужно разносить lighttpd, backend и varnish на разные машины. Лайти выдержит любую нагрузку, а вот varnish при большом количестве коннектов начинает работать немного криво, потому и пришлось ставить несколько серверов varnish и включать кэш у lighttpd.
Лайти не выдержит любую нагрузку, точнее даже сетевая подсистема умрет от 50К одновременных запросов. Тут надо скрипты для бана подключать, а в случае с такими объемами еще и на несколько серверов разносить и использовать ddns.
# netstat -tapn | grep 1.2.3.4:80 | wc -l
47189

=)
Это не отражает реальную картину. 50К висящих соединений это не 50К запросов одновременно.
У лайти есть статистика по количеству запросов в секунду. При 50К ботов будет где-то 200-500К запросов в секунду. Ну или по крайней мере не меньше 50К.
было бы интересно увидеть такую статистику и узнать как себя ведет сервер
Лайти говорит о ~2.5к одноременных запросов. Сервер по CPU загружен на 10-15% (AMD Athlon X2 4400) кроме лайти на этом сервере крутится один из серверов varnish.
При и на порядок более меньшем количестве хостов http флуда уже надо принимать меры по
ограничению количества параллельных коннектов с 1го ип и ограничения количества создания тсп сессий к вашему 80му порту в еденицу времени (речь не про син-кукисы, а про полноценные конекты).
И делать это желательно на уровне файрвола.

Кроме того, надо отслеживать както ддосящие хосты и добавлять их в DROP цепочки.

Как и чем — вторично. Главное не надеятся только на фронтенды.
50к динамических хостов?
для 50к (равно как и для 5к) есть ipset из path-o-matick, правда там 65к лимит, но никто не мешает иметь несколько сетов
А я делаю так
rrdns на домен
N штук веб-морд которые отдают статику nginx (200k с каждого тазика)
1 штук мастер-сервер, который вливает контент на морды

Для динамических сайтов и форумов такое решение не очень, но если надо держать шквал посещаемости на обычном сайте — это решение с большим КПД
Может перенесёте в тематический блог? (вдарил по карме, теперь её 5)
Защита информации. Для начала нужно зайи на страницу блога и в него вступить
Каким образом это относится к защите информации? Скорее уж «системное администрирование» какое-нибудь.
или чтото на тему highload
Мало спал много работал =)
Спасибо исправил.
Как то сложно все, чем это решение отличается от родного nginx с тем же кэшем и ограничением коннектов? Зачем кэшируем в лайти и что за варниш?
UFO just landed and posted this here
C ngnix не работал, это просто еще одно решение. И интересно ngnix не убьет тот-же самый apache на vps при обработке 50к запросов одновременно?
nginx в данном случае может еще взять еще кусок работы на себя. Например, количество соединений с ip. Хотя там есть опции и поинтереснее.

А вот насчет апача, спорно. Для php лучше работает php-fpm, для остальных ЯП возможно тоже есть альтернативные решения. Очень уж прожорлив на память это апач.
Ну и да, 50К запросов и ваше решение ниразу не выдержит. И не только на ВДС.
А если я наоборот хочу создать хаброэффект, что бы проверить работоспособность и какой пик нагрузки?
Как это можно без создание глупого топика в «Я пиарюсь»?
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
он реально медленней/тяжелей на проксировании? Сам не пробовал, негде, но на вскидку то что он умеет purge cache по http запросу уже хорошо
UFO just landed and posted this here
Спасибо за дополнение к моим TCP/IP конфигам :-)
От хабраэффекта спасает nginx — проверено.

Недавно оставил ссылку в комментариях, так у меня в течении нескольких часов сервер лежал ))… пока не поставил nginx www.picamatic.com/view/4868857_ram_day/
«Недавно»? А на watermark'е написано «RUcenter 2006»…
)) забавно. График недавний. Может это у них типо копирайта? :)))
отдельная машинка c BSD и nginx как frontend
vm.dirty_ratio = 1
vm.dirty_background_ratio = 1
vm.dirty_writeback_centisecs = 250
vm.dirty_expire_centisecs = 3000

это призвано сделать что?
Я что-то упустил. А для чего используется varnish c кешем, если в быстром лайти в самом есть кеширующий модуль?
Лайти настолько быстрый, что пока он пытался прокэшировать под таким шквалом запросов, бекэнд умирал от запросов лайти =)
Ага, а varnish более умный хоть и более медленный как-то не грузит при этом бакенд или дело в том что varnish-ы сидят за балансером?
да все верно, а варниши сидят за лайти (что-бы не загнулись) + конечно распределение нагрузки, в текущей схеме, варниш ресурсы вообще не жрет ни на одном из хостовв =)
А как данная связка будет работать в случае если пользователь на сайте может залогиниться и контент ему будет отдаваться уникальный?
Для каждого пользователя будет создавать отдельная страница с кешом?
Или такой вариант этой схемой не предусмотрен?
Предусмотрен, в теории должно кэшировать в конфигурации по умолчанию, на практике надо тестить, возможно придется вносить изменеия в конфигурацию варниша.
То есть пониманием того, что пользователь залогинен и созданием для него закешированных данных занимается варниш? лайт занимается только быстрой отдачей этого кеша, и в теории ничто не помешает поменять его на nginx?
ничто не помешает боту залогиниться и продолжить флуд от авторизованного пользователя
А лучше понять, по какому признаку (читай: по какой куки) работает кэш, и флудить от «разных» пользователей, чтобы гарантированно положить бэкенд.
на самом деле одна из корневых защит от ддоса — быстрые веб-приложения и >1 сервера минимум. Т.е. если не почивать себя приятными мыслми, что «ну намана, 60-70% CPU на сервере юзается при обычной работе», а разгонять проект до минимум 200-300 req/s с одного ядра, то бится с ддосом уже будет много легче, чем если и так сервер еле тянет не проект.

во-вторых моё мнение — при ddos бан просто _необходим_. Как минимум чтобы по тем IP кто в бан попал стопроцентно раскидать abuse по подсетям =).

в-третьих перебор с нагрузкой по http надо обрабатывать не просто отрубалкой соединений, но и показом чего-нибудь злого на экран, типа «извините, сервера в данный момент перегружены» и блаблабла. По секрету говоря, у ддосеров такие сообщения (а они явно наблюдают за сайтом!) вызывают ощущение «защищённости» ресурса куда больше, чем просто timeout на соединение.

в-четвертых, в комплекс все этих мер ОБЯЗАТЕЛЬНО надо делать шейпинг для ssh-трафика! Через htb/qdisc хотя бы.

в-пятых, нужна «резиновость». Атака стоит денег и не имеет смысла если не приносит никакой выгоды. Именно поэтому любой проект изначально должен иметь возможность подключать сервера в кратчайшие сроки. Чтобы за 1 день, например, можно было бы взять 1-2 сервера за 1 день и быстро там все устаканить, удвоив стойкость. Тут удобны разные cloud хостеры, само собой. Конечно, это будет стоить денег, но охоту атаковать если она не приносит результатов вообще — это отбивает начисто.

в-шестых, надо сесть и написать «антидос» на Си =)).
Уважаю за то что помог людям безвозмездно :) Мы — Русские! Должны помогать друг другу! (с) плюсик тебе.
lighttpd отлично, порт поменять прекрасно, оптимизация iptables замечательно,
Varnish можно заменить Tinyproxy, ratproxy и т.п.
Небольшая поправка:
mod_cache не скомпилирован если устанавливать из репозиториев ubuntu 12.04
т.е. как я понимаю — единственный вариант, компилировать из исходников.
Sign up to leave a comment.

Articles