- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
У меня в поддержке несколько серверов где клиентам практически за копейки даётся всё и SSH в том числе. И могу вас заверить что за всё время не один сервер не падал и даже не вис до такого состояния чтобы сайты не открывались, а сисадмин по ночам спокойно спит ;)
А как проверить это утверждение? 🍿
Я уже подумывал о том чтобы создавать wwwusername для PHP, чтобы в папку пользователя могли зайти только сам юзер и его ввв алиас. Также искал возможность создания файлов через FTP под ftp пользователем, но так чтобы владельцы имели полное право на их изменение. Или может есть другие решения?
Для простоты, рассмотрим suexec. Просто поставьте отдельного пользователя, скажем user-cgi для этого, поместите его в группу user. Правильно поставив права - Вы запретите user-cgi редактировать определенные файлы пользователя user, созданные в SFTP/SSH сеансе или по FTP.
Проблема в другом: рядовой пыхыпы-кодер (а тем более, пользователь, использующий какой-то стандартный движок) не будет разбираться в "этих ваших правах". Он просто сделает chmod -R 0777 на всем, куда руки дотянутся.
И плакало ваше "решение". А в том, что на его сайт из-за этого заползут козявки - он обвинит Вас.
И после этого апача пустят в каталог с правами 0700, принадлежащий vasya?
Садись, два.
Написано же что в данном случае права 0640.
Читаешь не внимательно , садись единица.
читайте про директиву session.save_path. Ах, Вы не подумали организовать отдельные каталоги для хранения сессий в /tmp? Ну вот и ССЗБ.
А чем собственно "организовать отдельные каталоги в /tmp" отличается от "переносить tmp в туже папку что и public_html для каждого юзера " ???
В том-то и проблема, что свои "советы" Вы отродясь не проверяли.
Проверял, и видел большое кол-во конфигураций.
И кстати получится прочитать поддельную сессию если на сессии права 0777
Ну а как Вы там тогда noexec поставите, если в домашнем каталоге пользователя нужны cgi-скрипты?
cgi-скриптов тоже "нет".
ScriptAlias можно заюзать.
И Вы лично, значит, знакомы с такими "админами" - которые стали после этого читать POST-логи на ночь? А серверов-то сколько у таких "админов"? Адын?
А их и не надо читать каждый день на ночь. Логи не для того чтобы их читать каждый день, а для того чтобы можно было понять что было, когда вы заметили, что что-то не так..
И вообще то что я изначально перечислил, это комплекс мер, из которых каждому стоит выбирать то, что ему подходит.
Написано же что в данном случае права 0640.
Читаешь не внимательно , садись единица.
Читаю я внимательно, это Вы "забыли" про права 0700 на домашней директории пользователя. А ведь я напоминал... Не беда, еще напомню:
поставить на папку каждого юзера права drwx------ с папок с сайтами, это не даст перемещатся вольяжно по серверу.
А чем собственно "организовать отдельные каталоги в /tmp" отличается от "переносить tmp в туже папку что и public_html для каждого юзера " ???
Многим. Тем, например, что марьванна будет забывать удалять файлы из своего tmp.
И кстати получится прочитать поддельную сессию если на сессии права 0777
Ага, а еще на каталоге сессий 0700 - зачитаетесь совсем.
ScriptAlias можно заюзать.
Можно? С suexec? Где-то вне домашнего каталога пользователя (который у вас на разделе с noexec, помним?) заводить ему отдельно директорию с доступом для него. Чтобы только он туда мог положить CGI-скрипты? :-) Юморист, блин.
А их и не надо читать каждый день на ночь. Логи не для того чтобы их читать каждый день, а для того чтобы можно было понять что было, когда вы заметили, что что-то не так..
И у вас есть время ковыряться в гигабайтах POST-логов ради одного клиента хостинга за 0.1 бакса?
И вообще то что я изначально перечислил, это комплекс мер, из которых каждому стоит выбирать то, что ему подходит.
Перевожу на русский язык: "Я краем уха слыхал, что вроде делают то-то и то-то, говоря такие слова... Сам я в этом не бум-бум. Люди добрые - выбирайте!".
MPM-ITK еще никто не советовал?
MPM-ITK еще никто не советовал?
У него и так itk стоит, см. стартпост.
А как проверить это утверждение? 🍿
Для простоты, рассмотрим suexec. Просто поставьте отдельного пользователя, скажем user-cgi для этого, поместите его в группу user. Правильно поставив права - Вы запретите user-cgi редактировать определенные файлы пользователя user, созданные в SFTP/SSH сеансе или по FTP.
Проблема в другом: рядовой пыхыпы-кодер (а тем более, пользователь, использующий какой-то стандартный движок) не будет разбираться в "этих ваших правах". Он просто сделает chmod -R 0777 на всем, куда руки дотянутся.
И плакало ваше "решение". А в том, что на его сайт из-за этого заползут козявки - он обвинит Вас.
проверять не зачем, стоит просто спец. защита от сетевой активности, по логам сайтов, также куча лимитов что не даёт покушать все ресурсы + самописанный киллер который при высоких нагрузках на сервер временно отключает злые аккаунты и воаля, результат)
На счёт user-cgi, тоже самое имел ввиду только назвал wwwusername, знаю что будет работать, единственное смущает что будет количество пользователей в 2 раза больше :)
Ну и ещё по мимо одного плюса получаем несколько минусов, например когда люди вообще не знаю как выставить права и спрашиваю почему не грузятся файлы)
А наезд как раз был от опытного пользователя, которому через уязвимость в CMS залили PHP-шелл на старый сайт, а получили доступ ко всем сайтам на этом аккаунте.
Ладно, буду думать что лучше.
Вобщем раскопал я тот злосчастный шел который залили, штучка прикольная))) поставил потестил, в режиме safe mode не работает совсем, а вот без него работает ну не полностью, например позволяет просмотреть директории другие (но не позволяет что то в них писать) и читать файлы не позволяет, список процессов может показать (но не позволяет что то с ним делать) порты открытые показует, но опять таки не позволяет с ними работать через этот скрипт, проанализировав код понял что работает он через POST запросы (вроде как) хотя до конца ещё код не разобрал, вобщем сам факт того что показует инфу мне не нравится, что такого включает safe_mode чего я не сделал руками?
И вариант ли включить mod_security что бы он фильтровал POST запросы (в доках вроде как реально) ну а на практике хотелось бы услышать ваше мнение, стоит или нет его применять?
P.S. В целом закрытый SSH и ограниченный доступ к панели на уровне root защищают сервер даже при наличии рут пароля, ну всё же не хочется что бы кто то обладал информацией о файлах, процессах портах и прочем...
mod_security как раз и сделан для этих штук, но...
post запросы можно фильтровать, так что не поможет
а для большей защиты поставь grsec kernel, тогда никто не узнает про процессы и порты
Кстати - mpm-itk позволяет скрыть чужие файлы от просмотра
mod_security как раз и сделан для этих штук, но...
post запросы можно фильтровать, так что не поможет
а для большей защиты поставь grsec kernel, тогда никто не узнает про процессы и порты
Кстати - mpm-itk позволяет скрыть чужие файлы от просмотра
Самое удивительное что пользовательские папки с правами 777 он и не показал в выборке точнее он вообще ничего не показал в папке /var/www он показал папки сервера и то не все в основном /var/log /proc и ещё некоторые.....
grsec kernel а в целом для юзеров это не отразится ничем?
babiy добавил 04.02.2011 в 11:55
описание нашёл
http://www.samag.ru/cgi-bin/go.pl?q=articles;n=09.2004;a=09
очень даже ничего так, ну только как вижу основной гемор в том что бы прописать всем системным юзерам соответствующие разрешения, и скажем так установка новых пакетов как бы потребует не простого yum install а ещё потребует дать соответствующие разрешения для группы, или я что то не так понял?
babiy добавил 04.02.2011 в 12:17
нашёл ман инсталляции на Centos
http://blog-admina.ru/2009/11/%D1%83%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0-kernel-2-6-27-10-%D0%B8-iptables-1-4-2-%D0%B8%D0%B7-%D0%B8%D1%81%D1%85%D0%BE%D0%B4%D0%BD%D0%B8%D0%BA%D0%BE%D0%B2-%D0%B4%D0%BB%D1%8F-linux/
создам вдсочку и буду тренироваться что покажет что бы потом накрутить на работающую машинку.
babiy, Если нет желания/времени ковыряться, обратите внимание на http://cloudlinux.com/
Там все что вы хотели выше и многое другое есть из-коробки. На месяц можно заказать лицензию для тестирования.