LINUX.ORG.RU
Форум — Admin  

SSHD и панамские боты

 ,


1

8

Всем привет. Мои странности выглядят следующим образом: в какой-то момент на серваке с FreeBSD 9.1-RELEASE перестает отвечать sshd. Вот так: 

$ ssh -v srv
OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to srv [192.168.0.5] port 22.
debug1: Connection established.
debug1: identity file /home/komintern/.ssh/id_rsa type -1
debug1: identity file /home/komintern/.ssh/id_rsa-cert type -1
debug1: identity file /home/komintern/.ssh/id_dsa type -1
debug1: identity file /home/komintern/.ssh/id_dsa-cert type -1
debug1: identity file /home/komintern/.ssh/id_ecdsa type -1
debug1: identity file /home/komintern/.ssh/id_ecdsa-cert type -1
Дальше замирает и висит. Начал анализировать что же делает sshd. Выявил интересную картину, итак:
lsof -p по парент-процессу sshd: 
sshd    940 root    3u  IPv4 0xfffffe0198bbc3d0      0t0    TCP *:ssh (LISTEN)
sshd    940 root    4u  IPv4 0xfffffe02f182fb70      0t0    TCP srv:64810->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root    5u  IPv4 0xfffffe04c1eedb70      0t0    TCP srv:50593->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root    6u  IPv4 0xfffffe06530077a0      0t0    TCP srv:61666->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root    7u  IPv4 0xfffffe01c9e517a0      0t0    TCP srv:12042->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root    8u  IPv4 0xfffffe042c7e9b70      0t0    TCP srv:31370->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root    9u  IPv4 0xfffffe0381fc63d0      0t0    TCP srv:64563->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   10u  IPv4 0xfffffe03f92bb3d0      0t0    TCP srv:64565->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   11u  IPv4 0xfffffe07effba3d0      0t0    TCP srv:64566->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   12u  IPv4 0xfffffe01798353d0      0t0    TCP srv:10607->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   13u  IPv4 0xfffffe06a51ea000      0t0    TCP srv:64569->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   14u  IPv4 0xfffffe06cca01b70      0t0    TCP srv:10614->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   15u  IPv4 0xfffffe057c7267a0      0t0    TCP srv:10616->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
sshd    940 root   16u  IPv4 0xfffffe015b0277a0      0t0    TCP srv:12066->193.255.191.181.rdns.panamaserver.com:http (CLOSED)
в общем дохрена таких соединений CLOSED. очень много.

sockstat: 

root     sshd       940   3  tcp4   *:22                  *:*
root     sshd       940   4  tcp4   192.168.0.5:64810   181.191.255.193:80
root     sshd       940   5  tcp4   192.168.0.5:50593   181.191.255.193:80
root     sshd       940   6  tcp4   192.168.0.5:61666   181.191.255.193:80
root     sshd       940   7  tcp4   192.168.0.5:12042   181.191.255.193:80
root     sshd       940   8  tcp4   192.168.0.5:31370   181.191.255.193:80
root     sshd       940   9  tcp4   192.168.0.5:64563   181.191.255.193:80
root     sshd       940   10 tcp4   192.168.0.5:64565   181.191.255.193:80
root     sshd       940   11 tcp4   192.168.0.5:64566   181.191.255.193:80
root     sshd       940   12 tcp4   192.168.0.5:10607   181.191.255.193:80
root     sshd       940   13 tcp4   192.168.0.5:64569   181.191.255.193:80
root     sshd       940   14 tcp4   192.168.0.5:10614   181.191.255.193:80
root     sshd       940   15 tcp4   192.168.0.5:10616   181.191.255.193:80
root     sshd       940   16 tcp4   192.168.0.5:12066   181.191.255.193:80
root     sshd       940   17 tcp4   192.168.0.5:12072   181.191.255.193:80
root     sshd       940   18 tcp4   192.168.0.5:45528   181.191.255.193:80
root     sshd       940   19 tcp4   192.168.0.5:46683   181.191.255.193:80
root     sshd       940   20 tcp4   192.168.0.5:46687   181.191.255.193:80
в общем опять же куча таких вот сокетов.

netstat: 

tcp4       0      0 192.168.0.5.15718    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.52468    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.29572    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.16004    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.63611    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.63610    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.63609    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.51769    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.51764    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.51763    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.51761    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.51752    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.51751    181.191.255.193.80     CLOSED
tcp4       0      0 192.168.0.5.33789    181.191.255.193.80     CLOSED

При этом, на сервере установлен fail2ban, в логах которого данный адрес никак не фигурирует. Вопрос: с чем я столкнулся? Это лечится перезапуском sshd, но каким образом этот странный панамский бот мог повесить мне демона? Благодарен за любые мысли по теме.

★★★★★

Последнее исправление: Komintern (всего исправлений: 1)
← Strongswan: как запретить нешифрованные пакеты?
cacti и права доступа →
  1 2 →
Ответ на: комментарий от xtraeft

в моем случае я таки действительно мог бы накатить патчи, которые товарищ указал в этом посте SSHD и панамские боты (комментарий) если бы был подписан на рассылку. особенно патч на openssl. это ж не считается 0-day, если патч вышел до того как хост взломали =(

Komintern ★★★★★
() автор топика
Последнее исправление: Komintern (всего исправлений: 1)
Ответ на: комментарий от Komintern

я и не про твой случай говорил, а об отсутствии 100% гарантии безопасности даже при своевременной установке обновлений

xtraeft ★★☆☆
()
Ответ на: комментарий от xtraeft

причем тут твоя слака?

при том, что в ней никто не бежит впереди паровоза. Например почитай про дыру в ядре 3.8 (в слаке тогда было 3.7 даже в курренте)

если ты не знаешь, что апдейты не дают 100% гарантии безопасности, то лучше не позорься в очередной раз

100% гарантии даёт только морг.

drBatty ★★
()
Ответ на: комментарий от drBatty

100% гарантии даёт только морг.

На Гоголя гарантии он выдавал ?

PS: Сына LOL ... в роду или хотят б среди знакомых медики то есть ?

anonymous
()
Ответ на: комментарий от anonymous

На Гоголя гарантии он выдавал ?

ты про легенду о том, что его живого хоронили? вот что нашёл: http://www.ngogol.ru/death/

Чтобы понять ее несостоятельность, достаточно вдуматься в следующий факт. Эксгумация проводилась спустя почти 80 лет после захоронения. При таких сроках от тела остаются лишь костные структуры, не связанные друг с другом. А гроб и обивка изменяются настолько, что определить какое-либо «исцарапывание изнутри» совершенно невозможно.

мои преподаватели, которые меня учили литературе, тоже считали эту байку - байкой, а не фактом. Хотя конечно куда им до анонимуса с ЛОРа…

в роду или хотят б среди знакомых медики то есть ?

есть. От них и услышал эту присказку. Речь обычно о развитие болезни идёт, а гарантии даёт только патологоанатом. Вот у них и спроси.

В нашем случае, я и без тебя знаю, что 100% гарантии апдейты не дают. Однако речь о том, что без них тебя поломают со 100% гарантией. А вот с ними - вряд-ли. Школьники про 0day не знают, а более-менее знающие люди тебя ломать не станут(это довольно дорого). Посему, если у тебя скажем debian stable, или Slackware, или скажем релиз RHEL, то гарантии есть. Если конечно апдейты ты ставишь вовремя. А если у тебя федора - извините.

drBatty ★★
()
Ответ на: комментарий от drBatty

ты про легенду о том, что его живого хоронили?

Сына, летаргия вполне реальное заболевание. Без относительно Гоголя.

мои преподаватели, которые меня учили литературе, тоже считали эту байку - байкой, а не фактом.

Дядь - в морге работают не литераторы, хотя в твоем случае - может и они.

есть. От них и услышал эту присказку.

Именно что присказку. Такие дела сына. Есть еще одна популярная присказка - здоровых людей не существует, есть недообследованные. Осилишь экстрапальнуть данную присказку на проблему безопасности в ИТ ? Как только что сделал первой присказкой ?

Речь обычно о развитие болезни идёт, а гарантии даёт только патологоанатом.

Поменьше рассуждай о том не имеешь понятия. Хотя бы о безопасности.

anonymous
()
Ответ на: комментарий от drBatty

Посему, если у тебя скажем debian stable, или Slackware, или скажем релиз RHEL, то гарантии есть. Если конечно апдейты ты ставишь вовремя. А если у тебя федора - извините.

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

Однако ж, поломали.

Хотя, я тоже думаю, что это был троян на путти коллег-виндузятников.

moot ★★★★
()
Ответ на: комментарий от moot

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

довольно быстро попадают секьюрные апдейты в stable Linux. За несколько часов/дней после опубликования дыры. Но это в Linux, а про фряху я не в курсе.

вот тебе, что-бы не быть голословным пример:

критичный баг в ФФ: http://www.mozilla.org/security/announce/2013/mfsa2013-36.html April 2, 2013

Исправление в слаке: http://slackware.com/security/viewer.php?l=slackware-security&y=2013&... Wed, 3 Apr 2013

И это слака, где маинтейнер вообще один. Очевидно, в других дистрах ещё быстрее.

Ну а большинство глюков в stable просто тупо не попадает, а исправляются ещё в тестинге. Ну как последняя дыра в ядре 3.8.

Однако ж, поломали.

дык я про проблемы 0day в дистрибутивах, а у ТСа там ещё куча быдлокода на php. В этих скриптах баги пачками каждый день ловят, что твой ФФ. И если он держит их на сервере - ССЗБ.

Хотя, я тоже думаю, что это был троян на путти коллег-виндузятников.

наличие таких коллег снимает вопрос ЛЮБЫХ мониторингов безопасности. Если у них есть доступ root, то о безопасности можно не думать. Только мечтать.

drBatty ★★
()
Ответ на: комментарий от Komintern

с путти и судо.

а им точно надо ВСЕ права? Наверняка, они выполняют одно-два действия, и их можно выполнить, написав один-два скрипта. Тогда можно настроить sudo на выполнение ЭТИМИ юзерами ЭТИХ скриптов. А вот rm -rf и руткит уже не прокатит.

drBatty ★★
()
Ответ на: комментарий от drBatty

я за другое подумал. на GNU Linux у людей было, причем массово - один в один моя ситуация:
http://www.opennet.ru/opennews/art.shtml?num=36155
При этом linux compat я не ставил, стоит только это:
compat6x-amd64-6.4.604000.200810_3

Учитывая:

Имеется подозрение, что атака совершается через неисправленную 0-day уязвимость в одном из доступных по сети сервисов.

венда путти может быть не при чем. щас читаю коменты. хотя нет. причем ))

Komintern ★★★★★
() автор топика
Последнее исправление: Komintern (всего исправлений: 1)
Ответ на: комментарий от Komintern

венда путти может быть не при чем. щас читаю коменты. хотя нет. причем

Дополнение 2: Появилась информация, что ряд аккаунтов был взломан в результате утечки паролей клиентов компании cPanel, используемых службой поддержки для удалённой диагностики проблем. Кроме того пароли перехватывались через установку троянского ПО на системы Windows.

ну как я и говорил - кривые глючные php скрипты (cpanel ещё и закрытая и платная) и/или венда затрояненая.

drBatty ★★
()
Ответ на: комментарий от Komintern

ну вот это:

Имеется подозрение, что атака совершается через неисправленную 0-day уязвимость в одном из доступных по сети сервисов.

вообще глупость

xtraeft ★★☆☆
()
6 июня 2013 г.

такая же проблема на Centos 6 

 netstat -pantu | grep SERVER_IP
tcp        1      0 SERVER_IP:49998         181.191.255.193:80          CLOSE_WAIT  1357/sshd
tcp        1      0 SERVER_IP:49996         181.191.255.193:80          CLOSE_WAIT  1357/sshd
tcp        1      0 SERVER_IP:57742         181.191.255.193:80          CLOSE_WAIT  1357/sshd
tcp        1      0 SERVER_IP:57745         181.191.255.193:80          CLOSE_WAIT  1357/sshd
tcp        1      0 SERVER_IP:57739         181.191.255.193:80          CLOSE_WAIT  1357/sshd

#ls -la /proc/1357/ | grep exe
lrwxrwxrwx   1 root root 0 Jun  6 11:50 exe -> /usr/sbin/sshd

нашел в /boot/lost+found/nginx-0.8.54/ исходники nginx непонятные.

самое интересное это сервер с виртуализацией Openvz, и там на главный сервер кроме ssh ничего не было по идее. (есть подозрение что все-таки через putty)

в папке /boot/lost+found/sbin/httpd был бинарник, который слушал 443 порт, если зайти по https там форма входа с логином и паролем ...

по логам ssh входа с других IP не было (хотя если бы и были они бы наверное почистили за собой)

то есть, это не только проблема freebsd, скорее винда + Putty. Это счастье нашел на двух серверах - на одном после обновления, блокировки портов, смены пароля больше не появилось. А на втором через денек снова в /boot/lost+found/sbin/httpd появился. Как только заблокировал порт 443 - само пропало, при перезагрузке пропадает потом появляется ...

nimdaxunil
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← Strongswan: как запретить нешифрованные пакеты?
Admin
cacti и права доступа →