Место для Вашей рекламы всего за 400 рублей в месяц ! email:incognito.anonimous@yandex.ru

Спонсор проекта
Лучший вариант для анонимности купить прокси на выделенном сервере IPANN.NET.
Ads



Последние комментарии
#1
Александр пишет: » Про себя расскажу, купил первый свой дистрибутив L... (13.02.2020)
// Переход с Windows на Linux - ГЛУПОСТЬ
#2
admin пишет: » Александр, я перепробовал немало конвертеров под л... (02.02.2020)
// 28 причин почему GNU/Linux не имеет будущего
#3
Александр пишет: » Всё верно, к примеру мне не хватает конвертера ауд... (01.02.2020)
// 28 причин почему GNU/Linux не имеет будущего
#4
admin пишет: » Ну и где это ваше будущее ? Уже прошёл четвёртый г... (29.01.2020)
// 28 причин почему GNU/Linux не имеет будущего
#5
admin пишет: » иван, аргументы давай (28.01.2020)
// 28 причин почему GNU/Linux не имеет будущего
#6
watersoda пишет: » А с другой стороны, какой смысл в МСВС 5.0, когда ... (12.11.2017)
// Обзор и попытка установки МСВС 5.0
#7
X_perienced пишет: » А какое именно оборудование там подерживается - го... (25.08.2017)
// Обзор и попытка установки МСВС 5.0
#8
Linups_Troolvalds пишет: » Хватит писать бред. МСВС (возможно) не работает на... (24.07.2017)
// Обзор и попытка установки МСВС 5.0
#9
watersoda пишет: » Да и RHEL под "Эльбрус" не помешал бы... (19.03.2017)
// Обзор и попытка установки МСВС 5.0
#10
watersoda пишет: » Небольшая поправка: ... через соответствующий паке... (19.03.2017)
// Обзор и попытка установки МСВС 5.0
Quotes
--OS X это POSIX? --угу...без букавак P и I

Разбор последствий взлома Linux-хостов выявил странную активность, связанную с OpenSSH | автор: Luca | 1 декабря 2011

Категория: GNU/Linux

В блоге Лаборатории Касперского появилась заметка с разбором последствий взлома двух Linux-хостов, используемых злоумышленниками для управления Windows-машинами, пораженными троянским ПО Duqu. Хосты были представлены для анализа после того, как злоумышленники пытаясь замести следы, удалили содержимое директорий "/var/log" и "/root" с серверов. Так как данные были очищены через простое удаление файлов без обнуления областей диска, проанализировав остаточные данные на дисковых разделах удалось достаточно полно восстановить активность после взлома.


Из всей активности злоумышленников наибольший интерес вызывают операции, связанные с OpenSSH, которым трудно найти логическое объяснение. На обоих хостах атакующие сразу после проникновения по каким-то причинам обновили OpenSSH с версии 4.3 до версии 5.x. На первом сервере в качестве обновления были использованы исходные тексты пакета openssh_5.8p1-4ubuntu1.debian.tar.gz из репозиториев Ubuntu, троянских вставок клиенте и сервере ssh не обнаружено (MD5-хэш копии соответствовал оригиналу). Спустя 5 месяцев было установлено обновление OpenSSH 5.8p2. На втором сервере новая версия была установлена из стандартного репозитория (yum install openssh5). После обновления в настройки "sshd_config" были добавлены две строки "GSSAPIAuthentication yes" и "UseDNS no" (обе опции прекрасно поддерживаются и в версии 4.3).

В настоящее время можно только предполагать, зачем атакующие после взлома обновили OpenSSH. Одна из гипотез указывает на вероятное наличие в OpenSSH 4.3 уязвимости, через которую злоумышленники проникли в систему и потом решили закрыть лазейку для других атакующих. Например, в OpenSSH 4.4 была устранена потенциальная уязвимость, проявляющаяся до стадии аутентификации и связанная с GSSAPI (активность в логе, напоминающая подбор пароля, может быть связана с достижением нужных условий "race condition"). Вторая, более правдоподобная гипотеза, связана с тем, что злоумышленникам понадобились какие-то функции, поддержка которых отсутствовала в OpenSSH 4.3 (например, появившийся в версии 5.4 режим netcat мог использоваться для создания вложенных туннелей). Но в любом случае не понятно зачем было нужно выполнять обновление OpenSSH 5.8p1 до версии 5.8p2.

В качестве наиболее вероятного способа проникновения в систему рассматривается результат атаки по подбору пароля для пользователя root, которому был разрешён вход по SSH. В пользу этого предположения свидетельствует череда неудачных попыток входа, окончившихся удачным входом. Против данной гипотезы указывает то, что пароль был подобран после относительно небольшого числа попыток и перед первым удачным входом был восьмиминутный перерыв (после удачного применения эксплоита атакующий мог сменить пароль и войти штатными средствами).

Кроме двух упомянутых в статье серверов, аналогичные системы были выявлены в Индии, Вьетнаме, Германии, Сингапуре, Великобритании и других странах. Взлом серверов был произведён ещё в ноябре 2009 года. Опасение также вызывает тот факт, что все управляющие работой Duqu серверы были взломаны аналогичным образом и работали только под CentOS 5.x (5.4, 5.5 и 5.2). Возможно для атаки использовался какой-то эксплоит, рассчитанный на поражение CentOS.

источник


Голосов: 12


Прочитано 4027 раз и оставлено 33 комментариев.


Комментарии посетителей

#1. Apollo 11

Luca написал:
В качестве наиболее вероятного способа проникновения в систему рассматривается результат атаки по подбору пароля для пользователя root, которому был разрешён вход по SSH.


Шыкарно!

#2. zg13

линукс безопасности нехватает одного - дружащих с головой линуксоидов.

#3. pavel2403

pavel2403
zg13, плюсую!!!
Ну так проблема была в OpenSSH! При чем тут Linux?

#5. pavel2403

pavel2403
Кантрабас написал:
Ну так проблема была в OpenSSH! При чем тут Linux?
да-да, Linux не причем, OpenSSH <>Linux!!! Линух это ведь только ядро!!!

#6. MOP3E

Кантрабас написал:
Ну так проблема была в OpenSSH! При чем тут Linux?

А вот в винде никакого OpenSSH нет!
Кантрабас написал:
Ну так проблема была в OpenSSH! При чем тут Linux?
[qoute=Топик]Возможно для атаки использовался какой-то эксплоит, рассчитанный на поражение CentOS.[/quote]
Тьфу, опечатался. =) Ну, да и так понятно. =)
Кантрабас написал:
Ну так проблема была в OpenSSH! При чем тут Linux?

Вот как раз GNU/Linux причемsmile . А одно ядро линукс само по себе нигде не применяется. Да и если из ядра выколупать сторонние модули поддержки оборудования - то что останется еще может глючить? (хотя калькулятор в убунту глючит ведь smile, так что наверное может)

#10. selenscy

Вообще то фишка в этом статье более интересная, если проследить цепочку дальше....
Троянец Duqu наследник Stuxnet, сначала ломают линупс сервер который, как я понял и засылает троянца жертве в составе ботнета из других линупс серверов. Хитро...

#11. selenscy

#12. nixadmin

Кантрабас написал:
Ну так проблема была в OpenSSH!


А пруфы будут? А то из статьи это как-то не прослеживается.

Цитата:
В качестве наиболее вероятного способа проникновения в систему рассматривается результат атаки по подбору пароля для пользователя root


MOP3E написал:
А вот в винде никакого OpenSSH нет!

Да ну?
Википедия написал:

SSH-серверы
* Windows: freeSSHd, copssh, WinSSHD, KpyM Telnet/SSH Server, MobaSSH, OpenSSH через Cygwin
дохтур
nixadmin написал:
Да ну?
Кто этим (под виндой) в реальности пользуется, кроме линуксоидов?

#14. selenscy

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

#16. SDSM

Я бы на месте администраторов этих серверов вообще пароль бы на рута не ставил - а зачем, если линукс такой безопасный?
А если не троллить толсто, то эффект обезьяны с гранатой никто не отменял.
Удалённый вход от пользователя root, это по дефолту отключено (по крайней мере в альте). То есть, восстанавливаем картину.
У админа на серевере линукс, админу как то пох№р на безопасность сервера и он вообще "в линуксах не разбирается", настраивает он ssh по мануалу и видит, зачем париться лишний раз повышая права (su-) или вводить sudo, если можно разрешить доступ из под рута. Он его разрешает и ему удобно.
Цитата:
Он его разрешает и ему удобно.

Ты так говоришь, как будто так не поступают все остальные линупсоиды. "Надаела вадить пороль" - одна из популярнейших тем на том же убунту.ру. Красноглазые хомяки - истинные хозяева линупса up

#19. msAVA

msAVA
Penis Trollvalds написал:
"Надаела вадить пороль" - одна из популярнейших тем на том же убунту.ру.

Справедливости ради: попытка сделать Бубунту удобной для вчерашних виндузятников привела к тому, что Бубунту стала неудобны для линуксоидов, но не стала удобной для виндузятников.

#20. selenscy

А вы тут мир собираетесь завоевать со своими поделиями biggrin biggrin biggrin

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

#21. MOP3E

nixadmin написал:
OpenSSH через Cygwin

Под линухом можно MSO через Wine юзать, дык никто же не говорит, что в линухе есть MSO.

#22. selenscy

Как то я поставил этот тихий ужас - OpenSSH через Cygwin. Это же п...ец полный!
Penis Trollvalds написал:

Ты так говоришь, как будто так не поступают все остальные линупсоиды. "Надаела вадить пороль" - одна из популярнейших тем на том же убунту.ру. Красноглазые хомяки - истинные хозяева линупса

Знаешь ли, надоел уже это ярлык "линуксоиды". Как будто всех пользователей линукса под одну гребёнку чешут.
В данном случае мы знаем что админ совершил глупость, а значит он либо проявил халатность (от ПО этот человеческий фактор зависит мало) либо просто взялся за то что неумеет, а именно за настройку linux-сервера.
дохтур
SDSM написал:
Я бы на месте администраторов этих серверов вообще пароль бы на рута не ставил
SSH (равно как и RDP надо заметить) не даст подключиться под учёткой с пустым паролем :P

#25. selenscy

дохтур написал:
Знаешь ли, надоел уже это ярлык "линуксоиды". Как будто всех пользователей линукса под одну гребёнку чешут.


ВрутЪ значит про супер-мега-чЮдо-ось?

штульманоподjибные с апполошеипанутыми? smile
Решето!!

#27. rmn

Дерьмо собачье этот линукс и ведроид вместе с ним.

#28. rmn

shhh
rmn написал:
Дерьмо собачье этот линукс и ведроид вместе с ним.

Его делал Дерьмос Собачес!!

#30. MOP3E

дохтур написал:
SSH не даст подключиться под учёткой с пустым паролем :P

Вот именно! Не ставим на рута пароль и хр№н кто по SSH зайдёт на сервер!
дохтур написал:
под учёткой с пустым паролем :P

Есть изящное решение, называется 123

MOP3E написал:
Вот именно! Не ставим на рута пароль и хр№н кто по SSH зайдёт на сервер!


Это содержимое /etc/openssh/sshd_config "по умолчанию"
<br />#	$OpenBSD: sshd_config,v 1.80 2008/07/02 02:24:18 djm Exp $<br /><br /># This is the sshd server system-wide configuration file.  See<br /># sshd_config(5) for more information.<br /><br /># This sshd was compiled with PATH=/bin:/usr/bin:/usr/local/bin<br /><br /># The strategy used for options in the default sshd_config shipped with<br /># OpenSSH is to specify options with their default value where<br /># possible, but leave them commented.  Uncommented options change a<br /># default value.<br /><br />#Port 22<br />#Protocol 2<br />#AddressFamily any<br />#ListenAddress 0.0.0.0<br />#ListenAddress ::<br /><br /># HostKey for protocol version 1<br />#HostKey /etc/openssh/ssh_host_key<br /># HostKeys for protocol version 2<br />#HostKey /etc/openssh/ssh_host_rsa_key<br />#HostKey /etc/openssh/ssh_host_dsa_key<br /><br /># Lifetime and size of ephemeral version 1 server key<br />#KeyRegenerationInterval 1h<br />#ServerKeyBits 1024<br /><br /># Logging<br /># obsoletes QuietMode and FascistLogging<br />#SyslogFacility AUTHPRIV<br />#LogLevel INFO<br /><br /># Authentication:<br /><br />#LoginGraceTime 2m<br />#PermitRootLogin without-password<br />#StrictModes yes<br />#MaxAuthTries 6<br />#MaxSessions 10<br /><br />#RSAAuthentication yes<br />#PubkeyAuthentication yes<br />#AuthorizedKeysFile	.ssh/authorized_keys<br /><br /># For this to work you will also need host keys in /etc/openssh/ssh_known_hosts<br />#RhostsRSAAuthentication no<br /># similar for protocol version 2<br />#HostbasedAuthentication no<br /># Change to yes if you don't trust ~/.ssh/known_hosts for<br /># RhostsRSAAuthentication and HostbasedAuthentication<br />#IgnoreUserKnownHosts no<br /># Don't read the user's ~/.rhosts and ~/.shosts files<br />#IgnoreRhosts yes<br /><br /># To disable tunneled clear text passwords, change to no here!<br />#PasswordAuthentication yes<br />#PermitEmptyPasswords no<br /><br /># Change to yes to enable s/key passwords<br />#ChallengeResponseAuthentication no<br /><br /># Kerberos options<br />#KerberosAuthentication no<br />#KerberosOrLocalPasswd yes<br />#KerberosTicketCleanup yes<br />#KerberosGetAFSToken no<br /><br /># GSSAPI options<br />#GSSAPIAuthentication no<br />#GSSAPICleanupCredentials yes<br /><br /># Set this to 'yes' to enable PAM authentication, account processing, <br /># and session processing. If this is enabled, PAM authentication will <br /># be allowed through the ChallengeResponseAuthentication and<br /># PasswordAuthentication.  Depending on your PAM configuration,<br /># PAM authentication via ChallengeResponseAuthentication may bypass<br /># the setting of "PermitRootLogin without-password".<br /># If you just want the PAM account and session checks to run without<br /># PAM authentication, then enable this but set PasswordAuthentication<br /># and ChallengeResponseAuthentication to 'no'.<br />#UsePAM yes<br /><br />#AllowAgentForwarding yes<br />#AllowTcpForwarding yes<br />#GatewayPorts no<br />#X11Forwarding yes<br />#X11DisplayOffset 10<br />#X11UseLocalhost yes<br />#PrintMotd yes<br />#PrintLastLog yes<br />#TCPKeepAlive yes<br />#UseLogin no<br />#UsePrivilegeSeparation yes<br />#PermitUserEnvironment no<br />#Compression delayed<br />#ClientAliveInterval 0<br />#ClientAliveCountMax 3<br />#UseDNS yes<br />#PidFile /var/run/sshd.pid<br />#MaxStartups 10:30:20<br />#PermitTunnel no<br />#ChrootDirectory none<br /><br /># no default banner path<br />#Banner none<br /><br /># override default of no subsystems<br />#Subsystem	sftp	/usr/lib/openssh/sftp-server<br /><br /># Accept locale environment variables<br />AcceptEnv LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE<br />AcceptEnv LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY<br />AcceptEnv LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME<br /><br /># Example of overriding settings on a per-user basis<br />#Match User anoncvs<br />#	X11Forwarding yes<br />#	AllowTcpForwarding no<br />#	ForceCommand cvs server<br />


Обратите внимание на
#PermitRootLogin without-password

Как должны видеть эксперты уровня СЛОРа, эта строка закоментирована. Вопрос в том насколько нужно пл.хо разбираться в безопасности UNIX систем дабы эту строку раскоментировать?

#32. MOP3E

Гареев Станислав написал:
Вопрос в том насколько нужно пл.хо разбираться в безопасности UNIX систем дабы эту строку раскоментировать?

Мандавойд, ты сам-то хоть в чём-то разбираешься? Короче, лучше кончай нести х.йню в массы и займись полезным трудом. Например, сантехником пойди работать. Или, если квалификации не хватает - хотя бы дворником.

#33. AxaRu

Apollo 11 написал:
Шыкарно!

"Жи", "Ши" пишы через "ы"

Гареев Станислав написал:
эта строка закоментирована

Гы-ы-ы... А там все закоментировано. Точно далбаебы. Они чо? Так над юзерами линупс прикалываются?

Добавление комментария:

Имя:
Пароль: (если зарегистрирован)
Email: (обязательно!)

теги форматирования

добавить смайлы
 

Правила комментирования >>