- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee

В 2023 году Google заблокировал более 170 млн фальшивых отзывов на Картах
Это на 45% больше, чем в 2022 году
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Доверчивым любителям r-x--x--x посвящается.
Не буду сейчас описывать ГРОМАДНЫЙ список HSP с правами к клиентским директориям по данной схеме. Хочется лишь напомнить их клиентам, что многочисленные «ботнеты», с помощью которых организуют DDOS атаки, методом закачки на их хостинг какого-то скрипта, делаются за счет типичной ошибки в организации доступа к файлам и директориям других клиентов.
Если администраторы вашего хостинга считают, что из директории другого клиента, права на которую установлены в “r-x—x—x” нельзя читать файлы, то они глубоко заблуждаются. Если они считают, что запретив чтение, к примеру “/home”, список домашних директорий нельзя узнать, то они не знают элементарных вещей.
Любой клиент такого хостинга может зайти под своим SSH заходом… а потом, к примеру:
for i in ls `cat /etc/passwd|awk -F ":" '{print $6}'`; do cat $i/public_html/index.php; done|more
Следовательно, злоумышленники могут читать не только index.html, а еще и .htaccess, index.php, а затем уже и includes/config.php и т.д. Потом, в результате сканирования файлов по ключевым словам, в чужие руки попадают учетные записи. Далее, остается только найти способ закачки скрипта, через какое-то приложение. К примеру, если это CMS система, php шаблоны которой можно править через WEB интерфейс, а исполняемым скриптам позволено что-то закачивать на сервер, то дело сделано.
IMHO это всеобщая беда некоторых готовых решений. Разработчики хостинговых систем как-то упустили этот момент, но, тем не менее, поразительны действия администраторов, которые не обращают на это внимание. Из сочувствия к ним, список готовых решений, которые по умолчанию помогают установить такие права к директориям на сервере, приводить само собой не буду.
Что правда то правда, так было три года назад, так было год назад и сейчас все тоже самое. Хостов таких полно. То и дело на форумах вижу сообщения от пользователей "ой, загрузил себе в директорию скрипт файл менеджера а он у меня видит какие то странные папки /home /ets /usr что это такое?" :) остается только представлять что может сделать то кто знает что это такое :) .. а если еще и сейф_моде выключен :)
jail ssh, jail cgi - решение проблемы. Хотя очень костыльное
По мне - так рулит виртуалхостинг с правами 600/700 и владельцем owner :)
user level security всегда обходили и будут обходить!
Простой пример: Все настроено в соответствии с докой от PHP, но у пользователя есть возможность исполнять бинарники в директориях куда у него есть доступ на запись. В них закачивается wrapper и ограничения php спокойно обходятся.
Мы jailssh установили, закрыли дырки
kostich, так во-первых есть TPE, а во вторых если права 600/700 - ему это ничего не даст :)
RomaHost.net, ядро какое поставили? ;)
kostich, так во-первых есть TPE, а во вторых если права 600/700 - ему это ничего не даст :)
права должны быть, к примеру, rwxr-x---, у uid httpd занесен в одну группу с owner.
По опыту администрирования дедика скажу, пользователю вообще ничего нельзя давать делать того что он не должен(компиляция, ssh, file_get_contents, allow_url_fopen=off)
права должны быть, к примеру, rwxr-x---, у uid httpd занесен в одну группу с owner.
Это плохие права. Предпочитаю 700/600 и владелец owner :D
По опыту администрирования дедика скажу, пользователю вообще ничего нельзя давать делать того что он не должен(компиляция, ssh, file_get_contents, allow_url_fopen=off)
Можно. Просто настраивать надо грамотно ;)
Это плохие права. Предпочитаю 700/600 и владелец owner :D
1. Чем они плохие?
2. Из под кого должен быть запущен web-сервер, что бы с такими правами читать из этой директории?