Forum Webscript.Ru
Разное => Флейм => Тема начата: docker от 26 Февраля 2004, 14:17:39
-
Добрый день!
Почитал про phpRemoteView.php, скачал, установил на сервер... работает!!!! Т.е. просто имеет доступ ко всем файлам сервера, как будто телнету заходишь.
Как советовали, чтобы этого избежать, нужно в виртул хосте php_base_dir выставлять. Но вот проблема у нас он иногда значительно замедляет открытие сайта. Это я по опыту говорю, т.к. не раз уже комментировал эту настройку в виртуал хосте, перезагружал apache, и после этого данный сайт значительно быстрей открывался.
Конфигурация: Apache/windows2000
Поэтому вопросы:
1) Как php_base_dir может влиять на время затрачиваемое на выполнение скриптов сайта, т.е. по сути на время открытия сайта.
2) Какие еще существуют способы защиты сервера от хакерских php скриптов. (вроде там еще можно safe mod в виртуал хосте выстанавливать.... об этом тоже пожалуйста поподробей..)
Спасибо!!
-
docker:
Как обезопасить апач от phpRemoteView.php
Как отпилить рукоятку у граблей, чтобы они не били по голове, когда на них наступаешь?
Ничего страшного, что грабли сделаны не для того, чтобы на них наступать?
Ничего страшного, что если им отпилить рукоятку, ими больше нельзя будет воспользоваться по назначению?
Прости за оффтопик, но это ты на 2000 винде + апач собрался хостинг открывать что ли?
По теме: единственное нормальное решение, которое я знаю - это сделать так, чтобы скрипты выполнялись от имени пользователя, который является их оунером, а не от nobody. А уже как ты это реализуешь - дело твоё.
Updated: Ой, совсем забыл, тебе же под винду надо. Тогда не знаю, по-моему это вообще не осуществимо без извратов.
-
FreeSpace:
...Updated: Ой, совсем забыл, тебе же под винду надо. Тогда не знаю, по-моему это вообще не осуществимо без извратов....
В голове у тебя извраты. Вместо того, чтобы что-то дельное посоветовать, ты тут демагогию разводишь. Чего-ты тогда вообще отвечаешь? Держи весь свой негатив при себе.
Представляешь, может для тебя это невообразимо, но есть люди, которые в этом, о чем ты написал, разбираются пока меньше чем ты. Да-да, именно в такой, по-твоему мнению, элементарщине. Представляешь? Или до тебя это не может дойти?
-
docker
Прошу прощения, возможно я немного переборщил с иронией.
Вот основные мысли, которые я хотел до тебя донести:
1. Вопрос твой поставлен некорректно.
2. Организовывать хостинг (для чего ещё могут понадобиться такие извращения с бедный RemView\'ом?) под связкой win2k + apache, мягко говоря, нецелесообразно.
3. Реализовать разумный способ обхода твоих граблей можно, насколько я знаю, только под никсами.
-
переехали
-
FreeSpace
Опиши как ты реализовываешь под *nix`ами.
ThE0ReTiC:
переехали
зря, кстати.
-
Croaker
Я сам это не реализовываю, потому что никсы пока плохо знаю.
Это реализовывает мой знакомый админ, у которого пхп так стоит уже пару лет и глюков не замечалось. Как он это реализовывает, прямо сейчас узнать не могу - нету его в аське. Если будет интересен именно его способ, могу дать его аську.
А пока можешь посмотреть на это - http://www.suphp.org/
-
FreeSpace:
Прошу прощения, возможно я немного переборщил с иронией.
Да ладно, ничего.
FreeSpace:
2. Организовывать хостинг (для чего ещё могут понадобиться такие извращения с бедный RemView\'ом?) под связкой win2k + apache, мягко говоря, нецелесообразно.
3. Реализовать разумный способ обхода твоих граблей можно, насколько я знаю, только под никсами.
Да хостинг организован уже давно. Да, именно на win2k + apache. Все знают, что это не очень хорошо. Но встречаются же решения, где была оптимальным именно такая связка.
Но кроме php_base_dir ничего в голову не приходит. Поэтому спрашиваю, еще как-то обезопасить сервер от phpRemoteView можно?
-
Croaker:
FreeSpace
Опиши как ты реализовываешь под *nix`ами.
ThE0ReTiC:
переехали
зря, кстати.
Конечно зря. Вопросы безопасности серверов обсуждаем - а тут во флейм... :-)
-
docker:
Но встречаются же решения, где была оптимальным именно такая связка.
Я не могу придумать ни одного повода для работы продакшн сервера в такой конфигурации. Если только на этом "сервере" секретарша пасьянсы не раскладывает...
Способов обезопасить сервер от этой "дырки" - огромное количество. Вот только большинство способов достаточно кривые. И, что самое обидное, большинство хостеров (особенно западных) используют самые кривые из придуманных способов.
Как я уже говорил, имхо самое правильное решение - это запуск скриптов от имени владельца скрипта. Но для этого надо для начала поставить никсы на сервер...
-
FreeSpace:
Я не могу придумать ни одного повода для работы продакшн сервера в такой конфигурации.
Во время планирования новой сети приезжает технический директор холдинга из одной далекой европейской страны и указывает список программного обеспечения, которое должно быть установлено в обязательном порядке на каждой машине. Не согласен — можешь возражать, но тогда прийдется подыскать другую работу, но и на другом месте работы в 60% случаев будет такая же ситуация, и так будет тех пор, пока сам не станешь техническим директором какого-то холдинга.
-
docker
читай тут:
http://phpclub.ru/talk/showthread.php?s=&threadid=22748&perpage=30&pagenumber=1
http://phpclub.ru/talk/showthread.php?s=&threadid=33321&highlight=phpRemoteView
-
Yukko:
читай тут:
http://phpclub.ru/talk/showthread.p...30&pagenumber=1
http://phpclub.ru/talk/showthread.p...t=phpRemoteView
Там тоже это в оффтопе. Странно!!! Никто не сталкивался с такой проблемой что ли? Вероятно сталкивался. А раз такие вопросы в оффтом загоняют, значит они считаются легко решаемыми, а раз так - то подскажите кто-как решал такую проблему?
P.S. Да, там конечно я тоже попытаюсь это спросить.
-
docker
С этой проблемой сталкивались многие, но сильно об этом не принято говорить.
FreeSpace:
Как я уже говорил, имхо самое правильное решение - это запуск скриптов от имени владельца скрипта. Но для этого надо для начала поставить никсы на сервер...
А если у тебя на одном веб-сервере крутятся сайты нескольких пользователей? :) А php реализован как модуль апача, а не cgi? Тогда нужно давать пользователю, от которго веб-сервер бегает, права на работу со скриптами, при чем со всеме (т.е. всех пользователей).
Единственное разумное решение, про которое я знаю - выдавать каждому пользователю по своему апачу. Но тут тоже много камней подводных.
-
FreeSpace
Спасибо за ссылку.
-
Yukko:
список программного обеспечения, которое должно быть установлено в обязательном порядке на каждой машине
Если нет возможности доходчиво объяснить этому "техническому директору" разницу между сервером и воркстейшеном, то я тебе искренне соболезную :(
Croaker:
А php реализован как модуль апача, а не cgi?
Вот это очень уместное уточнение!
Предложенный мною способ годится только в том случае, если php установлен как cgi-приложение.
Запускать несколько апачей под каждого отдельного пользователя я считаю высшей степенью помешательства, так что под SAPI, насколько я знаю, это не осуществимо.
-
FreeSpace:
Запускать несколько апачей под каждого отдельного пользователя я считаю высшей степенью помешательства, так что под SAPI, насколько я знаю, это не осуществимо.
И тем не мнее так делают и весьма успешно.
Почему помешательство, если не секрет?
-
FreeSpace
сочувствия приняты, легче не стало...
-
Croaker:
Почему помешательство, если не секрет?
Причин можно привести очень много, начиная от гибкости настройки и заканчивая обновлением версий или латанием дыр.
Но самый весомый аргумент, имхо, - это производительность.
Может быть на хостинге с парой-тройкою юверов этот способ можно относительно успешно применять, но если это крупный хостинг с тысячами юзеров? Представь себе хотя бы тот объем памяти, который будут занимать все эти апачи...
Кроме того, насколько я знаю, не всё так просто.
Апач слушает 80 порт, а сотня апачей, запущенных из-под разных юзверей, один и тот же порт слушать не могут. Следовательно, нужно вводить демона-координатора, который будет слушать 80-ый прот и "расфасовывать" запросы по разным апачам, закрепленными за разными виртуалхостами.
PS: Возможно я тут бред написал, с никсами я пока что на "Вы".
-
FreeSpace
Я тоже не юникс-гуру, но попробую тебя опровергнуть :)
Когда речь идет про апач для каждого пользователя, никто не говорит, что каждому пользователю надо ставить по дистрибутиву. Исполняемые файлы одни, а конфигурационныен файлы разные для всех пользователей.
Про память.. не берусь утверждать 100% но по-моему (ориентируюсь по опыту) основная нагрузка возникает, когда веб-сервер обрабатывает запрос, а сам процесс httpd, просто висящий в памяти жрет не так много. Соответственно разница, когда у тебя висит (утрировано) 100 процессов httpd и они обрабатывают 1000 запросов, либо когда у тебя висит 1 процесс httpd и те же 1000 запросов, разница не критична. За то ты можешь, если постараешься, отдельному процессу (и соответственно всем запросом от процесса) выдать лимит памяти, и пользователь будет жрать ее ровно столько, сколько ему положено. Когда 1 апач на всех, по памяти ограничить не получиться.
80-ый порт и демон координатор - ну тут я точно знаю как делать (так сделали мы) - ствишь Squid, который прослушивает запросы по внешним ip адресам \\ именам доменов, а потом перенаправляет запрос на web-сервер, который в свою очередь настроен на прослушивание внутренних ip-адресов и своего порта, который может быть от 80-ого отличен. Ну и ответ клиенту происходит так же.
В теории где-то так, на практике реалзовано пока не все.
-
Croaker
Вопросами администрирования серверов (а мы сейчас обсуждаем именно это) до сих пор я никогда не занимался - меня заботливо отгородил от этого админ, чтобы я сосредоточился на пыхе :)
Так что я не хочу продолжать дискуссию, используя в качестве аргументов собственные непроверенные домыслы.
-
[OFF]Сколько можно про пыху? :)[/OFF]
-
[OFF]А что такое?
Мы вообще во флейме, между прочим :)
Про что хотим - про то и говорим...[/OFF]
-
Блин, вы чего? Для каждого пользователя апач запускать и настраивать?
Вы думаете что вы говорите? Вы где-нибудь видели, чтобы на хостинге для каждого сайта свой сервер ставили?
Что за бред? В первый раз такое слышу!!!
И еще вы утверждаете, что это единственный способо обезопасить сервер от phpRemView.php.
Знаете, мне кажется я знаю способ проще, надежней и проверенней: php_base_dir. Дальше нее апач php не пропустит, как бы там скрипт не извращался! Только я с этим спобом и пришел сюда к вам.
Вы же это проигнорировали и стали обсуждать установку для каждого клиента хостинга - своего сервера!!! Ну не бред?
-
docker, родной
первое: если ты что-то слышишь в первый раз, прежде чем называть это бредом подумай 10 раз. Если не помогло - подумай еще 10. Даже если ты продолжаешь так думать, не стоит говорить об этом вслух, потому, что не обязательно, что ты прав.
второе: это ты сюда пришел, ты спросил совета, мы не напрашивались. Если ты считаешь, что ты самый умный, я не понимаю - почему ты задаешь вопросы. Если ты считаешь ответ не правильным, оспорь его аргументировано. если не хватает для аргументов знаний - лучше промолчи.
третье (по теме): 1 копия процесса httpd - это не отдельный веб-сервер для каждого сайта. Я для тебя разжую: это
конфигурационный файл httpd.conf, который содержит виртуальные хосты для отдельно взятого пользователя. хостов может быть хоть один, хоть тысяча. Но для каждого пользователя - по отдельному конфигурационному файлу, с возможностью пользователем этот conf-файл редактировать. Исполняемые файлы для всех пользователей одни и те же, конфигурационный файлы сделаны по одному шаблону, но с разным значениями. Естественно эти файлы генерируются автоматически. Вопрос тебе, гуру, по ходу дела: как дать пользователю 1) самому редактировать httpd.conf на хостинге, при этом не давая возможности даже при большом желании изменить чужие настройки 2) как сделать пользователю лимит на виртуальные директории (например 10 штук, в рамках его тарифного плана)? Интересно послушать твои мысли, пхп_бейс_дир.
Что касается проще, так проще всего вообще отключить серверные скрипты на сервере. 100% аптайм будет.
Что касается php_base_dir - так вот представь на секундочку, что тебе а) нужо пропустить пользователя выше чем php_base_dir указан, например в /var/lib/php/pear/.
И еще открою секрет: php скрипт можно запустить из командной строки при доступе по SSH. Реши проблему.