Как взломать двухфакторную аутентификацию
Крепкость цепи, как известно, определяется крепкостью самого слабого звена. Чтобы понять, где в двухфакторной аутентификации самое слабое звено, рассмотрим технические аспекты её работы.
Всё начинается с того, что пользователь переходит на сайт и вводит свой пароль. Затем по другому каналу он получает второй пароль/код для входа на сайт. Всё современно и безопасно.
В случае удачного входа, как удалённый сервис «запомнит» этого пользователя, как будет отличать его запросы от других? А здесь всё по старинке — с помощью токена (маркера) сохранённого в кукиз. В принципе, это единственный вариант, который предусмотрен в самом протоколе HTTP.
Поскольку перехватить одновременно и пароль, и код из СМС редко представляется возможным, то более простым вариантом является перехват токена (кукиз), который выдаётся пользователю уже после входа. После перехвата этого маркера злоумышленник может сохранить их в кукиз своего веб-браузера и получить доступ к сервисам пользователя, защищённым двухфакторной аутентификацией — вводить какие-либо пароли и коды из СМС злоумышленнику не нужно!
Установка Nginx на CentOS
Рассмотрим практически установку Nginx на Linux, взяв за основу один из самых популярных дистрибутивов данной операционной системы – CentOS.
- Добавляем yum-репозиторий Nginx на ОС с помощью команды:
sudo rpm -Uvh http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm
- Для установки используем команду sudo yum install nginx. Подтверждаем появившееся извещение.
- Для запуска сервера используем команду:
sudo systemctl start nginx.service
- Проверить, успешна ли установка, можно, посетив общественный IP-адрес сервера. Узнать его можно через команду:
ip addr show eth0 | grep inet | awk '{ print $2; }' | sed 's/\/.*$//' - Чтобы Nginx автоматически запускался при загрузке ОС, вводим:
sudo servicectl enable nginx.service
Другие способы
Открой файл /etc/sysctl.conf и помести в него следующие строки:
Поместив корневой каталог Web-сервера в выделенный раздел и запретив на нем размещение любых исполняемых файлов и файлов-устройств, ты обезопасишь остальную часть системы от тех, кто сможет получить доступ к корню Web-сервера. При этом запись в файле /etc/fstab должна иметь примерно такой вид:
Помести nginx в chroot/jail-окружение
Любая современная *nix-система позволяет запереть приложение в изолированной среде исполнения. В Linux для этого можно использовать технологии KVM, Xen, OpenVZ и VServer, во FreeBSD – Jail, в Solaris – Zones. Если ни одна из этих технологий не доступна, ты можешь поместить nginx в классический chroot, который хоть и намного более хрупок, но большинство взломщиков остановить сможет.
Установи правила SELinux для защиты nginx
Хорошей альтернативой изолированным средам исполнения являются локальные системы обнаружения и предотвращения вторжений, такие как SELinux или AppArmor. Будучи правильно настроенными, они смогут предотвратить попытки взлома Web-сервера. По дефолту ни одна из них не настроена для работы в связке с nginx, однако в рамках проекта SELinuxNginx (http://sf.net/projects/selinuxnginx/) были созданы правила для SELinux, которые может использовать любой желающий. Остается только скачать и установить:
Настрой брандмауэр
Обычно nginx устанавливают на выделенных машинах, готовых к высокой нагрузке, поэтому зачастую он остается единственным сетевым сервисом, работающим на сервере. Чтобы обезопасить сервер, достаточно создать совсем небольшой набор правил, которые будут открывать 80, 110 и 143-й порты (если, конечно, nginx должен работать еще и как IMAP/POP3-прокси) и закрывать от внешнего мира все остальное.
Ограничь количество соединений с помощью брандмауэра
Для не слишком нагруженного Web-сайта хорошей идеей будет ограничить количество попыток соединений с одного IP-адреса в минуту. Это сможет уберечь тебя от некоторых типов DoS-атак и брутфорса. В Linux это можно сделать с помощью стандартного iptables/netfilter-модуля state:
Правила урезают лимит на количество подключений с одного IP в минуту до 15. То же можно сделать и с помощью pf:
Кроме лимита на количество последовательных подключений (15 в минуту), данное правило устанавливает дополнительный лимит на количество одновременных подключений равный 100.
Настрой PHP
Если ты используешь nginx в связке с PHP, не забудь настроить и его. Вот как должен выглядеть конфигурационный файл /etc/php/php.ini защищенного сервера:
Что такое Nginx
Nginx (NGINX, Engine-X, «Энжин-кс») — это бесплатный веб- и почтовый прокси-сервер с непоточной (асинхронной) архитектурой и открытым кодом.
Разработку Nginx начал в 2002 году Игорь Сысоев для Rambler. А в 2004 году он стал доступен широкому кругу пользователей . С 2011 года серверное ПО начала выпускать уже собственная фирма Игоря, которая спустя 2 года запустила расширенную платную версию продукта (Nginx Plus). Весной 2019 года Nginx была выкуплена крупным американским девелопером F5 Networks.
Nginx работает на ОС Unix-типа и был успешно протестирован на OpenBSD, FreeBSD, Linux, Mac OS X, Solaris. На ОС Windows он стал доступен после выпуска бинарной сборки 0,7.52.
На данный момент функционалом пользуются такие известные платформы: Rambler, Begun, Yandex, SourceForge.net, WordPress.com, vkontakte.ru. Статистика показывает, что Nginx используют 22,3 млн веб-сайтов и 2,03 млн дополнительных активных сайтов.
Шаг 1. Установка или обновление NGINX
Для поддержки HTTP/2 веб-сервер NGINX должен быть версии 1.9.5 и старше. В данной версии появился модуль ngx_http_v2_module.
Обновление
Если в системе уже установлен nginx, проверяем его версию следующей командой:
nginx -v
Если она ниже необходимой, обновляем пакет:
yum update nginx
Установка
Для этого сначала создаем файл для настройки репозитория:
vi /etc/yum.repos.d/nginx.repo
И добавляем в него следующее:
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1
После обновляем список пакетов:
yum update
И теперь можно установить nginx:
yum install nginx
Подробнее пошаговый процесс установки NGINX на CentOS.
Сочетание базовой аутентификации и других ограничений
До сих пор мы видели простые примеры базовой аутентификации. Nginx поддерживает множество ограничений, и их можно комбинировать различными способами. В этом разделе мы рассмотрим интересный случай: объединение ограничений IP с базовой аутентификацией.
Скажем, у вас есть раздел на вашем сайте, предназначенный для использования сотрудниками компании. Любой сотрудник, обращающийся к веб-серверу из сети, может получить доступ к странице без использования пароля. Однако, если они пытаются получить к нему доступ через Интернет, им следует использовать пароль.
Это означает, что у нас должно быть два ограничения: ограничение IP и директива базовой аутентификации. Мы уже видели, как указать основные директивы аутентификации. IP-адреса могут быть разрешены или заблокированы с помощью директив и . Кроме того, вы можете указать nginx выполнить одно из этих условий, используя Таким образом, блок может выглядеть примерно так:
В приведенном выше примере любой пользователь с IP-адресом 10.2.0.0-10.2.255.255 и 10.3.155.26 допускается без пароля. Для других пользователей мы возвращаемся к базовой аутентификации.
Теперь рассмотрим другую ситуацию. Возможно, вы хотите, чтобы сотрудники имели доступ к этим файлам только из сети компании, используя пароль. Сотрудники не должны получать доступ к этим файлам вне сети компании. Это означает, что оба условия должны быть выполнены. Чтобы внести это изменение, измените на :
Как работает двухфакторная аутентификация
Двухфакторная аутентификация нужна для усиления защиты информации пользователя. С помощью неё можно защитить вход в аккаунт электронной почты, электронных кошельков, различных сервисов связанных с деньгами и их суррогатами.
Принцип работы двухфакторной аутентификации заключается в том, что требуется подтверждение личности пользователя двумя разными методами. Одним из этих методов обычно является пароль, который пользователь придумал сам. А второй элемент аутентификации должен быть получен по другому каналу, который пользователь привязал к своему аккаунту. Таким другим каналом может быть может быть одноразовый код из СМС сообщения, код-ответ из специального приложения (используется, например, в WebMoney), одноразовый пароль, выданный банкоматом (используется, например, в Сбербанк-онлайн) и другие варианты.
В целом двухфакторная аутентификация позволяет более надёжно защитить данные пользователя, поскольку для входа в аккаунт злоумышленнику уже недостаточно просто перехватить или подобрать пароль — также требуется код из другого источника, а коды в большинстве случаев являются одноразовыми. Поскольку вероятность взлома сразу двух устройств одного пользователя (например, компьютера для кражи пароля и мобильного телефона для кражи СМС с кодом) является очень низкой, то двухфакторная аутентификация является довольно надёжным методом защиты аккаунтов.
Установка
Пакет nginx доступен в прекомпилированном виде для любого дистрибутива. Однако собрав сервер самостоятельно, ты сможешь сделать его более компактным и надежным, а также получишь возможность изменить строку приветствия Web-сервера, чтобы отбить несмышленых скрипт-кидди.
Измени строку приветствия Web-сервера
Скачай исходники nginx, открой файл src/http/ngx_http_header_filter_module.c и найди следующие две строки:
Замени их на что-то вроде этого:
Удали все неиспользуемые тобой nginx-модули
Некоторая часть модулей nginx подключается к Web-серверу прямо во время компиляции, и любой из них таит в себе потенциальную опасность. Возможно, в будущем в одном из них будет найдена уязвимость, и твой сервер окажется под угрозой. Отключив ненужные модули, ты сможешь значительно снизить риск возникновения такой ситуации.
Выполни сборку с помощью следующих команд:
Так ты получишь nginx с заранее отключенными (и в большинстве случаев бесполезными) модулями SSI (Server Side Includes) и Autoindex. Чтобы узнать, какие модули можно безболезненно выбросить из Web-сервера, запусти скрипт configure с флагом ‘—help’.
Certbot и webroot
Мы будем получать сертификаты по методу webroot без перенастройки или остановки веб-сервера, под которым подразумевается nginx. Нам нужен какой-то каталог, в который будет писать свои файлы, и какой должен быть доступен из сети удостоверяющему серверу согласно протокола ACME.
Чтобы не писать каждый раз длинную строку из опций, а еще лучше — не вспоминать о них, запишем основные настройки в файл конфигурации, который ожидает найти в :
Последняя директива нужна чтобы избавить нас от прелестей и красивостей ncurses, что нужно чтобы вы могли сравнить вывод команд здесь, в этой статье, и у себя.
Также нам нужно мягко перезагрузить nginx (без перерыва в обслуживании) при успешном обновлении сертификатов. Ничего не мешает в этот же момент перезапускать и другие сервисы вроде Postfix, использующие полученные сертификаты. Команды указываются через точку с запятой.
Что будет делать Certbot
Ожидается что будет создавать необходимые для проверки прав на домен файлы в подкаталогах ниже по иерархии к указанному. Вроде таких:
Эти файлы должны будут быть доступны из сети на целевом домене по крайней мере по HTTP:
Для следующих проверок создадим какой-то такой файл:
Приемы оптимизации
«Легкий» контент
Виртуальный диск.
Создаем виртуальный диск (tmpfs или ramfs), папки js, css, images (если там небольшой обем картинок относящийся к дизайну а не контент) переносим туда и в конфиге nginx, отдельно прописываем Для того, чтоб виртуальный диск создавался автоматически при перезагрузке в /etc/fstab добавляем(при старте системы автоматически будет создаваться диск, размером 1G)
Тут следует обратить внимание на следующее обстоятельство: если статический файл попадает в системный кеш, то скорость его отдачи с системного кеша равняется скорости отдачи с виртуального диска. Другими словами если общее количество всей раздаваемой «легкой» статики небольшое, то надобность в виртуальном диске отпадает (Спасибо maxp за то что побудил меня провести тесты и убедится в этом)
Сжатие контента gzip-ом
Запускаем в нашей виртуальной папке в конфиг nginx добавляем строчку gzip_static on:Также можно включить online упаковку для динамических файлов:
Заголовки для проксирования контента
Указание в заголовках времени жизни статического контента также приведет к уменьшению нагрузки
Для этого будем использовать директиву expires. Если контент не будет меняться, со вренем можно использовать expires max. Даже expires 1d даст хороший результат
Кеширование дескрипторов файлов
Это даст прирост производительности, если у вас множество мелких файлов с развернутой иерархией директорий. Также можно закешировать обращение к несуществующим файлам. Выглядеть это будет приблизительно так:
SSL/TLS
Внедрение SSL-сертификата
Первым шагом в веб-безопасности является внедрение SSL, чтобы вы могли получить доступ к веб-приложениям по протоколу https и добавить уровень шифрования при общении.
Используйте OpenSSL для генерации CSR с 2048 битами и sha-2
Приведенная выше команда сгенерирует файлы CSR и файлы ключей при текущей работе напрямую. Не забудьте изменить имя файла .csr и .key.
Получите CSR, подписанный центром сертификации, и, получив сертификат, вы можете реализовать его в Nginx, как показано ниже.
- Вход на сервер Nginx
- Перейдите в папку conf, где у вас есть файл ssl.conf.
Примечание. При установке по умолчанию в Linux этот файл будет находиться в /etc/nginx/conf.d.
Отредактируйте файл и добавьте следующее, что позволит Nginx прослушивать порт 443
Примечание: не забудьте изменить путь к сертификату и файлу ключа.
Сохраните конфигурацию и перезапустите Nginx. Сертификат SSL успешно внедрен.
Отключите SSL 3 и оставьте только TLS
SSL 3 уязвим, и мы допустим только надежный протокол TLS.
Отредактируйте файл ssl.conf и добавьте ниже в блоке сервера
Сохраните файл ssl.conf и перезапустите Nginx
Отключить слабые комплекты шифрования
Слабые комплекты шифров могут привести к уязвимости, например, к перебою и поэтому нам нужно разрешить только надежный шифр.
Добавьте следующее в блок сервера в файле ssl.conf
Сохраните файл и перезапустите Nginx
Установить цепной сертификат (Chain Certificate)
Отсутствие цепного сертификата также влияет на общий рейтинг, и это может привести к ошибке при просмотре в современном браузере, таком как Chrome. Вам необходимо получить цепной сертификат.
Добавьте содержимое сертификата цепочки в сертификат сайта, как показано ниже. В моем примере это будет /opt/cert/bestflare.pem
Сохраните файл и перезапустите Nginx
Типы статического контента
| «Легкий» контент: html, css, js, xml, rss, txt. Он хорошо поддается сжатию, требует мало места для хранения. Приминение nginx в любом случае даст заметный прирост производительности. | |
| «Тяжелый» контент: фото, видео, аудио-файлы. Узким местом выступает, в первую очередь дисковая система, размер оперативной памяти, пропускная способность канала. Задача раздачи такого типа контента делится на 2 — хранение контента и, собственно, раздача контента. С помощью nginx можно добиться минимального расхода памяти и процессорного времени, но при увеличении нагрузки все же прийдется собирать RAID-масив. |
Загрузка необходимых файлов на веб-сервер
Услуги 1cloud
Лучшие цены на SSL-сертификаты (от 550 руб.)
- Все доверенные центры сертификации
- Большой выбор сертификатов
- Пошаговые инструкции по выпуску и установке
Сначала следует загрузить файлы .ca и .crt на веб-сервер из панели 1cloud. Если ваш сервер не имеет графического окружения рабочего стола, вы можете загрузить эти файлы на другой компьютер, а затем перенести их одним из описанных ниже способов.
Примечание: данный пример подразумевает, что необходимая для работы пара закрытый/открытый ключ была сгенерирована на том же веб-сервере, на который вы будете переносить приобретенный сертификат. Если вы создавали ключи на другой машине, вам необходимо также перенести файл закрытого ключа .key на ваш веб-сервер по аналогии с описанной ниже процедурой копирования файлов сертификатов.
Перенос сертификатов с компьютера Linux/Mac OS:
Самый простой способ загрузки сертификатов на сервер — опция SCP, встроенная в возможность терминала вашего компьютера:
- Скачайте файлы .CA и .CRT из панели управления 1cloud на локальный компьютер.
- Откройте терминал и перейдите в папку, в которую вы сохранили сертификаты (напр., Downloads):
Скопируйте сертификаты вашего сайта и Центра Сертификации на веб-сервер:Где:scp — команда копирования файловmydomain.ru_crt.crt — имя загруженного из панели файла сертификата вашего веб-сайтаmydomain.ru_ca.crt — имя загруженного из панели файла сертификата Центра Авторизацииuser — имя вашего пользователя для подключения к серверу через ssh (часто используется root)111.125.212.121 — IP-адрес вашего веб-сервера/etc/ssl — директория на удаленном сервере, в которую в хотите сохранить загружаемые файлы.
Перенос сертификатов с компьютера Windows:
- Установите программу WinSCP. Скачать ее можно здесь.
- Запустите WinSCP. В открывшемся окне введите данные, которые вы используете для подключени я к вашему серверу по SSH.
В левой части окна программы отображаются файлы на локальном компьютере, в правой — на подключенном удаленном сервере. Выберите или создайте директорию, в которую вы хотите сохранить сертификаты, в правой части окна. Перетащите файлы .CA и .CRT в эту директорию из левой части окна.
Примечение: для удобства вы можете перенести файл закрытого ключа (.key) в ту же директорию, в которую вы скопировали файлы сертификатов. Вы можете не делать этого, но таком случае запомните путь до этого файла и в дальнейшем укажите его в файле конфигурации Apache вместо пути, приведеленного в нашем примере.
Если закрытый ключ .key был сгенерирован непосредственно на сервере, то для его копирования в другую директорию вы можете использовать команду:Где:cp — команда копирования/home/root/ — путь до файла ключаprivate.key — имя файла ключа/etc/ssl/private.key — путь, по которому необходимо скопировать файл ключа
Удалить файл ключа из старого расположения вы можете с помощью команды:(синтаксис команды аналогичен предыдущему примеру)
Установка и использование сертификатов
Certbot не перезаписывает сертификаты, а заменяет их ссылками на самые актуальные варианты сертификатов в определенном каталоге, одноименном с первым доменом сертификата (т.е. ).
Давайте посмотрим что за файлы у нас есть:
С этим знанием мы можем задать настройки SSL для nginx:
Как видите, нигде в конфиге не используется, и это не ошибка. Для nginx он не нужен.
Полный рабочий пример конфига:
Конфиг для переадресации с голого домена без www:
Подразумевается что вы используете какой-то локальный сервер для кеширования DNS запросов. Если это не так, то в директиве нужно заменить на IP используемого DNS сервера.
Настройки шифров и прочее подобное (, ) лучше держать вне конфигов отдельных серверов.
Perfect Forward Secrecy
Если вы переживаете что Certbot может утащить ключи от вашего сертификата не смотря на открытые исходные коды, а значит, в теории, какие-то злодеи смогут расшифровать весь трафик, то спешу вас успокоить. Если для соединения с вашим сайтом используются шифры из семейств DHE и ECDHE, то утечка ключа не позволит расшифровать трафик. В этих шифрах ключ сертификата используется только для подтверждения подлинности, и не используется в качестве ключа для шифрования. Все современные браузеры поддерживают эти шифры.
Если для ECDHE на эллиптических кривых ничего не нужно делать, то для DHE нужно использовать усиленные параметры. Сначала создадим их:
Потом пропишем в одной строкой:
Заключение
Nginx представляет собой практически готовое решение для множества задач, требующих развёртывания полноценного веб-сервера или прокси. По ряду параметров Nginx превосходит своего «старшего коллегу» Apache. Главные из них — отсутствие требовательности к ресурсам и способность обрабатывать большое число соединений одновременно.
Понимание работы и принципа обработки запросов в Nginx позволяет грамотно масштабировать и балансировать нагрузку на современных сайтах, располагающих контентом разных категорий. А связка Nginx и Apache позволяет максимально расширить эффективность применения веб-сервера.
Оцените материал:
