Защита административного раздела моего сайта

Question

У меня есть сайт объявлений ...

Как вы можете себе представить, как веб-мастеру (администратору) мне иногда нужно удалять объявления, редактировать их и т. Д. И т. Д.

У меня есть свойСервер Linux, с доступом к руту.

В настоящее время у меня есть раздел моего веб-сайта со всеми административными сценариями php, которые я использую для удаления объявлений, их редактирования и т. Д .:

    /www/adm/ //Location of administrative tools

Этот раздел вышесегодня защищен простой аутентификацией с использованием файла apache2.conf:

<Directory /var/www/adm>
    AuthType Basic
    AuthName "Adm"
    AuthUserFile /path/to/password
    Require user username
</Directory>

Мой вопрос: достаточно ли этого, чтобы запретить доступ посторонних к моим административным инструментам?

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

Что обычно делается в подобных случаях?

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

Другая информация, которая может помочь вам решить, какое решение мне следует использовать:

• Я управляю веб-сайтом и сервером только с одного и того же компьютера
• IP-адрес этого компьютера динамический
• Я использую безопасные передачи файлов ftp на сервер
• Административными инструментами являются PHP-коды, которые обмениваются данными с базами данных
• У меня есть настройка брандмауэра IPTables, позволяющая подключаться к базе данных только с моего собственного сервера / веб-сайта.
• Я резервирую все файлы каждыйдень

Спасибо

Answer 1

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

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

Чтобы включить SSL, вам необходимо:

1. mod_ssl на вашем apache
2. самозаверяющий (бесплатный) сертификат
3. Измените конфигурацию apache, включив в нее порт SSL

В этом руководстве вы можете узнать, как включить SSLв Debian .

Answer 2

Лучшим вариантом, помимо обычной защиты паролем, ограничений IP, SSL и т. Д., Является размещение инструментов в полностью отдельном домене. Кто-то может догадаться, что у вас есть example.com/admin, и вы пытаетесь перебить его, но размещение простой страницы входа в систему на somecompletelydifferentdomain.com без клейм / маркировки, чтобы связать ее с example.com - еще лучшая защита.

Answer 3

Если вам нужен прямой удаленный доступ к инструментам администрирования, найдите внеполосный способ, чтобы веб-сервер вообще не запускал их, когда они не нужны. Вы можете, например, сделать chmod 000 /var/www/adm при нормальных обстоятельствах, изменить его на что-то пригодное для использования (скажем, 500), когда вам нужно его использовать, и вернуться к 000, когда вы закончите.

Лучше было бы обеспечить весь путь между вами и инструментами администрирования:

• Используйте стук портов для включения SSH на каком-либо порту, отличном от 22 (например, 2222).
• Заблокируйте sshd на этом порту в соответствии с вашими требованиями.
• Запустите отдельный экземпляр вашего веб-сервера, который прослушивает порт, отличный от 80 (например, 8080), который не виден снаружи и имеет конфигурацию, разрешающую доступ к /var/www/adm, но ограничивающую доступ к локальному хосту. только.

Когда приходит время использовать административные инструменты:

• Стук, чтобы открыть порт SSH.
• SSH на порт 2222 и установите туннель от 8080 на удаленном хосте до порта 8080 на сервере.
• Используйте удаленный браузер, чтобы посетить localhost: 8080 и получить доступ к своим инструментам. Сервер увидит, что соединение идет из локальной системы.

Answer 4

Проверка подлинности Apache также может быть ограничена по IP-адресу, поэтому, если у вас статический IP-адрес, его использование и пароль должны быть достаточно безопасными. Я бы также использовал AuthDigestFile вместо AuthUserFile, если вы беспокоитесь о атаках.

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