Как настроить персональный VPN на сервере в Amazon Web Services

Всем, кто хочет настроить свой собственный VPN на личном выделенном сервере рекомендую проект algo . Инструмент дает настроить WireGuard сервер в интерактивном режиме. WireGuard удобен тем, что дает пользоваться VPN на любых устройствах, от компьютера на Windows/Linux до iPhone или смартфона на Android.

Предполагается, что AWS аккаунт у вас уже есть, инструкции проверялись на Ubuntu.

Для AWS cоветую пользоваться LightSail, а не обычным EC2, так как LightSail имеет квоту бесплатного исходящего трафика в 1 терабайт. При активном использовании VPN на EC2 это может вылиться в копеечку, так как любой исходящий трафик будет тарифицироваться.

К примеру, чтобы запустить LightSail машину:

  1. git clone https://github.com/trailofbits/algo.git
  2. cd algo && sudo apt install -y python3-virtualenv

Читать далее Как настроить персональный VPN на сервере в Amazon Web Services

Что можно найти, если сделать реверс-инжиниринг 16 тысяч Android-приложений

Сайт Fallible помогает провести реверс-инжиринг Android приложения с целью получения секретов, прошитых в исходном коде. Компания периодически анализирует приложения заказчиков на безопасность и решила выложить сервис в откртый доступ. За пару месяц среди 16 тысяч приложений было найдено около двух с половиной тысяч приложений с ключами или секретами к внешним сервисам.

Например, получив секретный код приложения Uber, можно было рассылать произвольные уведомления как будто из настоящего приложения Uber.

Некоторые разработчики даже оставляют секретные коды к аккаунту Amazon Web Services c правами на запуск и остановку экземпляров виртуальных машин. Тут стоит упомянуть о существовании помощников, которые могут защитить от нечаянного коммита секретов в публичный репозиторий. Например, https://github.com/awslabs/git-secrets.

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

via Hackernoon

 

Почему протокол NTLM устарел

Аутентификационный протокол NTLM является устаревшим, так как обладает недостатками, которые могут скомпрометировать безопасность приложений и операционной системы. Отсутствие серверной аутентификации — одна из главных проблем, позволяет хакеру обмануть пользователей и заставить их подключиться к взломанному серверу.

Как следствие отсутствия серверной аутентификации, приложения, использующие NTLM могут быть уязвимы к атакам типа «отражение« Идея такой атаки состоит в том, чтобы запутать целевой компьютер в Challenge-response authenticationи заставить его  правильно ответить на свой же запрос инициировав новое встречное подключение с теми же параметрами. Правильный ответ можно использовать для дальнейшего нормального процесса аутентификации.

Хотя протокол Kerberos доступен уже долгие  годы, множество приложений продолжают поддерживать только NTLM режим, что существенно ухудшает безопасность системы. Однако Kerberos не может заменить NTLM во всех сценариях, например, когда клиент аутентифицируется в системе, но не состоит в домене. В таком случае необходимо использовать протокол Negotiage, который использует Kerberos всегда, когда это только возможно и переключается на совместимость с NTLM только когда нет возможности работы по Kerberos.

Стоит помнить, что Negotiage не серебряная пуля — можно найти случаи, в которых атакующий может соединиться через NTLM, но такие случаи более редко и трудно эксплуатируемы. Как минимум, приложения, правильно переписанные на Negotiate перестают страдать от уязвимости к NTLM атакам типа «отражение».

Еще одним предостережением против использования NTLM является возможность прекращения поддержки NTLM в новых версиях Windows, такие приложения просто не смогут аутентифицироваться.

 

По материалам ServerFault.