CentOS, CSF, cPanel, sshd, очень интересная история :)

Romka_Kharkov
На сайте с 08.04.2009
Offline
485
2056

День добрый,

Исходные данные, без расшифровок cPanel Server, CSF, sshd процессы.

Centos 5.8 (64bit)

2.6.18-308.13.1.el5 #1 SMP Tue Aug 21 17:10:18 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux


]# ps auxw|grep nobody|grep ssh
root 12145 0.0 0.0 74892 2336 ? Ss Sep12 0:00 sshd: nobody [priv]
root 12146 0.0 0.0 74892 2332 ? Ss Sep12 0:00 sshd: nobody [priv]
root 12147 0.0 0.0 74892 2336 ? Ss Sep12 0:00 sshd: nobody [priv]
sshd 12149 0.0 0.0 48008 1028 ? S Sep12 0:00 sshd: nobody [net]
sshd 12150 0.0 0.0 48008 1028 ? S Sep12 0:00 sshd: nobody [net]
sshd 12151 0.0 0.0 48008 1020 ? S Sep12 0:00 sshd: nobody [net]

# date
Thu Sep 13 18:42:46 EDT 2012

Смотрю процесс:


# lsof -p 12147
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 12147 root cwd DIR 9,0 4096 2 /
sshd 12147 root rtd DIR 9,0 4096 2 /
sshd 12147 root txt REG 9,0 507824 137271 /usr/sbin/sshd
sshd 12147 root mem REG 9,0 144776 196644 /lib64/ld-2.5.so
sshd 12147 root mem REG 9,0 1718232 196656 /lib64/libc-2.5.so
sshd 12147 root mem REG 9,0 23360 196686 /lib64/libdl-2.5.so
sshd 12147 root mem REG 9,0 85544 196728 /lib64/libz.so.1.2.3
sshd 12147 root mem REG 9,0 95464 196778 /lib64/libselinux.so.1
sshd 12147 root mem REG 9,0 247496 196777 /lib64/libsepol.so.1
sshd 12147 root mem REG 9,0 18152 196708 /lib64/libutil-2.5.so
sshd 12147 root mem REG 9,0 48600 196702 /lib64/libcrypt-2.5.so
sshd 12147 root mem REG 9,0 114352 196682 /lib64/libnsl-2.5.so
sshd 12147 root mem REG 9,0 92816 196680 /lib64/libresolv-2.5.so
sshd 12147 root mem REG 9,0 9472 196727 /lib64/libkeyutils-1.2.so
sshd 12147 root mem REG 9,0 10096 197120 /lib64/libcom_err.so.2.1
sshd 12147 root mem REG 9,0 98920 197102 /lib64/libaudit.so.0.0.0
sshd 12147 root mem REG 9,0 190976 140691 /usr/lib64/libgssapi_krb5.so.2.2
sshd 12147 root mem REG 9,0 613928 140690 /usr/lib64/libkrb5.so.3.3
sshd 12147 root mem REG 9,0 35984 140688 /usr/lib64/libkrb5support.so.0.1
sshd 12147 root mem REG 9,0 1367232 197121 /lib64/libcrypto.so.0.9.8e
sshd 12147 root mem REG 9,0 153720 140689 /usr/lib64/libk5crypto.so.3.1
sshd 12147 root mem REG 9,0 46800 197107 /lib64/libpam.so.0.81.5
sshd 12147 root mem REG 9,0 53880 196816 /lib64/libnss_files-2.5.so
sshd 12147 root mem REG 9,0 23736 196814 /lib64/libnss_dns-2.5.so
sshd 12147 root DEL REG 0,9 48136182 /dev/zero
sshd 12147 root DEL REG 0,9 48136183 /dev/zero
sshd 12147 root mem REG 9,0 11504 330372 /lib64/security/pam_env.so
sshd 12147 root mem REG 9,0 14297 330315 /lib64/security/pam_hulk.so
sshd 12147 root mem REG 9,0 48824 330397 /lib64/security/pam_unix.so
sshd 12147 root mem REG 9,0 40896 132859 /usr/lib64/libcrack.so.2.8.0
sshd 12147 root mem REG 9,0 12272 329496 /lib64/security/pam_succeed_if.so
sshd 12147 root mem REG 9,0 4040 330369 /lib64/security/pam_deny.so
sshd 12147 root mem REG 9,0 5648 329480 /lib64/security/pam_nologin.so
sshd 12147 root mem REG 9,0 4416 330381 /lib64/security/pam_permit.so
sshd 12147 root mem REG 9,0 12928 329453 /lib64/security/pam_cracklib.so
sshd 12147 root mem REG 9,0 6808 329470 /lib64/security/pam_keyinit.so
sshd 12147 root mem REG 9,0 15048 330376 /lib64/security/pam_limits.so
sshd 12147 root mem REG 9,0 6584 329473 /lib64/security/pam_loginuid.so
sshd 12147 root mem REG 9,0 5408 329491 /lib64/security/pam_shells.so
sshd 12147 root 0u CHR 1,3 0t0 1955 /dev/null
sshd 12147 root 1u CHR 1,3 0t0 1955 /dev/null
sshd 12147 root 2u CHR 1,3 0t0 1955 /dev/null
sshd 12147 root 3u IPv4 48136139 0t0 TCP 98.142.242.112:ssh->subscribe.arttour.ru:59273 (ESTABLISHED)
sshd 12147 root 5w FIFO 0,6 0t0 48136140 pipe
sshd 12147 root 6u unix 0xffff81029ccffc80 0t0 48136181 socket

Первая мысль, думаю капец, проломали сервер, честно :D потом начал осматриваться, tcpdump host 91.205.189.15 - 0 .... ваще ничего ... думаю, как же тогда ESTABLISHED если за 10 минут ни одного пакета..... лезу в логи:


Sep 12 23:14:51 core16 sshd[12142]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.205.189.15 user=nobody
Sep 12 23:14:52 core16 sshd[12145]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.205.189.15 user=nobody
Sep 12 23:14:52 core16 sshd[12147]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.205.189.15 user=nobody
Sep 12 23:14:52 core16 sshd[12146]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=91.205.189.15 user=nobody
Sep 12 23:14:53 core16 sshd[12142]: Failed password for nobody from 91.205.189.15 port 49117 ssh2
Sep 12 23:14:54 core16 sshd[12145]: Failed password for nobody from 91.205.189.15 port 39823 ssh2
Sep 12 23:14:54 core16 sshd[12147]: Failed password for nobody from 91.205.189.15 port 59273 ssh2
Sep 12 23:14:54 core16 sshd[12146]: Failed password for nobody from 91.205.189.15 port 54946 ssh2

Соответственно брутфорс, и я плавно прихожу к выводу:


# iptables -L -x -v -n |grep -i 91.205.189.15
80 6028 DROP all -- !lo * 91.205.189.15 0.0.0.0/0
1789 248204 DROP all -- * !lo 0.0.0.0/0 91.205.189.15

>>


# grep -rin 91.205.189.15 .
./csf.deny:114:91.205.189.15 # lfd: (sshd) Failed SSH login from 91.205.189.15 (RU/Russian Federation/subscribe.arttour.ru): 5 in the last 300 secs - Wed Sep 12 23:14:54 2012
./csf.tempip:9:91.205.189.15|1|1347506094

Собственно вопрос, какого хрена !!! SShd процесс который отвечал на эту попытку брутфорса... висит около суток !!! так еще и в состоянии ESTABLISHED?

Я так понимаю это уже проблема не sshd :) ? а состояния соединения.... ;) ? Причем как видно из ipables, по сути этот процесс еще и пытается контачить ту сторону... видимо он нарывается на ответ файрвола, по этому смыслу:


# ping 91.205.189.15
PING 91.205.189.15 (91.205.189.15) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

и шлет, шлет.... шлет.... ?:)

Баг :D ? (По факту получилось так, что мой файрвол сейчас сдерживает трафик от меня же в сторону этого брутфорсера.... :) Реально можно расценить как атаку изнутри...... :)))) )

Спасибо :D

IP не стал прятать так как реально с него брутят :D Может кто узнает свой в нем - проверьтесь на вирусы :D

Есть около 15.000 ipv4 !!! (http://onyx.net.ua/price.php#ipv4) Качественный хостинг с 2005 года - лучшее клиентам! (http://onyx.net.ua/)
N
На сайте с 06.05.2007
Offline
419
#1
Romka_Kharkov:
начал осматриваться, tcpdump host 91.205.189.15 - 0 .... ваще ничего ... думаю, как же тогда ESTABLISHED если за 10 минут ни одного пакета.....

строго говоря, tcpdump не гарантирует захвата всех пакетов прошедших по интерфейсу.

Если всякие параметры ядра типа net.ipv4.tcp_* хорошенько задрать вверх, то соединения могут провисеть довольно долго.

Ну и баг, разумеется, не нужно исключать - это же centos5, где все давно протухло.

Кнопка вызова админа ()
M
На сайте с 16.09.2009
Offline
278
#2

Вы покажите как именно блокируется IP. Т.е. цепочку правил целиком, которую проходит запрос при попадении в этот DROP (в INPUT и OUTPUT, соответственно).

Периодически сталкиваюсь, что "фильтруют", к примеру, TCP-соединения только в --state NEW для INPUT.

Абонементное сопровождение серверов (Debian) Отправить личное сообщение (), написать письмо ().
N
На сайте с 06.05.2007
Offline
419
#3
myhand:
Периодически сталкиваюсь, что "фильтруют", к примеру, TCP-соединения только в --state NEW для INPUT.

И вполне оправдано. Все равно эти люди не сознательно трафик экономят, а занимаются "повышением секурности" хостинга с помощью такой фигни как блокирование ssh.

M
На сайте с 16.09.2009
Offline
278
#4
netwind:
И вполне оправдано.

Технически - это ошибка. В результате которой мы, видимо, в данном случае и наблюдаем что наблюдаем.

PS: Филозофский вопрос зачем оно надо - оставляю за кадром.

N
На сайте с 06.05.2007
Offline
419
#5

Судя по размышлениям ТС, в его случае - ошибка.

Но другие люди могут делать подобную настройку вполне осознанно. ssh обычно рвет соединение при N неправильных попытках входа. Не провисит такое соединение долго.

Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#6

myhand, полагаю, что все как вы и сказали, есть фильтрующие правила по state NEW, видимо тут и проблема, приходить запрос приходит, потом ИП csf лочит, и обратка уже не возвращается, но до сих пор не понимаю, почему процесс sshd не отмирает после х времени , даже если он при этом пытается отвечать, должен же сработать какой-то таймаут? Или выходит , что новое соединение нельзя установить, а старое типа будет жить?

M
На сайте с 16.09.2009
Offline
278
#7
Romka_Kharkov:
почему процесс sshd не отмирает после х времени

Зависит в первую очередь от настроек собственно sshd.

Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#8
myhand:
Зависит в первую очередь от настроек собственно sshd.

Я там настроек про таймауты не помню, Grace login разве что , но это как бы на вход на сколько я понимаю.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий