Pull to refresh
151
1.7
Send message
То пока они не нашли что он у вас проверяется, т.к. и InBrowserlD и Device-ID можно довольно быстро менять...


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

Пока же кроме IP (ну и возможно еще длинного и долгоиграющего DH-сессионного ключа https-сессии) еще ничего не придумали.


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

Что касается DH-сессионного ключа https-сессии, в нашем случае при каждой попытке логина устанавливалась новая сессия.
В нашем случае заказчик не мог (не хотел) что-то менять в приложении в обозримом будущем. Поэтому пришлось организовывать капчу средствами F5.
Риск потери клиентов, конечно, был, но по итогу величина оказалась приемлемой для бизнеса (точную цифру не подскажу, это уже заказчик сам посчитал).
На принтскрине отображаются золотые монетки — они обозначают число правильных ответов, серые — неправильных. Заголовок над монетками — результат теста.
Здравствуйте. У нас подобная ошибка не воспроизводится. Пришлите, пожалуйста, принтскрин или скринкаст прохождения теста и экрана результатов, чтобы мы поняли, что не так. Возможно, у вас включен блокировщик рекламы/баннеров и он мешает воспроизвести содержимое.
Действительно, со слов представителей Bull, они в 90-х годах присутствовали в России и продавали какую-то свою компьютерную технику. После чего их присутствие закрылось и вновь открылось пару-тройку лет назад уже в текущем виде.
Мы как системный интегратор пишем о своей работе, а не оператора связи Тинькофф Мобайл. Мы поставляем решение, интегрируем, но не внедряем СОРМ на сети и не сдаём узел связи в РКН.

HLR,AUC, HSS — на этапе запуска на стороне MNO, сейчас оператором ведётся работа по внедрению этих элементов на своей сети.
Хороший пример. На первом этапе виртуальный оператор запускался для обслуживания абонентов Москвы и Санкт-Петербурга. Этим обусловлена централизация сервисных компонентов в Москве. По мере развития абонентской базы и экспансии в регионы на следующих этапах будут появляться региональные узлы, сначала на уровне макрорегионов, а затем, возможно, и на уровне областей страны. Работа в этом направлении уже ведётся, но размещение компонентов по всем регионам нашей страны требует определённых затрат и это становится оправдано, когда проект развивается успешно и региональная абонентская база растёт. В этом плюс для виртуального оператора на старте: сравнительно с небольшими инвестициями на старте можно быстро запустить сеть на всю страну и в дальнейшем развивать её, планомерно увеличивая пропускную способность и улучшая качество сервиса по мере набора абонентской базы.
Да, действительно, на схеме показано только ядро пакетной сети. Ядро голосовой сети пока остаётся на стороне MNO (Теле2) и голосовые вызовы у абонентов Тинькофф Мобайл, конечно же, работают. В то же время есть тренд на снижение интереса к голосовым сервисам со стороны абонентов. Многие новые виртуальные операторы, строящиеся сегодня по схеме Full MVNO, в качестве первого приоритета делают упор на собственное ядро пакетной сети, т.к. это напрямую связано с возможностями гибкого тарифного ценообразования, и уже во вторую очередь рассматривают построение ядра голосовой сети на своей инфраструктуре. Перенос GMSC на сторону MVNO добавляет гибкости виртуальному оператору в части реализации дополнительных сервисов и услуг, поэтому, скорее всего, он будет реализован на стороне MVNO, но в какие сроки и какие плюсы от этого получат абоненты, пока говорить рано.

Вопрос СОРМа вне зоны нашей ответственности, обычно операторы договариваются с производителями СОРМ напрямую. К нашему решению никаких специальных требований в части СОРМ не предъявляется.
Да, периодически пользуемся этой технологией. Наиболее частые примеры
интеграции в нашей практике, следующие:

1) Интеграция с Firepower при применении динамической авторизации
пользователей в сети по 802.1x — условно пользователь авторизовался,
ISE по политики аутентификации принял решение о том, к какой группе
относится пользователь (например: «доменный пользователь, недоменный
АРМ, посчуринг – не проводился»), и принадлежность к группе используется
на Firepower для применения каких-либо правил (например URL-фильтрации
и запрета приложений P2P).

2) Интеграция с Firepower при применении PassiveID — интересный вариант
взаимодействия, при котором тоже используется PxGrid для передачи на
Firepower информации о пользователях, но когда пользователь «не видит»
процесса аутентификации в сети. ISE получает данные об авторизации
пользователя в домене, профилирует его, проводит посчуринг (клиент
распространяется доменными политиками) и отдает на Firepower результат,
который так же применяется в политиках, как и в предыдущем случае.

3) Интеграция с StealthWatch. StealthWatch наблюдает за поведением сети и
при выявлении аномальных активностей может попросить ISE закарантинить
провинившийся хост.

4) Это решение сейчас на стадии «внутреннего тестирования» — сторонние
вендоры начинают поддерживать интеграцию с ISE по PxGrid, в том числе и
для SGT-меток. Сейчас мы прорабатываем интеграцию с шлюзами Check Point
инфраструктуры TrustSec с применением взаимодействия по PxGrid между
ISE и Checkpoint Identity Collector.

Открытого доступа к этой штуке еще нет (и официально полноценная поддержка будет в версии ПО 80.20, которая еще не вышла).
Спасибо! Исправили.
Шаблонизация заявок — в данном случае это создание единого входящего
шаблона для более точной категоризации заявок.
Планируем, это интересная тема. Сейчас решаем вопрос с шаблонизацией входящих заявок, без которой будет тяжело «разбирать» заявку на части и анализировать её.
Чат-бот не привязан к сайту, все зависит от конкретной задачи/задач. Конкретно наш инструмент выполняет роль помощника инженера тех. поддержки
На стороне заказчика имеется инструмент, предоставляющий веб-интерфейс для управления бизнес-процессами.
Selenium WebDriver – это программная библиотека, которая позволяет взаимодействовать с браузером (получать данные, заставлять выполнять различные действия/команды).
Selenium Python API предоставляет доступ ко всем функциям Selenium WebDriver.
В нашем случае веб-драйвер используется для авторизации, поиска различных элементов на веб-странице и взаимодействия с ними.

Открывать весь репозиторий не можем, но, если вас интересуют конкретные участки, готовы рассказать, как они примерно реализованы.
Мы с коллегами из ВТБ рассказали о нашем совместном проекте. Приглашаем хабражителей почитать подробности в блоге ВТБ.
Рады внимательным читателям :). Действительно, черновой вариант поста по недосмотру был размещен ранее и провисел тут несколько минут. Сейчас исправили ошибки.
Если ошибка затесалась, то дедуп или нет — не имеет значения. Восстанавливаться придется с предыдущего бэкапа в любом случае.
Если мы говорим об ошибке записи и битом блоке во время создания полной копии (или любой другой) и система резервного копирования это пропустила, то следующий бэкап при прохождении листинга файлов увидит несоответствие хранимого блока и того, что на системе. Как следствие получим резервирование данного блока. Противоречия нет:)
Оба описанных случая из серии “всё делали правильно, но не оценили возможные риски”. Вероятность программного повреждения данных не рассматривалась заказчиком как риск, ведь решение было массовым, стабильно работало длительное время и таких случаев ранее не было.

По нашему мнению, инфраструктура критичных бизнес-систем должна строиться так, чтобы использование системы резервного копирования в случае повреждения или потери данных было именно резервным средством, а не основным механизмом восстановления доступности бизнес-систем.

Такой подход обусловлен двумя недостатками систем резервного копирования:

  1. Сложность прогнозирования длительности восстановления данных. Безусловно, система резервного копирования может быть спроектирована под заданные параметры SLA и обеспечивать их в момент своего старта. Однако, как показывает практика, ИТ-инфраструктура любой компании — постоянно изменяющаяся среда, содержащая постоянно растущие объёмы данных. Поэтому спрогнозировать длительность восстановления какой-либо бизнес-системы спустя некоторый промежуток времени достаточно сложно, а в случае массового сбоя, заставляющего восстанавливать множество бизнес-систем (например, при отказе дискового массива) — практически невозможно.
  2. Недостаточная степень гранулярности восстановления данных. Система резервного копирования, как правило, работает с данными бизнес-приложений на достаточно низком уровне. Это приводит к тому, что при повреждении или потере небольшого набора данных, к примеру, при удалении строки в таблице СУБД Oracle, приходится восстанавливать значительный объём данных — в данном случае целиком табличное пространство СУБД. То есть объём данных, который необходимо восстановить из СРК, часто не соответствует объёму данных, которые были потеряны или повреждены при сбое. Как в данном случае.
Это, скорее, к вопросу о поставленных задачах, ожиданиях и реальности. В контексте оптимизации СРК программно-аппаратные комплексы с дедупликацией позволяют сократить объем передаваемых данных — в случае с БД, в среднем 5:1, — и тем самым ускорить прохождение бэкапов. Как следствие, позволяет чаще запускать бэкапы и сократить RPO. На длительности восстановления это никак не сказывается.

Information

Rating
1,051-st
Works in
Registered
Activity