aelfwine пишет:

Не смотрел. Крутится.

Последний вопрос - под каким юзером крутится апач?

А ведь хороший вопрос. Вот что получилось за выходные (естественно мой процесс только один - первый):

ps aux|grep httpd
root      8474  0.0  0.4 281940 18476 ?        Ss   May07   0:00 /usr/sbin/httpd
apache   19483  0.0  0.6 295868 26068 ?        S    May10   0:03 /usr/sbin/httpd
apache   20263  0.0  0.6 296928 26036 ?        S    May10   0:03 /usr/sbin/httpd
apache   20264  0.0  0.6 294748 24212 ?        S    May10   0:03 /usr/sbin/httpd
apache   20313  0.0  0.5 294728 24188 ?        S    May10   0:02 /usr/sbin/httpd
apache   22193  0.0  0.5 293412 23364 ?        S    00:01   0:02 /usr/sbin/httpd
apache   22400  0.0  0.5 293404 22780 ?        S    00:32   0:01 /usr/sbin/httpd
apache   22401  0.0  0.5 294596 23448 ?        S    00:32   0:02 /usr/sbin/httpd
apache   22402  0.0  0.6 294748 24632 ?        S    00:32   0:02 /usr/sbin/httpd
apache   22403  0.0  0.5 293588 23268 ?        S    00:32   0:02 /usr/sbin/httpd
apache   22404  0.0  0.5 293600 23244 ?        S    00:32   0:02 /usr/sbin/httpd
apache   22405  0.0  0.6 298940 27220 ?        S    00:32   0:02 /usr/sbin/httpd
apache   23376  0.0  0.5 294560 24024 ?        S    02:50   0:01 /usr/sbin/httpd
apache   23423  0.0  0.5 292416 21124 ?        S    02:58   0:01 /usr/sbin/httpd
apache   23984  0.0  0.5 294612 23932 ?        S    03:20   0:01 /usr/sbin/httpd
apache   24427  0.0  0.5 292584 22392 ?        S    04:24   0:01 /usr/sbin/httpd
apache   25468  0.0  0.5 292576 22188 ?        S    06:52   0:00 /usr/sbin/httpd
apache   25469  0.0  0.5 291420 20488 ?        S    06:52   0:00 /usr/sbin/httpd
apache   25470  0.0  0.5 292568 21872 ?        S    06:52   0:00 /usr/sbin/httpd
root     26537  0.0  0.0  61152   720 pts/0    S+   09:11   0:00 grep httpd

Не смотрел. Крутится.

Последний вопрос - под каким юзером крутится апач?

zerg пишет:

Третье - узнать у LanBiling о наличии уязвимостей на предмет удалённого контроля/исполнения кода в вашей версии.

aelfwine, не смотрели? ВебИнтрфейса LB на этом серваке крутился?

Не смотрел. Крутится.

Третье - узнать у LanBiling о наличии уязвимостей на предмет удалённого контроля/исполнения кода в вашей версии.

aelfwine, не смотрели? ВебИнтрфейса LB на этом серваке крутился?

Первое, что приходит на ум... У Вас там на заднем плане много portmap'а висит. Файлики от имени рута появляются. NFS проверяли?

portmap прибил, равно как и все остальное
NFS не проверял

bind запущен от другого имени, не от root.

э-э а вы знаете кто такой

62.32.173.244:senip

??=)

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

не знаю, возможно.

Пароль менял, да. Причем не только у рута, не помогло. Ключи перегенерял, лишних нет. На последний вопрос ответить не так просто. Увидев что /etc/passwd имеет свежую дату изменения, а рядом некий /etc/passwd- месячной давности (видимо тогда произошел взлом), поставил passwd- на место passwd, хоть и взглядом разницы не увидел. Раньше может и был такой пользователь.

О таком аспекте не подумал, разумно.

Это связь в одну сторону. Смской софт не обновишь и пароль не поменяешь.

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

Угу, спасибо.
ЗЫ: если есть shadow-, то значит вышеупомянутый passwd- тоже не левый был?

Лишнего там - только сервер игрульки, остальное по делу все и кушает ресурсов немного. Для нескольких компьютеров надо больше гарантированного электропитания, а это тоже деньги.

угу. я не про то, кто сколько кушает, а про то, что каждый сервис - это лишняя дыра. и проникнув в вашу систему через ЛЮБУЮ дыру, враг захватывает ВСЁ. А всякие M$овские протоколы расшарки (ака самба) - не слишком секьюрные вещи - они просто так проектировались...

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

ладно. вот примерная последовательность действий:
1) отрубить сеть
2) сменить ВСЕ пароли системы (список юзеров смотрите в /etc/shadow- )
3) обновите/переустановите ВСЕ демоны для работы с сетью (их не так уж и много)
4) полностью отключите sudo
5) закройте ВСЕ порты
6) запретите в sshd вход от рута, смените порт, отключите первый протокол, запретите любой вход кроме как по ключу.
7) ну и включайте демоны по одному, открывая для каждого свой порт. и логи читайте, особенно смотрите, кто и куда заходит.

удачи...

??=)
я вообще не очень разбираюсь что куда но

sshd    17389 root    3r  FIFO       0,6         445063959 pipe
sshd    17389 root    4u  IPv6 445063860               TCP xxx.xxx.xxx.xxx:s
sshd    17389 root    5w  FIFO       0,6         445063959 pipe

это типа что-то куда то копируется?)
ещё по поводу паролей рута и т.д

и вроде выше вы писали что пароль рута поменяли (как мне кажется).
Мб наиваное предположение но у вас случаем в /etc/passwd не появлялось лишних пользователей с ID и группой 0?

P.S ради интереса полистал про N3tshell v. Emp3ror Undetectable #18. как я понял это эксплойт для Joomla ( я так понял какой то система управления вед сайтом) а мб и не для Joomla просто много ссылок было с этим связанно)

aelfwine пишет:

А, просто rkhunter ругается на вполне стандартные сервисы, посчитал что вы о них.

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

Лишнего там - только сервер игрульки, остальное по делу все и кушает ресурсов немного. Для нескольких компьютеров надо больше гарантированного электропитания, а это тоже деньги.

Прибил все незнакомое, оставил только необходимое.

Круто, полезный совет. Нашел следующее:

lsof -w -n -i | grep sshd
sshd     17389   root    4u  IPv6 445063860       TCP xxx.xxx.xxx.xxx:ssh->62.32.173.244:senip (ESTABLISHED)

lsof -p 17389
COMMAND   PID USER   FD   TYPE    DEVICE    SIZE      NODE NAME
sshd    17389 root  cwd    DIR       8,3    4096         2 /
sshd    17389 root  rtd    DIR       8,3    4096         2 /
sshd    17389 root  txt    REG       8,3  293792 160307960 /usr/sbin/sshd
sshd    17389 root  mem    REG       8,3  134400  64520263 /lib64/ld-2.5.so
sshd    17389 root  mem    REG       8,3 1699880  64520499 /lib64/libc-2.5.so
sshd    17389 root  mem    REG       8,3   23360  64520519 /lib64/libdl-2.5.so
sshd    17389 root  mem    REG       8,3   85608 160307940 /usr/lib64/libz.so.1.2.3
sshd    17389 root  mem    REG       8,3  114352  64520517 /lib64/libnsl-2.5.so
sshd    17389 root  mem    REG       8,3   48600  64520520 /lib64/libcrypt-2.5.so
sshd    17389 root  mem    REG       8,3   18152  64520521 /lib64/libutil-2.5.so
sshd    17389 root  mem    REG       8,3 1366176  11403275 /lib64/libcrypto.so.0.9.8e
sshd    17389 root  mem    REG       8,3   53880  64520219 /lib64/libnss_files-2
sshd    17389 root  DEL    REG       0,8         445063868 /dev/zero
sshd    17389 root  DEL    REG       0,8         445063958 /dev/zero
sshd    17389 root    0u   CHR       1,3              1618 /dev/null
sshd    17389 root    1u   CHR       1,3              1618 /dev/null
sshd    17389 root    2u   CHR       1,3              1618 /dev/null
sshd    17389 root    3r  FIFO       0,6         445063959 pipe
sshd    17389 root    4u  IPv6 445063860               TCP xxx.xxx.xxx.xxx:s
sshd    17389 root    5w  FIFO       0,6         445063959 pipe
sshd    17389 root    6u   CHR       5,2               899 /dev/ptmx
sshd    17389 root    7u   CHR       5,2               899 /dev/ptmx
sshd    17389 root    8u   CHR       5,2               899 /dev/ptmx

Тоже интересно. Есть предполагаемая дата взлома, от неё смотрю измененные файлы, подозрительные вещи есть, анализирую.

А вот этот комментарий непонятен. Сервера то нон-стоп уже третий год, но не силой же мысли рулить.

Напакостили, повредили многое. В конце концов закрыл на маршрутизаторе все соединения к этому серверу, кроме самых нужных портов.

Для взлома использовали в т.ч. N3tshell v. Emp3ror Undetectable #18. Говорит кому-нибудь название?

Жизнь на сервере тем не менее осталась, порой появляются исходящие соединения с сервера от процесса "-", но без pid. Как это может быть? Например:
netstat -lpn

udp        0      0 0.0.0.0:4359                0.0.0.0:*                               -

Так уж получилось что не был в интернете сутки (есть вещи важнее работы).
Как следствие - пароли не менял, софт не обновлял. Прибил только процессы которые не знал за что отвечают (portmap, xinetd, rpc.statd). Судя по всему не помогло. Файлов новых не появилось, но chkrootkit оказался удаленным.

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

я тоже не бываю в инете сутками. но то - я. это не относится к моим серверам... они в сети постоянно...

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

можно ли как то отследить по процессам команду с помощью которой они появились?

можно найти все новые файлы - для этого достаточно найти все каталоги, которые изменились за последние N минут - в них-то и лежат новые файлы. Их также можно отыскать командой find, хотя нет "времени создания", но есть нижняя граница этого времени. а была и ещё какая-то команда для этого... не помню...

lsof -w -n -i

- далее идти по PID`ам и смотреть какие процессы используют создаваемые файлы.
т.е
lsof -p 8132|grep php

lsof -p 8132

ну или какие процессы используют подозрительные файлы.

P.S ну или можно написать простой скрипт который по выводу lsof пройдётся.

P.P.S кстать я тут задумался на тему появления этих фалов, если они появляются можно ли как то отследить по процессам команду с помощью которой они появились?.. желательно с PID, а по этому PID уже смотеть кто его запустил, а потому кто его запустил смотреть какие файлы он использовал и т.д=)

P. s. Да и заодно посмотреть может у Вас ключи его лежат с его ip.