drBatty пишет:aelfwine пишет:А, просто rkhunter ругается на вполне стандартные сервисы, посчитал что вы о них.
и о них - тоже. во первых - у вас сервисов слишком много навешано. вы не думали, что есть смысл разделить это всё по отдельным компьютерам? например сделать отдельную файлопомойку на самбе? раз она вам так нужна...
Лишнего там - только сервер игрульки, остальное по делу все и кушает ресурсов немного. Для нескольких компьютеров надо больше гарантированного электропитания, а это тоже деньги.
drBatty пишет:aelfwine пишет:Малые знания linuxа пока не дают ответа должны ли висеть и слушать сеть процессы portmap, xinetd, rpc.statd. Гугл просветления пока тоже не дал.
xinetd нужен для запуска демонов "по запросу". т.е. например если вам нужен FTP, но очень редко, то его имеет смысл запускать только тогда, когда к нему кто-то попросит доступ.
Про остальное уже сказали...
Прибил все незнакомое, оставил только необходимое.
tmp13 пишет:Столько написали даже страшно чёт вставить)
ну как вариант если что-то куда то лезет посмотреть
- далее идти по PID`ам и смотреть какие процессы используют создаваемые файлы.
т.е
lsof -p 8132|grep php
ну или какие процессы используют подозрительные файлы.
...
P.P.S кстать я тут задумался на тему появления этих фалов, если они появляются можно ли как то отследить по процессам команду с помощью которой они появились?.. желательно с PID, а по этому PID уже смотеть кто его запустил, а потому кто его запустил смотреть какие файлы он использовал и т.д=)
Круто, полезный совет. Нашел следующее:
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
drBatty пишет:можно найти все новые файлы - для этого достаточно найти все каталоги, которые изменились за последние N минут - в них-то и лежат новые файлы. Их также можно отыскать командой find, хотя нет "времени создания", но есть нижняя граница этого времени. а была и ещё какая-то команда для этого... не помню...
Тоже интересно. Есть предполагаемая дата взлома, от неё смотрю измененные файлы, подозрительные вещи есть, анализирую.
drBatty пишет:я тоже не бываю в инете сутками. но то - я. это не относится к моим серверам... они в сети постоянно...
А вот этот комментарий непонятен. Сервера то нон-стоп уже третий год, но не силой же мысли рулить.
Напакостили, повредили многое. В конце концов закрыл на маршрутизаторе все соединения к этому серверу, кроме самых нужных портов.
Для взлома использовали в т.ч. N3tshell v. Emp3ror Undetectable #18. Говорит кому-нибудь название?
Жизнь на сервере тем не менее осталась, порой появляются исходящие соединения с сервера от процесса "-", но без pid. Как это может быть? Например:
netstat -lpn
udp 0 0 0.0.0.0:4359 0.0.0.0:* -
