Правильное использование .htpasswd

Ответ 1

Какой уровень безопасности обеспечивает это?

.htpasswd не обеспечивает большую безопасность сам по себе. То есть он предоставляет механизм входа в систему, и Apache не будет отвечать без надлежащих учетных данных, но если отдельно не настроено, ничего об обмене не зашифровывается (или даже запутывается). Например, прослушивание запроса GET с Wireshark дает прекрасный обзор всех отправляемых клиентом заголовков, в том числе:

Authorization: Basic d3BhbG1lcjp0ZXN0dGVzdA==

"d3BhbG1lcjp0ZXN0dGVzdA==" - это только кодированная base64 форма "wpalmer:testtest". В наши дни хакер (или, скорее всего, вирус) может сидеть на открытом Wi-Fi-соединении и записывать любые запросы, содержащие Authorization: для более позднего прочтения. В общем, отправка любой информации об аутентификации по незашифрованному HTTP-соединению считается плохой идеей, даже если вы находитесь за провод или безопасный WiFi от конца до конца. Например, это не соответствует требованиям PCI Compliance, если вы храните данные клиента, информацию о платеже и т.д. За блокировкой .htpasswd.

Добавьте https в микс, и вы полностью устраните эту конкретную проблему, однако...

.htpasswd аутентификация, реализованная Apache httpd, не обеспечивает никакой защиты от ограничения скорости или грубой силы. Вы можете сделать так много одновременных попыток угадывать пароль, поскольку Apache готов обслуживать одновременные страницы, и Apache будет реагировать с успехом/сбоем, как только это возможно. Вы можете использовать что-то вроде Fail2Ban, чтобы ограничить количество неудачных попыток, которые могут быть сделаны до того, как клиент заблокирован от разговора с сервером, но это не обязательно обеспечит какую-либо полезную защиту от бот-сети, которая может автоматически настроить ваш сервер на тысячи уникальных адресов. Это может привести к принятию решения "не оставлять ли я себя уязвимым для попыток паролей из бот-сетей или не оставлять себя уязвимым для атак типа" отказ в обслуживании ", когда вся учетная запись заблокирована из-за сбоев от нескольких клиентов?"

Эти углы атаки могут быть ограничены добавлением ограничений на IP-адрес к вашему файлу .htaccess, разрешающим соединения только с определенных адресов. В зависимости от того, как вы работаете, это может быть неудобно, но это также серьезно ограничивает типы угроз, к которым вы были бы уязвимы. Вы по-прежнему рискуете от кого-то, специально нацеленного на ваш сайт, или заражения на части самой сетевой инфраструктуры. В зависимости от типа контента, который вы защищаете, это может быть "достаточно хорошим" . Примером такого типа ограничений является:

Order deny,allow
Deny from all
Allow from 127.0.0.1

Это означает, что, короче говоря, "разрешать соединения только с локального хоста". Построчно, это означает:

• Order deny,allow определяет порядок обработки правил с последним совпадением.
• Deny from all начинаем с предположения, что всем клиентам отказано
• Allow from 127.0.0.1, если клиент имеет IP 127.0.0.1, тогда он разрешен

В какой-то степени ограничения на основе IP также защитят вас до того момента, когда HTTPS можно считать необязательным. Атакующие/вирусы все еще могут видеть ваши учетные данные, но им сложнее использовать эти учетные данные на самой странице. Опять же, это не будет соответствовать требованиям PCI, и оно не подходит для "важной" информации, но есть некоторые ситуации, для которых это можно считать "достаточно хорошим" . Имейте в виду, что многие люди повторно используют учетные данные на нескольких сайтах, поэтому отказ защитить данные для входа в систему обычно считается очень опасным для пользователя, даже если сам сайт защищен.

Наконец, файл .htaccess сам по себе является частью ответственности. См. Ответ на вопрос: "нужно ли им находиться за пределами общедоступного каталога?" для более подробной информации об этом.

Можно ли легко обходить его?

Нет. Нет никаких оснований ожидать, что сервер при правильной настройке никогда не будет требовать регистрационных данных для доступа к защищенному контенту. Хотя аутентификация HTTP Basic имеет свои недостатки, Apache httpd является очень надежным и является одним из наиболее тщательно протестированных компонентов программного обеспечения в мире. Если вы сообщите Apache, что для доступа к определенному контенту требуется обычная проверка подлинности HTTP, потребуется.

Если Apache по умолчанию не позволяет пользователям напрямую обращаться к одному из двух файлов, нужно ли им находиться за пределами общего каталога?

Есть несколько моментов. Во-первых, Apache делает непо умолчанию для предотвращения доступа к любому из этих файлов. Многие дистрибутивы Apache httpd включают начальную конфигурацию, которая запрещает доступ (используя правила "Запретить все" ) в зависимости от дистрибутива, .htaccess/.htpasswd файлов, .ht* файлов или .* файлов. Это очень распространено, но есть много причин, почему это может быть не так. Вы можете добавить правило самостоятельно, чтобы заблокировать эти файлы, если они еще не заблокированы:

<FilesMatch "^.(htaccess|htpasswd)$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

Во-вторых, следует указать, что файлы .htaccess работают, они обрабатываются, когда каталог, в котором они находятся, сопоставляется. То есть: .htpasswd может быть в другом месте, но .htaccess должен находиться в одном каталоге. Тем не менее, см. Раздел "Последствия скорости" для более подробной информации.

Итак, поскольку их можно так легко заблокировать, зачем хранить .htpasswd вне общедоступного каталога? Потому что ошибки происходят, а файл .htpasswd - большая ответственность. Даже если вы используете HTTPS, экспозиция вашего файла .htpasswd означает, что ваши пароли можно легко взломать с помощью грубой силы. В наши дни графические процессоры потребительского класса могут делать миллионы догадок пароля в секунду. Это может привести к тому, что даже "сильные" пароли упадут сравнительно малое время. Опять же, этот аргумент, как правило, применим только к целевой атаке, но факт остается фактом: если злоумышленник имеет ваш файл .htpasswd и хочет получить доступ к вашей системе, в наши дни они могут сделать это легко. См. Speed ​​Hashing в кодировании Horror для относительно недавнего (апрель 2012 г.) обзора состояния вещей.

Учитывая это, возможность случайно (временно) подвергнуть ваш файл .htaccess стоит переместить его где-то, на что никогда не стоит даже смотреть, когда httpd ищет контент для обслуживания. Да, есть еще изменения конфигурации, которые могли бы выставить его, если он "на один уровень вверх", а не "в общедоступном каталоге", но эти изменения гораздо менее вероятны. Случайно.

Есть ли какие-либо последствия скорости?

Некоторые.

Во-первых, использование файлов .htaccess несколько замедляет работу. Более конкретно, директива AllowOverride all вызывает много потенциального замедления. Это заставляет Apache искать файлы .htaccess в каждом каталоге и каждый родительский каталог, к которому осуществляется доступ (вплоть до DocumentRoot). Это означает запрос файловой системы файла (или обновления к файлу) для каждого запроса. По сравнению с альтернативой потенциально никогда не ударяя файловую систему, это совсем не так.

Итак, почему существует .htaccess вообще? Есть много причин, которые могут сделать его "достойным":

• В зависимости от нагрузки на сервер вы никогда не заметите разницы. Ваш сервер действительно должен сжимать каждую последнюю миллисекунду из каждого запроса? Если нет, то не беспокойтесь об этом. Как всегда, не беспокойтесь о оценках и прогнозах. Профилируйте свои ситуации в реальном мире и посмотрите, не изменилось ли это.
• .htaccess можно изменить без перезапуска сервера. Фактически, это то, что делает его настолько медленным - Apache проверяет изменения или наличие файла .htaccess для каждого запроса, поэтому изменения применяются немедленно.
• Ошибка в .htaccess приведет к удалению каталога, а не сервера. Это делает его гораздо менее ответственным, чем изменение файла httpd.conf.
• .htaccess может быть изменен, даже если у вас есть только доступ на запись к одному каталогу. Это делает его идеальным для среды совместного размещения. Нет необходимости иметь доступ к httpd.conf вообще или доступ к перезапуску сервера.
• .htaccess может сохранять правила доступа к файлам, которые они должны выполнять. Это может сделать их намного легче найти и просто держать вещи более организованными.

Не хотите использовать .htaccess, даже учитывая все вышеперечисленное? Любое правило, которое применяется к .htaccess, может быть добавлено непосредственно к httpd.conf или к включенному файлу.

Как насчет .htpasswd? Это зависит от того, сколько у вас пользователей. Он основан на файлах и минимальный с точки зрения реализации. Из Документы для httpd 2.2:

Из-за того, как указана базовая проверка подлинности, имя пользователя и пароль должны быть проверены каждый раз, когда вы запрашиваете документ с сервера. Это даже если вы перезагружаете тот же страницы и для каждого изображения на странице (если они получены из защищенного каталог). Как вы можете себе представить, это немного замедляет работу. количество, которое оно замедляет, пропорционально размеру файл паролей, поскольку он должен открыть этот файл и спуститься вниз список пользователей, пока он не получит ваше имя. И он должен делать это каждый время загрузки страницы.

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

Короче говоря, .htpasswd работает медленно. Если у вас есть только несколько пользователей, которым необходимо пройти аутентификацию, вы никогда не заметите, но это еще одно соображение.

Резюме

Защита раздела администратора с помощью .htpasswd не идеальна для всех ситуаций. Учитывая его простоту, это может стоить рисков и проблем, когда безопасность и производительность не являются самыми высокими приоритетами. Для многих ситуаций, с небольшой настройкой, это можно считать "достаточно хорошим" . То, что составляет "достаточно хорошо", - это призыв к суждению, который вы можете сделать.