В публичном доступе появился рабочий эксплойт, позволяющи получить удаленно рута в FreeBSD, если там запущен ftpd или proftpd. Более подробная информация по ссылке http://lists.grok.org.uk/pipermail/full-disclosure/2011-November/084372.html

Для запуска требуется указать логин и пароль юзера, который имеет chroot в ftpd и которому разрешено создавать в этом корне файлы /etc/nsswitch.conf и /lib/nss_compat.so.1. Туда заливается код, заливает туда код, который, будучи запущенным от рута, через ptrace подключается к inetd/syslogd/cron вне chroot и внедряет в них код, который открывает TCP-коннект от рута обратно к машине атакующего на заранее указанный порт, который там должен слушать nc -l или аналог и даёт root shell уже вне chroot. Подгружает /lib/nss_compat.so.1 сама libc, в ней уязвимость.

Против взлома кроме фильтрации доступа к порту 21 или через /etc/hosts.allow, ещё помогает либо полностью запретить юзеру запись в свой домашний каталог (можно оставить право на запись в существующие подкаталоги), либо запретить создавать /etc/nsswitch.conf и /lib/nss_compat.so.1 в домашнем каталоге юзера: touch etc lib && chflags uchg etc lib

Для штатного ftpd и ftp-пользователей, не имеющих другого доступа на запись к своему домашнему каталогу (через samba/http/whatever) есть и другое временное решение, не требующее что-либо менять в домашних каталогах пользователей: патч на ftpd, позволяющий администратору задавать гибкие ограничения в зависимости от логина пользователя и IP-сети, из которой он подключился. Он доступен по ссылке ttp://www.grosbein.net/freebsd/patches/ftpd-restr-0.2.tbz

После приложения патча, для защиты от данной дырки:

В /etc/login.conf поменять для класса default строчку:
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
на строчку:
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,NOMKD=/etc=0.0.0.0/0;/lib=0.0.0.0/0:\
Перегенерировать /etc/login.db командой cap_mkdb /etc/login.conf
После этого через ftpd будет нельзя создавать каталоги /etc и /lib и как временное решение это позволит спокойно прожить до официального исправления.

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

awk -F: '{print $6}' /etc/passwd | sort -u | xargs -n 1 -I . sh -c '[ -d . ] && [ ! -O . ] && cd . && touch etc lib && chflags uchg etc lib'

Будьте бдительны!

Для этого достаточно в письме указать заголовок:

rcpt to: root+:"|whoami"

Подробности по ссылке.

К наиболее популярным атакам без сомнения можно отнести этот популярный способ, когда веб-сервер переполняется запросами от ботов и не может нормально обслуживать запросы посетителей.
В результате такой атаки сайт становится недоступным, а с серверной стороны можно наблюдать рост нагрузки на сервер, большое число процессов веб-сервера и конечно, значительный рост коннектов. Если атака будет очень сильной и паразитный трафик превысит пропускную способность канала к серверу, то на него нельзя будет зайти по ssh.
Но столь сильные атаки — редкость, так как 10-20Mbps такого трафика вполне способны свалить неподготовленный сервер.

Способов борьбы с такими атаками очень много, как программных так и аппаратных. Кроме этого существуют отдельные сервисы, которые «чистят» трафик, присылая только легальные запросы.
Я же хочу рассмотреть очень простой и элегантный способ борьбы, для которого нам потребуется nginx и iptables с модулем string.
Слабое место ботов в том, что они не понимают кукисы. На этой особенности и основана моя система защиты. Мы будем передавать на все запросы к веб-серверу «печеньку», и разделять трафик на легальный и мусорный, основываясь именно на этом параметре.
Сначала нужно будет спрятать веб-сервер, например повесив на 8080 порт, а на его место поставить быстрый nginx, и сконфигурировать страницу-заглушку. В качестве примера подойдет стандартный конфиг nginx, единственное, что нужно сделать — добавить cookie, дописав в конфиге nginx:
<b>add_header Set-Cookie "type=this-is-not-bot";</b>

На самой странице-заглушке можно написать нечто вроде «Извините, сайт под DDOS, включите кукисы в браузере и нажмите на ссылку для перехода».
Когда посетитель откроет такую страницу, то при следующем запросе он передаст эту «печеньку», на основе которой можно направить трафик к спрятанному веб-серверу:
<b>iptables -t nat -A PREROUTING -p tcp --dport 80 -m string --string "this-is-not-bot" --algo kmp -j REDIRECT --to-ports 8080</b>

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

Ожидали чего-то более сложного? Извините...

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

Корень проблемы: UDP

Прежде чем описать очередную возможную интернет атаку со стороны конкурентов, я бы хотел сначала немного углубится в UDP, а точнее в его проблемную область: информация об IP адресе отправителя в UDP может быть легко подделана!
Я небуду рассказывать всех нюансов, но это точно такая же проблема, как и заголовок From в email, они существуют и им нельзя доверять.

Проблема была бы легко решена, если бы каждый провайдер перед отправлением UDP «в мир» отсекал все поддельные (спуфленные) UDP на маршрутеризаторе. Причем технически это сделать не сложнее, чем настроить в почтовом сервере запрет отправки email с поддельным адресом отправителя. Увы, ISP в нашем мире далеки от идеала.

Говорят, что в Парижской Палате Мер и Весов где-то есть Идеальный Провайдер. Он дает канал на 1Gbps на 1 год за 1 рубль. Он хранится под стеклом и его нельзя трогать руками.

Так вот, для своей работы DNS использует TCP и UDP. Причем, если размер информации будет меньше 512 байт, то она будет отправлена по UDP. Все бы хорошо, DNS будут работать быстро, для UDP можно выделить отдельную полосу, так как он легче TCP.

Но есть один момент. Если отправить специально сформированный запрос размером в 17 байт к DNS серверу и подставить IP жертвы, то жертва в ответ получит ответ в 500 байт! Причем, что самое печальное, в интернете масса DNS серверов с открытой рекурсией, что позволяет использовать их для атаки!
Я не шучу, таких серверов действительно очень много. Обычно популярные панели для управления хостингом, такие как WHM, Plesk, DirectAdmin и ISPManager устанавливают DNS и оставлют открытым рекурсивные запросы. А таких хостингов в интернете много, очень много!

Атака на DNS: как это бывает

Итак, у Вас есть некий сайт, к нему положен домен, а к доменам — DNS сервера. Обычно хостер дает свои DNS сервера и вы просто прописываете их в домене. Предположим, хостер выдал 2 DNS: dns1.hoster.ru и dns2.hoster.ru.

Злоумышленник смотрит, на каких IP стоят эти DNS серверы и намечает их в качестве жертвы.
После этого он при помощи поисковых систем ищет хостинги с панелями, которые устанавливает DNS с открытой рекурсией и собирает базу.
Затем покупает самый дешевый хостинг за 1$ с открытыми сокетами и начинает рассылать фальшивые DNS запросы в которых установлен IP адрес жертвы.

К чему это приводит? Подсчитать очень просто. Предположим, скрипт рассылает запросы со скоростью 2Mbps. Так как серверы обычно подключены к 100Mbps порту, то хостеры просто ничего не замечают. Несложно посчитать, что при соотношении 17:500 сила выхлопа информационного мусора составит примерно 58Mbps.

А если злоумышленник накупит таких хостингов в числе 10 штук? Это уже примерно под 500Mbps!
Канал хостера к DNS будет физически забит столь большим трафиком, что DNS сервера перестанут получать запросы от легальных пользователей и отвечать на них. Сайт перестанет работать. И стоимость такой атаки составит всего десять долларов!

Как защитить свой домен от DNS атак

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

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

Нет ничего проще. Сначала вам нужно узнать на каком адресе находится сайт и почта. Для этого используйте команду host:

<strong>$host habrahabr.ru</strong>

habrahabr.ru has address 62.213.122.2
habrahabr.ru mail is handled by 10 aspmx4.googlemail.com.
habrahabr.ru mail is handled by 10 aspmx5.googlemail.com.
habrahabr.ru mail is handled by 1 aspmx.l.google.com.
habrahabr.ru mail is handled by 5 alt1.aspmx.l.google.com.
habrahabr.ru mail is handled by 5 alt2.aspmx.l.google.com.
habrahabr.ru mail is handled by 10 aspmx2.googlemail.com.
habrahabr.ru mail is handled by 10 aspmx3.googlemail.com.

В ответе мы получили адрес сайта и адреса почтовых серверов домена. Теперь укажите в DNS wildcard запись A (она еще может называться @) на адрес сайта (в этом примере — 62.213.122.2), и создайте почтовые записи MX, куда пропишите почтовые сервера (в этом примере — почта на Google).

Теперь ваш сайт станет более надежным к подобного рода атакам. Однако есть еще один совет, который поможет сделать ваш домен практически 100% надежным к подобного рода атакам.

«Одна голова хорошо — а три лучше» © Змей Горыныч

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

Между прочим, правилом хорошего тона является регистрация домена в популярных зонах — RU, COM, NET, ORG. Посмотрите как это делает Google.

Например, основной домен для своего проекта вы выбрали в зоне COM у европейского регистратора. Пусть это будет domain.com.

Теперь зарегистрируйте еще domain.ru например у nic.ru и domain.net у какого-то западного регистратора, например — directi. В доменных записях domain.ru и domain.net создайте набор DNS записей по тому же принципу что и выше, а потом обязательно зарегистрируйте эти домены в качестве DNS серверов. Некоторые регистраторы делают это сами, у других это делается через панель, а третьим надо писать в техподдержку.
А теперь, внимание, никакого мошенничества — только ловкость рук, смените DNS сервера у домена domain.com на domain.ru и domain.net!

Проверьте, что при запросе NS серверов действительно выдаются нужные нам домены:

<strong>$host -t ns domain.com</strong>

domain.com name server domain.ru.
domain.com name server domain.net.

Отлично! Теперь DNS поддерживают сразу два независимых регистратора. С такой защитой вашему домену вряд-ли будет грозить какая-то неприятность. Ну а если вы хотите, то можете продолжить систему — зарегистрировать еще больше доменов в разных зонах и у разных регистраторов. А потом установить их всех в качестве DNS для вашего основного домена.

Надеюсь, что мой совет поможет вам сделать свой домен более защищенным от DNS атак.

Я продолжаю тему атаки конкурентов на ваши сайты, и сейчас хочу рассказать о более сложной и более серьезной атаке, так называемый Mail Bounce DDOS.

Но сначала я хочу немного рассказать про один из способов, которым спаммеры собирают себе базы ящиков для спама.
Спаммеры бывают разные, и базы у них тоже разные. Некоторые собирают их по сайтам с помощью самописных краулеров. Другие — методом перебора вычисляют существующие почтовые ящики. А третьи, назовем их элитными, хотя это слово для спаммеров не примлемо, собирают базу реальных, живых людей, которые получают и читают спам.

Сначала спаммер выбирает несколько доменов-жертв, как правило, сервисов бесплатной почты локальных интернет-провайдеров, многие из которых имеют недостаточные средства для фильтрации спама. Причем выбирают как правило по регионам, чтоб сразу получить региональную базу потенциальных жертв.
Затем, пользуясь особенностью провайдеров, которые так или иначе «засвечивают» логины своих клиентов, генерирует список email-адресов вида логин@почтовый.сервер.isp.

Как именно ISP могут подсказать спаммеру логины своих клиентов?
Например, многие создают бесплатный хостинг для своих клиентов в виде логин.сервер.isp или сервер.isp/~логин. У многих логины на форуме ISP совпадают с их реальными логинами почтовых ящиков. И наконец, если ISP выдает реальный IP, то он очень часто имеет реверсивную запись DNS PTR в виде логин.сервер.isp

Итак, сначала спаммер находит недорогие хостинги, на которых открыты исходящие соединения от скриптов на 25-й порт удаленных серверов и c помощью скрипта dm.cgiначинает рассылку писем, причем каждое письмо снабжается уникальной ссылкой, по которой надо кликнуть, якобы для отписки от рассылки.
Нечего и говорить, что кликая по таким ссылкам, человек подтверждает то, что у него этот ящик рабочий и более того — на нем не фильтруется спам. Следовательно, такой человек будет получать и читать спам-письма, особенно если их содержимое как-то причастно к его региону.

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

Вместо того, чтоб тратить время и трафик на сбор базы логинов, малограмотный спаммер просто берет домены провайдеров и генерит списоквероятных ящиков по словарю. Один словарь спаммера может содержать в среднем 50 000 часто встречающихся логинов.

Рассылка по подобным базам приводит к тому, что в среднем на каждые 100 писем, только одно доходит до адресата, а остальные будут несуществующими. И это приводит к тому, что все эти письма начинают возвращаться отправителю. И тут происходит самое интересное!

Адрес отправителя можно указать какой угодно, в том числе и адрес и поток оповещений о недоставленных письмах хлынет лавиной в тысячи мусорных писем, забивающих ящик и перегружающий почтовый сервер. Не каждый хостер сможет выдержать подобную атаку и скорее всего заблокирует на время прием почты, а в худшем случае — вообще временно отключит сайт, так как поток Mail Bounce может достигать 100Mbps и полностью забивать канал к серверу.

Самое печальное, что несмотря на кажущуюся сложность, такой вариант будет в результате очень дешев и эффективен для конкурента:

• Скрипт рассылки спама dm.cgi тысячами копий лежит на файлообменниках и скачать его не составит никакого труда
• Множество дешевых хостингов, использующих популярные системы управления хостингом, таких как: cPanel/WHM,Plesk,DirectAdmin,ISPManager — по умолчанию позволяют подобным скриптам расслыку спама напрямую через сокеты, и наспамить по 50 000 адресов c такого хостинга можно меньше чем за 1$
• Многие почтовые сервера ISP игнорируют SPF и DomainKeys

Что же делать, чтоб избежать или хотя-бы смягчить последствия Mail Bounce DDOS?

Ну и наконец я могу предложить абсолютно бесплатно перенести почту кGoogle Mail, хотя это принесет ряд ограничений — например, число ящиков не более 50, есть лимит на отправку сообщений. Зато Google Mail отлично фильтрует подобного рода атаки. А если вдруг ограничения не устроят, то за 50$ в год вы получите надежную почтовую систему.

Порой приходится хранить ценную информацию, к которой никто не должен иметь доступа. Но в тоже самое время необходимо пользоваться услугами системных администраторов.

Как же быть? Как сохранить свои данные в целости и сохранности? И тут на помощь приходит шифрование файловых систем. Я расскажу только про две из них — LUKS и CryptoFS.

Следует отметить, что LUKS отлично работает на Linux, а CrytopFS — на FreeBSD.

LUKS

dd if=/dev/urandom of=luks.img bs=1M count=100
losetup /dev/loop0 luks.img
cryptsetup luksFormat /dev/loop0
cryptsetup luksOpen /dev/loop0 luks
mkfs.ext3 /dev/mapper/luks
mkdir /luks
mount /dev/mapper/luks /luks

Для последующего включения:

losetup /dev/loop0 luks.img

cryptsetup luksOpen /dev/loop0 luks

mount /dev/mapper/luks /luks

CryptoFS

mkdir /usr/local/cfs /cfs
cp /usr/local/share/doc/cryptofs/cryptofs.conf /usr/local/cfs/.cryptofs
cryptofs -r /usr/local/cfs /cfs

Подключать потом:

cryptofs -r /usr/local/cfs /cfs

Вывод:

LUKS позволяет выбрать тип файловой системы, но использует блочное устройство, а CryptoFS использует текущую файловую систему для шифрования. CryptoFS ощутимо быстрее, а LUKS гибче.

Что именно использовать — решать вам.

И да, самая надежная защита — это репутация вашего системного администратора.

luks.img

Linux Zombie

Ко мне поступил сервер, выполняющий роль коммерческого хостинга сайтов, который был взломан и взломщики не потрудились вытереть за собой все инструменты, которые они использовали.
Проанализировав их, я смог составить цепочку событий, которая привела к взлому сервера и компрометации рутовой учетной записи.
Никаких логов небыло, так как они все были почищены, так что взломщик не оставил за собой следов, и я начал поистине детективное расследование — с уликами и подозреваемыми.

Как сообщает Przemyslaw Frasunek, известный специалист в сфере безопасности, в ядре FreeBSD 6.x обнаружена уязвимость, позволяющая получить права root любому непревлилгированному процесу.
Уязвимость была найдена в интерфейсе уведомлений о событиях kqueue, которая приводит к разыменованию null-указателя в в ядре. Рабочий эксплойт позволяет запускать любой процесс с привилегиями root, разместив его в странице памяти с указателем на этот адрес — 0×0.

Информация об уязвимости поступила в сообщество FreeBSD 29 Августа 2009 года, но была проигнорирована.

К сожалению неясно, в каких точно версиях имеется эта уязвимость. Изначально были затронуты версии 6.0-6.4, но мне удалось успешно запустить эксплоит на версии 7.2.

Учитывая, что в nginx недавно была обнаружена уязвимость, позволяющая удаленно выполнять запуск кода с правами nginx, комбинация этих двух уязвимостей может привести к тому, что на FreeBSD с работающим nginx будет скомпроментирован root.

Источник информации.

P.S. По этическим причинам ссылка на рабочий эксплоит убрана с блога.

P.P.S. По просьбам посетителей опубликован патч ядра FreeBSD:

/*
Patch for this vulnerability, as in CVS:

--- src/sys/kern/kern_descrip.c	2006/09/04 10:30:09	1.279.2.8
+++ src/sys/kern/kern_descrip.c	2006/09/29 18:30:48	1.279.2.9
@@ -35,7 +35,7 @@
  */

 #include <sys/cdefs.h>
-__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_descrip.c,v 1.279.2.8 2006/09/04 10:30:09 pjd Exp $");
+__FBSDID("$FreeBSD: /usr/local/www/cvsroot/FreeBSD/src/sys/kern/kern_descrip.c,v 1.279.2.9 2006/09/29 18:30:48 jmg Exp $");

 #include "opt_compat.h"
 #include "opt_ddb.h"
@@ -2602,7 +2602,7 @@ static int
 badfo_kqfilter(struct file *fp, struct knote *kn)
 {

-	return (0);
+	return (EBADF);
 }
 static int
*/

Сервер без бекапа

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

Копирование данных с продакшен-сервера на backup-сервер

Продакшен-сервер – это рабочий сервер, который выполняет какие либо сервисы для пользователей.
backup-сервер – это сервер на который копируется контент с продакшен-сервера. Единственное предназначение такого сервера – хранить данные с других серверов. Обычно сам он никаких сервисов не выполняет. Главное требование – большое дисковое пространство. Скорость дисковых
накопителей особого значения не имеет, так как доступ к данным не частый – записать бекап на диск и считать его в случае необходимости.
Минус этого решения – необходимость в отдельном сервере под backup`ы — а это дополнительные затраты. Маленькие и средние компании обычно пытаются сэкономить деньги на покупке вспомогательного оборудования.

Перекрестное копирование данных

Когда два или более продакшен серверов копируют друг на друга свои данные. В случае когда на продакшен серверах есть достаточное количество дискового пространства для хранение данных с других серверов, их можно использовать как backup-серверы. Мы копируем данные с сервера server1
на server2 а данные с server2 на server1.
Плюс – экономим деньги на оборудование. Как я писал выше маленькие и средние организации могут не выделить деньги на вспомогательное оборудование, даже если это необходимо под резервные копии. В таком случае вам может помочь такой способ бекапа.

Системы хранения данных

“Классические” сервера для хранения бекапов хороши при относительно небольших объемах. Сейчас это несколько сотен гигабайт. Когда же объемы гораздо больше на помощь приходят СХД, Системы Хранения Данных:

• Дисковые массивы
  По сути такой же сервер, но спроектирован специально под хранение данных. Имеет много HDD большего размера.
• Ленточные накопители
  Они же стримеры. Данные как и в случае с ленточными библиотеками записываются на специальные картриджи. Как правило, картридж – это магнитная лента в пластиковом корпусе.
• Ленточные библиотеки
  Предназначены для автоматизированного резервного копирования данных. Одновременное использование нескольких лентопротяжных механизмов увеличивает производительность библиотеки и сокращает время, необходимое для записи и чтения резервных копий.
• Другие носители данных
  optical disc (CD-R/RW, DVD-R/RW);
  flash-накопители;
  ZIP, Jaz, MO драйвы.

Виды бекапа

• Полное – все файлы и каталоги которые мы хотим сохранять на отдельном носителе.
• Инкрементальное – копируем только то, что изменилось с момента последнего резервного копирования. Полного или инкрементального.
• Дифференциальное – копируем только то, что изменялось с моментапоследнего ПОЛНОГО бекапа.
• Пофайловый метод – копируем нужные файлы в индивидуальном порядке.
• Дублирование диска – метод при котором мы делаем полный снимок диска. Например утилитой dd.
• Теневой метод — метод совмещающий все вышеперечисленные, основанный на мониторинге изменения файловой системы

Схемы ротации бекапов

Ротация – это политика по которой делается резервное копирование. Как часто мы будем делать бекап, как долго мы будем хранить резервные копии. Все это описывается политикой ротации.

• Одноразовое копирование – администратор делает копирование вручную. Обычно делается полный бекап данных.
• Простая ротация – подразумевается, что некий набор носителей используется циклически. К примеру 5 ленточных носителей на каждый день недели. В пятницу мы делаем полный бекап данных а в остальные дни недели инкрементальный.
• “Дед, отец, сын” (GFS) – имеет иерархическую структуру ротации. Используется три набора носителей. Раз в неделю делается полной бекап данных. В остальные дни недели – инкрементальный. Раз в месяц делается еще один полный бекап системы. Набор носителей для ежедневного инкрементального копирования – сын, набор для еженедельного полного бекапа – отец, набор для ежемесячного полного бекапа – дед.
• “Ханойская башня” – название пошло от древней китайской игры. Смысл игры заключается в следующем. Есть три стержня и какой-то набор дисков. Диски нужно перемещать со стержня на стержень, но так, чтобы каждый новый диск ложился на диск большего диаметра. Такой метод бекапа достаточно сложен и практически не применяется в настоящее время.
• “10 наборов” – метод рассчитан на 10 наборов носителей. Период из 40 недель делится на десять циклов. В течение цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла осуществляется сдвиг номера набора. То есть в первом цикле за понедельник отвечал набор N1, за вторник N2, за среду N3 и т.д. Во втором цикле за понедельник будет отвечать набор N2, за вторник N3, за среду N4 и т.д. Такая схема позволяет равномерно распределить нагрузку между носителями но из-за своей сложности практически не используется.

Методы резервирования баз данных

• hot backup – горячий бекап базы данных. Это когда резервная копия делается при включенном сервере БД.
• cold backup – холодный бекап базы данных. Это когда сервер БД нужно выключить чтобы сделать резервную копию.

Продолжение

В последнее время участились случаи взлома серверов с CentOS. По проверенным данным дистрибутив CentOS имеет уязвимость в ssh 4.3 и рабочий эксплойт, который успешно ее эксплуатирует.

Настоятельно рекомендуется обновить openssl и ssh, установив последние версии из исходных кодов и запретив yum обновлять эти пактеы из репозиториев.