- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Зачем быть уникальным в мире, где все можно скопировать
Почему так важна уникальность текста и как она влияет на SEO
Ingate Organic
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
На очень многих (виртуальных) хостингах есть проблема в безопасности, позволяющая пользователям читать файлы друг у друга.
Это можно сделать многими путями, через php скрипты, CGI, cron, shell...
если немного разбираться в функционировании сервера.
А если все файлы можно прочитать, то можно получить доступ к БД, к файлам с паролями ...
Проблема заключается в том, что все хостеры и их специалисты сис. админы, даже не подозревают о такой проблеме.
Все полностью уверены, что их сервер безопасен на все 100%.
Так же проблема заключается в том, что решения (подходящего для хостинга) эта проблема не имеет.
Предлагаю поделится опытом о решении этой проблемы.
Не хотелось бы, чтобы в этой теме спрашивали как использовать эту проблему или как это вобще возможно.
Я, честно говоря, вообще такой проблемы не вижу - как отдельной, по крайней мере.
Один юзер может прочесть файлы другого в двух случаях:
1. Неправильно выставлены пермишены, т.е. все могут читать у всех. Лечится правильными пермишенами.
2. На сервере не закрыты дыры, через которые юзер может получить большие привилегии. Лечится своевременной установкой патчей, правильной политикой безопасности. В частности, веб-сервер не должен работать от рута, перл тоже лучше запускать не от рута, вообще всем веб-скриптам нечего делать за пределами /usr/local/www и так далее.
Что тут обсуждать отдельно-то? По-моему, я совершенно не открыл никаких секретов, правда? Или вы про что-то другое?
Я как раз про это, многие думают что у них выставлены правильные права и всё безопасно.
Когда на самом деле, выставление "правильных" прав поможет только cgi скриптам с suexec, другие же скрипты (mod_perl, mod_php) не будут работать при таких правах.
Им нужно быть читабельным для apache, а значит и для всех.
Я как раз про это, многие думают что у них выставлены правильные права и всё безопасно.
Когда на самом деле, выставление "правильных" прав поможет только cgi скриптам с suexec, другие же скрипты (mod_perl, mod_php) не будут работать при таких правах.
Им нужно быть читабельным для apache, а значит и для всех.
/ru/forum/94609
kostich, расскажите людям про какое-нибудь решение, которое будет работать для большинства дистрибутивов right from the box, не требуя установки патча на ядро, патча на апач, запуска отдельного апача на каждый виртуальный хост или vserver.
Я, честно говоря, вообще такой проблемы не вижу
тот же Apache+mod_php в большинстве случаев даст мне возможность прочитать файлы с другого виртуального хоста на той же машине, если я знаю структуру файловой системы на этом тазике. Стоит мне только выцепить хотя бы один файлик из чужой директории, предназначенный для выполнения вебсервером, а там я уже по инклудам все структуру воссоздам. Парсер недолго пишется на самом деле, да и воссоздавать долго не надо, самое главное дойти до конфига, где доступ к БД прописан.
Я, честно говоря, вообще такой проблемы не вижу - как отдельной, по крайней мере.
Один юзер может прочесть файлы другого в двух случаях:
1. Неправильно выставлены пермишены, т.е. все могут читать у всех. Лечится правильными пермишенами.
2. На сервере не закрыты дыры, через которые юзер может получить большие привилегии. Лечится своевременной установкой патчей, правильной политикой безопасности. В частности, веб-сервер не должен работать от рута, перл тоже лучше запускать не от рута, вообще всем веб-скриптам нечего делать за пределами /usr/local/www и так далее.
Что тут обсуждать отдельно-то? По-моему, я совершенно не открыл никаких секретов, правда? Или вы про что-то другое?
Тут Вы не правы.
Если на сервере работает apache (пусть из-под nobody), то закачав простой phpshell можно получить доступ (с правами apache) к папкам других пользователей, прочитать файлы с паролями и получить доступ к базе. Можно ставить php в safe_mode, но это считается дурным тоном многими разработчиками (например, очень известный проект http://gallery.menalto.com/ принципиально не рекомендует работать в safe_mode).
Поскольку не php единым, то взлом с правами web-сервера можно осуществить через cgi-bin (лечится установкой suexec, но по умолчанию этого тоже нет).
Имхо правильный выход иметь свой апач для каждого пользователя. Но тут появляются свои проблемы: если апач запущен от имени пользователя, то он может менять права любых файлов этого пользователя, что может понизить безопасность скриптов.
Например, через "маленькую" дыру можно будет сделать большую, удалив где-нить файл .htaccess (в обычном режиме этого сделать нельзя при правильных правах).
Cамый безопасный вариант - делать chroot каждому аккаунту, но это уже фактически VPS, и довольно накладно по ресурсам (в основном HDD).
Пока из идей:
для каждого аккаунта делать двух пользователей: один для файлов, второй для web-сервера, соответственно апачи придётся развесить на разные ip-адреса, но чтобы не делать кучу реальников, можно сделать виртуальных интерфейсов, например, 172.16/16, а на front-end посадить отдельный web-сервер, например, nginx.
Кстати как раз планирую в ближайшем будушем реализовать такую схему на нашем новом сервере.
Работающий вариант по такой или похожей схеме видел на хостинге от Хайвей.
Cамый безопасный вариант - делать chroot каждому аккаунту, но это уже фактически VPS, и довольно накладно по ресурсам (в основном HDD).
В фре есть mount_nullfs, есть nfs. Совсем не обязательно создавать всё дерево для каждого chroot, достаточно подмонтировать корень на ридонли, а внутри уже
размещать только файлы хоста.
Пока из идей:
для каждого аккаунта делать двух пользователей: один для файлов, второй для web-сервера, соответственно апачи придётся развесить на разные ip-адреса, но чтобы не делать кучу реальников, можно сделать виртуальных интерфейсов, например, 172.16/16, а на front-end посадить отдельный web-сервер, например, nginx.
Как это поможет в случае с mod_php?
Если только каждому клиенту пускать по apache. Но тогда и 2-х юзеров не надо,
можно обходиться одним.
Пока из идей:
для каждого аккаунта делать двух пользователей: один для файлов, второй для web-сервера, соответственно апачи придётся развесить на разные ip-адреса, но чтобы не делать кучу реальников, можно сделать виртуальных интерфейсов, например, 172.16/16, а на front-end посадить отдельный web-сервер, например, nginx.
Схема по безопасности - хорошая (2 юзера на реальный аккаунт) .. есть только один минус - фактически будет запущено много апачей (по одному на аккаунт), которые будут потреблять ресурсы :( ... а реально могут и не работать ... но все-таки лучше так
соответственно апачи придётся развесить на разные ip-адреса
дык, это и получается, что на каждый виртуальный хост свой апач. или я чего-то недопонял 😕
Схема по безопасности - хорошая (2 юзера на реальный аккаунт) .. есть только один минус - фактически будет запущено много апачей (по одному на аккаунт), которые будут потреблять ресурсы :( ... а реально могут и не работать ... но все-таки лучше так
Честно, но понял смысла в 2-х юзерах, если апач будет выполняться от пользователя.
В чём тайный смысл и зачем плодить сущности?