Комментарии 89
К автору статьи — (он так и не выяснил причины взлома) — так какие права на файл .htaccess были?
У вас не был подключен яндекс вебмастер? Он присылает письма если сайт заражен
в связке, например, nginx + nodejs такой взлом вряд ли удастся. а если еще все разнести в docker контейнеры, то все интереснее становится. для взломщика, конечно.
я не говорю что невозможно, но гораздо сложнее взломать простой заливкой файлов. на шаред хостинге так кончено не настроишься
Меня китайские боты заколебали уже, в логах 404 одни login.php, admin.php, phpmyadmin.php, administrator.php, хочутебявзломать.php
А у меня все на Django — китайский_облом.php :D
А по теме поста — гигиена прежде всего — длинные пароли, свои VDSки, логин только с ключами.
Забрутфорсили его, ага, 2016 на улице, боты терабитные атаки устраивают, а он с 5.2 версией и «я вообще редко на сервер заглядываю»…
1. Раз Вас спрашивают, значит Вы ярый противник PHP, но для меня это не суть как важно.
2. Если Вы противник, значит у Вас были какие то подобные автору проблемы.
3. Если были подобные проблемы, так может проблема в Вас? Не думали?
Вот лично у меня, а я пишу исключительно самописные решения, подобных проблем не было.
Что я делаю не так?
P. S. Комментарий не ради холивара на тему PHP. А то начнётся сейчас…
Затрахали с этим «не поддерживается уже». Да, не поддерживается, но используется. И Windows XP, бывает, используется, если нужный софт больше ни под чем не запускается. Вариантов-то нет.
Писателям и пользователям малвари нравится ход ваших мыслей. :)
Затрахали с этим «не поддерживается уже». Да, не поддерживается, но используется. И Windows XP, бывает, используется, если нужный софт больше ни под чем не запускается. Вариантов-то нет.Я Windows 98 иногда использую, но это же не повод пропагандировать ее использование.
Затрахали уже с этим «работает — не трогай». И потом жаловаться что взломали. Если тебе это надо и надо чтобы работало — нужно готовиться платить за постоянную поддержку.
У меня на машине с плеском и на 5.2 недавно обновления прилетали. и плеск 11.5, не последний. Так что ой
А вы просто удалили левые файлы и ждёте их нового появления?
А вы просто удалили левые файлы и ждёте их нового появления?Именно :)
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.
К сожаленю нельзя ограничить .htaccess в другом .htaccess. Т.е. нельзя на шаред хостинге создать структуру в которой все .htaccess либо лежат в реадолни, либо не читаются апачем. Такое навернуть можно только если есть доступ к конфигу. И с этой точки зрения я очень позитивно смотрю на фреймворки, которые хранят временные и пользовательские файлы в базе данных. Такие движки и контейнизировать легко.
Если скрипты выполняются от вас, тут, конечно, ничего не запретишь. Только контролировать чексуммы.
Если коротко, то лучший путь работы со стронней CMS это, во-первых, разобраться в движке хотябы с точки зрения админа (куда пишет, откуда берет конфиги, как обновляется, как конектится к другим сервисам), и, во-вторых, построить CI для нужного софта, хотя бы на уровне дайджеста коммитов, который можно глазами посмотреть.
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.Гораздо проще настроить разделение прав через неймспейсы, через тот же systemd, например: Изолируем демоны с systemd или «вам не нужен Docker для этого!». Но у автора, вроде, хостинг, а не собственный сервер.
1. В .htaccess установить запрет на вызов всех исполняемых файлов (php, py и т.п.), кроме одного index.php
2. Сделать слепок системы (хеш-суммы всех исполняемых файлов, html, css, js)
3. В случае обновления модулей обновлять слепок.
4. Сверять этот слепок раз в сутки по расписанию cron. В случае появления новых файлов или изменения существующих уведомлять вебмастера.
Hash&logs.
1.Регулярная проверка хэшей поможет своевременно обнаружить несанкционированные изменения чувствительных фалов;
2. Логи дадут информацию о происходящем в момент времени, полученный из первой манипуляции.
Если есть возможность, логи лучше слать на другой, отдельный сервер.
Как-то написал простенькую форму загрузки файла для одного единственного случая — надо было чтобы один очень неподготовленный пользователь залил файл. Конечно, никаких проверок не было, скрипт был написан за пару минут. Файл получил, а про скрипт забыл. Вспомнил, только когда на почту посыпались сообщения о неудачной отправке огромного количества писем сомнительного содержания. Благо, сервер домашний, ничего серьезного там не было.
Завтра будете повторять?
И еще — всего несколько файлов нашли?
А где остальные шеллы?
По опыту лечения (не такого, а закрытием уязвимостей) их не меньше 20-30, а иногда порядка 100 на каждый сайт на CMS
Менее вероятный: подкинули через Yii.
Что нужно сделать:
1) добавить владельца в группу www-data;
2) выставить права на файлы и каталоги такие, чтобы владелец мог читать и писать, а группа была www-data и могла только читать;
3) определиться с каталогами, где требуются права записи для php и добавить туда права записи группе www-data.
Всё. Даже если будет дырка в пхп коде, то записать что-либо злоумышленник не сможет, не зная файловой структуры проекта. Даже если он узнает, куда можно положить свой скрипт и положит, то прав на изменение основных файлов проекта у него не будет, как и доступа к уязвимым файлам системы.
В целом не важно какие дальнейшие уязвимые места с правами доступа,… существуют. Важно узнать каким способом загрузили самый первый скрипт.
Всем привет, я вебмастер и меня взломали