LINUX.ORG.RU
решено ФорумAdmin

Залезли на сервер, нужен совет как найти заразу.

 , , ,


0

1

Привет!

Предположительно через дыру в движке сайта клиента (какая-то старая джумала) залезли на серв и ддосили сайты зарубежных банков (~50MBps).

Сейчас наружу всё закрыли с помощью iptables: разрешён обмен данными только между уже установленными соединениями, сам сервер может быть инициатором соединения только для списка разрешённых айпишников.

Понятно, что избавились от последствий, а не от причин. Хочется найти и причину.

Чтобы найти причину нужно смотреть по пакетам - что и куда идёт в момент активности.

Подскажите, каким образом можно ловить исходящие пакеты?

Всё открывать заново не хочется, а tcpdump в данный момент не помогает (исходящие соединения не устанавливаются, и пакетам некуда уходить, соответственно их и нет).

В сервере одна сетевая карта.

Есть идея поднять виртуальный интерфейс сделать через него маршрут по умолчанию (на этом интерфейсе и слушать), с него перенаправлять на eth0 (реальный интерфейс с интертеном), а на eth0 резать всё лишнее. Но не понятно - реально ли такое? А если реально, то не хватает мозгов как прокидывать всё это :( Или нужно заморачиваться с ВПНами?

Или есть какие-то другие идеи?

Спасибо!

PS: на сервере Debian wheezy с последними обновлениями.

Но не понятно - реально ли такое?

Вполне. man iproute2:

 netns  - manage network namespaces

Требуется ядро 3.3 или новее, поддержка network namespaces и policy based routing

Pinkbyte ★★★★★ ()

fwbuilder. Шаблон "web-server" или как-то так.

ziemin ★★ ()

Сохрани нужные конфиги и переустанови систему. В дебиане с нетинсталл можно всё круто установить и настроить

anonymous ()
Ответ на: комментарий от anonymous

Ага, а потом ещё всех клиентов заставить сайты свои переустанавливать и перенастраивать заново.

Был бы пустой сервер, давно бы так сделал.

Вариант не подходит, т.к. если влезли один раз, то и влезут другой раз через ту же дырку (а по поводу джумалы в первом сообщении - это предположение, т.к. там были какие-то левые файлы со свежестью 1 день)

IPFreely ★★ ()
Ответ на: комментарий от IPFreely

Боюсь, что если влезли, то уже лучше переставлять. Ну а так, по логике, любая ддосилка обычно управляема, стоит проверить sudo ss -plan на предмет лишних слушающих, и уже от них плясать. Ну и сайты проверить на предмет дыр и нестандартных запросов в access.

chenger ★★ ()
Ответ на: комментарий от IPFreely

Можно попробовать заворачивать трафик в обратку в -t nat -A OUTPUT с помощью DNAT --to-destination 127.0.2.1

Ну и --state соответственно добавить. Не уверен, давно iptables не дергал, но может поможет.

chenger ★★ ()
Ответ на: комментарий от IPFreely

1 Сервер скомпрометирован

2 А что с за проблема, развернуть сайты клиентов из резервных копий?

3 Они у тебя разве не в изолированных средах?

sin_a ★★★★★ ()
Ответ на: комментарий от chenger

Боюсь, что если влезли, то уже лучше переставлять.

Это бесполезно, если на сервере клиентские виртуалхосты: так же и влезут. Каждый раз переставлять, что ли ? Да это по 10 раз на дню может происходить всвязи с утягиванием паролей с клиентских виндостанций. То есть, это, даже, не дырка в джумалах может быть. Надо искать и думать, нет ли локал рут в системе. Лучше бы локал рут не было на таком сервере.

AS ★★★★★ ()
Ответ на: комментарий от sin_a

А что с за проблема, развернуть сайты клиентов из резервных копий ?

Из-за пары-тройки лопухов всех класть ? А на сколько минут это спасёт ? А время восстановления всего сколько по времени занимает ?

AS ★★★★★ ()
Ответ на: комментарий от chenger

А толку переставлять сервер если проблема в каком-то клиентском сайте?

Прогон по debsums ничего не показал, антивири и rkhunter тоже не говорят ничего о подозрительных файлах. Значит проблема где-то в пользовательских файлах.

После перестановки системы все пользовательские файлы лягут на свои места и проблема не исчезнет.

Похоже на наше кстати: http://blog.blocklist.de/2013/01/26/update-from-the-brobot-ddos-against-finan...

И от 27 марта: https://devlog.websafe.pl/2013/03/27/outdated-joomla-websites-with-jce-used-t...

Пробежался по http логам совпадения есть.

IPFreely ★★ ()

После того как уже влезли - однозначная переустановка.

Ага, а потом ещё всех клиентов заставить сайты свои переустанавливать и перенастраивать заново.

Это полный ССЗБ, если у вас через дырку в сайте можно получить доступ к системе. Вот теперь расплачивайтесь это маленькой неурядицей.



Вспомните как kernel.org делали полный реинсталл, как дебиан на каком-то из своих проектов аналогично. Это ведь не просто так. Есть бэкдоры, которые подменяют системные утилиты, которые ставят свои ps и top, фильтрующие во всех выводах левые демоны и т.д. Или вы думаете сейчас обрежете один коннект и пусть клиенты дальше живут на неконтролируемом сервере с возможностью утечки прайваси или еще чего похуже? По вашему это лучше? Скажите где работаете, чтоб знать с кем не нужно сотрудничать.

Делайте слепок системы, если нужно расследование, ставьте свижий инсталл, полностью обновляйте, как минимум - не забудьте про Chroot при новой настройке хостинга.

BaBL ★★★★★ ()
Ответ на: комментарий от amorpher

Нет не организатор. Интересно каким образом делалась атака и попробовать избавиться от неё.

Т.е. моё видение такое: нужно слушать и анализировать исходящий трафик, но так, чтобы он не выходил наружу. Т.е. гнать его через какой-нибудь виртуальный интерфейс (на котором слушать), а на выходе уже резать.

Или может поднять фейковый сервер, а запросы наружу перекидывать на него, а на нём уже слушать и делать анализ (ну тупо считать скорость и количество соединений на айпишник назначения, и из этого делать выводы)?

IPFreely ★★ ()
Ответ на: комментарий от IPFreely

При переустановке подумать о защите посерьезнее. BaBL правильно говорит, может получиться что ничего и не найдете даже, а оно будет жить и радоваться жизни.

chenger ★★ ()
Ответ на: комментарий от IPFreely

Прогон по debsums ничего не показал, антивири и rkhunter тоже не говорят ничего о подозрительных файлах.

При запуске из-под скомпрометированной системы это ни о чём не говорит.

Если есть возможность, я бы клиентские сайты разнёс по разным виртуальным машинам, а сервер переустановил.

router ★★★★★ ()

Сейчас наружу всё закрыли с помощью iptables:

Подскажите, каким образом можно ловить исходящие пакеты?

Перед -j DROP поставь -j LOG и лови в /var/log/syslog. Не забудь только для LOG ограничение поставить, например

-m state --state NEW -m limit --limit 10/s -j LOG

router ★★★★★ ()
Ответ на: комментарий от router

Лог на DROP уже давно установлен, но он даёт только лог куда идут соединения, а самих соединений соответственно нет (режутся по DROP-у)

IPFreely ★★ ()
Ответ на: комментарий от IPFreely

А что ты ожидаешь увидеть в дампе, если не хочешь разрешать траффик обратно? Пустой tcp пакет с установленным syn флагом?

router ★★★★★ ()

Систему видимо на самом деле переустановлю. А в Nagios добавлю дополнительные проверки с самописным «анализом» (как писал выше) на исходящие соединения и скорость отдачи. Если у кого-то есть что посоветовать на этот счёт, то буду признателен.

Всем спасибо.

IPFreely ★★ ()
Ответ на: комментарий от router

хочу увидеть тело запроса (для этого соответственно фейковую машину нужно завести будет).

IPFreely ★★ ()
Ответ на: комментарий от chenger

Можно попробовать заворачивать трафик в обратку в -t nat -A OUTPUT с помощью DNAT --to-destination 127.0.2.1

Очень здравая идея, никогда об этом не думал, беру на вооружение.

the_green ()

Чего переживать то, если через дырку в движках

джумала

то система не будет затронута, апач (нжинкс) работают от непривилегированного юзера (www-data). А вообще они должны работать от того юзера который является владельцем файлов виртхоста (с правами 700).

Так что восстановить файлы сайта из бекапа (он же есть, правда?) и все дела, ну и попросить исправить версию дырявого движка.

И конечно использовать тестинг на сервере это сильно.

invokercd ★★★★ ()

Скорее всего зараза в таких случаях сидит внутри движка сломанного сайта и дальше него не пролезла(я ж надеюсь, у тебя апач не от рута работает?). Обычно это делается путём добавления какого-нить php-файлика с адресом типа http://brockensite.com/bla/bla/somefile.php. Те, кого спамить либо зашиты в нём, либо отправляются взломщиком при помощи POST-запросов. Реже, файлик прописан во внутреннем кроне сломанного движка.

Нужно внимательно изучать логи апача. Если через POST адреса шлются, значит в логах будет неестественно частое обращение к одному и тому же файлу. Да, иногда взломщики меняют этот файл раз в некоторое время, но суть та же. Искать левую активность. Помимо этого, надо смотреть, когда впервые пошёл спам(если на сервере было что-то типа munin'а/zabbix'а/nagios'а, то с помощью них вычислять время повышения активности, если нет, то руками по логам). Зная время, можно точнее выяснить, как пролезли и что залили на сервер опять же по логам апача. Далее удалять всё то, что найдётся.

Ну и в идеале надо обновить движок. Злодеи всякие, бывает, пробую заново залезть на те сайты, что у них отобрали. Если движок древний, то залезут опять.

shell-script ★★★★★ ()
Ответ на: комментарий от BaBL

Это полный ССЗБ, если у вас через дырку в сайте можно получить доступ к системе.

Это вопрос владельца сайта. Одно дело, если под сайт взят VPS, а если просто apache virtual host ? apache virtual host не предоставлять ? Так, увы, спрос рождает предложение. Другой вопрос, что следует отдельно и внимательно прорабатывать ограничения и рассматривать риски эскалации привилегий, придумывать средства контроля (хотя, на самом деле, эти средства давно придуманы, надо только использовать). А «однозначная переустановка», для такой системы - это полный бред.

AS ★★★★★ ()
Ответ на: комментарий от chenger

На 127.0.0.0/8 не получится, только на какой-нибудь маршрутизируемый ip-адрес. Пакеты от 127.0.0.0/8 могут идти только на 127.0.0.0/8, пакеты с других адресов будут признаны марсианскими.

state в DNAT добавлять не нужно, там и так приходит только первый пакет (state == NEW).

А так это вполне подойдёт ТС, в DNAT правило добавить перенаправление порта, засунуть в OUTPUT. На этом порту запустить отдельный http-сервер и смотреть его логи. Перед DNAT правилом сделать -j ACCEPT правила для адресов, куда можно ходить серверу.

mky ★★★★★ ()
Ответ на: комментарий от mky

Спасибо за корректировку, давно настраивал iptables, да и с сетью возился подзабыл.

chenger ★★ ()
Ответ на: комментарий от AS

Это вопрос владельца сайта. Одно дело, если под сайт взят VPS, а если просто apache virtual host ? apache virtual host не предоставлять ? Так, увы, спрос рождает предложение. Другой вопрос, что следует отдельно и внимательно прорабатывать ограничения и рассматривать риски эскалации привилегий, придумывать средства контроля (хотя, на самом деле, эти средства давно придуманы, надо только использовать). А «однозначная переустановка», для такой системы - это полный бред.

Как же это вопрос владельца сайта, если ты предоставляешь услугу на сервере? Сайт - это клиент, а клиенты априори считаются тупыми марсианами. Для владельца сервера есть множество инструментов: chroot, LXC, есть apache2-mpm-itk в конце концов. На настройку PHP так же требуется немного времени потратить, open_basedir и disable_functions хотя бы.

Я потому и пишу что это ССЗБ, судя по постам у ТС как раз голые вхосты, единый юзер для всех и не факт что не рут при этом. Полностью ситуация не описана, но указано что на сервер влезли => скомпрометирован. Буквально в прошлом году все проверялись на руткиты, подменяющие системные утилиты, в таких условиях я бы не рисковал лишний раз, благо хостинг переустановить не так сложно.

BaBL ★★★★★ ()
Ответ на: комментарий от BaBL

судя по постам у ТС как раз голые вхосты, единый юзер для всех и не факт что не рут при этом.

Это было бы совсем неаккуратно... Надеюсь, там не такой расклад. Просто и с apache2-mpm-itk не всегда просто найти именно тот сайт, который поломали. Хотя, вообще, при большом левом трафике, я бы с просмотра процессов в top начал. Есть шанс, что сразу что-то попадётся.

Буквально в прошлом году все проверялись на руткиты, подменяющие системные утилиты

Если регулярно проверять контрольные суммы файлов, это всё ловится. Но да, не пост фактум, надо заранее готовиться.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Это было бы совсем неаккуратно... Надеюсь, там не такой расклад. Просто и с apache2-mpm-itk не всегда просто найти именно тот сайт, который поломали. Хотя, вообще, при большом левом трафике, я бы с просмотра процессов в top начал. Есть шанс, что сразу что-то попадётся.

вот тут 50 на 50. Если там попадется что-то отличное от /usr/bin/php - то это уже явно на переустановку. А если не попадется, то где гарантии? Вон, выбирай какой больше нравится:
http://www.ussrback.com/UNIX/penetration/rootkits/

У половины:

Includes trojaned chfn, chsh, inetd, login, ls, du, ifconfig, netstat, passwd, ps, top, rshd, syslod, tcpd, etc.

BaBL ★★★★★ ()
Ответ на: комментарий от AS

Для этого надо, чтобы система был с local root. А это, всё же, не часто происходит. Так что, вероятнее всего, что всё происходит от пользователя.

это известных local-root уязвимостей с работающим эксплоитом не так уж много, а сколько их у тех кто разводит ботнеты - никто не знает.

и да, как регулярная проверка контрольных сумм спасет, если файл подменят между этими проверками и заставят юзерспейс считать, что файл остался прежним?

maloi ★★★★★ ()
Ответ на: комментарий от maloi

а сколько их у тех кто разводит ботнеты - никто не знает.

Да почти нисколько. Процентов 90% ботов попадает на виртуальный хост вполне законным методом: с известным логином/паролем. А вот метод получения логина/пароля - другой вопрос. Но это уже воровство у пользователя с окошками, как правило. Смысла делать что-то иное нет - виндопользователей вагон, на всех хватит. Оставшиеся 10% - уязвимости в CMS. Какая-то неуловимая часть процента, может быть, что-то хитрое. Мне не попадалось в живом виде. Но, может, и прямо сейчас тихо живёт. ;-)

и да, как регулярная проверка контрольных сумм спасет, если файл подменят
между этими проверками и заставят юзерспейс считать

Да как хочешь. Можно прицепить по nfs к другому хосту и на нём проверять. Юрерспейс хоть опподменяйся, это будет не тот юзерспейс. Или этот зоопарк разводи в OpenVZ контейнере (одном). Оверхед у ovz маленький, а проверять из хост-системы.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)

создай виртуальный интерфейс перекинь на него трафик его и фильтруй, хотя смысла нет...

тебе надо сравнить хэши всех исполняемых файлов с базой если делал, ну и для профилактики проверь все исполняемые файлы есть ли они в составе дистрибутива...

lsof пользуй тоже может поможет... netstat тоже посмотри...

litlemil ()

Ох-ох! О чём спор, ребят?

Rkhunter и chkrootkit работают со времён установки системы - на почту ничего не валилось о проблемах. Свежеустановленный clamav тоже ничего не дал по прогону.

На апаче виртуальные хосты с suexec и с обёртками для php.

В процессах соответственно тоже ничего не висит, кроме как по http к серверу не добраться снаружи - всё закрыто и разрешено только для избранных.

Поэтому если это уязвимость, то это уязвимость в цмс-ке клиента (очень высокий процент), или же в апаче (что исключаю).

По логам апача всё походит на это Залезли на сервер, нужен совет как найти заразу. (комментарий) , и найденные файлы тоже.

Клиента с его джумалой перекинули со своего сервера на другого хостера.

А сейчас надо просто, подробно следить за активностью на сервере, т.к. перед тем как переустанавливать нужно найти причину проблемы.

Всем спасибо за советы :)

IPFreely ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.