- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Как снизить ДРР до 4,38% и повысить продажи с помощью VK Рекламы
Для интернет-магазина инженерных систем
Мария Лосева
Не нужно забывать, что для взлома могут хостинг просто купить. И залить сразу все, что нужно :)
рута получить не смогут в большинстве случаев а покрошить юзерам индексные файлы - запросто. это связано с особенностями организации виртуального хостинга на спанели, директадмине, испманагере, хсфере, плеск и т.п. так как полного разделения между аккаунтами без принятия специальных мер (например без выделения для каждого аккаунта своего апача или среды окружения) не существует пока что.
Так вина то в этом как раз хостера. До сих пор многие (как у рег.ру и что там случилось не знаю) ставят дырявый mod_php - это о чем-то да говорит. Как раз надо понимать, что делаешь. Взлом сервера - прямая вина его администратора в первую очередь - недосмотрел. Во вторую очередь уже всё остальное.
а для перл скрипта запущенного из /tmp она не сработает (даже если засекурен /tmp).
Простите, а вы знаете способы запускать скрипты из /tmp с привилегиями отличными от привилегий пользователя? Простите, но чем /tmp отличается от любой другой папки? Для сведения, 777 можно поставить и на хоумдиру юзверя.
и что-то я совсем не верю, что запущенный perl скрипт из temp каким-то образом обойдет систему привилегий linux.
Во-во, оно самое.
посчитайте сколько в libc было критичных фиксов только за этот год.
Эм... А серверы обновлять - не прямая задача администратора?!
TheJetHost.com, работа апача от nobody - потенциальная дырка. Никогда так не делайте.
банальный mod_php фактически более безопасный, если пользоатель грамотный, а производительность выше примерно раз пять
Смотря что за админ им рулит. Настроить его сложнее.
Отключаем глобально в php.ini ВСЕ ф-ции, кои могут быть использованы для повышения прав (exec, system и т.д.)
И чем это вам поможет? Не забудьте пёрл тогда порезать. закрыть доступ к системному интерпретатору python, покромсайте ruby и у вас вообще ничего работать не будет.
Ограничиваем путь, по которому апач будет искать php.ini (дабы не было возможности загрузить свой php.ini с разрешёнными ф-циями)
Тоже бред. А вы под каждую cms отдельный сервер ставите (с включенным magick quotes и с отключенным, к примеру)?
Используем CloudLinux + CageFS + Grsecurity
Гм, гм. Не вижу, как это поможет. От сплойтов может и спасет в какой-то степени, но уповать не рекомендую...
Используем mod_security (с правилами соответствующими)
Опять же нужен спец. Иначе только себе хуже делаем.
Нормального пользователя на том же сервере ни кто не укусит.
Да вот я пока не знаю, в чем же там собсно дело то было... Если повышение привилегий имело место - и нормальному зверю достанется. Кстати, 70% юзверей ставят правильные права.
которые доступные только на чтение 644
Особенно мне нравится ставить такие права на файлы конфигов скриптов с паролями к БД. Ну при условии что на папки стоит 755 - сами понимаете, к чему может привести. Нельзя так делать, или ограничивать через openbasedir - но тогда права побоку. Правда, существуют способы обхода этого ограничения, но все же лучше чем ничего.
TheJetHost.com, работа апача от nobody - потенциальная дырка. Никогда так не делайте.
В чем дырка? Ткните носом на пруфлинк.
Тоже бред. А вы под каждую cms отдельный сервер ставите (с включенным magick quotes и с отключенным, к примеру)?
бред писать глупости, magick quotes можно включить или выключить для отдельного аккаунта (то есть создаётся php.ini по умолчанию для всех и есть php.ini (внимание!) созданный специально для конкретного пользователя (пути к обоим php.ini жёстко прописаны, как-то изменить путь нельзя, загрузить свой php.ini нельзя, точнее можно, но он будет игнорироваться системой)
TheJetHost.com, Лирика: каждый скрипт должен работать от своего владельца, а не от nobody.
Факт: Кроме того, в системе работает от nobody и другой софт помимо апача, как правило. Например, qmail часто от него работает. Ну и фтп-серверы разные. В комплексе может оказаться весело, если хакер исследует систему и обнаружит сей факт. Пусть работает от апача, но будет так же ограничен как и nobody - это гораздо более корректно.
Raistlin добавил 15.08.2011 в 01:23
(пути к обоим php.ini жёстко прописаны, как-то изменить путь нельзя, загрузить свой php.ini нельзя, точнее можно, но он будет игнорироваться системой)
ну млин. Во-первых, пути жёстко прописывать - это как? пхп.ини лежит рядом с исполняемым файлом пхп или рядом с его враппером, или в системной дире. Собсна все... Ну можно еще с параметром запустить, например, из шелла или крона пыху, но от этого вы не спасётесь.
TheJetHost.com, Лирика: каждый скрипт должен работать от своего владельца, а не от nobody.
Raistlin, видимо вы не внимательно читали. nobody только для апача, скрипты выполняются от имени юзеров.
ну млин. Во-первых, пути жёстко прописывать - это как? пхп.ини лежит рядом с исполняемым файлом пхп или рядом с его враппером, или в системной дире. Собсна все... Ну можно еще с параметром запустить, например, из шелла или крона пыху, но от этого вы не спасётесь.
есть соответствующие средства у suPHP
TheJetHost.com, У вас пыхадмин работает от nobody, не? собственно, в его конфигах лежит рутовый пасс. дальнейший алгоритм мне подсказать?
Raistlin добавил 15.08.2011 в 01:36
есть соответствующие средства у suPHP
собсна, php -c свой-конфиг.ini -f скрипт.php в кроне. Варианты противодействия?
Raistlin добавил 15.08.2011 в 01:43
З.Ы. юзеру ничто не мешает пользовать свой враппер к php-cgi, кстати, в очень многих случаях.
TheJetHost.com, У вас пыхадмин работает от nobody, не? собственно, в его конфигах лежит рутовый пасс. дальнейший алгоритм мне подсказать?
собсна, php -c свой-конфиг.ini -f скрипт.php в кроне. Варианты противодействия?
Не надо изобретать велосипед на костылях вместо колес.
Сомневаюсь, что вы сможете что-то сделать лучше, чем рекомендованные настройки по безопасности от специалистов cpanel.
К стати, кто-то упоминал, что покупаем аккаунт и делаем что хотим, т.е. льем нужный софт и ломаем сервак. Так и хочется дать этому человеку аккаунт и сказать: вот тебе целевой файл /home/vzlomuser/lala.txt прочитай его и допиши туда "ha-ha-ha".
Тогда я смогу поверить, что спецы из cpanel чего-то не досмотрели в рекомендованных настройках безопасности.
собсна, php -c свой-конфиг.ini -f скрипт.php в кроне. Варианты противодействия?
Вы видимо просто не работали с suPHP, так как на лицо факт непонимания разницы между работой suPHP и других CGI режимов... php -c свой-конфиг.ini -f скрипт.php обработается с ИГНОРИРОВАНИЕМ данного ini файла (будет использован php.ini, заданный в настройках suPHP)
используется
<Location />
suPHP_ConfigPath