Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Администрирование *NIX систем > борьба с Black Hole Exploits Kit на BSD сервере


Автор: Acraft 11.6.2011, 13:28
Доброго времени суток.
Попробую сформулировать вопрос наиболее полно, но если что я не админ и могу упустить какие-то тонкости.
В конторе стоит FreeBSD'шный веб-сервер apache+php+mysql. На нём, как не трудно догадаться, вертятся конторские же php-шные самописки. Один из сервисов (сайт) смотрит наружу и является сайтом-визиткой. С недавнего времени, что-то прописывает "левый код" в файлы этого сайта (сначала - index.php, потом прицепился к js-файлам), в результате чейго сайт становится распространителем вот такой заразы:
http://www.uinc.ru/news/sn15376.html 

Нужно сказать, что после удаления этого кода, он снова появляется только в одном файле, и не обязательно том же что в предыдущий раз. Ещё, замечено, что время появления - это где-то 1:20-1:30 ночи.

На клиентских машинах его видят KAV и Norton, другими не пробовал (но MS Essentials точно не видит).
Norton идентифицирует его как Black Hole Exploits Kit.
Касперский как Trojan.JS.Iframe.tl

Файлы которые модифицирует эта гадост имеют права 644, что, видимо, значит что действует она из-под владельца файлов.

Для очистки совести запустили на сервере ClamScan, он конечно же ничего не нашёл.

Может кто-то уже сталкивался с такой напастью и сможет поделиться опытом по борьбе с ней?

Автор: GrayCardinal 12.6.2011, 12:23
Acraft, 
Вопрос в лоб. Много народу имеют доступ к скриптам ? smile

Добавлено через 32 секунды
P.S.
Может прописывает не "что-то" а "кто-то" ?

Автор: bilbobagginz 13.6.2011, 11:00
Цитата(Acraft @  11.6.2011,  12:28 Найти цитируемый пост)
Может кто-то уже сталкивался с такой напастью и сможет поделиться опытом по борьбе с ней? 

дело понятное: кто-то имеет доступ.

0) надо машину обернуть фаерволом, который экранирует, и контролируем тобой (ВНЕ машины), и смотреть, кто когда и откуда подключается.
1) переустановить систему, реставрировать данные.
2) сравнивать конфиги ДО взлома и после, сравнивать файлы php до взлома и после.
ессно для этого желательно иметь систему контроля версий на другом сервере.
3) иногда взлом делают посредством дыр в таких инфраструктурах как apache, php, и т.д. иногда есть дыры в сторонних скриптах, которые вы запускаете для статистики, и т.д. Если у вас дыра в скрипте (какой - нибудь банальный SQL injection) есть смысл в логгировании изменений паролей, добавки пользователей в б.д. вашего приложения, заблокировать доступ к бд. из ненужных источников. ну и логгировать доступ к админке (если она имеется)

систему регулярно обновляете ? порты обновленные ?
логи лежат только на машине или есть внешний логхост ?

Автор: Acraft 13.6.2011, 11:21
Спасибо за ответы. 

Доступ к консоли разрешён только с опрделённых адресов.
Фаерволл стоит. Логи локальные. На счёт портов не знаю, но php и впрямь надо бы обновить.

Юзеров там по пальцам перечесть.
Сменил пароль юзеру-владельцу файлов сайта. И раздал всем js и css скриптам "r--r--r--".

Вроде помогло, т.к. 2 ночи тихо. Т.е. по утрам антивирусы не верещат, и яндекс опасным сайт не называет. 

Буду смотреть как дальше дела пойдут.

p.s.: для отслеживания активности на сервере, возникла идея поставить Snort

Автор: GrayCardinal 13.6.2011, 15:31
>Доступ к консоли разрешён только с опрделённых адресов.
Извини, но это очень элементарно обходится :(

Автор: Сумасшедший 13.6.2011, 19:09
Acraft, дайте попробую угадать с половины попытки: на сервере поднят ftp, который откуда-либо доступен. Так?

Автор: Acraft 24.6.2011, 12:49
Цитата(GrayCardinal @  13.6.2011,  15:31 Найти цитируемый пост)
>Доступ к консоли разрешён только с опрделённых адресов.Извини, но это очень элементарно обходится :( 

Если не секрет, то как?

Цитата(Сумасшедший @ 13.6.2011,  19:09)
Acraft, дайте попробую угадать с половины попытки: на сервере поднят ftp, который откуда-либо доступен. Так?

Нет, ftp и wget не стоят. Доступ через SSH.

Кстати, эту фигню начала воспринимать Windows Essentials : http://www.microsoft.com/security/portal/Threat/Encyclopedia/Entry.aspx?name=VirTool%3aJS%2fObfuscator.BN&threatid=2147646584

Долго же они раскачивались.

p.s.:
В общем и целом, помогла смена паролей SSHного юзера и юзера из-под которого работает Апач.
И на все файлы кроме тех куда надо писать выставлены права 644 (кой где по недосмотру или еще почему-то были права на запись). Ну и немного перетасованы владельцы для них и их группы.

Автор: bilbobagginz 25.6.2011, 20:12
во первых: LOL.
Цитата(Acraft @  24.6.2011,  11:49 Найти цитируемый пост)
 юзера из-под которого работает Апач.

а у этого юзера должна быть оболочка из вида /bin/false или кастомизированаая версия его, /bin/fuckoff
(т.е. печатающая идите-ка на 3 буквы, а потом /bin/false)
а доступ к серьезным сервантам по SSH должен быть по запароленным ключам. желательно с обновленной системой, особенно openssl, а то несколько лет (уже) назад была дырявая опенссл, к которой можно было подобрать ключ довольно быстро.

Доступ должен быть логгируемым, а не только "контролируемым" (настраивается в PAM, и в настройках iptables, т.е. логгировать попыткуи на уровне сети) и есть еще пакет в дебиан системах называется fail2ban.

кстати вы пробили персонал?


Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)