Добавлю вариант организации доступа к корпоративным ресурсам с использованием класса продуктов Access Gateway. В этом случае вы ставите фронтом один сервер, который является реверс-прокси для всех остальных ресурсов. Наружу никакие корпоративные ресурсы напрямую не торчат, а становятся доступны только через Access Gateway. Получается как вариант с фрон-эндом, только он тут один для всех ресурсов, а следовательно сокращается количество векторов атак. Обычно Access Gateway обеспечивает не только сам доступ, но и аутентификацию, авторизацию, SSO.
Если я правильно помню тервер, то формула расчета вероятности для такой ситуации такая:
1-(1-0,001)^100 = 0,095 = 9,5%
То есть ваши выводы вроде правильные.
Пару недель назад мне доставили wifi-розетку из поднебесной. Когда покупал, знал, что она легко модифицируется по инструкции. Розетка работает под openwrt, на ней запущен веб-сервер. По сути я просто положил в /www/cgi-bin скрипт, который меняет состояние розетки вкл/выкл.
Родное приложение мне не очень удобно, поэтому я настроил виджет, отправляющий HTTP GET запрос на веб-сервер розетки.
Цена вопроса 1000р с доставкой.
И все-таки у сбера есть проверка IMSI.
Сегодня я попытался создать новый шаблон в онлайн-банке. Его нужно было подтвердить паролем из СМС. Однако на телефон пришло сообщение, что «В связи с заменой сим-карты смс-пароль не может быть отправлен на этот номер». Так же в сообщении указывалось, что надо позвонить на линию поддержки, чтобы перерегистрировать СИМ-карту.
Позвонил, перерегистрировал и заодно расспросил: «Как же так получилось, что я успешно делал платежи как через онлайн-банк с СМС-паролями, так и с использованием 3dSecure и банк не обращал внимания на смену сим-карты, а теперь обратил». Сказали, что есть какие-то критерии, по которым банк решает, когда надо проверять замену сим, а когда не надо. Создание шаблона — один из триггеров, по которому такая проверка срабатывает.
Удивительно, что платежи по 20т.р. не являются сигналами для банка проверить мою сим-карту, а безобидный шаблон (а это даже не подтверждение оплаты) является.
Злоумышленникам удалось получить «валидные» данные доступа операторов, имеющих права на создание и одорбрение сообщений SWIFT.
Как раз недавно делал проект по строгой аутентификации для доступа к платформе SWIFT. Насколько я знаю, SWIFT начал требовать от сервис-бюро наличие двухфакторной аутентификации пользователей (пункт 7 в этом документе, полная версия с оглавлением). Однако, многие финансовые организации продолжают пользоваться простыми паролями по старинке.
Только что отписался от одной из рассылок в интерфейсе почты Яндекса. Никаких внешних переходов. Просто появилось "Вы отписались от этой рассылки", а само сообщение было перенесено в удаленные.
Так что Яндекс похоже для некоторых рассылок умеет отписываться сам, без редиректа браузера на страницу отписки.
Скорее всего сейчас просто добавит в спам.
Но я как раз говорю, что было бы круто, чтобы рассыльщики делали отписку по простому get-запросу, не требуя дополниетльных действий. Тогда list-unsubscribe можно везде реализовать одинаково — без перехода по ссылке в браузере, а простым гет-запросом со стороны самого почтового клиента. По-моему, красивое и безопасное решение.
Предложение отписаться в виде ссылки внутри письма может, конечно, открывать красивую страницу с дополнительными вопросами.
По-моему, автоматическое добавление всех писем от отписанного сервиса в спам очень сомнительное решение. Как раз нажать на кнопку спам не так сложно, а вот найти письма, после повторной подписки в спаме как-то неприятно. Тем более странно, что меняется репутация рассыльщика. Я бы таким, кто правильно формирует рассылки и позволяет так удобно отписаться наоборот репутацию поднимал.
Опускать репутацию нужно, если после отписывания пользователь вынужден нажимать спам для этого отправителя.
Я как раз не поддерживаю отправку в спам и написал об этом в своем комментарии.
Я про то, что кнопка "Отписаться" в интерфейсе почтового клиента (пусть даже веб-клиента) не должна открывать ссылки, а должна просто отписывать от рассылки.
По вашему комментарию:
Как можно узнать, какой ответ возвращает кнопка, если по ней переходит не условный mail.ru, а браузер пользователя? Если же условный mail.ru начнет переходить по этим ссылкам для проверки доступности, то отпишет всех пользователей автоматически.
Очевидное решение по отписке от рассылки это простая ссылка, get-запрос которой отписывает пользователя. И такой get-запрос может осуществить сам почтовый клиент, без необходимости подвергать опасности браузер пользователя. Так зачем пользователю открывать это в браузере? А главное, что никто таким образом не страдает, а даже больше: злодеи лишаются возможности завлечь пользователей по ссылке Unsubscribe в конце своего письма.
Для меня, например, было не очевидно, что нажатие на кнопку "Отписаться" приведет к открытию ссылки на сторонний ресурс. Как я уже писал, пользователь доверяет почтовому клиенту намного больше чем спам-письму. Даже те, кто догадывается, что нажимать Unsubscribe в незнакомом письме опасно, могут легко довериться кнопке "Отписаться", которую предлагает почтовый-клиент.
Не думал, что когда-нибудь напишу это, но тут я на стороне mail.ru. Я бы предпочел, чтобы кнопка "отписаться" так и работала, вместо того, чтобы открывать мне непонятно какую ссылку в браузере (ну кроме автоматической отправки в спам, конечно).
Что если злоумышленник только и ждет, что вы нажмете по кнопке "Отписаться", и подготовил по ссылке List-Unsubscribe ресурс, распространяющий вирусы? К кнопке почтового клиента доверия намного больше и ее будут нажимать гораздо смелее, чем ссылки в самом спам-письме.
Если правильно понял, то делают один гос УЦ, а остальные станут подчиненными.
Зачем генерировать ключевую пару на каком-то ГУЦ? Почему этот ГУЦ не может просто подписать сертификаты тех УЦ, которые он считает правильными? Если у пользователя сертификат ГУЦ в доверенных, то и те УЦ, сертификаты, которых он подписал, тоже доверенные.
В итоге через несколько лет мы получим единое и связное пространство доверия, в котором пользователи смогут чувствовать себя комфортно и использовать свои российские сертификаты для своих интернет-страничек, что в настоящее время не возможно.
Через несколько лет мы получим полную зависимость от единой точки — ГУЦ. Компрометация единственного УЦ приведет к полному краху всей модели доверия. Такого рода централизация мне не нравится.
Скажу честно, я доволен работой МКС по развитию пространства доверия, которое перерастает детские болезни в области использования ЭП в России, давно пора.
Децентрализация удостоверяющих центров это не детская болезнь, а принятая модель доверия в инфраструктурах с открытым ключом. Я был бы крайне недоволен, если завтра, например, США скажут, что все WebTrust УЦ должны получать корневые ключи от USA_ROOT_CA, а не генерировать их самостоятельно.
Сервер аутентификации может быть любой, который поддерживает протокол RADIUS. Я использовал neXus Hybrid Access Gateway. Этот сервер избыточен для такой узкой задачи. Вы можете попробовать что-то полегче, например, linotp + freeRADIUS.
Спасибо за интересный пост. Я в свое время тоже тестировал аналогичное решение с одноразовыми паролями для Windows. Использовал сервер аутентификации, поддерживающий протокол RADIUS, а на клиенте устанавливал PGina.
Если моя формула верная, то для 1000 человек:
1-(1-0,001)^1000 = 0,632 = 63,2%
1-(1-0,001)^100 = 0,095 = 9,5%
То есть ваши выводы вроде правильные.
Родное приложение мне не очень удобно, поэтому я настроил виджет, отправляющий HTTP GET запрос на веб-сервер розетки.
Цена вопроса 1000р с доставкой.
https://geektimes.ru/post/273030/
Сегодня я попытался создать новый шаблон в онлайн-банке. Его нужно было подтвердить паролем из СМС. Однако на телефон пришло сообщение, что «В связи с заменой сим-карты смс-пароль не может быть отправлен на этот номер». Так же в сообщении указывалось, что надо позвонить на линию поддержки, чтобы перерегистрировать СИМ-карту.
Позвонил, перерегистрировал и заодно расспросил: «Как же так получилось, что я успешно делал платежи как через онлайн-банк с СМС-паролями, так и с использованием 3dSecure и банк не обращал внимания на смену сим-карты, а теперь обратил». Сказали, что есть какие-то критерии, по которым банк решает, когда надо проверять замену сим, а когда не надо. Создание шаблона — один из триггеров, по которому такая проверка срабатывает.
Удивительно, что платежи по 20т.р. не являются сигналами для банка проверить мою сим-карту, а безобидный шаблон (а это даже не подтверждение оплаты) является.
Как раз недавно делал проект по строгой аутентификации для доступа к платформе SWIFT. Насколько я знаю, SWIFT начал требовать от сервис-бюро наличие двухфакторной аутентификации пользователей (пункт 7 в этом документе, полная версия с оглавлением). Однако, многие финансовые организации продолжают пользоваться простыми паролями по старинке.
Так что Яндекс похоже для некоторых рассылок умеет отписываться сам, без редиректа браузера на страницу отписки.
Но я как раз говорю, что было бы круто, чтобы рассыльщики делали отписку по простому get-запросу, не требуя дополниетльных действий. Тогда list-unsubscribe можно везде реализовать одинаково — без перехода по ссылке в браузере, а простым гет-запросом со стороны самого почтового клиента. По-моему, красивое и безопасное решение.
Предложение отписаться в виде ссылки внутри письма может, конечно, открывать красивую страницу с дополнительными вопросами.
Опускать репутацию нужно, если после отписывания пользователь вынужден нажимать спам для этого отправителя.
Я про то, что кнопка "Отписаться" в интерфейсе почтового клиента (пусть даже веб-клиента) не должна открывать ссылки, а должна просто отписывать от рассылки.
По вашему комментарию:
Как можно узнать, какой ответ возвращает кнопка, если по ней переходит не условный mail.ru, а браузер пользователя? Если же условный mail.ru начнет переходить по этим ссылкам для проверки доступности, то отпишет всех пользователей автоматически.
Очевидное решение по отписке от рассылки это простая ссылка, get-запрос которой отписывает пользователя. И такой get-запрос может осуществить сам почтовый клиент, без необходимости подвергать опасности браузер пользователя. Так зачем пользователю открывать это в браузере? А главное, что никто таким образом не страдает, а даже больше: злодеи лишаются возможности завлечь пользователей по ссылке Unsubscribe в конце своего письма.
Для меня, например, было не очевидно, что нажатие на кнопку "Отписаться" приведет к открытию ссылки на сторонний ресурс. Как я уже писал, пользователь доверяет почтовому клиенту намного больше чем спам-письму. Даже те, кто догадывается, что нажимать Unsubscribe в незнакомом письме опасно, могут легко довериться кнопке "Отписаться", которую предлагает почтовый-клиент.
Что если злоумышленник только и ждет, что вы нажмете по кнопке "Отписаться", и подготовил по ссылке List-Unsubscribe ресурс, распространяющий вирусы? К кнопке почтового клиента доверия намного больше и ее будут нажимать гораздо смелее, чем ссылки в самом спам-письме.
Зачем генерировать ключевую пару на каком-то ГУЦ? Почему этот ГУЦ не может просто подписать сертификаты тех УЦ, которые он считает правильными? Если у пользователя сертификат ГУЦ в доверенных, то и те УЦ, сертификаты, которых он подписал, тоже доверенные.
Через несколько лет мы получим полную зависимость от единой точки — ГУЦ. Компрометация единственного УЦ приведет к полному краху всей модели доверия. Такого рода централизация мне не нравится.
Децентрализация удостоверяющих центров это не детская болезнь, а принятая модель доверия в инфраструктурах с открытым ключом. Я был бы крайне недоволен, если завтра, например, США скажут, что все WebTrust УЦ должны получать корневые ключи от USA_ROOT_CA, а не генерировать их самостоятельно.