DDOS атака на FileShare
Собственно досят файлшару уже давно. Но атака была слабая и, хотя и приводила к не сильно хорошей работе сайта, он нее без проблем отбивался наш скрипт, фаерволя подозреваемых в атаке на 10 минут. Однако неделю назад такая атака прекратилась и началась атака другого рода, намного более сильная. Она пробивала скрипт защиты (из-за высокой нагрузки он просто не успевал отрабатывать) и вроде неплохо нагружала веб-сервер.
Упала посещаемость, особенно хиты, все стало долго открываться, часто не открывался вообще (gateway timeout) и в общем сайт чувствовал себя нехорошо. Небольшая оптимизация позволила кое-как работать и мы начали думать над тем, чтобы как-то отбить атаку. Оптимизировать было больше нечего (по крайней мере существенного), разве что сайт по-новой переписать на основе той архитектуры, о которой я писал немного раньше.
Решение пришло само-собой - у нас в том-же ДЦ что и веб-сервер стоят еще и файловые сервера, у которых очень нагружены винты, но проц и память практически гуляет (а так-же винт на которой стоит система). Среди таких серверов нашелся двухядерный оптерон с 4Гб оперативы, решили сайт перенести туда. Чтобы не менять записи в ДНС, не юзать забитые каналы, которые служат для раздачи файлов итд мы сделали следующее: оптерон был настроен для работы в качестве backend сервера, на основном сервере в конфиге nginx прописали для домена fileshare.in.ua этот backend, а остальные сайты (их на том сервере всего около десятка, кроме файлшары, суммарной посещаемостью порядка 15К хостов и 70К хитов в сутки) оставить как есть.
Решение помогло на какое-то время, сайт стал нормально работать и другие сайты тоже порезвее стали отзываться. Где-то через часов 6 после такого вот нововведения атака усилилась в несколько раз. Оптерон не выдержал, файлшара снова просела, однако остальные сайты, которые работали не на оптероне, а на основном веб-сервере отлично отзывались.
На этот раз я решил что файлшара важнее и сделал кластер: файлшара работала на обоих серверах, балансировку делал nginx, а остальные сайты крутились на основном. При чем для файлшары веб-сервер был прописан как резервный (т.е. на основном сервере скрипты файлшары выполнялись только если оптерон умер), и, чтобы долго не ждать, я установил параметр ожидания ответа от backend 2 секунды. Все наладилось, отперон не всегда выдерживал, был постоянно загружен на 100%, но второй сервер подхватывал сайт, если оптерон падал и все более-менее работало.
Видимо злоумышленники следили за развитием событий потому, что буквально через час, после того как я развел нагрузку с файлшары на 2 сервера на атаку были кинута большая часть ресурсов. Входящий трафик подрос в 3 раза по сравнению с обычным (дальше ему просто уже некуда расти из-за ограничений провайдера), сайт упал и не поднимался, загрузка сервера (любого) была на 100% уже сразу после рестарта апача, la на основном сервере подскочил до 60, все было в ступоре небыло никаких шансов подняться. Атака шла не только на файлшару но и остальные сайты, даже по ssh зайти было проблемой (не смотря на повышенный приоритет) и я потушил nginx, чтобы иметь возможность что-то сделать. Видимо по маштабам атака была сравнима с теми, от которых лежал 0day и progs не так давно. Не знаю уж кому мы так жить мешаем, но думать об этом небыло времени… через 20 минут атака была полностью отбита;)
Первым делом я добавил в кластер еще 3 машины. Во-вторых замаунтил на все машины по nfs исходники сайтов, подрехтовал конфиги апача и пхп и перевел сессию на mysql. Теперь все сервера могли работать как backend’ы. После этого я поставил на все сервера APC (php-акселератор), проверил работоспособность сайтов на каждом из серверов, прописал их в конфиге nginx и снова его запустил.
Атака, которая легко посадила 2 сервера, на этот раз спасовала. Входящий трафик не уменьшился, атака шла до утра, но всем сайтам на хостинге это уже было по барабану. Даже ab в 200 потоков, который я запустил параллельно с атакой ничего не изменил. Я боялся за базу - она хоть и на мощной машине, но на одной, однако, видимо за счет агрессивного кеширования, база справилась. la на веб-сервере опустился до 3, на сервере появился idle и тут-же взялся за дело антидос-скрипт. Запросы валили шквалом, однако антидос находил время их анализировать и забанил самых активных, тем самым снизив нагрузку где-то на 40%.
Итог: во время атаки сервера были загружены не более чем на 60% (много ресурсов отжирала раздача файлов), все сайты (даже на Вордпрессе) откликались быстро, атака шла лесом. Сегодня полдня пришлось потратить на поиск багов, которые появились в связи с такой сменой архитектуры, однако в целом результат хороший. Будем надеяться, что сайт теперь защищен от ДДОС полностью. Почему полностью? потому что в ua-ix не будет достаточного количества компьютеров, чтобы его положить, а ширина входящего мира такова, что сама сдержит большой наплыв ботов. Максимум, чего можно будет добиться, так это того, что сайт не будет доступен из мира, однако и для этого надо будет сильно постараться.
По крайней мере это мой оптимистичный прогноз, думаю, что организаторы атак не остановятся на достигнутом и сайт еще не раз проверят на прочность (да у и нас есть еще гуляющие сервера+можно собрать mysql кластер), однако то что какое-то количество денег они уже спустили в унитаз (10 часов безрезультатной достаточно массированной атаки), это радует. Желаю им еще и Лексус чей-то побить не имея страховки;)
Мотивы таких вот уродов не сильно понятны, но пока сайт держится, пока я и не буду этим интересоваться. Надеюсь теперь сайты будут работать лучше, чем последние 7-8 дней (исключая сегодня).
04.11.2007 в 17:13
Так в проблеме
>>Волнообразность и нестабильность вызвана далеко не Колоколом. Я >>напишу позже,
>>ориентировочно в понедельник.. Получилось очень нехорошо и
>>один из самых авторитетный ДЦ выставил себя в очень плохом >>свете.
не виноват ?
а Ддос случаем вчера(3.11.2007) часиков этак в 16 на площадке колокола не наблюдался ?
P.S. вариант попроще для устранения Ддоса в твоем случаи когда канал на мир все равно был забит, положить мир….
04.11.2007 в 18:11
Да уж, бывает. Конечно жаль что теперь в отличии от того что было ранее все чаще и чаще “too many connections from your ip”, тем не менее желаю удачи в развитии и работоспособности :)
05.11.2007 в 02:57
Кстати - о мотивах. Не борцуны ли с нелегальным контентом? Вряд ли они такие моралисты…
05.11.2007 в 06:11
а повесить сессию на memcached не догадались ? фигли базу грузить? тем более всякий там row-locking..
05.11.2007 в 11:55
Мускульный кластер - идея хорошая, но пока ты его доведешь до стабильной работы - врятли это будет уже актуально :) Гораздо проще сделать репликацию, и писать на мастер, а читать со слейва. При этом можно будет мускуль затачивать один на запись, другой на чтение. + твое кеширование - хорошая вещь :) У нас так когда-то VoIP биллинг работал на 800 тыщ абонентов :)
05.11.2007 в 13:25
Да уж… Кластер против ДДоС практически единственное что может защитить
06.11.2007 в 18:27
Я никогда не понимал людей, которые пытаються вредить. Все наверное потому, что не могут сделать что-то стоящее самостоятельно…
08.11.2007 в 00:51
2 kost BebiX
ну это фича;) ограничение для обычных аккаунтов. И местами для премиумов.. иначе бы сервера давно лягли
2 adsh
вот уж не думаю;)
2maserg
Та мы тут только что книжку по пхп прочитали, что такое memcached?=)
Если серьезно, то он кеширует запросы и кое что еще с самого начала работы сайта;)
2onorua
А что, в 5м МуСКЛе нестабильный кластер? Мне говорили что в 5м все ок, просто прописать в конфиге и все..
Посмотрим как будет.. если будет геморно сильно, то я просто переведу базу на самый крутой сервак и все.. сейчас немного оттюнил, вроде дышит..
08.11.2007 в 15:09
ага, и в итоге делаем сессии на БД…. :)
08.11.2007 в 15:10
прямо как в книжках про пхп…. :)
08.11.2007 в 15:11
ты считаешь что сессии можно хранить в мемкеше? ну попробуй=)
для сессий юзается другой сервер БД
08.11.2007 в 15:15
где их еще хранить, если не в БД? по nfs маунтить что-ли? вот это как раз и есть глупость, он работает в разы медленнее чем хранение в базе..
08.11.2007 в 18:08
ги, а ты считаешь что нельзя? :)
уже попробывал….
рекомендую к прочтению http://php.net/manual/ru/ref.memcache.php
ключевая фраза:
ini_set(’session.save_handler’,'memcache’);
это если встроенный….
http://dozo.matrix.jp/pear/index.php?PECL%2Fmemcache%2Fsession_support
или можно руками написать такую же байду, которая у вас юзает БД в качестве хранения…
первый пример из гугля
http://imysql.cn/?q=node/215
первое ествественно работает быстрее, чем второе
08.11.2007 в 18:24
вот для примера.
ini_set(’memcache.allow_failover’,'0′);
ini_set(’memcache.max_failover_attempts’,'20′);
ini_set(’memcache.chunk_size’,MEMCACHE_CHUNK_SIZE);
ini_set(’memcache.default_port’,MEMCACHE_PORT);
ini_set(’session.save_handler’,'memcache’);
ini_set(’session.save_path’,'tcp://’.MEMCACHE_HOST.’:’.MEMCACHE_PORT.’?persistent=1&weight=1&timeout=1&retry_interval=5′);
есть еще секрет: memcached умеет работать по udp
08.11.2007 в 23:36
>>ги, а ты считаешь что нельзя? :)
Я не считаю что нельзя, я считаю что не нужно. memcache не гарантирует сохранение объектов, как только память, которая у него есть (сколько там выделено в конфиге) у него заканчивается, некоторые объекты уничтожаются.
Т.е. сессия юзера может просто удалиться, при большом количестве людей на сайте. Понятно, что если выделить много памяти (пару гиг) то скорее всего она не закончится, но в один прекрасный момент, прийдется столкнуться с тем, что на сайт зашло уж очень много людей и сессии стали теряться. Кроме того что это явная бага, которую сами сознательно и написали (зная про особенность memcache не гарантировать хранения объектов), так еще и, возможно, прийдется провести несколько замечательных часов пытаясь найти проблему, особенно если пройдет несколько месяцев. Ведь проявляться она будет только в продакшене и при большом наплыве народа и далеко не у всех (у разработчика в том числе может не проявляться).
Так что спасибо конечно за советы (если бы я даже не знал про то, что у ПХП в конфиге можно менять переменные, я бы наверняка догадался просто подправить класс сессий, чтобы он не в базу ложил в мемкеш), но пока не впечатляет. Даже то, что умеет работать по upd (где бы это нам тут могло пригодиться?)
09.11.2007 в 03:56
memcache в этом отношении ничуть не уступает по надежности БД, с которой тоже что-то может случиться…
более того сессии имею особенность уничтожаться после заданного TTL, освобождая память.
что вы храните в сессии? сколько она занимает? килобайт? сколько вы ожидаете активных посетителей? миллион? 10 миллионов?
при каждом рефреше создаётся соединение к бд, которое уже даёт гарантированный delay. раскидывая по бекам, уменьшаем delay, но увеличиваем кол-во коннекшенов к БД. сколько их выдержит мускл?
более того, большинство высоконагруженных проектов используют именно эту схему, что говорит о многом. (иногда с периодическими сохранялками данных из МК на диск, иногда с бекендом ввиде БД (после мемкеша))
просто так:
http://www.mysqlperformanceblog.com/2007/03/27/php-sessions-files-vs-database-based/
udp шустрее tcp, учитывая высоконадежность соединения машин в DC можно гонять сессии по нему. в случаи невысоконадежных соединений, udp естественно отпадает.
интересно, а у вас в БД с сессиями myisa или innodb ?
09.11.2007 в 13:07
>>memcache в этом отношении ничуть не уступает по надежности БД, с которой тоже что-то может случиться…
С мемкешем может случиться переполнение памяти, что ситуация вполне нормальная и предсказуемая. Так что я бы не стал утверждать что мемкеш по надежности хранения ну уступает базе. А случиться может со всем, не только с базой.
>>что вы храните в сессии? сколько она занимает? килобайт? сколько вы ожидаете активных посетителей? миллион? 10 миллионов?
Любая ДДОС атака без проблем создаст хоть 10 миллионов;) И сколько бы под кеш не выделили памяти (хотя у меня на сервере всего 3Гб на том, больше чем гиг я не выделю) есть неплохой шанс что атака создаст столько сессий что многие валидные сессии пользователей просто будут удалены из мемкеша. Что я считаю неприемлимым.
>>при каждом рефреше создаётся соединение к бд
или не создается, если юзать pconnect ;) К слову, даже не сильно мощный тазик выдерживает особо не напрягаясь 1000 записей/считываний по ключу в секунду, если таблица не содержит много данных в одном ряде (row), что справедливо в случае сессий.
Так что скорость работы с сессиями - наверное последнее во что упрется сервер при атаке. Я это проверял и проверял производительность такой вот работы с БД, когда создавал систему статистики (рейтинг для СМИ).
И другим, перед тем, как что-то советовать или осуждать какую-то из используемых мною методик, советовал бы тоже проверить и поделиться _своими_ результатами.
по поводу последнего - myisam.
09.11.2007 в 15:21
если pconnect, то это всегда упрётся в максимальное кол-во соединений с сервером. или он миллион создасть коннекшенов?
что будет дальше? “не могу создать соединение?”
про систему статистики: если в ней используется ДБ (а тем более mysql)- то это очень слабенькая система статистики, со слабенькой нагрузкой, очевидным пределом и очень плохой масштабируемостью… будет там нагрузка побольше, оно всё ляжет…
чтение-запись? а локинг как-же? для myisam например? а при наплыве посетителей?
http://rutube.ru/tracks/197537.html?v=52f40f83d2363cd555561afd73aef639
http://www.rit2007.ru/paper_view.html?id=1362&show=1
эти методики вообще-то не обсуждаются :) хранение сессий в БД не есть ноу-хау, ей 100 лет в обед… :)
более того я вообще не советую, а предлогаю рассмотреть варианты…. типа “сочувствующий”. мне очень нравится, когда люди что-то делают реально полезное, а не стоят со спид-ганом на дороге или “эвакуируют” машины, при этом им еще кто-то палки в колесе вставляет…
для несогласных: да, “файло-помойка” в UA-IX - это полезная штука, или всем на репидшару ходить?
11.11.2007 в 03:54
Чувак, продолжай писать — увлекательно выходит.
12.11.2007 в 14:37
абязательна, чувак!
13.11.2007 в 00:15
Я взял небольшой таймаут, хочу кое-что узнать из первых рук насчет систем статистики и СУБД. Как будут точные данные, я скажу. Думаю, что будет интересно.
По остальному тоже отвечу заодно.
27.11.2007 в 12:31
Опять упала файлшара…
27.11.2007 в 14:48
Ага, немного по-другому решили задосить. Получилось(
но поднялись практически без потерь.
05.12.2007 в 20:36
На роутере поставте защиту от SYN атаки + Load Balancer + IP Connection Limit
05.01.2008 в 22:35
Забавная маза, у меня вот сейчас уже с неделю один сервак досят…
благо есть скрипты которые в автомате это все в блеклист закидуют..
Сейчас в нем больше 40к хостов
07.01.2008 в 15:26
40 или 40000? Если 40 то это больше прикол чем атака;)
2CHEP - это не поможет. load balancer это в принципе nginx, ip connection limit он тоже умеет, проблема в том, что большие сети с nat об этот лимит спотыкаться начинают.