Комментарии 34
Почему нельзя оптимизировать блокировки?
Если от одного участника идут частые запросы, то зачем обрабатывать их все? Начинаете обрабатывать запрос. Остальные ставите в очередь после быстрой первичной проверки. После окончания обработки первого запроса, обрабатываете последние из очереди. Это можно в правилах прописать — что последовательные запросы от одного участника обрабатываются в порядке их поступления и при этом во время обработки запроса от участника могут обрабатываться запросы других участников, а идентификация участников — по ключу. Можно даже глубину очереди запрос на каждого участника ограничить в правилах и давать отлуп при переполнении. При должном старании можно прикрутить быструю идентификацию участников без ключа по дополнительным и косвенным признакам (и деать исключения для искусственных «тяжёлых» случаев, но есть мнение, что если вы устанавливаете правила и сайт ваш, то этого можно избежать). Естественно, что финалься идентификация при обработке заявки должна быть по ключу.
При правильной формулировке и реализации пропадёт всякий смысл флуда запросами — фактически, будет получаться, что множественные запросы понижают приоритет участника.
Если от одного участника идут частые запросы, то зачем обрабатывать их все? Начинаете обрабатывать запрос. Остальные ставите в очередь после быстрой первичной проверки. После окончания обработки первого запроса, обрабатываете последние из очереди. Это можно в правилах прописать — что последовательные запросы от одного участника обрабатываются в порядке их поступления и при этом во время обработки запроса от участника могут обрабатываться запросы других участников, а идентификация участников — по ключу. Можно даже глубину очереди запрос на каждого участника ограничить в правилах и давать отлуп при переполнении. При должном старании можно прикрутить быструю идентификацию участников без ключа по дополнительным и косвенным признакам (и деать исключения для искусственных «тяжёлых» случаев, но есть мнение, что если вы устанавливаете правила и сайт ваш, то этого можно избежать). Естественно, что финалься идентификация при обработке заявки должна быть по ключу.
При правильной формулировке и реализации пропадёт всякий смысл флуда запросами — фактически, будет получаться, что множественные запросы понижают приоритет участника.
Оптимизация — это же процесс практически вечный, но не всегда дающий идеальный результат.
Во многом мы завязаны на гарантию факта приема и обработки ценовых предложений (или любых других действий юридического характера), и поэтому без блокировок работать попросту нельзя.
В целом обработка запросов от одного участника уже сейчас происходит в каком-то смысле «по очереди», но и это тоже является частью накладных расходов инфраструктуры — ведь содержать и распределять очередь из сотен тысяч подобных запросов тоже трудоемкая работа. Что касается последовательности и предложенного Вами алгоритма — нечто похожее у нас уже реализовано, но в этом сценарии всегда есть фактора времени совершения юр. значимой операции в условиях конкурентных запросов (в условиях торга).
Другими словами — модуль электронных торгов должен работать максимально корректно и быстро, иначе может пострадать экономическая модель компании. Во многом и из-за очень высоких штрафов от госрегулятора.
Во многом мы завязаны на гарантию факта приема и обработки ценовых предложений (или любых других действий юридического характера), и поэтому без блокировок работать попросту нельзя.
В целом обработка запросов от одного участника уже сейчас происходит в каком-то смысле «по очереди», но и это тоже является частью накладных расходов инфраструктуры — ведь содержать и распределять очередь из сотен тысяч подобных запросов тоже трудоемкая работа. Что касается последовательности и предложенного Вами алгоритма — нечто похожее у нас уже реализовано, но в этом сценарии всегда есть фактора времени совершения юр. значимой операции в условиях конкурентных запросов (в условиях торга).
Другими словами — модуль электронных торгов должен работать максимально корректно и быстро, иначе может пострадать экономическая модель компании. Во многом и из-за очень высоких штрафов от госрегулятора.
Как вариант — некто может флудить запросами с невалидной подписью. Если подпись невалидна, её же всё равно надо проверить, а это тяжело. А потом среди этого мусора он отправит один запрос с правильной подписью.
Я вижу такой вариант: выдавать каждому участнику индивидуальный VPN с паролем, и ставить в очередь запросы, пришедшие из одного VPN. VPN используют симметричные криптоалгоритмы, они быстрые, так что производительность сильно пострадать не должна.
Я вижу такой вариант: выдавать каждому участнику индивидуальный VPN с паролем, и ставить в очередь запросы, пришедшие из одного VPN. VPN используют симметричные криптоалгоритмы, они быстрые, так что производительность сильно пострадать не должна.
а вы обращаетесь с заявлением в компетентные органы? Неужели указанные DoS-атаки укладываются в ст.274 УК РФ?
Под 274 ст. попадают.
Обращались, обращаемся и будем обращаться дальше. Случаи, когда органы находили и наказывали авторов атак, есть.
Однако у компетентных органов, к сожалению, не всегда есть возможность максимально оперативно начать работу по поиску злоумышленников и уж тем более добиться нужного результата. В условиях большого роста сервисов/запросов, ддос-атака является челленджем не только для сервиса (например, торговой площадки), но и также для органов, которые ловят преступников в этой сфере.
Обращались, обращаемся и будем обращаться дальше. Случаи, когда органы находили и наказывали авторов атак, есть.
Однако у компетентных органов, к сожалению, не всегда есть возможность максимально оперативно начать работу по поиску злоумышленников и уж тем более добиться нужного результата. В условиях большого роста сервисов/запросов, ддос-атака является челленджем не только для сервиса (например, торговой площадки), но и также для органов, которые ловят преступников в этой сфере.
НЛО прилетело и опубликовало эту надпись здесь
Публичных списков нет, но СБ площадок стараются вести свои внутренние.
Еще скоро может появиться вот такой публичный список: Реестр участников картелей
prozakupki.interfax.ru/articles/1208
Еще скоро может появиться вот такой публичный список: Реестр участников картелей
prozakupki.interfax.ru/articles/1208
А помогло бы от вредоносного трафика просто введение лимитов, например от одного участника — не более n действий в минуту? Или требуются более сложные схемы фильтрации?
Лимитирование запросов — мера действенная, но ее следует использовать только в крайних случаях, т.к. у нас нет права на ошибку.
Если неумышленно будет ограничен доступ/запрос законопослушного и добросовестного пользователя — практически неминуемо к нам прилетят жалобы и штрафы от регулятора.
Другими словами — отсутствие отклика от электронной площадки может трактоваться как ее собственные проблемы с производительностью, мол «площадка тормозит».
Если неумышленно будет ограничен доступ/запрос законопослушного и добросовестного пользователя — практически неминуемо к нам прилетят жалобы и штрафы от регулятора.
Другими словами — отсутствие отклика от электронной площадки может трактоваться как ее собственные проблемы с производительностью, мол «площадка тормозит».
А раз у вас все записывается и хранится, и на вас потом подают в суд, разве в суде вы не можете предоставить эти логи, и сказать, что компания действительно запылала кучу плохого трафика, всем вредила и мешала конкуренции?
Несмотря на очевидность подобных доказательств, судебная практика в этом вопросе совсем неоднозначна. Еще совсем недавно в качестве доказательств принимались копии распечатанных (!) скриншотов, где было изображено окно браузера, в котором показывалась какая-то ошибка (самый простой пример — «500 server error»), а в адресной строке фигурировал адрес одной из наших торговых секций. По итогу таких рассмотрений судья может легко встать не на сторону площадки. То есть здесь речь больше идет не о технике, а скорее о юридической/судебной практике рынка электронных торгов. Как уже обозначали выше — у нас тут отдельный мир. Со своими нюансами, тараканами и правилами.
Я бы думал в сторону простого регламента
— запретить одному клиенту давать запросы чаще чем раз в X секунд. Понять, при каком X система не лежит.
— сделать высокопроизводительный фильтр, который расшифровывает данные и смотрит на соответствие означенному критерию. Если критерий не выполнен — просто отшивает запрос на транзакцию
Ключевая идея в том, чтобы придумать предварительную проверку гораздо более быструю чем реальная запись транзакции в БД
— запретить одному клиенту давать запросы чаще чем раз в X секунд. Понять, при каком X система не лежит.
— сделать высокопроизводительный фильтр, который расшифровывает данные и смотрит на соответствие означенному критерию. Если критерий не выполнен — просто отшивает запрос на транзакцию
Ключевая идея в том, чтобы придумать предварительную проверку гораздо более быструю чем реальная запись транзакции в БД
Нужно просто сменить правила торгов, при которых дос атака станет бессмысленной.
А нельзя просто обрабатывать такие запросы медленно?)
А если атаковать не количеством запросов, а количеством пользователей? Открыть УЦ-однодневку, выдать подписи миллиону фирм, аккедитовать их всех и навалится на один аукцион.
В такой атаке слабым звеном может стать человек. Рассмотреть млн первых частей заявок за 10 дней. Рассматривать логи от млн участников. Получить млн жалоб в ФАС.
Если речь идет о применении самоподписанных сертификатов, то это исключено. В торговых секциях по 44-ФЗ и 223-ФЗ разрешено применение только квалифицированных ЭП (и все цепочки сертификации ведут к головному УЦ страны). УЦ, с сертификатами которого можно участвовать в электронных торгах (на аккредитованных федеральных площадках), должен входить в перечень доверенных УЦ со стороны Минкомсвязи. А это, мягко говоря, не так просто сделать, т.е. сделать «УЦ-однодневку» — это очень дорогая, кропотливая и долгая работа.
Жесть у вас… сочувствую. Мы то смогли на кф переложить, а с вашими проблемами фиг так получится.
Блокировать доступ нельзя, но можно значительно срезать максимальный объем данных и скорость передачи для злоумышленника. Или нельзя?
Какая-то странная проблема… Ну в нормальной системе пришёл запрос, расшифровали его и положили во входящую очередь на обработку, ок… Но если вас так давят, так вы модель с push в эту очередь замените на модель с pull из входящих очередей и набирайте очередь на обработку от каждого пользователя по запросу (конечно можно зарегать 100500 фирм, но, подозреваю, это сложнее, чем послать 100500 запросов от одной фирмы). И всё, сколько бы у пользователя не было входящих запросов — вы всё равно их все обработаете (можно хоть в kaffka складывать и потом юзеру 2 месяца на email слать отлупы, что его запрос 8129431 из спам-аттаки не может быть обработан по причине завершения торгов 2 месяца назад...) О чём вам тут уже не раз написали (значит не только я тупой и не понял чё вы сразу так не сделали.
Ваше направление мысли правильное, и у нас есть идеи и наработки схожего с вашим алгоритма. Но проблема состоит в том, что приходится сталкиваться с «кричащим нарушителем», т.е. таким пользователем, который в случае своей неудачной атаки подает жалобу на нас за длительную обработку его запросов.
Если ситуация дойдет до суда, то суд может вынести решение не в пользу площадки.
Потому что отложенная обработка запросов или их ограничение можно трактовать как «ограничение доступа к торгам по конкурентному принципу».
Если ситуация дойдет до суда, то суд может вынести решение не в пользу площадки.
Потому что отложенная обработка запросов или их ограничение можно трактовать как «ограничение доступа к торгам по конкурентному принципу».
А ддос нынче окупается при таком использовании?
ИМХО, вопрос решается старыми проверенными способами. Если есть дефицит ресурсов — то нужно ограничить их распределение по количеству «в руки» и/или по времени.
Скажем, если в официальном интерфейсе кнопка отправки ставки будет после ее нажатия (или получения клиентом подтверждения доставки) пропадать на пару секунд (и, соответственно, сервер ту же пару секунд будет дропать все от этого клиента а хоть бы и по ip — маловероятно, что у реального участника ip настолько динамический) — это не будет восприниматься как нарушение пункта 1. Еще вариант — «ставка по кругу». В цикле все участники могут или сделать ставку, или пропустить ход (последнее может производиться и по таймауту) — но только явно и один раз за цикл, после чего, опять же, до конца цикла у них нет «официальной» возможности отправить что-либо еще — и все пакеты от них сервер дропает. Три цикла без изменения ставки => завершение торгов.
Скажем, если в официальном интерфейсе кнопка отправки ставки будет после ее нажатия (или получения клиентом подтверждения доставки) пропадать на пару секунд (и, соответственно, сервер ту же пару секунд будет дропать все от этого клиента а хоть бы и по ip — маловероятно, что у реального участника ip настолько динамический) — это не будет восприниматься как нарушение пункта 1. Еще вариант — «ставка по кругу». В цикле все участники могут или сделать ставку, или пропустить ход (последнее может производиться и по таймауту) — но только явно и один раз за цикл, после чего, опять же, до конца цикла у них нет «официальной» возможности отправить что-либо еще — и все пакеты от них сервер дропает. Три цикла без изменения ставки => завершение торгов.
будет дропать все от этого клиента а хоть бы и по ip
А если несколько клиентов сидят за одним ip?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
DoS-атака, от которой нельзя закрыться: в закупках своя атмосфера