Войти в систему

Home
    - Создать дневник
    - Написать в дневник
       - Подробный режим

LJ.Rossia.org
    - Новости сайта
    - Общие настройки
    - Sitemap
    - Оплата
    - ljr-fif

Редактировать...
    - Настройки
    - Список друзей
    - Дневник
    - Картинки
    - Пароль
    - Вид дневника

Сообщества

Настроить S2

Помощь
    - Забыли пароль?
    - FAQ
    - Тех. поддержка



Пишет Misha Verbitsky ([info]tiphareth)
@ 2009-12-04 21:05:00
Previous Entry  Add to memories!  Tell a Friend!  Next Entry
Настроение: sick
Музыка:Legendary Pink Dots - Chemical Playschool 3
Entry tags:ddos, kuklachev, ljr, spam

Попал под лошадь
LJR подвергся атаке Куклачева
кровавой гебни президента Путина
неизвестных недоброжелателей.

В общей сложности за сутки мы получили
чуть больше 50 миллионов запросов от вражеской
ботсети, где-то 20,000 зомбированных Куклачевым
кровавой гебней неизвестными недоброжелателями
компутеров (не иначе как под воздействием электричества).

Один из прокси-серверов лег сразу, другой
пока держится, и даже что-то показывает, но медленно.

В секунду получается около 600-1000 запросов,
в минуту тысяч 50.

Для развлечения почтенной публики, вот
кусок ботнета, выловленный из логов.
http://verbit.ru/LJR/botnet.txt
Там тысяч 5 хостов.

Масштаб акции потрясающий: нас атакуют из
всего мира, от Таиланда до Туниса.
Промышленное производство. Некоторые
из таких доменов, которые я вообще ни разу
не видел, типа .gh (Гана, что ли), .do
(Доминиканская Республика, очевидно) и
.tt (наверное, Тринидад и Тобаго).
Зимбабве тоже было. А что такое .vn
я даже догадаться не могу.

Логи я тоже хотел выложить, но там их
гигабайты уже, так что обломится.

Некоторые страницы LJR уже отключены
(ботнет умеет атаковать только одну или две).
Потом включим.

Атака такого масштаба стоит, кстати, недешево,
ну, думаю, Куклачев кровавая гебня не обеднеет.

Ботнетами реально торгуют, в основном для рассылки
спама, но часто и для ddos-атак. Виндоз это зло большое,
кстати.

А вот иллюстрация: по слухам, Куклачев
дрессирует кошек электричеством.


[info]l_u_f_t@lj, по ссылке от [info]mancunian@lj.

Привет


(Читать комментарии) - (Добавить комментарий)


[info]oona
2009-12-05 03:23 (ссылка)
Thank you. Understood, but I was also reading articles that say things like this:

In recent past zombie (another name for bot–infected computers) networks were controlled with the use of proprietary tools, developed intentionally by crackers themselves. Experience has lead to experiments with new remote control methods. IRC is considered the best way to launch attacks, because it is flexible, easy to use and especially because public servers can be used as a communication medium. IRC offers a simple method to control hundreds or even thousands of bots at once in a flexible manner. It also allows attackers to cover their identity with the use of simple tricks such as anonymous proxies or simple IP address spoofing. Thanks to this, server administrators have little chance to find the origin of an attack controlled in such a manner.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]kaledin
2009-12-05 03:33 (ссылка)
No, this refers to control messages -- commands from the attacker to the individual zombie-boxes. They are sent via IRC, and they are hard to trace. Zombieboxes themselves can be traced, but it is not very useful, there are thousands of them.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]oona
2009-12-05 04:47 (ссылка)
Thank you for the explanation.

(Ответить) (Уровень выше)


[info]rafail.livejournal.com
2009-12-05 04:54 (ссылка)
Да ничего подобного. В хедер исходящего с зараженного компа TCP-пакета вставляется какая-нибудь абракадабра вместо исходящего IP, и дело в шляпе. Поэтому-то Мише и кажется, что с ним весь мир воюет :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]grp
2009-12-05 05:57 (ссылка)
Это может быть IP spoofing, конечно.

Но по многим (наугад выбранным) IP Google выдает всякие черные списки, связанные с атаками и спамом.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 06:06 (ссылка)
Я говорю о том, как это бы было сделано, если бы я сам этим занимался. Как делают всякие говнорашкинские дебилоиды с балалайками - мне неведомо :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]grp
2009-12-05 06:15 (ссылка)
Но-но-но.

По спаму и ддосу говнорашкинские дебилоиды с балалайками
впереди планеты всей, я уверен.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 06:42 (ссылка)
дадад невпиздрические русские программеры

(Ответить) (Уровень выше)


[info]kaledin
2009-12-05 16:38 (ссылка)
>если бы я сам

Poka chto ty, skol'ko tebya vizhu, tol'ko pizdish'.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 22:00 (ссылка)
Это что за эльфийские руны? Перумов?

(Ответить) (Уровень выше)


[info]tiphareth
2009-12-05 06:06 (ссылка)
Мы отключили через ядро почти все возможности для спуфинга, то есть
оно неиллюзорно делает проверку аутентичности
# Enables source route verification
net.ipv4.conf.default.rp_filter = 1
# Enable reverse path
net.ipv4.conf.all.rp_filter = 1

я, конечно, тупой, но не знаю даже, при таких проверках
вообще возможен спуфинг или нет?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]grp
2009-12-05 06:38 (ссылка)
Понятия не имею.

Но rp_filter = 1 правильно.

(Ответить) (Уровень выше)


[info]rafail.livejournal.com
2009-12-05 06:42 (ссылка)
Вы что, всерьез полагаете что эта херота спрашивает через все интернеты у удаленного компа тот ли это комп? Она просто локально сверяет, может ли на данный сетевой интерфейс в принципе прийти пакет с такого адреса. Вот ламота-то, я ебу. А еще линуксоид.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 06:54 (ссылка)
Теоретически, провайдер может вписывать во все TCP-пакеты своего клиента тот IP, который он ему дал. Да только практически никто так не делает, ибо заебешься.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2009-12-05 14:56 (ссылка)
вписывать - не всегда реализуемо, зависит от того, как построено физическое подключение конечного пользователя.

на шлюзе провайдера можно (я бы сказал должно) блокировать исходящие из некоторой внутренней сети пакеты, ей по source address не принадлежащие.

но это ничего для Миши не меняет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 22:13 (ссылка)
Да конечно, это я так, пофантазировал. А почему вписывать нереализуемо в зависимости от физического подключения? Провайдерский шлюз же должен увязывать IP, которое он юзеру дал, с адресом юзерского железа (какое бы оно ни было, и как бы ни адресовалось), иначе как же он отошлет пришедший юзеру извне пакет.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2009-12-06 00:28 (ссылка)
сопоставление ip-mac происходит автоматически и динамически через arp. но mac адрес можно произвольно задавать. ваш сосед может выйти в сеть с вашим mac-адресом, если, скажем, подключен к той же самой открытой wifi сети. поэтому обычно реализуют доп. авторизацию по паролю.

это не касается peer-to-peer соединений.

(Ответить) (Уровень выше)


[info]pzz
2009-12-05 06:44 (ссылка)
Source route - это такая фича IP протокола, которая позволяет при отправке пакета указать, каким путем этот пакет должен идти. В мирной жизни не используется, эти пакеты надо не верифицировать, а просто выбрасывать.

rp_filter выбрасывает пакеты, если они пришли не на тот интерфейс, который был бы выбран для отправки паката назад, на source address. если у тебя один интерфейс, rp_filter ни на что не влияет.

от спуфинга помогают syn cookies. смысл их в том, что прежде чем линух потратит какие-то заметные ресурсы на TCP-соединение, та сторона должна подтвердить, что она умеет не только посылать, но и принимать пакеты по заявленному адресу

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2009-12-05 06:52 (ссылка)
Спасибо, дорогой.
Да, они у нас тоже есть.
Но говоришь, все равно есть риск спуфинга?

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 07:12 (ссылка)
да что тебе до этого спуфинга? да и наверняка роутер, который стоит перед тобой (от твоего провайдера и по дороге к тебе) весь этот спуфинг прибивает, как может

общий принцип защиты заключается в том, чтобы врагу было дорого добраться до того места в твоем сервере, где аллоцируются дорогие ресурсы

дешевле всего врагу посылать IP-пекаты веером (SYN-flooding). Но SYN-cookies от этого защищает: чтобы зааллицировать у тебя хоть какой-то ресурс, враг должен не просто посылать пакеты, а уметь на них отвечать. больше ты на попакетном уровне все равно ничего не добъешься

проблема в том, что в случае ddos-атаки враг запросто может организовать тебе море полноценных HTTP-запросов. т.е., не просто послать SYN и ответить на SYN-ACK, а пройти полный handshake, и добраться до твоего апача. у врага машин много, и не важно, что каждая из них больше десятка запросов в секунду не пошлет, суммарно все равно получается дохрена

я бы подумал в ту сторону, чтобы прежде чем добраться до дорогих, в плане ресурсов, мест, врагу надо продемонстрировать какое-то умение, более характерное для настоящего бровсера, чем для написанной на коленке хакерской программы. ну например, умение исполнять javascript. сейчас спать слишком хочется, чтобы предложить что-то более конкретное :-)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2009-12-05 07:26 (ссылка)
Картинка сейчас такая: супостат делает 1000 коннектов в секунду на
http://lj.rossia.org/ и http://lj.rossia.org/communities/ljr-news/
в которых он получает denied, но с таким количеством коннектов
он намертво забивает apache. То есть никаких тонких методов, просто
ботнет на 20000 мест, который шлет запросы по 10 штук в минуту
каждая машина.

Мы их давим, понятно.

>добраться до дорогих, в плане ресурсов, мест

Кажется, дешевле 403 все равно нет, только если через
IP-tables коннект сбрасывать.

(Ответить) (Уровень выше) (Ветвь дискуссии)


(Анонимно)
2009-12-05 15:31 (ссылка)
1k pps - это очень мало, тем более для описывавшихся когда-то вами серверов
nginx на прокси
sysctl net.ipv4.tcp_max_syn_backlog=4096
sysctl net.core.netdev_max_backlog=2500
отключить keepalive на апаче и покрутить таймауты для начала уже будет неплохо помогать

(Ответить) (Уровень выше)


[info]andris.livejournal.com
2009-12-05 15:43 (ссылка)
Неужели никто не догадался у Вас хотя бы nginx для облегчения труда Apache поставить? Ну воистину же: было бы желание сделать, а не поорать.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2009-12-05 19:36 (ссылка)
У нас там два кэширующих apache для фильтрации траффика. Nginx
был, но я его убрал, о чем сейчас жалею.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 21:54 (ссылка)
мы перешли с nginx'а на haproxy. только я забыл, почему :-) кажется потому, что не смогли добиться от nginx'а достаточной стабильности.

у нас, впрочим, не веб-портал, а ультрапроизводительный bittorrent tracker.

впрочем, никто из них тебе не поможет, если все запросы в конечном итоге будут попадать в апач. тот, кто стоит между апачем и внешним миром, должен каким-то образом отсекать мусорные запросы

(Ответить) (Уровень выше)


[info]pzz
2009-12-05 21:46 (ссылка)
а сколько запросов в секунду твой апач получает при мирной жизни?

я вот думаю, если на 80-м порту поставить редирект на https, а настоящий контент перевесить туда, может полегчает? вряд ли эти боты такие умные, чтобы понимать редиректы и ssl-протокол. говорят, обычный писюк без особого труда способен удержать 100-200 ssh handshakes в секунду (они вычислительно сложные, там какой-нибудь RSA, который заключается, содержательно, в возведении очень большого числа в очень большую степень).

а как развитие подхода, я бы отвечал не редиректом, а ява-скриптом, который вычисляет url с контентом и отправляет бровсер туда (или высасывает контент оттуда и рендерит в текущем окне). url, конечно, должен быть временным, обновляемым несколько раз в минуту (а еще лучше, чтобы он криптографически зависел от, например, IP-адреса, с которого пришел запрос), чтобы ботам пришлось таки продемонстрировать свое умение исполнять ява-скрипт - вряд ли они таким умением обладают

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2009-12-05 21:54 (ссылка)
Там сейчас все ддос-коннекты надежно отлавливаются и получают denied.
Думаешь, редирект сильно быстрее?

В нормальное время наверное где-то 1000 в минуту запросов, ага.

Мне насоветовали ставить nginx в качестве прокси (сейчас там апач),
сейчас попробую этим заняться

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 22:00 (ссылка)
ну 1000 редиректов в секунду - технически это немного. если только не дергать на каждый редирект какой-нибудь cgi-скрипт

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2009-12-05 22:54 (ссылка)
Я не очень понимаю, серьезная ли тут
экономия сравнительно с 1000 denied в секунду
(как сейчас)

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 23:54 (ссылка)
тут есть 3 ортогональных вопроса

1. можно ли терминировать 1000 http-запросов в секунду и чего-нибудь на них ответить? я считаю, что да, и без особого труда, но по-видимости, апач для этого не очень подходит. кстати, denied отвечает сам апач или какая-нибудь cgi'ка?

2. является ли частота запросов с данного IP-адреса надежным критерием, позволяющим отличить атаку от легитимных запросов? по-видимому, нет. 10 запросов в секунду - достаточно близко к тому, что живой человек может накликать, и двигать планку вниз особо некуда. с другой стороны, в какое положение планку не ставь, для врагов это лишь увеличивает количество компутеров, вовлеченных в атаку, а сильно ты уже это количество не увеличишь

3. можно ли предложить более надежный критерий, позволяющий отличить мусорные запросы от нормальных? мои рассуждения про ssl и ява-скрипт именно на эту тему. содержательно, я предлагаю заставить вражеский компутер продемонстрировать умения близкие к тем, которыми обладает нормальный полнофункциональный бровсер

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]tiphareth
2009-12-06 00:02 (ссылка)
>denied отвечает сам апач

Угу, он

>является ли частота запросов с данного IP-адреса надежным критерием

В данный момент они долбят только http://lj.rossia.org/users/tiphareth/
причем долбят его по 100 раз в минуту каждый IP. Нетрудно отличить.

(Ответить) (Уровень выше)


[info]rafail.livejournal.com
2009-12-05 08:06 (ссылка)
Ога, пусть RSA на жабаскрипте ломает. Вот когда сломает - получит свою вебстраницу на два килобайта

Кстати так можно на халяву делать распределенные вычисления. Считать простые компоненты радикальных дифференциальных идеалов например. Чем больше гениальных русских хакеров - тем быстрее результат

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 22:00 (ссылка)
ну что-то в таком роде, да

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 22:26 (ссылка)
Правда, жабаскриптовскую задачу надо на более низком уровне отсылать чем веб-сервер. Иначе шило на мыло получается, только трафика в два раза больше :-)

Опять же не вижу особой проблемы "хакерской программе" подключить жабаскриптовскую библиотеку на том же компе.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 22:38 (ссылка)
если ее отсылать из cgi-скрипта, то это, конечно, будет узким местом. но я не вижу причин, почему высокопроизводительный сервер, типа nginx'а, haproxy и т.п. не справился бы с этой задачей

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

и вторая вещь: задачки, которые мы подкидываем клиентам, должны быть по возможности вычислительно сложными, но чтобы проверить правильность ответа было легко. ну например, "к заданной последовательности байт подобрать продолжение такое, что sha1 от их конкатенации имеет последние 20 бит, равные 0". бот, который все время жрет процессор, гораздо заметнее пользователю, чем бот, который тихо шарится по интернету

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]rafail.livejournal.com
2009-12-05 22:45 (ссылка)
Я не знаю как в виндовсе устроено, но в линухе же можно те же самые библиотеки/плагины подключать, что каким-либо браузером используются. Ничего там не надо переписывать, интерфейсы библиотек открытые.

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]pzz
2009-12-05 23:56 (ссылка)
ну, задача "написать веб-бровсер из готовых компонентов" безусловно имеет решение. но я хочу сказать, это достаточно трудоемкая задача, несмотря на доступность готовых компонентов. и существует вероятность, что злобные хакеры не станут ее решать, или не справятся

(Ответить) (Уровень выше)


[info]tiphareth
2009-12-05 22:53 (ссылка)
Ну, данная конкретная фигня, в принципе, убивается на раз, если
просто банить через IP-tables все хосты, которые запрашивают
слишком много или слишком часто одно и то же. В теории, это
можно делать в Apache модулем mod-evasive, но на практике почему-то
mod-evasive не сработал. Сейчас оно, кажется, глобально побеждено,
но скорее всего ненадолго

(Ответить) (Уровень выше) (Ветвь дискуссии)


[info]ksenija.livejournal.com
2009-12-06 10:35 (ссылка)
Eto pravil'no. Nuzhno ispol'zovat' modul' "recent" iz iptables, kak opisano zdes':

http://www.debian-administration.org/articles/187

prosto nuzhno podobrat' parametry, harakterizujuschie etot botnet.
Udachi!

(Ответить) (Уровень выше)


[info]rafail.livejournal.com
2009-12-05 07:26 (ссылка)
syn-кукиз просто помогают вашему серверу не рухнуть под напором говна. Но юзерам ваш сервер все равно не видно, что так, что эдак. А конечный смысл в том, чтобы юзерам ваш сервер было видно.

(Ответить) (Уровень выше)


[info]mao
2009-12-06 03:05 (ссылка)
IRC is THE shit, btw

(Ответить) (Уровень выше)

(Читать комментарии) -