Comments 89
.htaccess закрывать 444 правами… ну зачем… да?
Если взломали сервер, это не поможет.
файлы можно загрузить и не имея доступа к серверу.
К автору статьи — (он так и не выяснил причины взлома) — так какие права на файл .htaccess были?
К автору статьи — (он так и не выяснил причины взлома) — так какие права на файл .htaccess были?
404, как ни странно. Но я еще раз повторю, права на файл можно менять.
Смотря что взломали. 99.9% всех взломов — это взлом CMS тупым ботом без какого либо дальнейшего повышения привилегий. Если www-data (или от кого там выполняются скрипты) при этом может писать в ограниченное количество каталогов, из которых запрещено исполнение скриптов, дальнейшей эскалации взлома не происходит.
А потом меня еще спрашивают, за что я на люблю PHP…
При наличии возможности заливать файлы на сервер язык программирования уже не имеет значения.
А при чем тут PHP? Взломали то не через него, как пишет автор.
Дыра, она на любом языке — дыра.
Да ладно :D пэпэха — сам по себя одна сквозная дыра. Как на нем люди пишут — он же корежит мышление, я не могу представить чтобы мне подложили исполняемый файл в папку и происходило вышеописанное, как у автора.
Меня китайские боты заколебали уже, в логах 404 одни login.php, admin.php, phpmyadmin.php, administrator.php, хочутебявзломать.php
А у меня все на Django — китайский_облом.php :D
А по теме поста — гигиена прежде всего — длинные пароли, свои VDSки, логин только с ключами.
Забрутфорсили его, ага, 2016 на улице, боты терабитные атаки устраивают, а он с 5.2 версией и «я вообще редко на сервер заглядываю»…
Меня китайские боты заколебали уже, в логах 404 одни login.php, admin.php, phpmyadmin.php, administrator.php, хочутебявзломать.php
А у меня все на Django — китайский_облом.php :D
А по теме поста — гигиена прежде всего — длинные пароли, свои VDSки, логин только с ключами.
Забрутфорсили его, ага, 2016 на улице, боты терабитные атаки устраивают, а он с 5.2 версией и «я вообще редко на сервер заглядываю»…
Тут сразу всплывает некий подсмысл…
1. Раз Вас спрашивают, значит Вы ярый противник PHP, но для меня это не суть как важно.
2. Если Вы противник, значит у Вас были какие то подобные автору проблемы.
3. Если были подобные проблемы, так может проблема в Вас? Не думали?
Вот лично у меня, а я пишу исключительно самописные решения, подобных проблем не было.
Что я делаю не так?
P. S. Комментарий не ради холивара на тему PHP. А то начнётся сейчас…
1. Раз Вас спрашивают, значит Вы ярый противник PHP, но для меня это не суть как важно.
2. Если Вы противник, значит у Вас были какие то подобные автору проблемы.
3. Если были подобные проблемы, так может проблема в Вас? Не думали?
Вот лично у меня, а я пишу исключительно самописные решения, подобных проблем не было.
Что я делаю не так?
P. S. Комментарий не ради холивара на тему PHP. А то начнётся сейчас…
Любляна, Ивана Цупала? Серьезно? :)
Какая версия php на сервере?
5.3
2016 год, 5,3… Хоть последняя версия 5,3 или нет? И да, Вы же знаете что она не поддерживается уже?
Что такого, собственно? И 5.2 бывает. Если не хотят платить за переписывание под новый PHP, что предлагаете? А платить не хотят правильно: работало пять лет — с чего бы оно вдруг должно было перестать работать и потребовало денег? Обновления? Мне не нужны ваши обновления, мне нужно, чтобы сайт работал, тот самый, за который я уже давно расплатился.
Затрахали с этим «не поддерживается уже». Да, не поддерживается, но используется. И Windows XP, бывает, используется, если нужный софт больше ни под чем не запускается. Вариантов-то нет.
Затрахали с этим «не поддерживается уже». Да, не поддерживается, но используется. И Windows XP, бывает, используется, если нужный софт больше ни под чем не запускается. Вариантов-то нет.
Затрахали с этим «не поддерживается уже»
Писателям и пользователям малвари нравится ход ваших мыслей. :)
Писателям и пользователям малвари нравится ход ваших мыслей. :)
Затрахали с этим «не поддерживается уже». Да, не поддерживается, но используется. И Windows XP, бывает, используется, если нужный софт больше ни под чем не запускается. Вариантов-то нет.Я Windows 98 иногда использую, но это же не повод пропагандировать ее использование.
Не хотят платить — так зачем кричать про то, что взломали? Старые версии php — кладезь уязвимостей.
Затрахали уже с этим «работает — не трогай». И потом жаловаться что взломали. Если тебе это надо и надо чтобы работало — нужно готовиться платить за постоянную поддержку.
Затрахали уже с этим «работает — не трогай». И потом жаловаться что взломали. Если тебе это надо и надо чтобы работало — нужно готовиться платить за постоянную поддержку.
Простите, о каких уязвимостях идёт речь? То, что они есть никто не отрицает, но взломать сервер через сам php скорее невозможно. Среди открытых уязвимостей я не нашёл ни одну предоставляющую какой либо доступ для записи. Я уже неоднократно повторял, что если взлом был через приложение, то скорее ломились через неоткрытую уязвимость Yii, а не через сам php.
Почему взята именно 5.3.24? До этой версии есть несколько уязвимостей, которые позволяют выполнить рандомный код и получить доступ к серверу
0-day для ломания хостинга? Маловероятно. Обычно такое можно увидеть, когда профит получили те, кто дыру нашел и бросил инфу в паблик. CVE к этому времени уже есть обычно.
У меня на машине с плеском и на 5.2 недавно обновления прилетали. и плеск 11.5, не последний. Так что ой
Интереснее версия Yii
1.1.12
Интересно. Сходу CVE для неё не нашел.
А вы просто удалили левые файлы и ждёте их нового появления?
А вы просто удалили левые файлы и ждёте их нового появления?
UFO just landed and posted this here
Я предпочитаю полностью запрещать запись в директории (кроме тех, что действительно нужны движку на запись) и полностью запрещаю htaccess файлы, перенося всю конфигурацию в конфиг файлы apache, доступные только руту. Кроме того пользователь под которым работает apache должен быть максимально бесправным, а все core расширения запрещены, кроме списка действительно нужного (в 2.4 с этим стало гораздо удобнее управляться).
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.
Запретить htaccess — неплохое решение, думаю, но для шаред-хостингов не прокатит, к сожалению. Что бы вы могли посоветовать в этом случае?
А почему, собственно, не прокатит? Что мешает иметь один кусок кода, который имеет права на запись в .htaccess-ы, проверяет, всё что можно и делает это аккуратно. Работает при этом от отдельного пользователя и запускается через sudo и/или доступен через локальный сокет?
Потому, что это шаред хостинг. Там обычно один пользователь.
Тут мы опять получаем проблему с тем, что если в где-то в движке есть уязвимость, то он может написать свои .htaccess в те директории к которым есть доступ, а это уже путь к уязвимости описаной в посте.
К сожаленю нельзя ограничить .htaccess в другом .htaccess. Т.е. нельзя на шаред хостинге создать структуру в которой все .htaccess либо лежат в реадолни, либо не читаются апачем. Такое навернуть можно только если есть доступ к конфигу. И с этой точки зрения я очень позитивно смотрю на фреймворки, которые хранят временные и пользовательские файлы в базе данных. Такие движки и контейнизировать легко.
К сожаленю нельзя ограничить .htaccess в другом .htaccess. Т.е. нельзя на шаред хостинге создать структуру в которой все .htaccess либо лежат в реадолни, либо не читаются апачем. Такое навернуть можно только если есть доступ к конфигу. И с этой точки зрения я очень позитивно смотрю на фреймворки, которые хранят временные и пользовательские файлы в базе данных. Такие движки и контейнизировать легко.
Зависит от того, как устроен шаред-хостинг. Если скрипты выполняются от пользователя апача, а файлы принадлежат вам (и апач входит в вашу группу), то можно у группы отнять w и x на .htaccess.
Если скрипты выполняются от вас, тут, конечно, ничего не запретишь. Только контролировать чексуммы.
Если скрипты выполняются от вас, тут, конечно, ничего не запретишь. Только контролировать чексуммы.
UFO just landed and posted this here
Дык отвалилось — пошли по функционалу, разрешили писать куда она не может не писать, остальное оставили закрытым. Заодно — изучили хоть как-то CMS и её привычки. Или вы предпочитаете ставить софт бесконтрольно — а, фиг с ним, пусть что хочет, то и делает?
Самые распространённые не отвалятся. Сломается часть функций по администрированию через админку CMS, а для всего остального можно добиться, что на запись будут доступны только те каталоги, из которых запрещён запуск скриптов.
Это только вершина айсберга. Скорее проблема в том, что нужно реально понимать что ты делаешь. Но с другой стороны админов держат не за бороду и свитер, а за другие заслуги.
Если коротко, то лучший путь работы со стронней CMS это, во-первых, разобраться в движке хотябы с точки зрения админа (куда пишет, откуда берет конфиги, как обновляется, как конектится к другим сервисам), и, во-вторых, построить CI для нужного софта, хотя бы на уровне дайджеста коммитов, который можно глазами посмотреть.
Если коротко, то лучший путь работы со стронней CMS это, во-первых, разобраться в движке хотябы с точки зрения админа (куда пишет, откуда берет конфиги, как обновляется, как конектится к другим сервисам), и, во-вторых, построить CI для нужного софта, хотя бы на уровне дайджеста коммитов, который можно глазами посмотреть.
Если есть возможность использовать selinux, то можно отрубить возможности apache по самостоятельным открытиям сокетов и запускам других приложений. Но это уже на любителя да и тяжеловато. Ну и чрутирование/контейнеризация, если возможно.Гораздо проще настроить разделение прав через неймспейсы, через тот же systemd, например: Изолируем демоны с systemd или «вам не нужен Docker для этого!». Но у автора, вроде, хостинг, а не собственный сервер.
Можно защитится так:
1. В .htaccess установить запрет на вызов всех исполняемых файлов (php, py и т.п.), кроме одного index.php
2. Сделать слепок системы (хеш-суммы всех исполняемых файлов, html, css, js)
3. В случае обновления модулей обновлять слепок.
4. Сверять этот слепок раз в сутки по расписанию cron. В случае появления новых файлов или изменения существующих уведомлять вебмастера.
1. В .htaccess установить запрет на вызов всех исполняемых файлов (php, py и т.п.), кроме одного index.php
2. Сделать слепок системы (хеш-суммы всех исполняемых файлов, html, css, js)
3. В случае обновления модулей обновлять слепок.
4. Сверять этот слепок раз в сутки по расписанию cron. В случае появления новых файлов или изменения существующих уведомлять вебмастера.
Тема рулила 6-3 года назад. Год назад поисковики начали давить такие сайты в поиске. И уже почти не актуальна.
Я и сам так думал, но в статье конкретный пример. В поисковике сайт показывался, только с надписью, что он возможно был взломан.
Увы. Есть у нас старый сайт на шаред-хостинге, владельцы не имеют средств переписать его, или хотя бы портировать под новую CMS. Ломают как по часам. Подозреваю, что боты. Проблема решается git checkout, пока не найдутся деньги, но сам факт, что до сих пор такое происходит.
Деньги и не найдутся, потому, что проблема решается git checkout. Зачем платить, если и так решается?
А что мешает, если ломают «как по часам», отследить методику взлома и костылём закрыть конкретную дырку? Например, если ломают через админку, с помощью того же .htaccess закрыть админку доп.паролем (basic-auth) и т.п.?
В таких случаях еще необходимо логировать POST-запросы. Судя по датам изменения файлов — их скоро вновь попытаются залить — вот из файла логов можно будет узнать через какую дыру в системе.
Обновление yii от 2012 года, которое уже даже не на поддержке. Я думаю никакие контейнеры не помогут. Контейнеры и любые прослойки вообще никак не помогут сайту от дыр и скорее наоборот. Максимум немного обезопасят хост машину.
Применительно не только к этой истории, а вообще:
Hash&logs.
1.Регулярная проверка хэшей поможет своевременно обнаружить несанкционированные изменения чувствительных фалов;
2. Логи дадут информацию о происходящем в момент времени, полученный из первой манипуляции.
Если есть возможность, логи лучше слать на другой, отдельный сервер.
Hash&logs.
1.Регулярная проверка хэшей поможет своевременно обнаружить несанкционированные изменения чувствительных фалов;
2. Логи дадут информацию о происходящем в момент времени, полученный из первой манипуляции.
Если есть возможность, логи лучше слать на другой, отдельный сервер.
Когда у меня мой бложик похакали, я почесал репу и переделал его на Hugo (благо динамический контент на нём не требовался).
В результате удалось избавиться от CMS, PHP и MySQL. Остался только Linux и nginx.
Изначальный заголовок больше заинтриговал ))
Раньше часто такие редиректы в .htaccess клиентов находил, в 70% случаев это старые Joomla/Wordpress или их плагины написаные пионерами, но были и тупо брутфорсы ftp-пароля которые юзеры вообще не меняют годами, так что парольчики нужно менять регулярно и обязательно после таких случаев.
Как-то написал простенькую форму загрузки файла для одного единственного случая — надо было чтобы один очень неподготовленный пользователь залил файл. Конечно, никаких проверок не было, скрипт был написан за пару минут. Файл получил, а про скрипт забыл. Вспомнил, только когда на почту посыпались сообщения о неудачной отправке огромного количества писем сомнительного содержания. Благо, сервер домашний, ничего серьезного там не было.
вроде бы как всё обсудили, но вот запретить авторизацию ftp доступа для всех, а оставить для своего ip?
А где найденная и закрытая дыра в CMS?
Завтра будете повторять?
И еще — всего несколько файлов нашли?
А где остальные шеллы?
По опыту лечения (не такого, а закрытием уязвимостей) их не меньше 20-30, а иногда порядка 100 на каждый сайт на CMS
Завтра будете повторять?
И еще — всего несколько файлов нашли?
А где остальные шеллы?
По опыту лечения (не такого, а закрытием уязвимостей) их не меньше 20-30, а иногда порядка 100 на каждый сайт на CMS
Я что-то на самом деле так и не понял, как первый файл попал на сервер?
Наиболее вероятный вариант: брутфорсом взломали ftp либо ssh.
Менее вероятный: подкинули через Yii.
Менее вероятный: подкинули через Yii.
Почитал бегло комменты. Зачем IDS и какие-то нагромождения? Надо просто понять, что есть юзер, под которым выполняется php, допустим www-data. А есть владелец файлов и директорий проекта на сервере. Это не одно и то же.
Что нужно сделать:
1) добавить владельца в группу www-data;
2) выставить права на файлы и каталоги такие, чтобы владелец мог читать и писать, а группа была www-data и могла только читать;
3) определиться с каталогами, где требуются права записи для php и добавить туда права записи группе www-data.
Всё. Даже если будет дырка в пхп коде, то записать что-либо злоумышленник не сможет, не зная файловой структуры проекта. Даже если он узнает, куда можно положить свой скрипт и положит, то прав на изменение основных файлов проекта у него не будет, как и доступа к уязвимым файлам системы.
Что нужно сделать:
1) добавить владельца в группу www-data;
2) выставить права на файлы и каталоги такие, чтобы владелец мог читать и писать, а группа была www-data и могла только читать;
3) определиться с каталогами, где требуются права записи для php и добавить туда права записи группе www-data.
Всё. Даже если будет дырка в пхп коде, то записать что-либо злоумышленник не сможет, не зная файловой структуры проекта. Даже если он узнает, куда можно положить свой скрипт и положит, то прав на изменение основных файлов проекта у него не будет, как и доступа к уязвимым файлам системы.
Если у вас Shared-hosting, то очень велика вероятность что взломали именно его. Ради эксперимента интересно было бы проверить другие сайты, которые расположены на этом IP.
взлом был совершен давно и поэтому никаких логов не осталось, сейчас жду повтора. Возможно Вы правы и взломали хостинг. Поищу как можно сделать Reverse DNS lookup для shared хостинга и попробую curlом постучаться как гуглбот, может что нибудь и проясниться. Спасибо за идею.
Проверил. Из найденных мной 196 сайтов, только 2 оказались зараженными, но это из за того, что оба они на wordpress. Поэтому думаю всё же взлом был по ftp или ssh.
… также нужно проверить лог файлы. Если повезет, то вы найдете какие файлы/функции вызывались при взломе. И тогда можно подробно эти файлы изучить.
В целом не важно какие дальнейшие уязвимые места с правами доступа,… существуют. Важно узнать каким способом загрузили самый первый скрипт.
В целом не важно какие дальнейшие уязвимые места с правами доступа,… существуют. Важно узнать каким способом загрузили самый первый скрипт.
Как то вел блог на wordpress и потянуло меня сменить шаблон — выбрал на одном сайте где было множество шаблонов, скачал и установил естественно бесплатно )) — После этого через 2-3 месяца мой друг заметил, что наши же новости появляются на другом сайте автоматически. В итоге сменили шаблон.
Sign up to leave a comment.
Всем привет, я вебмастер и меня взломали