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

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

Вполне. man iproute2:

 netns  - manage network namespaces

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

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

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

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

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

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

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

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

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

на сервере Debian wheezy

дальше не читал
//и зараза, имеется ввиду кто? организатор?

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

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

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

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

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

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

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

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

Прогон по 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 логам совпадения есть.

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

джумала

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

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

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

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

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

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

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

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

На 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 правила для адресов, куда можно ходить серверу.

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

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

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

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

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

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

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

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

Это было бы совсем неаккуратно... Надеюсь, там не такой расклад. Просто и с 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.

http://www.ussrback.com/UNIX/penetration/rootkits/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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