Кто-то второй раз добавил кусок javascript на сайт, который я помогаю запускать. Этот javascript захватывает Google AdSense, вставляя собственный номер учетной записи и расклеивая рекламу.
Код всегда добавляется, всегда в одном конкретном каталоге (который используется сторонней рекламной программой), влияет на количество файлов в нескольких каталогах внутри этого одного каталога (около 20) и вставляется примерно в одно и то же время за ночь. время. Учетная запись AdSense принадлежит китайскому веб-сайту (расположенному в городе, расположенном не в часе езды от того места, где я буду в Китае в следующем месяце. Может, мне стоит разориться ... шучу, вроде того), кстати ... вот информация о сайт: http://serversiders.com/fhr.com.cn
Итак, как они могли добавлять текст в эти файлы? Связано ли это с разрешениями, установленными для файлов (от 755 до 644)? Пользователю веб-сервера (он находится на MediaTemple, поэтому он должен быть безопасным, да?)? Я имею в виду, что если у вас есть файл, для которого установлены разрешения 777, я все равно не могу просто добавить к нему код по своему желанию ... как они могут это делать?
Вот образец кода для вашего удовольствия от просмотра (и, как вы можете видеть ... не особо. Настоящая уловка в том, как они его туда поместили):
<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>
Поскольку многие люди упомянули об этом, вот что я проверил (и под проверкой я имею в виду, что я посмотрел время, когда файлы были изменены на предмет каких-либо странностей, и я нашел файлы для операторов POST и обходов каталогов:
* ОБНОВЛЕНИЕ: ** ОК, решил. Хакеры из Китая физически разместили на нашем сайте файл, который позволяет им выполнять всевозможные административные операции (доступ к базе данных, удаление и создание файлов и каталогов, вы называете это, у них был доступ). Нам повезло, что они не сделали чего-то более разрушительного. В обычных файлах журнала apache ничего не было, но я нашел другой набор файлов журнала в анализаторе журнала веб-сервера, и доказательства были там. Они обращались к этому файлу со своим собственным именем пользователя и паролем администратора, а затем редактировали все, что им нужно, прямо на сервере. Их файл имеет "apache", установленный как пользователь, в то время как все остальные файлы на нашем сайте имеют другое имя пользователя. Теперь мне нужно выяснить, как они физически перенесли этот файл в нашу систему. Я подозреваю, что вина за это в конечном итоге будет лежать на нашем веб-хосте (Media Temple), если у них действительно не было нашего входа в FTP ... не знаю, как я это определю, однако, поскольку этот файл, вероятно, был там какое-то время.
Мои учетные записи сервера Media Temple Grid Server неоднократно "взламывали" подобным образом. Их безопасность очень плохая ... начал с ОБЫЧНЫЕ ТЕКСТОВЫЕ ПАРОЛИ в прошлом году и продолжается по сей день (вы можете позвонить в техподдержку, и они скажут «какой у вас пароль?»). Я знаю это, потому что ежемесячно получаю электронные письма о том, как они изменили пароли всех моих учетных записей, и они на самом деле заходят и меняют пароли баз данных для вас каждый раз, когда их взламывают. На первый взгляд эта компания выглядит чертовски блестящей, но с сетевым сервером полный беспорядок. Рекомендую сменить немедленно.
Посмотри пожалуйста этот пост из прошлого года о оригинальное фиаско (предупреждение, это вас разозлит). Оттуда все пошло под откос. Я провел молебен в прошлом году от моей семьи и удаление порно ссылки из моих сайтов. Прекрасно.
Следите за весельем на их страница статуса: Он расскажет вам все о последних эксплойтах (и, да, действительно, прямо сейчас там есть «возможный эксплойт»).
Прежде всего chmod 744 это НЕ то, что вы хотите. Смысл chmod - отозвать доступ к другим учетным записям в системе. Chmod 700 намного безопаснее, чем chmod 744. Однако Apache нужен только бит выполнения для запуска вашего php-приложения.
chmod 500 -R /your/webroot/
chown www-data:www-data -R /your/webroot/
www-data обычно используется в качестве учетной записи Apache, которая используется для выполнения файла php. Вы также можете запустить эту команду, чтобы увидеть учетную запись пользователя:
`<?php
print system("whoami");
?>`
FTP - это ужасно незащищенный и очень вероятно, что вас взломали этим методом. Используя FTP, вы можете сделать файлы доступными для записи, а затем снова заразить их. Убедитесь, что вы запустили антивирус на всех машинах с доступом по FTP. Существуют вирусы, которые прослушивают локальный трафик в поисках имен пользователей и паролей FTP, а затем входят в систему и заражают файлы. Если вы заботитесь о безопасности, вы будете использовать SFTP, который все шифрует. Отправлять исходный код и пароли по сети открытым текстом - полное безумие.
Другая возможность - вы используете старую библиотеку или приложение. Посетите сайт поставщика программного обеспечения и убедитесь, что у вас установлена последняя версия.
На основании отсутствия активности в журналах доступа и т. Д. И того факта, что это происходит примерно в одно и то же время, может показаться, что они скомпрометировали сервер и имеют какой-то сценарий оболочки, выполняющий добавление.
Вы проверяли crontab на что-нибудь странное?
Вы пытались переименовать каталог и ссылки на него (это может сломать сценарий оболочки)?
Да, это определенно может быть связано с правами доступа к файлам. Имея файлы, которые доступны для записи веб-процессу, вы открыты для любых уязвимостей безопасности в запущенных веб-приложениях. Заблокируйте все, чтобы веб-процесс не мог читать или писать больше, чем нужно.
Другой компонент отслеживает, как именно они изменяют ваши файлы. Проверка журналов доступа к веб-серверу - хорошее место для начала. Проверьте время последнего входа для различных пользователей. Вы также можете настроить скрипт, который отслеживает изменения файлов и уведомляет вас, чтобы вы могли попытаться поймать преступников с поличным!
Это звучит ужасно знакомо для Wordpress хаки которые в последнее время поразили множество сайтов Network Solutions. Поскольку вы находитесь в Media Temple, возможно, вы оставили некоторые файлы видимыми для других пользователей, использующих ваш компьютер. Это объясняет отсутствие POST или жутких трассировок журнала Apache. В этом случае было бы смертельно просто ввести код в командную строку.
Код всегда добавляется, всегда в одном конкретном каталоге
Связано ли это с разрешениями, установленными для файлов (от 755 до 644)? Пользователю веб-сервера
Вы на общем сервере? Если это так (или даже если нет), кто-то мог подобрать пароль FTP и загрузить скрипт, который добавлял любые файлы, которые он мог получить.
один, используемый сторонней рекламной программой
Или, возможно, в этой программе есть эксплойт.
Если у вас есть соответствующий доступ (и поддержка ядра), вы можете попытаться запустить демон мониторинга на основе inotify или уведомлять чтобы следить за изменениями в ваших файлах, затем (быстро) используйте «lsof», чтобы увидеть, в каком процессе файл открыт с правом записи. Вы также можете использовать Strace для мониторинга. Это должно дать представление о том, какой исполняемый файл используется.
Журналы проверки FTP - это первое, с чего нужно начать. Журнал должен содержать большую часть, если не все действия, а также временные метки, поэтому, если вы знаете, в какое время были изменены ваши файлы, вы можете определить, была ли ваша учетная запись FTP взломана или нет.
Затем это может быть сценарий на вашем веб-сервере, который вводит этот код. В сценарии виртуального хостинга я думаю, что можно сделать cat /web/malicious.com/script.js >> /web/innocent.com/index.php. Это может работать при определенных условиях, например, когда команда выполняется пользователем httpd, а файл index.php также принадлежит этому пользователю / доступен для записи. В этом случае у вас должен быть провайдер хостинга для отслеживания учетной записи, используемой для внедрения скриптов.
Большинство файлов сайта должны быть доступны для чтения веб-серверу. На сайте только для чтения веб-сервер должен иметь возможность записи только в журналы. установить владельца на кого-то, кроме того, который используется веб-сервером. Установите защиту 640 для всех файлов, кроме скриптов. Установить сценарии и каталоги 750. Для файлов или каталогов, которые должны быть записаны веб-сервером, вы можете изменить владельца на веб-сервер или установить chmod g + 2 для соответствующих файлов или каталогов.
Существует множество способов взломать сайт. Они могли использовать уязвимость в вашем скрипте, украсть ваш пароль, использовать уязвимость совместно размещенного сайта (если вы находитесь на дешевом хосте), использовать уязвимость какой-либо службы, не связанной с Интернетом, на сервере .. .
В качестве первого шага проверьте дату изменения файла и проверьте журналы доступа, ошибок и ftp на предмет подозрительной активности в это время.
То же самое случилось со мной некоторое время назад. Насколько мне известно, Wordpress был единственным программным обеспечением, которое могло вызвать нечто подобное.