Примерно в 2000-2010 годах виртуальный хостинг был чрезвычайно популярен как дешевое решение (иногда за несколько долларов в месяц, а иногда даже бесплатно всего за несколько МБ) для людей, начинающих вести блоги, небольшие веб-сайты, например. с помощью Wordpress.
Обычно было:
Вопрос: как до того, как контейнеризация / Docker стали популярными, как основные провайдеры виртуального хостинга обеспечивали изоляцию пользователей?
Они просто использовали ChrootDirectory в sshd_config + разные пользователи, как в Как создать изолированного / заключенного в тюрьму пользователя SFTP? + <VirtualHost> config с open_basedir чтобы предотвратить доступ PHP-кода к файлам других учетных записей?
В целом, каковы были основные методы изоляции, предотвращающие user1234 получить доступ user5678файлы на одном сервере с вредоносным кодом PHP?
Короткий ответ, они боролись!
Иногда немного истории эволюции - хороший способ понять, откуда мы пришли и где мы находимся прямо сейчас ...
Простой веб-сервер должен был привязаться к IP-адресу.
Таким образом, это действительно означало, что если вы ограничили себя одним портом (80), у вас может быть только один реальный домен на каждый IP-адрес (машину). Однако вы можете указать каталог, в котором находится контент, возможно, пользовательский $ HOME dir.
Доступ к файлам обеспечивался просто разрешениями учетных записей пользователей.
Ваш уникальный идентификатор пользователя (UUID) будет считаться достаточным для разделения учетных записей.
Поскольку архитектура веб-сервера на самом деле не использует традиционный способ предоставления привилегий и разрешений учетной записи пользователя, веб-сервер обычно работал как root (в худших случаях) или как пользователь с ограниченными правами в лучших случаях. (www-data / никто).
Лучшее в веб-сервере заключалось в том, что он мог передавать файлы, которые вы хотели, по сети для отображения в браузере, хуже всего в веб-сервере то, что он мог передавать файлы, которые вам, вероятно, тоже не нужны. (/ etc / passwd).
https://cwiki.apache.org/confluence/display/httpd/PrivilegeSeparation.
Затем появилась директива виртуального хоста apache. Это позволило веб-серверу определить, какой домен нужен клиентскому веб-браузеру.
Изобретение Vhosts, чтобы веб-сервер мог обслуживать файлы в зависимости от имени заголовка хоста, а не IP-адреса сервера.
https://httpd.apache.org/docs/current/vhosts/examples.html
Службы передачи файлов, такие как FTP / SSH, были связаны через ваше имя пользователя с областью, в которой у вас было разрешение, и вы тоже могли писать ... (у этих систем также были свои проблемы с безопасностью).
В то же время прижился PHP, и спрос клиентов на возможность писать активные скрипты резко вырос. Они хотели иметь возможность работать на веб-сервере динамически и хотели этого СЕЙЧАС !.
Итак, это был вопрос защиты системы unix, где все эффективно работает с одним и тем же UUID ... видите ли вы, что проблема начинает возникать?
Это начало гонку вооружений в области безопасности веб-серверов !!!
Атака была обнаружена, а затем был развернут патч или способ борьбы с ней ... что обычно означало больше кода в производстве ... или ограничение того, что веб-сервер мог делать с точки зрения конфигурации.
Иногда это было бы ошибкой в реальном коде, иногда конфигурация позволяла бы использовать уязвимость. В худшем случае ваши пользователи не могли получить доступ к какой-то функции, на которую они полагались !!
Следуйте символическим ссылкам на apache, почему это угроза безопасности
Итак, хосты развернули исправление за исправлением, исправление за исправлением. Как и все меры безопасности, вы начинаете ограничивать конфигурацией или исправлять код, чтобы «делать правильные вещи» с точки зрения безопасности, вы начинаете нарушать совместимость и начинаете придумывать проблемы интеграции.
Добавьте больше технологий гонки вооружений, таких как SELINX, хотя вы можете создать безопасный веб-сервер, вы сломаете так много программного обеспечения, что оно станет бесполезным ... оно либо работает, либо становится так сложно управлять, что становится неуправляемым. Теперь умножьте это на X пользователей на одной машине ... Каждый добавленный уровень безопасности может нарушить существующие сценарии PHP или сделать их отладку чрезвычайно сложной.
Вы можете добраться до точки, в которой вы будете в полной безопасности, но на самом деле ничего не будет работать ..... ;-).
Разрешение клиентам загружать свои собственные сценарии на машину или уязвимость, при которой атаки могут быть такими же, могут привести к включению этого сервера, позволить злоумышленнику получить контроль не только над этой учетной записью, повысив их до привилегий root на этой машине. .
Проблемы возникают даже с ошибками локального повышения привилегий, потому что, когда вы запускаете активный язык сценариев, такой как PHP, вы фактически локальны на машине.
Плохая новость в том, что все это по-прежнему с нами.
Хорошие новости: Docker и другие технологии контейнеров / виртуальных машин только решают проблему. Однако вы можете использовать гораздо более простую конфигурацию, используя меньше кода в контейнере, чтобы сделать то же самое.
Кроме того, конфигурации могут быть намного проще, и ими можно эффективно управлять.
Вероятно, вы понимаете, почему сейчас происходит отказ от больших веб-серверов «кухонной раковины» и тысяч учетных записей на одной машине.
На общих хостингах у вас обычно был и сейчас есть только FTP доступ. У вас никогда не было и до сих пор нет доступа SSH к фактическому файловому серверу.
В База данных если вы приобрели, он назначен вам на другом сервере базы данных, который не гарантируется даже на том же физическом хосте.
Если вы приобрели Адрес электронной почты также не было гарантировано, что он будет расположен на каком-либо конкретном физическом хосте.
Провайдер хостинга сегодня и, как всегда, управляет перенаправлением трафика для клиентов хостинга.
В большинстве случаев вам необходимо приобрести Домен вместе с вашим файловым хостингом.
На Панель управления вы настроили корневой каталог и поддомены для своего хостинга.
Если ваши файлы находятся на физическом хосте, хостинг-провайдер никогда не сообщал вам, каким будет каноническое имя этого хоста, если таковое будет.
До сих пор это работает так.
Контейнеризация была прозрачно введена для клиентов хостинга на стороне сервера.
Все еще классические веб-приложения, такие как "WordPress"строить на этой Архитектуре.
Они требуют только, чтобы вы предоставили Учетная запись FTP и Учетная запись базы данных.
Контейнеризация в основном это приносит пользу только хостинг-провайдеру, потому что таким образом он может быстро и прозрачно для Клиента перемещать Контент Клиента туда, где он считает нужным.
Я нашел все это методы усиления безопасности всегда действительны даже в контейнерном Интернете.
На Сторона сервера есть также некоторые конфигурации усиления безопасности на системном уровне, который должен принадлежать любой настройке сервера.
Первая линия защиты от атак из Интернета - это
httpd.conf Файл конфигурации:<Directory "/var/www/html">
AllowOverride None
#Disabling it by commenting
#Options Indexes
</Directory>
<Directory "/var/www/cgi-bin">
AllowOverride None
Options None
# "denied" will restrict any call to it from the internet
Require all denied
</Directory>
# Disable Aliases you don't use
<IfModule alias_module>
# ScriptAlias: This controls which directories contain server scripts.
#Disabling it by commenting
#ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
</IfModule>
disable_functions Вариант вроде:; This directive allows you to disable certain functions for security reasons.
; It receives a comma-delimited list of function names. This directive is
; *NOT* affected by whether Safe Mode is turned On or Off.
; http://php.net/disable-functions
disable_functions = escapeshellarg,escapeshellcmd,exec,passthru,proc_close,proc_get_status,proc_nice,proc_open,proc_terminate,shell_exec,system
Лучше всего избегать любых Cron Работа на системном уровне.
Если вы не можете полностью их избежать, они должны работать на уровне пользователя в качестве пользователя FTP с sudo ftp_user или в своем собственном crontab с участием crontab -u ftp_user:
# pwd
/var/spool/cron
# ls -alh
insgesamt 12K
drwx------. 2 root root 29 feb 12 18:59 .
drwxr-xr-x. 15 root root 4,0K may 3 2019 ..
-rw-------. 1 ftp_user ftp_user 698 feb 5 10:17 ftp_user
На Веб приложение Уровень также существует риск безопасности, который слишком часто недооценивается веб-разработчиками.
-- ftp_user
|-- public_html
|-- index.php
|-- cache
|-- cache_file.txt
Это входит в обязанности веб-разработчика, поскольку вы можете изменить и создать его из своей учетной записи FTP.
Часто WordPress Разработчики плагинов побуждают вас отдавать Доступ для записи к их плагину в wp-content Справочник. Но это действительно плохая практика и плохой стиль.
cache_file.php:<?php
$cache_content = "my cache data";
?>
Если cache_file.php поскольку файл кэша доступен для записи, злоумышленник может заменить содержимое на Вредоносный код которое ваше приложение загружает прямо в память и выполняет его.
Составлено Веточка Шаблоны являются PHP код, который «на лету» генерирует Приложение. Oни не должен проживать в вашем public_html Справочник.