DoS-атака, от которой нельзя закрыться: в закупках своя атмосфера



    1. Закон: площадка для торгов должна обеспечить доступ любому аккредитованному участнику.
    2. Практика: один из участников регистрирует какое-нибудь ООО «Ромашка», получает электронную подпись и начинает флудить тяжёлыми запросами площадку. Запросы включают криптографию, причём не самую быструю.
    3. Стандартное противодействие: отключить его или временно заблокировать.

    Как видите, пункты 1 и 3 — взаимоисключающие.

    А мы так живём.

    Итак, если аккредитованному участнику приходит блокирование доступа — при жалобе возникает большой штраф. Один запрос из миллиона заблокируем — сразу штраф за работу файрвола. Если это был пакет с юридически значимым действием.

    Это логично, но идёт вразрез с вопросами защиты информации. Все существующие средства работают по принципу определения вредоносной составляющей трафика и её блокирования. Когда участники приходят на площадку и участвуют в аукционах — нельзя доверять системе фильтрацию, кого пустить, кого — нет. Все должны попасть на торги. Никакие алгоритмы не имеют права решить, кого не допускать на площадку. Подпись — это огромная криптограмма на 10 килобайт. По меркам веб-трафика — это одно из самых тяжёлых входящих сообщений (кроме закачки файлов). Используются стойкие алгоритмы, прожорливые на производительность.

    Есть правила площадки. И если пользователи используют клиент-серверное приложение, и если они это делают в рамках регламента, то всё хорошо. Система может обрабатывать много торгов сразу.

    Мы имеем право блокировать работу небраузерных клиентов. Они не соответствуют регламенту площадки. Находятся умельцы, которые создают альтернативное ПО, которое имитирует работу живого пользователя с помощью браузера, — и оно может создавать серию высокочастотных запросов серверу.

    Анонимные запросы можно отбрасывать.

    Подписанные надо обрабатывать.

    Если они подписаны — это подача ценовых предложений, например. Первая идея — давать сессионные ключи, чтобы каждый раз не обрабатывать сложную аутентификацию. Пережили волну, борьба эскалировалась.

    Имели место случаи, когда все уже не DoS, а DDoS-запросы содержали легитимную электронную подпись. При этом применялись технологии сокрытия источника (размывание): под одним и тем же пользователем запросы шли с десятков разных подсетей. Они сложны тем, что сливаются с потоком легитимных запросов. Даже отделив, их нельзя блокировать.

    Вторая идея: блокировать таким товарищам подпись. Есть подписи, выданные удостоверяющими центрами с быстрой связью, есть такими, которые сотрудничать не захотят. Но даже если удостоверяющий центр заблокирует подпись, это будет проблемой, потому что дальше ляжет жалоба в ФАС. А они вас за блокировку без технической экспертизы сильно накажут. Аккредитация на площадке тоже не может быть приостановлена — она по закону на три года, и нельзя её приостановить никак. Просто нет процедуры.

    Теперь — почему надо с трудом обрабатывать каждый запрос. Дело в том, что запросы на цену или мониторинг ставятся в очередь обработки на горячую базу. Из-за одной десятитысячной секунды может возникнуть спор до суда. Запрос расшифровывается, дальше идёт исключительная блокировка, потом изменение в нескольких таблицах, потом обработка следующего запроса. Если ценовое предложение принять нельзя, то идёт процедура откатывания изменений (например, если предложение было больше текущей цены аукциона). Каждое решение имеет юридический статус.

    Надо иметь полноценные логи каждого ценового предложения. Это накладывает ограничения на инфраструктуру, в частности — на возможность дробления базы и инкапсуляции её отдельных участков.

    От классических DDoS нас защищает комплекс системы фильтрации на базе «Арбор» и «Куратор». Они работают в тяжёлых случаях по белому списку. У нас все участники процедур в белом списке. Привлекали одну антивирусную лабораторию по договору, и по их рекомендациям приняли некоторые изменения. Они на какое-то время дадут положительный эффект, но это тактическая мера.


    Анализируемый при помощи машинного обучения трафик

    Атаки организуют те, кто хотят выиграть аукцион. Например, один участник ставит цену ниже, а потом забивает площадку, чтобы другие не могли её перебить. Есть и более сложные схемы и их комбинации. Есть типы процедур, где законодательно выигрывает первый, кто подал определённое ценовое предложение. Это немного неактуально в цифровом мире уже, но таково законодательство со времён бумаги.

    Иногда непонятно, кто стоит за подписью. Оформлено на одного, но по факту другой участвует. Ещё нет статьи за сам DDoS. Есть 274 — нарушение правил работы системы. Предполагается, что просто DDoS — это нормально, если не написали в правилах. Мы написали.

    Появилась практика ловить злоумышленников и жестоко их наказывать. Эти меры пока купируют проблему, но не решают её.

    А ещё у нас отличные диалоги с поставщиками DDoS-решений. Сначала приходит менеджер и говорит, что всё будет работать. Потом, ещё до заключения договора, приходит уже не продажник, у которого всё в ажуре, а техспециалист. Будет в глаза смотреть и говорить, что у него и как сработало. Они до покупки уже начинают заднюю: «Оно шалить может начать. Но чуть-чуть. Может, не гарантируем. Чуть-чуть». А потом как-то плавно оно переходит в «может, и не чуть-чуть».

    Ещё мы используем элементы машинного обучения. Делаем профили — слепок нормального поведения обычного пользователя. Система опирается на эти слепки добросовестного поведения и при отклонении начинает блокировать автоматически. Стараемся делать сами руками. Причём выводим команды «советской автоматики» заранее. Знаем, что если во вторник будут большие важные торги — их попытаются положить. Люди хотят помешать ходу торгов. У нас не одна сотня атак в год (сейчас стало чуть меньше). Часто мы можем просто ждать нарастания нагрузки: 5–10 тысяч ботов — не очень большая проблема. Когда уже прямо ситуация критическая — начинаем выборочные блокировки. При этом мы блокируем топовых (самых активных) ботов, потому что у нас нет задачи прекратить атаку полностью, а есть потребность снизить нагрузку до выдерживаемого уровня, не отрубая ничего юридически значимого.

    Вторая часть атак — это атаки, связанные с каналом, прямо на ЦОД. Был случай, когда ЦОД ложился целиком. Были проблемы с каналом провайдера. Мы заблаговременно определили формат сотрудничества с провайдером. В частности, управляем всем сегментом IP, не позволяем делать правила фильтрации на нашу группу IP. Любой контракт с системой очистки трафика означает, что мы будем терять людей и получать штрафы. Атакующим достаточно положить систему на секунду, чтобы зафиксировать факт непрохождения транзакции: это не совсем привычные атаки, задача которых ограничить доступ к ресурсу или сделать его полностью неработоспособным.

    Используем Elastic Search для сохранения данных матчинга по профилям пользователей. Важно не просто отследить, что кто-то начал делать потенциально аномальное. Потому что есть ещё очень похожие на DDoS активности, когда кто-то из активистов или журналистов скидывает ссылку на закупку, а люди идут толпой на неё смотреть.

    Нужно минуты две-три, чтобы алгоритм начал сравнивать, и тем самым произойдёт детектирование отклонения. В это время точно инфраструктура должна выдерживать весь трафик. Каким бы он ни был. У нас запас 15-кратной бизнес-нагрузки.

    Атаки предсказуемы по большим закупкам. Из-за компьютера вставать опасно. Отошёл куда-нибудь — SMS и телеграм-мониторинг. Есть полуминутный лаг, чтобы добежать обратно. Битва за секунды. Стараются положить на 10–15 минут в утренний период. На сутки атаковали только пару раз. В целом опоздал с реакцией на 5 минут — процедуре конец.

    Что нам нужно — это либо дать законодательное право защищаться от вредоносного трафика (когда площадка это фиксирует: что, в какой момент и почему отклонено), либо поменять процедуру аккредитации (приостанавливать аккредитацию и юридически инициировать разбирательство с нарушителями).

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

    Ссылки:


    Единая электронная торговая площадка
    123,00
    №1 по электронным закупкам в России
    Поделиться публикацией

    Комментарии 34

      +3
      Почему нельзя оптимизировать блокировки?
      Если от одного участника идут частые запросы, то зачем обрабатывать их все? Начинаете обрабатывать запрос. Остальные ставите в очередь после быстрой первичной проверки. После окончания обработки первого запроса, обрабатываете последние из очереди. Это можно в правилах прописать — что последовательные запросы от одного участника обрабатываются в порядке их поступления и при этом во время обработки запроса от участника могут обрабатываться запросы других участников, а идентификация участников — по ключу. Можно даже глубину очереди запрос на каждого участника ограничить в правилах и давать отлуп при переполнении. При должном старании можно прикрутить быструю идентификацию участников без ключа по дополнительным и косвенным признакам (и деать исключения для искусственных «тяжёлых» случаев, но есть мнение, что если вы устанавливаете правила и сайт ваш, то этого можно избежать). Естественно, что финалься идентификация при обработке заявки должна быть по ключу.
      При правильной формулировке и реализации пропадёт всякий смысл флуда запросами — фактически, будет получаться, что множественные запросы понижают приоритет участника.
        +2
        Оптимизация — это же процесс практически вечный, но не всегда дающий идеальный результат.
        Во многом мы завязаны на гарантию факта приема и обработки ценовых предложений (или любых других действий юридического характера), и поэтому без блокировок работать попросту нельзя.

        В целом обработка запросов от одного участника уже сейчас происходит в каком-то смысле «по очереди», но и это тоже является частью накладных расходов инфраструктуры — ведь содержать и распределять очередь из сотен тысяч подобных запросов тоже трудоемкая работа. Что касается последовательности и предложенного Вами алгоритма — нечто похожее у нас уже реализовано, но в этом сценарии всегда есть фактора времени совершения юр. значимой операции в условиях конкурентных запросов (в условиях торга).

        Другими словами — модуль электронных торгов должен работать максимально корректно и быстро, иначе может пострадать экономическая модель компании. Во многом и из-за очень высоких штрафов от госрегулятора.
          0
          Как вариант — некто может флудить запросами с невалидной подписью. Если подпись невалидна, её же всё равно надо проверить, а это тяжело. А потом среди этого мусора он отправит один запрос с правильной подписью.

          Я вижу такой вариант: выдавать каждому участнику индивидуальный VPN с паролем, и ставить в очередь запросы, пришедшие из одного VPN. VPN используют симметричные криптоалгоритмы, они быстрые, так что производительность сильно пострадать не должна.
          0
          а вы обращаетесь с заявлением в компетентные органы? Неужели указанные DoS-атаки укладываются в ст.274 УК РФ?
            +1
            Под 274 ст. попадают.
            Обращались, обращаемся и будем обращаться дальше. Случаи, когда органы находили и наказывали авторов атак, есть.

            Однако у компетентных органов, к сожалению, не всегда есть возможность максимально оперативно начать работу по поиску злоумышленников и уж тем более добиться нужного результата. В условиях большого роста сервисов/запросов, ддос-атака является челленджем не только для сервиса (например, торговой площадки), но и также для органов, которые ловят преступников в этой сфере.
            0
            А есть публичные черные списки или что то наподобие доски позора — где указаны какие ООО рога и копыта работают по читерски?
            И еще интересны сферы в которых наиболее часто балуют такими вещами, подозреваю IT :)
              0
              Публичных списков нет, но СБ площадок стараются вести свои внутренние.
              Еще скоро может появиться вот такой публичный список: Реестр участников картелей
              prozakupki.interfax.ru/articles/1208
              0
              А помогло бы от вредоносного трафика просто введение лимитов, например от одного участника — не более n действий в минуту? Или требуются более сложные схемы фильтрации?
                0
                Лимитирование запросов — мера действенная, но ее следует использовать только в крайних случаях, т.к. у нас нет права на ошибку.

                Если неумышленно будет ограничен доступ/запрос законопослушного и добросовестного пользователя — практически неминуемо к нам прилетят жалобы и штрафы от регулятора.

                Другими словами — отсутствие отклика от электронной площадки может трактоваться как ее собственные проблемы с производительностью, мол «площадка тормозит».
                  0
                  В правилах работы площадки нельзя прописать ограничение 1 запрос в секунду, остальные отбрасываются?
                0

                А раз у вас все записывается и хранится, и на вас потом подают в суд, разве в суде вы не можете предоставить эти логи, и сказать, что компания действительно запылала кучу плохого трафика, всем вредила и мешала конкуренции?

                  0
                  Несмотря на очевидность подобных доказательств, судебная практика в этом вопросе совсем неоднозначна. Еще совсем недавно в качестве доказательств принимались копии распечатанных (!) скриншотов, где было изображено окно браузера, в котором показывалась какая-то ошибка (самый простой пример — «500 server error»), а в адресной строке фигурировал адрес одной из наших торговых секций. По итогу таких рассмотрений судья может легко встать не на сторону площадки. То есть здесь речь больше идет не о технике, а скорее о юридической/судебной практике рынка электронных торгов. Как уже обозначали выше — у нас тут отдельный мир. Со своими нюансами, тараканами и правилами.
                    0
                    самый простой пример — «500 server error»

                    Что происходит, если в качестве доказательств приносят отфотошопленные скрины?
                      0
                      Сейчас благодаря различным системам внутреннего мониторинга, в т.ч. благодаря государственной системе «Независимый регистратор», опровергнуть такой скрин достаточно легко.
                      Тем не менее, процесс все равно может растянуться, если потребуются какие-то дополнительные экспертизы и пр.
                  –1
                  Я бы думал в сторону простого регламента

                  — запретить одному клиенту давать запросы чаще чем раз в X секунд. Понять, при каком X система не лежит.
                  — сделать высокопроизводительный фильтр, который расшифровывает данные и смотрит на соответствие означенному критерию. Если критерий не выполнен — просто отшивает запрос на транзакцию

                  Ключевая идея в том, чтобы придумать предварительную проверку гораздо более быструю чем реальная запись транзакции в БД
                    +1
                    Нужно просто сменить правила торгов, при которых дос атака станет бессмысленной.
                      +1
                      В верху сайта добавлять надпись «Площадка тормозит, потому что Иванов Иван Иванович из ООО „Рога и Копыта“ юр. адрес ххх, т. ууу, DDoSит площадку в попытке препятствовать ее нормальной работе и нечестно выиграть торги» )
                        0
                        Firz — не так, и не туда.
                          0
                          А чем не правило? Правило номер N+1: «Площадка оставляет за собой право открыто публиковать информацию о лицах, пытающихся нанести ущерб или препятствующих нормальному функционированию площадки.»
                      0

                      А нельзя просто обрабатывать такие запросы медленно?)

                        0
                        В случае начала противоборства с ботами подобная тактика может создать дополнительные накладные расходы на инфраструктуру, т.к. медленный ответ заставит систему держать все соединения/сессии открытыми.
                        0

                        А если атаковать не количеством запросов, а количеством пользователей? Открыть УЦ-однодневку, выдать подписи миллиону фирм, аккедитовать их всех и навалится на один аукцион.


                        В такой атаке слабым звеном может стать человек. Рассмотреть млн первых частей заявок за 10 дней. Рассматривать логи от млн участников. Получить млн жалоб в ФАС.

                          0
                          Если речь идет о применении самоподписанных сертификатов, то это исключено. В торговых секциях по 44-ФЗ и 223-ФЗ разрешено применение только квалифицированных ЭП (и все цепочки сертификации ведут к головному УЦ страны). УЦ, с сертификатами которого можно участвовать в электронных торгах (на аккредитованных федеральных площадках), должен входить в перечень доверенных УЦ со стороны Минкомсвязи. А это, мягко говоря, не так просто сделать, т.е. сделать «УЦ-однодневку» — это очень дорогая, кропотливая и долгая работа.
                          0

                          Жесть у вас… сочувствую. Мы то смогли на кф переложить, а с вашими проблемами фиг так получится.

                            0
                            Блокировать доступ нельзя, но можно значительно срезать максимальный объем данных и скорость передачи для злоумышленника. Или нельзя?
                              0
                              C объемами данных запроса на подачу ценового предложения ничего не сделать — процедура равна стоимости типичного https-запроса. Ограничение скорости и иные лимиты применяются.
                              0
                              Какая-то странная проблема… Ну в нормальной системе пришёл запрос, расшифровали его и положили во входящую очередь на обработку, ок… Но если вас так давят, так вы модель с push в эту очередь замените на модель с pull из входящих очередей и набирайте очередь на обработку от каждого пользователя по запросу (конечно можно зарегать 100500 фирм, но, подозреваю, это сложнее, чем послать 100500 запросов от одной фирмы). И всё, сколько бы у пользователя не было входящих запросов — вы всё равно их все обработаете (можно хоть в kaffka складывать и потом юзеру 2 месяца на email слать отлупы, что его запрос 8129431 из спам-аттаки не может быть обработан по причине завершения торгов 2 месяца назад...) О чём вам тут уже не раз написали (значит не только я тупой и не понял чё вы сразу так не сделали.
                                0
                                Ваше направление мысли правильное, и у нас есть идеи и наработки схожего с вашим алгоритма. Но проблема состоит в том, что приходится сталкиваться с «кричащим нарушителем», т.е. таким пользователем, который в случае своей неудачной атаки подает жалобу на нас за длительную обработку его запросов.
                                Если ситуация дойдет до суда, то суд может вынести решение не в пользу площадки.
                                Потому что отложенная обработка запросов или их ограничение можно трактовать как «ограничение доступа к торгам по конкурентному принципу».
                                0
                                А ддос нынче окупается при таком использовании?
                                  0
                                  Думаю, что когда речь идет о многомиллионном или даже миллиардном контракте — окупается.
                                  0
                                  ИМХО, вопрос решается старыми проверенными способами. Если есть дефицит ресурсов — то нужно ограничить их распределение по количеству «в руки» и/или по времени.
                                  Скажем, если в официальном интерфейсе кнопка отправки ставки будет после ее нажатия (или получения клиентом подтверждения доставки) пропадать на пару секунд (и, соответственно, сервер ту же пару секунд будет дропать все от этого клиента а хоть бы и по ip — маловероятно, что у реального участника ip настолько динамический) — это не будет восприниматься как нарушение пункта 1. Еще вариант — «ставка по кругу». В цикле все участники могут или сделать ставку, или пропустить ход (последнее может производиться и по таймауту) — но только явно и один раз за цикл, после чего, опять же, до конца цикла у них нет «официальной» возможности отправить что-либо еще — и все пакеты от них сервер дропает. Три цикла без изменения ставки => завершение торгов.
                                    0
                                    Чуть выше писали что будет. Нет кнопки — нет доступа. Нет доступа — делаем скриншот и го в суд )
                                      0
                                      Вместо кнопки показать на время паузы пассивный объект с надписью «ставка принята» и обратным счетом.
                                    0
                                    будет дропать все от этого клиента а хоть бы и по ip

                                    А если несколько клиентов сидят за одним ip?

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое