Comments 29
UFO just landed and posted this here
В нашем случае заказчик не мог (не хотел) что-то менять в приложении в обозримом будущем. Поэтому пришлось организовывать капчу средствами F5.
Риск потери клиентов, конечно, был, но по итогу величина оказалась приемлемой для бизнеса (точную цифру не подскажу, это уже заказчик сам посчитал).
Риск потери клиентов, конечно, был, но по итогу величина оказалась приемлемой для бизнеса (точную цифру не подскажу, это уже заказчик сам посчитал).
2FA, Oauth от сильных мира сего
Но мы не стали блокировать атаку на основе этого признака, потому что в таком случае перестали бы видеть действия злоумышленника.
В хонепот его, гада...
и когда зараженная машина открывает эту страницу, то сообщает свой уникальный идентификатор.
То пока они не нашли что он у вас проверяется, т.к. и InBrowserlD и Device-ID можно довольно быстро менять...
Пока же кроме IP (ну и возможно еще длинного и долгоиграющего DH-сессионного ключа https-сессии) еще ничего не придумали.
То пока они не нашли что он у вас проверяется, т.к. и InBrowserlD и Device-ID можно довольно быстро менять...
Поскольку индентификатор браузера генерирует F5, атакующим пришлось бы подстраиваться под методы генерации, что уже существенно усложнило бы атаку.
Пока же кроме IP (ну и возможно еще длинного и долгоиграющего DH-сессионного ключа https-сессии) еще ничего не придумали.
У коллег похожая атака производилась с адресов, которые были в известных репутационных списках, для них бы метод блокировки по IP, безусловно, сработал. В нашем случае адреса не фигурировали ни в одном из известных списков, и при блокировке по IP был риск блокировки легитимных клиентов, на что безопасность и бизнес заказчика не были готовы пойти.
Что касается DH-сессионного ключа https-сессии, в нашем случае при каждой попытке логина устанавливалась новая сессия.
Поскольку индентификатор браузера генерирует F5, атакующим пришлось бы подстраиваться под методы генерации...
Поскольку индентификатор браузера генерирует F5… в браузере! Подстраиватся?
Скорее вероятно просто (пока) не нашли, что вы его используете...
при каждой попытке логина устанавливалась новая сессия
Думается мне вы путаете DH-сессию с какой-то другой. Длительность DH-сессии задаётся в обработчике https-слоя и в нормальном виде не зависит от логина и т.п…
DH-ключи (особенно для длинных сертификатов) не обновляются на протяжении длительных интервалов времени.
или я в этом мало понимаю, но неужели сложно отфильтровать куки в клиенте? да и каждый раз генерить или брать из списка client id, чтобы он не повторялся. так что, сработавший способ это не ваша заслуга, а недоработка и лень хакеров :)
Не очень понятно, что имелось в виду под «отфильтровать куки в клиенте».
Что касается генерации client id — идентификатор клиента генерировал F5.
Что касается генерации client id — идентификатор клиента генерировал F5.
Не очень понятно, что имелось в виду под «отфильтровать куки в клиенте».не сохранять те, которые могут в будущем скомпрометировать как повторного посетителя. или сохранять все, но только в пределах одного сеанса.
Что касается генерации client id — идентификатор клиента генерировал F5
там уже выше написали, но я повторю. Этот айди сгенерирован на клиенте, хранится на клиенте и полностью подконтролен клиенту. Достать\найти его там — вопрос времени\лени. Основывать хоть какую-либо защиту на клиенте — это все равно что прикрыться зонтиком во время цунами
Описанный случай, естественно, не универсальный. Я описал защиту в условиях имеющихся ограничений (невозможность доработки веб-приложения, ограниченность во времени). На ID клиента, конечно, можно влиять, но такой способ в любом случае усложняет атаку. А дальше, да — вопрос времени/лени атакующего, но время это было бы для нас очень кстати.
Альтернативный извращенный костыль. Срисовывать атакующие ip и при попытке залогинится с них, пускать только при повторном вводе пароля, а первый раз всегда выдавать ошибку с записью в куки или сессию. Юзер подумает что ошибся при наборе и повторит ввод(проверяем наличия предыдущего кривого ввода — пускаем), а бот отвалится.
А как по итогу обнаружили атаку? Ручным анализом логов или IDS распознала?
Ну, я бы предложил примерно такой алгоритм противодействия:
При входе с неправильным логином, если такого логина нет в базе — имитируем удачный вход. Пусть атакующие пытаются воспользоваться таким логином — и тратят на это свои силы. Заодно можно будет узнать, на какой адрес атакующие закажут доставку товара.
При входе с правильным логином и неверным паролем — тоже имитировать удачный вход, но в виде картинки сообщать, что вход неудачный. Короче говоря — морочить атакующему голову, как отличить удачную попытку входа от неудачной.
Дальше можно рандомно менять имена полей ввода. Как правило, атакующие один раз настраивают атакующий скрипт на отправку запроса, считая, что поле для имени = login, поле для пароля = password.
Как тут уже предложили — через JS отслеживать поведение пользователя — нажатие клавиш и движение мыши. Вряд ли атакующий скрипт будет полноценно имитировать поведение пользователя.
Идеально было бы настроить вход не по паролю (который реально подобрать), а по ключу, как в SSh. Вот только не знаю, насколько это годится для простых юзеров; обычно это делают крутые сисадмины для себя или для натасканных юзеров.
Ещё есть вариант — привязка логина к IP-адресу или к IP-сети класса C (или что там выдаёт провайдер). Однозначная привязка не обязательна — но добавление IP-адреса в список привязанных к логину проводить по сложной процедуре типа дополнительной авторизации через SMS.
При входе с неправильным логином, если такого логина нет в базе — имитируем удачный вход. Пусть атакующие пытаются воспользоваться таким логином — и тратят на это свои силы. Заодно можно будет узнать, на какой адрес атакующие закажут доставку товара.
При входе с правильным логином и неверным паролем — тоже имитировать удачный вход, но в виде картинки сообщать, что вход неудачный. Короче говоря — морочить атакующему голову, как отличить удачную попытку входа от неудачной.
Дальше можно рандомно менять имена полей ввода. Как правило, атакующие один раз настраивают атакующий скрипт на отправку запроса, считая, что поле для имени = login, поле для пароля = password.
Как тут уже предложили — через JS отслеживать поведение пользователя — нажатие клавиш и движение мыши. Вряд ли атакующий скрипт будет полноценно имитировать поведение пользователя.
Идеально было бы настроить вход не по паролю (который реально подобрать), а по ключу, как в SSh. Вот только не знаю, насколько это годится для простых юзеров; обычно это делают крутые сисадмины для себя или для натасканных юзеров.
Ещё есть вариант — привязка логина к IP-адресу или к IP-сети класса C (или что там выдаёт провайдер). Однозначная привязка не обязательна — но добавление IP-адреса в список привязанных к логину проводить по сложной процедуре типа дополнительной авторизации через SMS.
Первый вариант любопытный с точки зрения запутывания атакующего, но требует значительных изменений приложения, а у нас с этим, как я уже писал, была проблема.
Про вход по ключам — это все-таки не банковская система, пострадает юзабилити + потребуются существенные затраты.
Про привязку логина к IP — тоже уже пахнет банковским антифродом, слишком затратно для данной задачи.
Про вход по ключам — это все-таки не банковская система, пострадает юзабилити + потребуются существенные затраты.
Про привязку логина к IP — тоже уже пахнет банковским антифродом, слишком затратно для данной задачи.
Мне кажется, лучшим решением было бы:
То, что было реализовано, больше похоже на «любые костыли за ваши деньги» — решение чрезмерное и слабое в долгосрочной перспективе.
- Внедрить парольную политику, требующую надежных паролей.
- Посмотреть примерный список паролей, которые пытаются использовать брутфорсеры.
- Найти в базе пользователей, которые используют эти пароли. Это может быть затратно по вычислениям, но это разовая операция.
- Принудительно сменить пользователям пароли и разослать их на почту.
То, что было реализовано, больше похоже на «любые костыли за ваши деньги» — решение чрезмерное и слабое в долгосрочной перспективе.
На шаге, что такое "надежный" пароль и как определенные политики "надежных" паролей ломают UX и прибыль, бизнес справедливо возмутится таким решением.
Изменение парольной политики — шаг потенциально правильный, но опять же страдает удобство пользователей. Плюс сразу после принудительной смены пароля большое количество клиентов захочет сменить его обратно на «попроще», пусть он и будет удовлетворять парольной политике, но вполне вероятно попадет в ещё какой-нибудь известный словарь. Дальнейшее ужесточение парольной политики приведет к оттоку клиетов и скажется на бизнесе.
С учетом того, что мы всего лишь донастроили модуль antibruteforce в уже имеющемся WAFe F5 ASM решение получилось довольно быстрым и недорогим.
С учетом того, что мы всего лишь донастроили модуль antibruteforce в уже имеющемся WAFe F5 ASM решение получилось довольно быстрым и недорогим.
в уже имеющемся WAFe F5 ASM решение получилось довольно быстрым и недорогим
Как Вы можете быть уверены, что Вы решили проблему?
После того, как мы обнаружили атаку, следить за ней было уже не так сложно. Атакующая машина повторяла определенный набор действий.
После применения защитных мер мы по логам веб-сервера отметили, что, во-первых, выводы бонусных баллов из личного кабинета существенно сократились, а во-вторых, количество атакующих машин стало снижаться, пока не сошло на нет. Видимо, атакующий понял, что дальнейшие затраты в развитие атаки не окупят результаты.
Как я уже говорил, данный способ не универсальный, но по соотношению «затраченные ресурсы — эффективность» способ оказался вполне жизнеспособным.
Идеального способа сделать так, чтобы предотвратить любую Brute-Force атаку нет, особенно с учетом все большего их очеловечивания.
После применения защитных мер мы по логам веб-сервера отметили, что, во-первых, выводы бонусных баллов из личного кабинета существенно сократились, а во-вторых, количество атакующих машин стало снижаться, пока не сошло на нет. Видимо, атакующий понял, что дальнейшие затраты в развитие атаки не окупят результаты.
Как я уже говорил, данный способ не универсальный, но по соотношению «затраченные ресурсы — эффективность» способ оказался вполне жизнеспособным.
Идеального способа сделать так, чтобы предотвратить любую Brute-Force атаку нет, особенно с учетом все большего их очеловечивания.
А вот, кстати, может быть аудитория подскажет — существует ли такой ресурс, на который можно залить список IP, на которых, по моему мнению, работает ботнет, в смысле — компьютеры заражены, а их владельцы, возможно, об этом не подозревают?
Sign up to leave a comment.
Редкий представитель вида brute-force: история одной атаки