Чем опасен chmod 777

Я простой вебмастер, а не сисадмин, потому для меня права доступа к файлам на сервере — лишняя морока. Установить бы всем файлам и директориям chmod 777 и не париться. Но сегодня понял, чем опасен chmod 777, обнаружив на своём сервере неприкрытую критическую уязвимость в ProFTPD.

Опасная уязвимость в FTP-сервере ProFTPD позволяет копировать файлы в пределах сервера без проведения аутентификации с помощью команд site cpfr и site cpto. Подробнее здесь: goo.gl/BQtkcI

Итак, описываю мой случай. Если у директорий сайта права доступа 755 (как должно быть), то право писать в них имеет лишь владелец и php-скрипты, запускаемые от имени владельца. Где владелец — это учётная запись на сервере, в которую добавлен сайт.

Если же права доступа директории 777, то писать в них может любая учётная запись на сервере. Этим пользуются хакеры, обнаружившие уязвимость в ProFTPD — остаётся определить движок, узнать путь на сервере до директории uploads, и если права доступа у неё 777, то можно от имени учётной записи ProFTPD без ввода логина и пароля записать php-скрипт, содержащий строку <?php eval($_REQUEST[cmd]);?>. Затем этот скрипт может выполнить любую команду хакера. Например, залить шелл и предоставить полное управление сайтом (или сайтами, если их несколько добавлено в одну учётную запись).

Вывод. Бывают уязвимости в CMS, плагинах, темах, самописных скриптах... А chmod 777 делает сайт беззащитным ещё и от уязвимостей серверных программ. Если у вас сервер (пусть даже виртуальный), приходится быть хоть немножко сисадмином и серьёзно относиться к chmod.

Запись опубликована в рубрике Web-мастеринг с метками . Короткая ссылка для добавления в закладки: Чем опасен chmod 777.

18 ответов к “Чем опасен chmod 777”

Кирилл:

Еще одна причина не ставить плагины, а решать проблемы руками.

Нам в универе достаточно ясно дали понять, что атрибуты файлов не просто так придумали :)

Павлуха:

Классный у вас универ! Не в первый раз замечаю, судя по твоим постам. Скажи, какой универ и специальность, уж больно интересно :)

Кирилл:

Челябинский государственный, математический факультет, специальность «компьютерная безопасность». Очень громкое название, но по факту нам дают очень и очень много по разным IT сферам, и про безопасность там далеко не больше всего. Мы и математики(прикладная алгебра в больших количествах, теорвер), и сисадмины, и сетевики, и программисты(ООП, веб, скриптовые, решение математических задач), и криптографию нам дают. В общем, голова кругом идет только и думаешь, как побольше закрыть, о конкретной специализации просто некогда задумываться

Павлуха:

Круто! Была бы у меня возможность вернуться к точки выбора специальности, я бы сейчас выбрал что-то такое. Может, оно не всегда интересное, зато в наш цифровой век — актуальное и нужное направление. К сожалению, когда я документы в универ подавал, думал лишь о перспективе не пойти в армию))

Кирилл:

И куда перспектива завела, если не секрет?

Павлуха:

Универ не назову, т.к. гордиться нечем, а дурную славу пусть другие разносят. Факультет естественнонаучный. Привлекло красивое название направления: вычислительная техника. Прямо нам не говорили, что будет написано в дипломе. Завкафедры комментировал отговорками: то «грядут перемены», то «как захотите, так и напишем». В итоге получил диплом, заглядываю в него. Думаю, вот теперь-то узнаю, на кого учился. Читаю: «педагог проф.обучения по специальности проф.обучение». Ясней не стало. Ну, короче, педагог

andi:

Уж от ProFTPD подобного не ожидал.

Под раздачу попадают не только те, кто админит сам, но и клиенты виртуального хостинга. Админам нужно обновить пачку серверов, а новой версии проги ещё нет. Хотя есть способ проще: сбросить всем клиентам 777 нафиг. Так сказать, хардфорк произвести 😀

Павлуха:

Да там похоже заплата появилась в тот же день, как дыра утекла в паблик. Другое дело, что я, например, узнал о дыре случайно через год или два с момента анонса. И нашёл в своей единственной на сайте 777-директории целый зоопарк php-троянов и продуктов их жизнедеятельности — сохранить на память, будет с чем коротать долгие зимние вечера. А потом я ещё и сервер нехило накренил, пытаясь самостоятельно обновить софт. Без профессиональной помощи суппорта в правке конфигов не обошлось. Хорошо хоть на утро апдейт запланировал

andi:

Ох как серьёзно-то всё :(

Остаётся надеяться, что ничего секретного злыдни не узнали.

Как-то обнаружил, что пропала флешка. А на ней все пароли, логины... 2 дня корпел, менял везде. Потом флешку нашёл 😀

Павлуха:

Говорят, менять пароли тоже иногда полезно)) А в каком виде пароли были на флэшке?

andi:

Пароли были в текстовых файлах, критичные — в запароленном архиве)

Менять рекомендуют, некоторые даже ставят перед фактом. Но обычно такое наоборот к снижению сложности паролей ведёт. Юзер знает, что обяжут поменять, поэтому и придумает что-то простое.

Павлуха:

Скорее всего, требование менять пароли — хитрый способ замораживать аккаунты, которыми только боты пользуются. Пароль — этот товар портится не от времени, а событийно (в кафе с публичным вайфаем в админку зашёл, например). С меня обычно когда требуют такое, меняю пароль дважды: сначала добавляю в конце пароля 1 символ, потом удаляю его))

andi:

Может быть. Некоторые, особо хытрые, даже хранят все прошлые пароли и не дают их устанавливать.

ЗЫ: Павел, спасибо за интересную идею! Давно хотел сделать как у тебя, чтобы в последних комментариях мои ответы не светились, а то ощущение, что я один только общаюсь 😀

Сегодня руки дошли, ожидаемо управился в пару правок.

Павлуха:

Велкам! Да сам дольше собирался исключить свои комментарии, чем делал саму работу. Всего-то в цикл вывода комментариев:

foreach ($comments as $comment) {

вставил строчку:

if ( 'мой@имэйл' == $comment->comment_author_email ) continue;

andi:

Пошёл другим путём, в вызове получения комментов get_comments () добавил ещё один параметр — author__not_in.

Остальные правки — создал копию функции, где это вызывается, ибо не хотелось копаться и искать, где оно ещё там используется. Наверно, можно было как-то проще, но я ж лёгких путей не ищу 😀

Павлуха:

Хороший вариант. Технически правильней делать как ты — использовать author__not_in, указав свой id. При этом нет зависимости от e-mail, который можно когда-то захотеть сменить

zusicks438:

Да, тоже заметил, что если раньше чуть ли не каждый движок просил 777 на uploads, теперь от этого почти все отказались.

Здесь ещё не лишним будет сказать, что на сайтах всё же просто необходимо регулярно устанавливать обновления CMS (можно сначала почитать форум на предмет проблем и ошибок, если всё нормально — обновляться). Раньше я их частенько игнорировал, особенно в случае с Joomla, где для обновления нередко нужно садиться голой задницей на раскалённую плиту, а привычный интерфейс меняется значительно. Но всё меняется, когда приходят они — спамеры и дудосеры, ломающие древние движки просто пачками через кучу известных уязвимостей. Приходится обновляться. Ну, точнее, обновлять друзей и знакомых, своих-то сайтов у меня сейчас нет.

К вопросам безопасности начал относиться крайне серьёзно после того, как у меня ломанули Wi-Fi (с вполне себе WPA2) и даже дёрнули пакет с паролем от одного из форумов, благо что больше нигде его не использовал. После этого решил, что избыточных средств защиты в Интернете не бывает :)

Денис:

Да, лучше за этим следить. Я часто стараюсь все на 555/444 закрыть, за исключением папок статики.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *