- Закон: площадка для торгов должна обеспечить доступ любому аккредитованному участнику.
- Практика: один из участников регистрирует какое-нибудь ООО «Ромашка», получает электронную подпись и начинает флудить тяжёлыми запросами площадку. Запросы включают криптографию, причём не самую быструю.
- Стандартное противодействие: отключить его или временно заблокировать.
Как видите, пункты 1 и 3 — взаимоисключающие.
А мы так живём.
Итак, если аккредитованному участнику приходит блокирование доступа — при жалобе возникает большой штраф. Один запрос из миллиона заблокируем — сразу штраф за работу файрвола. Если это был пакет с юридически значимым действием.
Это логично, но идёт вразрез с вопросами защиты информации. Все существующие средства работают по принципу определения вредоносной составляющей трафика и её блокирования. Когда участники приходят на площадку и участвуют в аукционах — нельзя доверять системе фильтрацию, кого пустить, кого — нет. Все должны попасть на торги. Никакие алгоритмы не имеют права решить, кого не допускать на площадку. Подпись — это огромная криптограмма на 10 килобайт. По меркам веб-трафика — это одно из самых тяжёлых входящих сообщений (кроме закачки файлов). Используются стойкие алгоритмы, прожорливые на производительность.
Есть правила площадки. И если пользователи используют клиент-серверное приложение, и если они это делают в рамках регламента, то всё хорошо. Система может обрабатывать много торгов сразу.
Мы имеем право блокировать работу небраузерных клиентов. Они не соответствуют регламенту площадки. Находятся умельцы, которые создают альтернативное ПО, которое имитирует работу живого пользователя с помощью браузера, — и оно может создавать серию высокочастотных запросов серверу.
Анонимные запросы можно отбрасывать.
Подписанные надо обрабатывать.
Если они подписаны — это подача ценовых предложений, например. Первая идея — давать сессионные ключи, чтобы каждый раз не обрабатывать сложную аутентификацию. Пережили волну, борьба эскалировалась.
Имели место случаи, когда все уже не DoS, а DDoS-запросы содержали легитимную электронную подпись. При этом применялись технологии сокрытия источника (размывание): под одним и тем же пользователем запросы шли с десятков разных подсетей. Они сложны тем, что сливаются с потоком легитимных запросов. Даже отделив, их нельзя блокировать.
Вторая идея: блокировать таким товарищам подпись. Есть подписи, выданные удостоверяющими центрами с быстрой связью, есть такими, которые сотрудничать не захотят. Но даже если удостоверяющий центр заблокирует подпись, это будет проблемой, потому что дальше ляжет жалоба в ФАС. А они вас за блокировку без технической экспертизы сильно накажут. Аккредитация на площадке тоже не может быть приостановлена — она по закону на три года, и нельзя её приостановить никак. Просто нет процедуры.
Теперь — почему надо с трудом обрабатывать каждый запрос. Дело в том, что запросы на цену или мониторинг ставятся в очередь обработки на горячую базу. Из-за одной десятитысячной секунды может возникнуть спор до суда. Запрос расшифровывается, дальше идёт исключительная блокировка, потом изменение в нескольких таблицах, потом обработка следующего запроса. Если ценовое предложение принять нельзя, то идёт процедура откатывания изменений (например, если предложение было больше текущей цены аукциона). Каждое решение имеет юридический статус.
Надо иметь полноценные логи каждого ценового предложения. Это накладывает ограничения на инфраструктуру, в частности — на возможность дробления базы и инкапсуляции её отдельных участков.
От классических DDoS нас защищает комплекс системы фильтрации на базе «Арбор» и «Куратор». Они работают в тяжёлых случаях по белому списку. У нас все участники процедур в белом списке. Привлекали одну антивирусную лабораторию по договору, и по их рекомендациям приняли некоторые изменения. Они на какое-то время дадут положительный эффект, но это тактическая мера.
Анализируемый при помощи машинного обучения трафик
Атаки организуют те, кто хотят выиграть аукцион. Например, один участник ставит цену ниже, а потом забивает площадку, чтобы другие не могли её перебить. Есть и более сложные схемы и их комбинации. Есть типы процедур, где законодательно выигрывает первый, кто подал определённое ценовое предложение. Это немного неактуально в цифровом мире уже, но таково законодательство со времён бумаги.
Иногда непонятно, кто стоит за подписью. Оформлено на одного, но по факту другой участвует. Ещё нет статьи за сам DDoS. Есть 274 — нарушение правил работы системы. Предполагается, что просто DDoS — это нормально, если не написали в правилах. Мы написали.
Появилась практика ловить злоумышленников и жестоко их наказывать. Эти меры пока купируют проблему, но не решают её.
А ещё у нас отличные диалоги с поставщиками DDoS-решений. Сначала приходит менеджер и говорит, что всё будет работать. Потом, ещё до заключения договора, приходит уже не продажник, у которого всё в ажуре, а техспециалист. Будет в глаза смотреть и говорить, что у него и как сработало. Они до покупки уже начинают заднюю: «Оно шалить может начать. Но чуть-чуть. Может, не гарантируем. Чуть-чуть». А потом как-то плавно оно переходит в «может, и не чуть-чуть».
Ещё мы используем элементы машинного обучения. Делаем профили — слепок нормального поведения обычного пользователя. Система опирается на эти слепки добросовестного поведения и при отклонении начинает блокировать автоматически. Стараемся делать сами руками. Причём выводим команды «советской автоматики» заранее. Знаем, что если во вторник будут большие важные торги — их попытаются положить. Люди хотят помешать ходу торгов. У нас не одна сотня атак в год (сейчас стало чуть меньше). Часто мы можем просто ждать нарастания нагрузки: 5–10 тысяч ботов — не очень большая проблема. Когда уже прямо ситуация критическая — начинаем выборочные блокировки. При этом мы блокируем топовых (самых активных) ботов, потому что у нас нет задачи прекратить атаку полностью, а есть потребность снизить нагрузку до выдерживаемого уровня, не отрубая ничего юридически значимого.
Вторая часть атак — это атаки, связанные с каналом, прямо на ЦОД. Был случай, когда ЦОД ложился целиком. Были проблемы с каналом провайдера. Мы заблаговременно определили формат сотрудничества с провайдером. В частности, управляем всем сегментом IP, не позволяем делать правила фильтрации на нашу группу IP. Любой контракт с системой очистки трафика означает, что мы будем терять людей и получать штрафы. Атакующим достаточно положить систему на секунду, чтобы зафиксировать факт непрохождения транзакции: это не совсем привычные атаки, задача которых ограничить доступ к ресурсу или сделать его полностью неработоспособным.
Используем Elastic Search для сохранения данных матчинга по профилям пользователей. Важно не просто отследить, что кто-то начал делать потенциально аномальное. Потому что есть ещё очень похожие на DDoS активности, когда кто-то из активистов или журналистов скидывает ссылку на закупку, а люди идут толпой на неё смотреть.
Нужно минуты две-три, чтобы алгоритм начал сравнивать, и тем самым произойдёт детектирование отклонения. В это время точно инфраструктура должна выдерживать весь трафик. Каким бы он ни был. У нас запас 15-кратной бизнес-нагрузки.
Атаки предсказуемы по большим закупкам. Из-за компьютера вставать опасно. Отошёл куда-нибудь — SMS и телеграм-мониторинг. Есть полуминутный лаг, чтобы добежать обратно. Битва за секунды. Стараются положить на 10–15 минут в утренний период. На сутки атаковали только пару раз. В целом опоздал с реакцией на 5 минут — процедуре конец.
Что нам нужно — это либо дать законодательное право защищаться от вредоносного трафика (когда площадка это фиксирует: что, в какой момент и почему отклонено), либо поменять процедуру аккредитации (приостанавливать аккредитацию и юридически инициировать разбирательство с нарушителями).
Мы сейчас над этим работаем, а вам пока предлагаем полюбоваться на пример проблемы, которая возникает при адаптации законодательства, созданного для бумажных процедур, к электронному миру.
Ссылки:
- Экосистема цифрового мира закупок (чтобы воровали меньше)
- Электронная подпись для участия в закупках
- Для чего нужны закупки, и как это выглядит с точки зрения ИТ
- Модель атак: где в основном злоупотребляют на конкурсных закупках и как с этим борются
- Какие бывают процедуры закупок (простыми словами)
- Краткая история электронных госзакупок на Руси
- Как мы открывали офисы разработки
Комментарии (34)
akamap
14.02.2019 14:16а вы обращаетесь с заявлением в компетентные органы? Неужели указанные DoS-атаки укладываются в ст.274 УК РФ?
M_Kudryashov Автор
14.02.2019 14:16Под 274 ст. попадают.
Обращались, обращаемся и будем обращаться дальше. Случаи, когда органы находили и наказывали авторов атак, есть.
Однако у компетентных органов, к сожалению, не всегда есть возможность максимально оперативно начать работу по поиску злоумышленников и уж тем более добиться нужного результата. В условиях большого роста сервисов/запросов, ддос-атака является челленджем не только для сервиса (например, торговой площадки), но и также для органов, которые ловят преступников в этой сфере.
happy-cat
14.02.2019 14:48А есть публичные черные списки или что то наподобие доски позора — где указаны какие ООО рога и копыта работают по читерски?
И еще интересны сферы в которых наиболее часто балуют такими вещами, подозреваю IT :)M_Kudryashov Автор
14.02.2019 14:48Публичных списков нет, но СБ площадок стараются вести свои внутренние.
Еще скоро может появиться вот такой публичный список: Реестр участников картелей
prozakupki.interfax.ru/articles/1208
mk2
14.02.2019 15:22А помогло бы от вредоносного трафика просто введение лимитов, например от одного участника — не более n действий в минуту? Или требуются более сложные схемы фильтрации?
M_Kudryashov Автор
14.02.2019 15:56Лимитирование запросов — мера действенная, но ее следует использовать только в крайних случаях, т.к. у нас нет права на ошибку.
Если неумышленно будет ограничен доступ/запрос законопослушного и добросовестного пользователя — практически неминуемо к нам прилетят жалобы и штрафы от регулятора.
Другими словами — отсутствие отклика от электронной площадки может трактоваться как ее собственные проблемы с производительностью, мол «площадка тормозит».
vanxant
15.02.2019 05:12В правилах работы площадки нельзя прописать ограничение 1 запрос в секунду, остальные отбрасываются?
TimsTims
14.02.2019 16:29А раз у вас все записывается и хранится, и на вас потом подают в суд, разве в суде вы не можете предоставить эти логи, и сказать, что компания действительно запылала кучу плохого трафика, всем вредила и мешала конкуренции?
M_Kudryashov Автор
14.02.2019 18:45Несмотря на очевидность подобных доказательств, судебная практика в этом вопросе совсем неоднозначна. Еще совсем недавно в качестве доказательств принимались копии распечатанных (!) скриншотов, где было изображено окно браузера, в котором показывалась какая-то ошибка (самый простой пример — «500 server error»), а в адресной строке фигурировал адрес одной из наших торговых секций. По итогу таких рассмотрений судья может легко встать не на сторону площадки. То есть здесь речь больше идет не о технике, а скорее о юридической/судебной практике рынка электронных торгов. Как уже обозначали выше — у нас тут отдельный мир. Со своими нюансами, тараканами и правилами.
algotrader2013
14.02.2019 20:27самый простой пример — «500 server error»
Что происходит, если в качестве доказательств приносят отфотошопленные скрины?M_Kudryashov Автор
15.02.2019 16:27Сейчас благодаря различным системам внутреннего мониторинга, в т.ч. благодаря государственной системе «Независимый регистратор», опровергнуть такой скрин достаточно легко.
Тем не менее, процесс все равно может растянуться, если потребуются какие-то дополнительные экспертизы и пр.
Mox
14.02.2019 18:56-1Я бы думал в сторону простого регламента
— запретить одному клиенту давать запросы чаще чем раз в X секунд. Понять, при каком X система не лежит.
— сделать высокопроизводительный фильтр, который расшифровывает данные и смотрит на соответствие означенному критерию. Если критерий не выполнен — просто отшивает запрос на транзакцию
Ключевая идея в том, чтобы придумать предварительную проверку гораздо более быструю чем реальная запись транзакции в БД
AVI-crak
14.02.2019 20:59+1Нужно просто сменить правила торгов, при которых дос атака станет бессмысленной.
Firz
14.02.2019 21:21+1В верху сайта добавлять надпись «Площадка тормозит, потому что Иванов Иван Иванович из ООО „Рога и Копыта“ юр. адрес ххх, т. ууу, DDoSит площадку в попытке препятствовать ее нормальной работе и нечестно выиграть торги» )
mSnus
15.02.2019 00:25А нельзя просто обрабатывать такие запросы медленно?)
M_Kudryashov Автор
15.02.2019 14:09В случае начала противоборства с ботами подобная тактика может создать дополнительные накладные расходы на инфраструктуру, т.к. медленный ответ заставит систему держать все соединения/сессии открытыми.
boroda_el
15.02.2019 00:54А если атаковать не количеством запросов, а количеством пользователей? Открыть УЦ-однодневку, выдать подписи миллиону фирм, аккедитовать их всех и навалится на один аукцион.
В такой атаке слабым звеном может стать человек. Рассмотреть млн первых частей заявок за 10 дней. Рассматривать логи от млн участников. Получить млн жалоб в ФАС.
M_Kudryashov Автор
15.02.2019 14:08Если речь идет о применении самоподписанных сертификатов, то это исключено. В торговых секциях по 44-ФЗ и 223-ФЗ разрешено применение только квалифицированных ЭП (и все цепочки сертификации ведут к головному УЦ страны). УЦ, с сертификатами которого можно участвовать в электронных торгах (на аккредитованных федеральных площадках), должен входить в перечень доверенных УЦ со стороны Минкомсвязи. А это, мягко говоря, не так просто сделать, т.е. сделать «УЦ-однодневку» — это очень дорогая, кропотливая и долгая работа.
rionnagel
15.02.2019 03:01Жесть у вас… сочувствую. Мы то смогли на кф переложить, а с вашими проблемами фиг так получится.
istepan
15.02.2019 08:23Блокировать доступ нельзя, но можно значительно срезать максимальный объем данных и скорость передачи для злоумышленника. Или нельзя?
M_Kudryashov Автор
15.02.2019 13:58C объемами данных запроса на подачу ценового предложения ничего не сделать — процедура равна стоимости типичного https-запроса. Ограничение скорости и иные лимиты применяются.
Berkof
15.02.2019 12:35Какая-то странная проблема… Ну в нормальной системе пришёл запрос, расшифровали его и положили во входящую очередь на обработку, ок… Но если вас так давят, так вы модель с push в эту очередь замените на модель с pull из входящих очередей и набирайте очередь на обработку от каждого пользователя по запросу (конечно можно зарегать 100500 фирм, но, подозреваю, это сложнее, чем послать 100500 запросов от одной фирмы). И всё, сколько бы у пользователя не было входящих запросов — вы всё равно их все обработаете (можно хоть в kaffka складывать и потом юзеру 2 месяца на email слать отлупы, что его запрос 8129431 из спам-аттаки не может быть обработан по причине завершения торгов 2 месяца назад...) О чём вам тут уже не раз написали (значит не только я тупой и не понял чё вы сразу так не сделали.
M_Kudryashov Автор
15.02.2019 16:31Ваше направление мысли правильное, и у нас есть идеи и наработки схожего с вашим алгоритма. Но проблема состоит в том, что приходится сталкиваться с «кричащим нарушителем», т.е. таким пользователем, который в случае своей неудачной атаки подает жалобу на нас за длительную обработку его запросов.
Если ситуация дойдет до суда, то суд может вынести решение не в пользу площадки.
Потому что отложенная обработка запросов или их ограничение можно трактовать как «ограничение доступа к торгам по конкурентному принципу».
mkovalevskyi
15.02.2019 14:46А ддос нынче окупается при таком использовании?
M_Kudryashov Автор
15.02.2019 14:47Думаю, что когда речь идет о многомиллионном или даже миллиардном контракте — окупается.
OldGrumbler
15.02.2019 20:56ИМХО, вопрос решается старыми проверенными способами. Если есть дефицит ресурсов — то нужно ограничить их распределение по количеству «в руки» и/или по времени.
Скажем, если в официальном интерфейсе кнопка отправки ставки будет после ее нажатия (или получения клиентом подтверждения доставки) пропадать на пару секунд (и, соответственно, сервер ту же пару секунд будет дропать все от этого клиента а хоть бы и по ip — маловероятно, что у реального участника ip настолько динамический) — это не будет восприниматься как нарушение пункта 1. Еще вариант — «ставка по кругу». В цикле все участники могут или сделать ставку, или пропустить ход (последнее может производиться и по таймауту) — но только явно и один раз за цикл, после чего, опять же, до конца цикла у них нет «официальной» возможности отправить что-либо еще — и все пакеты от них сервер дропает. Три цикла без изменения ставки => завершение торгов.mkovalevskyi
15.02.2019 21:50Чуть выше писали что будет. Нет кнопки — нет доступа. Нет доступа — делаем скриншот и го в суд )
OldGrumbler
16.02.2019 18:16Вместо кнопки показать на время паузы пассивный объект с надписью «ставка принята» и обратным счетом.
boroda_el
15.02.2019 21:19будет дропать все от этого клиента а хоть бы и по ip
А если несколько клиентов сидят за одним ip?
Sap_ru
Почему нельзя оптимизировать блокировки?
Если от одного участника идут частые запросы, то зачем обрабатывать их все? Начинаете обрабатывать запрос. Остальные ставите в очередь после быстрой первичной проверки. После окончания обработки первого запроса, обрабатываете последние из очереди. Это можно в правилах прописать — что последовательные запросы от одного участника обрабатываются в порядке их поступления и при этом во время обработки запроса от участника могут обрабатываться запросы других участников, а идентификация участников — по ключу. Можно даже глубину очереди запрос на каждого участника ограничить в правилах и давать отлуп при переполнении. При должном старании можно прикрутить быструю идентификацию участников без ключа по дополнительным и косвенным признакам (и деать исключения для искусственных «тяжёлых» случаев, но есть мнение, что если вы устанавливаете правила и сайт ваш, то этого можно избежать). Естественно, что финалься идентификация при обработке заявки должна быть по ключу.
При правильной формулировке и реализации пропадёт всякий смысл флуда запросами — фактически, будет получаться, что множественные запросы понижают приоритет участника.
M_Kudryashov Автор
Оптимизация — это же процесс практически вечный, но не всегда дающий идеальный результат.
Во многом мы завязаны на гарантию факта приема и обработки ценовых предложений (или любых других действий юридического характера), и поэтому без блокировок работать попросту нельзя.
В целом обработка запросов от одного участника уже сейчас происходит в каком-то смысле «по очереди», но и это тоже является частью накладных расходов инфраструктуры — ведь содержать и распределять очередь из сотен тысяч подобных запросов тоже трудоемкая работа. Что касается последовательности и предложенного Вами алгоритма — нечто похожее у нас уже реализовано, но в этом сценарии всегда есть фактора времени совершения юр. значимой операции в условиях конкурентных запросов (в условиях торга).
Другими словами — модуль электронных торгов должен работать максимально корректно и быстро, иначе может пострадать экономическая модель компании. Во многом и из-за очень высоких штрафов от госрегулятора.
Sergey_Cheban
Как вариант — некто может флудить запросами с невалидной подписью. Если подпись невалидна, её же всё равно надо проверить, а это тяжело. А потом среди этого мусора он отправит один запрос с правильной подписью.
Я вижу такой вариант: выдавать каждому участнику индивидуальный VPN с паролем, и ставить в очередь запросы, пришедшие из одного VPN. VPN используют симметричные криптоалгоритмы, они быстрые, так что производительность сильно пострадать не должна.