Спасибо!
Для отслеживания мы используем систему GPS-мониторинг. Сложность обычно в том, что система мониторинга работает как GPS-связь и на момент отсутствия связи накапливает данные, а потом выпускает на портал.
Периодически всех людей отслеживаем и обзваниваем.
Проблема бывает еще в том, что вызвать подмогу — это тоже несколько сотен километров и несколько часов езды.
Но, конечно, каждый водитель фиксирует время выезда и прибытия.
То что было рассказано – это случаи, которые имели место быть не на регулярной основе. При всем этом, температура –30 — это вполне обычная температура на северах, и ребята совершают рейсы по 2-3 раза в неделю, вполне уверенно работая в таких условиях.
Так и есть. Например, какая-то компания выиграла тендер и зашла на объект с новой техникой, отработала ей условно 5-10 лет, заработала свою «кучу денег» и уходит. Техника им не нужна, потому что на рынке спустя 5-10 лет она становится неликвидна, а заниматься перепродажей невыгодно из-за удаленности объекта от цивилизации. Вот они ее и закапывают безжалостно.
К счастью, в нашей работе специфика такова, что техника не настолько изнашивается — перевозим ее с места на место. Плюс изначально покупаем ее с дальним прицелом — чтоб надолго хватило.
В данном абзаце шла речь не конкретно про Новый Уренгой, а про Тюменскую область, в которую входит и ЯНАО, и ХМАО. Необходимость была вызвана производственными причинами, а не желанием геройствовать.
Какая разница, большая она или нет? Для грубой оценки нам всё равно выгоднее взять более быстрый алгоритм (во всяком случае вы пока не назвали ни одного аргумента, почему это не так).
Не совсем. При грубой оценке хочется выбирать наиболее приближенный к лучшему значению, если это сравнимо по времени.
Если утрировать, то самым быстрым алгоритмом тогда можно взять линейную регрессию и просто решающее дерево, однако это не даст вменяемый потолок.
Вопрос в балансе скорости получения результата и адекватности полученного результата. За счет быстроты работы к Lightgbm, например, быстрее подобрать гиперпараметры, однако если просто попробовать, без задания грида и as is, то это может быть не лучшим, т.к. нет уверенности что это не плюс-минус километр (как, например, при применении необученного RandomForest из scikit-learn).
Это миграция библиотеки для MatLab Torch на язык питон с сохранением функционала, грубо говоря. В данном обзоре мы рассматривали именно Python с упором на функциональную разницу.
Это слишком абстрактно — смотря какие порядки. Если разница в несколько минут, то можно и подождать, это сильно быстрее, чем тюнить руками, и отнимает меньше времени.
Лидером по скорости, несомненно, является LightGBM, после тюна параметров часто тоже. Но в случае, если совсем не задавать гиперпараметры и просто применять алгоритм на данных быстро, то catboost сразу показывает результаты, помогающие оценить порядок точности. Пробовали как на наших датасетах, так и есть исследования Яндекса, например, с конференции Smart Data, там же обещали GPU, но пока новостей не видели.
После того, как мы обнаружили атаку, следить за ней было уже не так сложно. Атакующая машина повторяла определенный набор действий.
После применения защитных мер мы по логам веб-сервера отметили, что, во-первых, выводы бонусных баллов из личного кабинета существенно сократились, а во-вторых, количество атакующих машин стало снижаться, пока не сошло на нет. Видимо, атакующий понял, что дальнейшие затраты в развитие атаки не окупят результаты.
Как я уже говорил, данный способ не универсальный, но по соотношению «затраченные ресурсы — эффективность» способ оказался вполне жизнеспособным.
Идеального способа сделать так, чтобы предотвратить любую Brute-Force атаку нет, особенно с учетом все большего их очеловечивания.
Изменение парольной политики — шаг потенциально правильный, но опять же страдает удобство пользователей. Плюс сразу после принудительной смены пароля большое количество клиентов захочет сменить его обратно на «попроще», пусть он и будет удовлетворять парольной политике, но вполне вероятно попадет в ещё какой-нибудь известный словарь. Дальнейшее ужесточение парольной политики приведет к оттоку клиетов и скажется на бизнесе.
С учетом того, что мы всего лишь донастроили модуль antibruteforce в уже имеющемся WAFe F5 ASM решение получилось довольно быстрым и недорогим.
Описанный случай, естественно, не универсальный. Я описал защиту в условиях имеющихся ограничений (невозможность доработки веб-приложения, ограниченность во времени). На ID клиента, конечно, можно влиять, но такой способ в любом случае усложняет атаку. А дальше, да — вопрос времени/лени атакующего, но время это было бы для нас очень кстати.
Первый вариант любопытный с точки зрения запутывания атакующего, но требует значительных изменений приложения, а у нас с этим, как я уже писал, была проблема.
Про вход по ключам — это все-таки не банковская система, пострадает юзабилити + потребуются существенные затраты.
Про привязку логина к IP — тоже уже пахнет банковским антифродом, слишком затратно для данной задачи.
Для крупного энтерпрайза такой костыль не подойдет. Бизнес ни за что на такое не пойдет. С точки зрения юзабилити для клиентов это еще хуже, чем капча.
И если к капче все уже более-менее привыкли, то как клиенты отреагируют на такое поведение сайта — не понятно.
Для отслеживания мы используем систему GPS-мониторинг. Сложность обычно в том, что система мониторинга работает как GPS-связь и на момент отсутствия связи накапливает данные, а потом выпускает на портал.
Периодически всех людей отслеживаем и обзваниваем.
Проблема бывает еще в том, что вызвать подмогу — это тоже несколько сотен километров и несколько часов езды.
Но, конечно, каждый водитель фиксирует время выезда и прибытия.
То что было рассказано – это случаи, которые имели место быть не на регулярной основе. При всем этом, температура –30 — это вполне обычная температура на северах, и ребята совершают рейсы по 2-3 раза в неделю, вполне уверенно работая в таких условиях.
К счастью, в нашей работе специфика такова, что техника не настолько изнашивается — перевозим ее с места на место. Плюс изначально покупаем ее с дальним прицелом — чтоб надолго хватило.
Не совсем. При грубой оценке хочется выбирать наиболее приближенный к лучшему значению, если это сравнимо по времени.
Если утрировать, то самым быстрым алгоритмом тогда можно взять линейную регрессию и просто решающее дерево, однако это не даст вменяемый потолок.
Вопрос в балансе скорости получения результата и адекватности полученного результата. За счет быстроты работы к Lightgbm, например, быстрее подобрать гиперпараметры, однако если просто попробовать, без задания грида и as is, то это может быть не лучшим, т.к. нет уверенности что это не плюс-минус километр (как, например, при применении необученного RandomForest из scikit-learn).
Графики AUC vs время обучения в сравнении catboost с другими алгоритмами можно найти в этой презентации от Яндекса assets.ctfassets.net/oxjq45e8ilak/1NtBCBQxXCaAOwy8kumUKu/edccea9c32bdf119e10417367cc85602/_________________________________________CatBoost___________________________________________________________________________.pdf
После применения защитных мер мы по логам веб-сервера отметили, что, во-первых, выводы бонусных баллов из личного кабинета существенно сократились, а во-вторых, количество атакующих машин стало снижаться, пока не сошло на нет. Видимо, атакующий понял, что дальнейшие затраты в развитие атаки не окупят результаты.
Как я уже говорил, данный способ не универсальный, но по соотношению «затраченные ресурсы — эффективность» способ оказался вполне жизнеспособным.
Идеального способа сделать так, чтобы предотвратить любую Brute-Force атаку нет, особенно с учетом все большего их очеловечивания.
С учетом того, что мы всего лишь донастроили модуль antibruteforce в уже имеющемся WAFe F5 ASM решение получилось довольно быстрым и недорогим.
Про вход по ключам — это все-таки не банковская система, пострадает юзабилити + потребуются существенные затраты.
Про привязку логина к IP — тоже уже пахнет банковским антифродом, слишком затратно для данной задачи.
И если к капче все уже более-менее привыкли, то как клиенты отреагируют на такое поведение сайта — не понятно.