Кто-то во второй раз добавил кусок 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 и обратного пути в каталогах:
- access_log (ничего за это время, кроме нормального (т. е. чрезмерного) трафика бота msn)
- error_log (ничего, кроме обычного файла, не существует ошибок для безобидно выглядящих файлов)
- ssl_log (ничего, кроме обычного)
- messages_log (здесь нет доступа к FTP, кроме меня)
* ОБНОВЛЕНИЕ: ** ОК, решил. Хакеры из Китая физически разместили на нашем сайте файл, который позволяет им выполнять всевозможные административные действия (доступ к базе данных, удаление и создание файлов и директорий, вы называете это, они имели доступ). Нам повезло, что они не сделали что-то более разрушительное. В обычных лог-файлах apache ничего не было, но я нашел другой набор лог-файлов в анализаторе логов веб-сервера, и доказательства были там. Они обращались к этому файлу с помощью своего собственного имени пользователя и пароля администратора, а затем редактировали все, что им нужно, прямо на сервере. В их файле «apache» установлен как пользователь, в то время как все остальные файлы на нашем сайте имеют другое имя пользователя. Теперь мне нужно выяснить, как они физически поместили этот файл в нашу систему. Я подозреваю, что вина за это в конечном итоге будет лежать на нашем веб-хостинге (Media Temple),
Ответы:
Прежде всего,
chmod 744это НЕ то, что вы хотите. Задача chmod - отозвать доступ к другим учетным записям в системе. Chmod700гораздо безопаснее, чем chmod744. Однако для запуска вашего php-приложения Apache нужен только бит исполнения.chmod 500 -R /your/webroot/chown www-data:www-data -R /your/webroot/www-данные обычно используются как учетная запись Apache, которая используется для выполнения php. Вы также можете запустить эту команду, чтобы увидеть учетную запись пользователя:
FTP ужасно небезопасен, и очень вероятно, что вы были взломаны этим методом. Используя FTP, вы можете сделать файлы доступными для записи, а затем снова заразить их. Убедитесь, что вы запускаете антивирус на всех компьютерах с доступом по FTP. Существуют вирусы, которые прослушивают локальный трафик для имен пользователей и паролей FTP, а затем входят в систему и заражают файлы. Если вы заботитесь о безопасности, вы будете использовать SFTP, который шифрует все. Отправка исходного кода и паролей по тексту в открытом виде - это полное безумие.
Другая возможность заключается в том, что вы используете старую библиотеку или приложение. Посетите сайт поставщика программного обеспечения и убедитесь, что у вас установлена последняя версия.
источник
Мои учетные записи сервера Media Temple Grid неоднократно подвергались такому «взлому». Их безопасность очень плохая ... началась с PLAIN TEXT PASSWORDS в прошлом году и продолжается по сей день (вы можете позвонить в службу технической поддержки, и они скажут: «Какой у вас пароль?»). Я знаю, потому что я получаю ежемесячные электронные письма о том, как они изменили все пароли моей учетной записи, и они фактически заходят и меняют пароли базы данных для вас каждый раз, когда их взламывают. Эта компания выглядит чертовски блестящей на поверхности, но сервер грид - беспорядок. Я рекомендую переключиться немедленно .
Пожалуйста, смотрите этот пост прошлого года о первоначальном фиаско (предупреждение, это вас разозлит). Это пошло вниз оттуда. Я провел молебен в прошлом году от моей семьи и удаление порно ссылки из моих сайтов. Прекрасный.
Следите за забавой на их странице статуса : она расскажет вам все о последних подвигах (и, действительно, прямо сейчас есть «возможный подвиг»).
источник
На основании отсутствия активности в журналах доступа и т. Д., А также того факта, что это происходит примерно в одно и то же время, может показаться, что они взломали сервер и создали какой-то сценарий оболочки для выполнения добавления.
Вы проверили crontab на что-нибудь странное?
Вы пытались переименовать каталог и ссылки на него (это может сломать сценарий оболочки)?
источник
Да, это может быть определенно связано с правами доступа к файлам. Имея файлы, доступные для записи веб-процессом, вы открыты для любой уязвимости безопасности в работающих веб-приложениях. Заблокируйте все, чтобы веб-процесс не мог читать или писать больше, чем нужно.
Другой компонент отслеживает, как именно они изменяют ваши файлы. Проверка журналов доступа веб-сервера - это хорошее место для начала. Проверьте время последнего входа в систему для различных пользователей. Вы также можете установить скрипт, который отслеживает файлы на предмет изменений и уведомляет вас, чтобы вы могли попытаться поймать преступников с поличным!
источник
Это звучит очень знакомо для хакеров Wordpress, которые недавно поразили множество сайтов Network Solutions. Поскольку вы находитесь в Media Temple, возможно, вы оставили некоторые файлы видимыми для других пользователей, использующих ваш компьютер. Это объясняет отсутствие POST или следов журналов Apache. В таком случае было бы смертельно просто ввести код в командной строке.
источник
Вы на общем сервере? Если это так (или даже если нет), кто-то может взломать пароль FTP и загрузить скрипт, добавляющий любые файлы, которые он может получить.
Или, возможно, эта программа имеет подвиг.
источник
Если у вас есть соответствующий доступ (и поддержка ядра), вы можете попытаться запустить демон мониторинга на основе inotify или dnotify для отслеживания изменений в ваших файлах, а затем (быстро) использовать «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 был единственным программным обеспечением, которое могло вызвать что-то подобное.
источник