Pull to refresh

Comments 34

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

А если несколько клиентов сидят за одним ip?
Sign up to leave a comment.