А почему с России столько DDoS атак?
Всем привет!
Меня недавно спросил товарищ с Бразилии - "а почему c Вас из России так много атак льется?"
Жаловался он предметно, на прилетающий ему почти гигабит мелкого мусора из сети одного нашего известного ШПД провайдера.
Я где-то полчаса думал прежде чем начал отвечать, но довольно скоро понял - что я не знаю что писать и почему так выходит.
Предлагаю обсудить причины подобного, так как именно в этом причина обсуждаемых в соседнем топике мер по противодействию.
On Tue, Oct 13, 2015 at 07:11:05PM +0300, Pavel Odintsov wrote:
Всем привет!
Меня недавно спросил товарищ с Бразилии - "а почему c Вас из России так много атак льется?"
Жаловался он предметно, на прилетающий ему почти гигабит мелкого мусора из сети одного нашего известного ШПД провайдера.
Я где-то полчаса думал прежде чем начал отвечать, но довольно скоро понял - что я не знаю что писать и почему так выходит.
jimho, это следствие нескольких особенностей региона: - ADSL и DOCSIS (с их асимметричными полосами up/down) развиться особо не успели: в девяностых и начале нулевых телекомам было ещё немного не до того, а в конце нулевых уже пошло развитие независимых ETTH-сетей, с симметричным up/down (как следствие, гораздо более удобные для торрентокачания), что и добило асимметричные скорости.. В результате средняя полоса на upload у абонентов побольше будет. А в более широкую полосу больше ddos'а влазит.
- в случае с ETTH клиенту, по большому счёту, не нужна CPE: он может воткнуть в сеть почти всё, что угодно. Как показывает практика - он этим пользуется и действительно втыкает всё, что угодно :( В результате на границе сети стоит не предоставленный провайдером "модем" (с возможностью обновления софта и конфигов), а куча железа, которое контролируется самими пользователями (ну, то есть, не контролируется от слова совсем). На одной из прошлых работ (pppoe-доступ с честными адресами) насмотрелся я и на винду, торчащую голым каком в холодном интернете c отключённым firewall'ом и на "короёбочки-рОутеры" с открытым внешним управлением из интернета и паролем admin/admin..
PS: обе особенности, jimho, наблюдаются не только в России, но и по большинству стран постсоветского пространства. Просто у нас пользователей побольше :)
On Tuesday 13 October 2015, Alexandre Snarskii wrote:
а куча железа, которое контролируется самими пользователями (ну, то есть, не контролируется от слова совсем).
Это хороший подход, на самом деле. Просто операторы, в погоне за клиентом, даже если abuse@ читают, стесняются клиента отключить за проблемы, возникающие из-за настройки его оборудования.
Вариант с асимметрией не рассматривал - интересно, спасибо!)
Неоднократно слышал мысль о том, что контролировать и фильтровать трафик ШПД клиента - моветон. Мол слишком сложная задача никак не относящаяся к оператору.
Со стороны ДЦ / хостера могу сказать, что жалобы на ддос разруливаем в худшем случае несколько часов в любое время суток.
2015-10-13 22:13 GMT+03:00 Sergey Y. Afonin asy@kraft-s.ru:
On Tuesday 13 October 2015, Alexandre Snarskii wrote:
а куча железа, которое контролируется самими пользователями (ну, то есть, не контролируется от слова совсем).
Это хороший подход, на самом деле. Просто операторы, в погоне за клиентом, даже если abuse@ читают, стесняются клиента отключить за проблемы, возникающие из-за настройки его оборудования.
-- С уважением, Сергей Афонин asy@kraft-s.ru _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
On Wednesday 14 October 2015, Pavel Odintsov wrote:
Неоднократно слышал мысль о том, что контролировать и фильтровать трафик ШПД клиента - моветон. Мол слишком сложная задача никак не относящаяся к оператору.
Контролировать - это хорошо бы, но Volodymyr Litovka верно сказал про затратность решения. Фильтровать, разумеется, не стоит. А вот по поводу "никак не относящаяся", то, на самом деле, пресекать неправомерные действия - это не то, что не моветон, а должно быть обязанностью оператора. Если таковые действия совершаются за счёт оборудования пользователя, это пользователя ни коим образом не извиняет. По хорошему, надо прописывать условия ответственности за некорректную работу оборудования в договорах и предусматривать там отключение до устранения проблемы.
On 14 Oct 2015, at 10:39, Sergey Afonin asy@kraft-s.ru wrote:
On Wednesday 14 October 2015, Pavel Odintsov wrote:
Неоднократно слышал мысль о том, что контролировать и фильтровать трафик ШПД клиента - моветон. Мол слишком сложная задача никак не относящаяся к оператору.
Контролировать - это хорошо бы, но Volodymyr Litovka верно сказал про затратность решения. Фильтровать, разумеется, не стоит. А вот по поводу "никак не относящаяся", то, на самом деле, пресекать неправомерные действия - это не то, что не моветон, а должно быть обязанностью оператора. Если таковые действия совершаются за счёт оборудования пользователя, это пользователя ни коим образом не извиняет. По хорошему, надо прописывать условия ответственности за некорректную работу оборудования в договорах и предусматривать там отключение до устранения проблемы.
Смахивает на утопию. Времена когда технари рулили телеком давно в прошлом. Воевать со своими абонентами во имя благой цели чистоты инета не многие лишь могут, особенно если это напрямую не афектится на бизнес оператора. Да и тех кто решится - неминуемо ждет провал. Ибо разнообразие архитектур клиентских устройств и возможных уязвимостей неподъёмны ни для конечных юзеров, ни для оператора. Последним остается только нивелировать данные угрозы в своей зоне ответственности - за это собственно нам (технарям) и платят. Ну и порассуждать как сделать этот мир лучше канеш :)
-- С уважением, Сергей Афонин asy@kraft-s.ru _______________________________________________ discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
Best Regards, Yaroslav Kapsalov
BCP38/BCP84 - это не война с абонентами, это гигиена в собственной сети.
-- Cheers, Sergey
On 14 Oct 2015, at 10:52, Yaroslav yksmoke@gmail.com wrote:
Воевать со своими абонентами во имя благой цели чистоты инета не многие лишь могут, особенно если это напрямую не афектится на бизнес оператора
On 14 Oct 2015, at 11:05, Sergey Myasoedov sergey@devnull.ru wrote:
BCP38/BCP84 - это не война с абонентами, это гигиена в собственной сети.
-- Cheers, Sergey
On 14 Oct 2015, at 10:52, Yaroslav yksmoke@gmail.com wrote:
Воевать со своими абонентами во имя благой цели чистоты инета не многие лишь могут, особенно если это напрямую не афектится на бизнес оператора
Речь шла об отключении абонентов пока не починятся, а не о инструментах в зо провайдера вроде urpf и прочих антиспуфах
Best Regards, Yaroslav Kapsalov
On Wednesday 14 October 2015, Yaroslav wrote:
Да и тех кто решится - неминуемо ждет провал. Ибо разнообразие архитектур клиентских устройств и возможных уязвимостей неподъёмны ни для конечных юзеров, ни для оператора.
Так я не зря приводил пример с автомобилем. Если клиент не умеет сам, то пусть нанимает кого-нибудь, кто умеет. Маркетологи виновны в одном: создали видимость того, что доступ в Интернет - обычная бытовая услуга, как телевизор какой-нибудь.
Так на чем же остановились? Антиспуф включать или нет? :)
Да :)
On 10/19/15 2:33 PM, Vladislav V. Prodan wrote:
Так на чем же остановились? Антиспуф включать или нет? :)
-- Vladislav V. Prodan System & Network Administrator support.od.ua http://support.od.ua
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
Но если включите не поближе к пользователям, а только на выходе из своей автономки - то спуфить все равно будут, но с src ip рандомным не вообще, а только из вашего адресного пространства :-)
On 19.10.2015 14:39, Volodymyr Litovka wrote:
Да :)
On 10/19/15 2:33 PM, Vladislav V. Prodan wrote:
Так на чем же остановились? Антиспуф включать или нет? :)
-- Vladislav V. Prodan System & Network Administrator support.od.ua http://support.od.ua
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
-- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
19 октября 2015 г., 17:09 пользователь Stepan Kucherenko twh@megagroup.ru написал:
Но если включите не поближе к пользователям, а только на выходе из своей автономки - то спуфить все равно будут, но с src ip рандомным не вообще, а только из вашего адресного пространства :-)
Есть примеры использования? ACL на каждом порту подключения? Антиспуфинг до NAT'a ?
Ну, зависит от организации "последнего фута". Например, DHCP Snooping и вот это вот всё.
2015-10-19 17:23 GMT+03:00 Vladislav V. Prodan admin@support.od.ua:
19 октября 2015 г., 17:09 пользователь Stepan Kucherenko <twh@megagroup.ru
написал:
Но если включите не поближе к пользователям, а только на выходе из своей автономки - то спуфить все равно будут, но с src ip рандомным не вообще, а только из вашего адресного пространства :-)
Есть примеры использования? ACL на каждом порту подключения? Антиспуфинг до NAT'a ?
-- Vladislav V. Prodan System & Network Administrator support.od.ua
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
19 октября 2015 г., 18:59 пользователь Alex Semenyaka < alex.semenyaka@gmail.com> написал:
Ну, зависит от организации "последнего фута". Например, DHCP Snooping и вот это вот всё.
DHCP Snooping в той реализации в массовых устройств на доступе никак не защитит от IP спуффинга.
ACL-и или uRPF на смотрящих в сторону абонента интерфейсах, желательно как можно ближе к ним.
К абонентам за натом антиспуф можно сказать вполне применяется и так :-) От этих абонентов уже проблематичны скорее долбящиеся по хттп боты, которых абоненты словили броузером, но оператору это затруднительно как-либо решить или даже заметить.
On 19.10.2015 17:23, Vladislav V. Prodan wrote:
19 октября 2015 г., 17:09 пользователь Stepan Kucherenko <twh@megagroup.ru mailto:twh@megagroup.ru> написал:
Но если включите не поближе к пользователям, а только на выходе из своей автономки - то спуфить все равно будут, но с src ip рандомным не вообще, а только из вашего адресного пространства :-)Есть примеры использования? ACL на каждом порту подключения? Антиспуфинг до NAT'a ?
-- Vladislav V. Prodan System & Network Administrator support.od.ua http://support.od.ua
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
Ну просто рано или поздно подобная безответственность операторов шпд и хостеров вызовет интерес законодателей и если мы не выработаем решение сами. Опять получим неадекватные реальности меры по блокировке трафика наиболее затратным из существующих на рынке способом при обеспечении ничтожной эффективности.
Мне нравится идея проекта dots - о предоставлении оперативного способа связи между noc@.
Пускать простых смертных к нок - задача сомнительная, особенно для крупных операторов. У нас есть 3 фултайм юнита, которые занимаются исключительно жалобами от клиентов извне.
Но когда я как дважды лир и оператор двух крупных площадок не могу выйти на связь с довольно крупным оператором шпд - это не нормально.
Я против универсальных апи/протоколов по отражению атак. Но я за эффективный способ связи хотя бы между лирами и хотя бы в рамках региона РАЙП.
Даешь соц сеть с обятельным присутствием и разумным временем ответа на запросы и с публичным рейтингом злостных игнорщиков.
А-то смех смехом, но в нашей стране до сих пор есть мегаоператрры, которые требуют сброса acl по факсу с подписью ген директора, это даже не смешно в 21 веке, от этого плакать хочется.
On Wednesday, 14 October 2015, Sergey Afonin asy@kraft-s.ru wrote:
On Wednesday 14 October 2015, Pavel Odintsov wrote:
Неоднократно слышал мысль о том, что контролировать и фильтровать трафик ШПД клиента - моветон. Мол слишком сложная задача никак не относящаяся к оператору.
Контролировать - это хорошо бы, но Volodymyr Litovka верно сказал про затратность решения. Фильтровать, разумеется, не стоит. А вот по поводу "никак не относящаяся", то, на самом деле, пресекать неправомерные действия - это не то, что не моветон, а должно быть обязанностью оператора. Если таковые действия совершаются за счёт оборудования пользователя, это пользователя ни коим образом не извиняет. По хорошему, надо прописывать условия ответственности за некорректную работу оборудования в договорах и предусматривать там отключение до устранения проблемы.
-- С уважением, Сергей Афонин asy@kraft-s.ru javascript:; _______________________________________________ discuss mailing list discuss@enog.org javascript:; http://www.enog.org/mailman/listinfo/discuss
Дык злостные игнорщики уже заранее известны. Напомнить ОПГ?
14.10.2015 10:59, Pavel Odintsov пишет:
Ну просто рано или поздно подобная безответственность операторов шпд и хостеров вызовет интерес законодателей и если мы не выработаем решение сами. Опять получим неадекватные реальности меры по блокировке трафика наиболее затратным из существующих на рынке способом при обеспечении ничтожной эффективности.
Мне нравится идея проекта dots - о предоставлении оперативного способа связи между noc@.
Пускать простых смертных к нок - задача сомнительная, особенно для крупных операторов. У нас есть 3 фултайм юнита, которые занимаются исключительно жалобами от клиентов извне.
Но когда я как дважды лир и оператор двух крупных площадок не могу выйти на связь с довольно крупным оператором шпд - это не нормально.
Я против универсальных апи/протоколов по отражению атак. Но я за эффективный способ связи хотя бы между лирами и хотя бы в рамках региона РАЙП.
Даешь соц сеть с обятельным присутствием и разумным временем ответа на запросы и с публичным рейтингом злостных игнорщиков.
А-то смех смехом, но в нашей стране до сих пор есть мегаоператрры, которые требуют сброса acl по факсу с подписью ген директора, это даже не смешно в 21 веке, от этого плакать хочется.
On Wednesday, 14 October 2015, Sergey Afonin <asy@kraft-s.ru mailto:asy@kraft-s.ru> wrote:
On Wednesday 14 October 2015, Pavel Odintsov wrote: > Неоднократно слышал мысль о том, что контролировать и фильтровать > трафик ШПД клиента - моветон. Мол слишком сложная задача никак не > относящаяся к оператору. Контролировать - это хорошо бы, но Volodymyr Litovka верно сказал про затратность решения. Фильтровать, разумеется, не стоит. А вот по поводу "никак не относящаяся", то, на самом деле, пресекать неправомерные действия - это не то, что не моветон, а должно быть обязанностью оператора. Если таковые действия совершаются за счёт оборудования пользователя, это пользователя ни коим образом не извиняет. По хорошему, надо прописывать условия ответственности за некорректную работу оборудования в договорах и предусматривать там отключение до устранения проблемы. -- С уважением, Сергей Афонин asy@kraft-s.ru <javascript:;> _______________________________________________ discuss mailing list discuss@enog.org <javascript:;> http://www.enog.org/mailman/listinfo/discuss-- Sincerely yours, Pavel Odintsov
discuss mailing list discuss@enog.org http://www.enog.org/mailman/listinfo/discuss
А чем, кстати, регламентируется ответственность операторов за фильтрацию и корректность пропускаемого трафика?
14.10.2015 10:39, Sergey Afonin пишет:
On Wednesday 14 October 2015, Pavel Odintsov wrote:
Неоднократно слышал мысль о том, что контролировать и фильтровать трафик ШПД клиента - моветон. Мол слишком сложная задача никак не относящаяся к оператору.
Контролировать - это хорошо бы, но Volodymyr Litovka верно сказал про затратность решения. Фильтровать, разумеется, не стоит. А вот по поводу "никак не относящаяся", то, на самом деле, пресекать неправомерные действия - это не то, что не моветон, а должно быть обязанностью оператора. Если таковые действия совершаются за счёт оборудования пользователя, это пользователя ни коим образом не извиняет. По хорошему, надо прописывать условия ответственности за некорректную работу оборудования в договорах и предусматривать там отключение до устранения проблемы.
А и не надо отключать. При детектировании подозрительной или аномальной активности - автоматически переводить абонента на пониженную скорость и делать периодическую переадресацию на портал с сообщением о проблеме и способе её лечения (потому что почту они всё равно не читают).
Но для этого нужны деньги, которых, при тарифе $2/month Internet+TV (включая НДС), найти не представляется возможным. Т.е. начинать борьбу с DDoS нужно с поднятия ARPU, а не с обсуждения технических способов, коим несть числа :)
А если посадить три десятка студентов на обработку abuse@, отключение и неизбежное после этого общение с пользователем, то на круги это получится дороже, чем автоматизированная система.
On 10/13/15 10:13 PM, Sergey Y. Afonin wrote:
On Tuesday 13 October 2015, Alexandre Snarskii wrote:
а куча железа, которое контролируется самими пользователями (ну, то есть, не контролируется от слова совсем).
Это хороший подход, на самом деле. Просто операторы, в погоне за клиентом, даже если abuse@ читают, стесняются клиента отключить за проблемы, возникающие из-за настройки его оборудования.
On Wednesday 14 October 2015, Volodymyr Litovka wrote:
А и не надо отключать. При детектировании подозрительной или аномальной активности - автоматически переводить абонента на пониженную скорость и делать периодическую переадресацию на портал с сообщением о проблеме и способе её лечения (потому что почту они всё равно не читают).
Вот потому и отключать, что, во-первых, пониженная скорость не спасёт жертву (когда атака будет идти с сотен и тысяч хостов, они сделают плохо и на маленькой скорости), а, во-вторых, многие просто не будут торопиться что-от делать.
Т.е. А если посадить три десятка студентов на обработку abuse@, отключение и неизбежное после этого общение с пользователем, то на круги это получится дороже, чем автоматизированная система.
Это да. А общение в любом случае будет.
participants (11)
-
Alex Semenyaka -
Alexandre Snarskii -
Dennis Yusupoff -
Pavel Odintsov -
Sergey Afonin -
Sergey Myasoedov -
Sergey Y. Afonin
-
Stepan Kucherenko -
Vladislav V. Prodan -
Volodymyr Litovka -
Yaroslav