Эксплуатация нулевого дня на сервере SSH - предложения по защите

13

По данным Internet Storm Center , похоже, что существует уязвимость SSH нулевого дня.

Здесь есть некоторые доказательства концептуального кода и некоторые ссылки:

Это кажется серьезной проблемой, поэтому каждый системный администратор Linux / Unix должен быть осторожен.

Как мы можем защитить себя, если эта проблема не исправлена ​​вовремя? Или как вы справляетесь с подвигами нулевого дня в целом?

* Я отправлю свое предложение в ответах.

linux security ssh hacking exploit sucuri
источник
Насколько это реально? Небольшой гуглтроллинг оказался seclists.org/fulldisclosure/2009/Jul/0028.html в качестве самого оригинального источника этих слухов. У кого-нибудь есть независимая проверка этого?
Крис
Много хороших комментариев на Hacker News об этой проблеме: news.ycombinator.com/item?id=692036
sucuri

Ответы:

6

Комментарий Дэмиена Миллера (разработчика OpenSSH): http://lwn.net/Articles/340483/

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

Так что я не убежден, что 0day существует вообще. Пока единственным доказательством являются некоторые анонимные слухи и непроверенные записи вторжений.

х-полосная
источник
Я думаю, что мы можем
поверить
11

Мое предложение состоит в том, чтобы заблокировать доступ SSH на брандмауэре для всех, кроме вашего ip. На iptables:

/sbin/iptables -A INPUT --source <yourip> -p tcp --dport 22 -j ACCEPT
/sbin/iptables -A INPUT -p tcp --dport 22 -j DROP
sucuri
источник
5

Согласно такому посту SANS, этот эксплойт does not work against current versions of SSHи, следовательно, на самом деле не 0day. Патч своих серверов, и у вас все будет хорошо.

Dentrasi
источник
2
технически это 0-дневный эксплойт (не опубликован и неизвестен), но он работает только на старых версиях SSH. Однако версия по умолчанию на RHEL, Fedora уязвима (согласно второму посту). Таким образом, это большая проблема, если в вашем дистрибутиве нет патча (если вы не используете ssh из не распространенного источника) ...
sucuri
1
Они предполагают, что на основе журналов атак. Никто не знает наверняка ... Даже последняя версия может быть уязвимой
sucuri
3

Пожаловаться на ваших поставщиков

Таким образом, все получают более новую версию.

Брэд Гилберт
источник
3

К вашему сведению, первоначальный источник истории: http://romeo.copyandpaste.info/txt/ssanz-pwned.txt

Есть также две похожие истории (взлом astalavista.com и другой сайт): romeo.copyandpaste.info/txt/astalavista.txt
romeo.copyandpaste.info/txt/nowayout.txt

Похоже, у кого-то есть повестка дня: romeo.copyandpaste.info/ («Держите 0days в тайне»)

х-полосная
источник
Согласовано. Группа за оригинальными журналами, которая начала это, имеет миссию, чтобы связываться с «индустрией безопасности» - и какой лучший способ сделать это, чем вызвать у всех недовольство по поводу «боже мой! Openssh 0day ?!», как мне найти это / остановить? это / взломать с этим? "
Чи
Не первый раз подобные слухи и ажиотаж оказываются ложными.
Дэн Карли
2

Я компилирую SSH, чтобы использовать tcprules, и имею небольшое количество разрешающих правил, запрещающих все остальные.

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

Эрни
источник
2

Я не запускаю ssh на порту 22. Поскольку я часто захожу с разных компьютеров, мне не нравится запрещать доступ через iptables .

Это хорошая защита от атак нулевого дня, которые наверняка пойдут после конфигурации по умолчанию. Он менее эффективен против тех, кто пытается скомпрометировать только мой сервер. Сканирование портов покажет, на каком порту я использую ssh, но скрипт, атакующий случайные порты SSH, пропустит мои хосты.

Чтобы изменить свой порт, просто добавьте / измените порт в файле / etc / ssh / sshd_config .

brianegge
источник
Запуск SSH на нестандартном порту, по-видимому, уменьшает количество атак методом перебора, которым он подвергается, и, вероятно, защитит вас от большинства червей. Хотя это не защита от чьего-либо ручного сканирования, и в будущем червь может просто сканировать порты для каждого порта в поисках ssh (что легко, просто занимает много времени)
MarkR
@MarkR: Он не может остановить решительного «взломщика / малыша / хакера», но будет держать ботов в страхе, пока не будет выпущено исправление. Это самое главное, имхо.
Андриоид
2

Я бы брандмауэр и подождал. Мой внутренний инстинкт - это одна из двух вещей:

A> Мистификация. Из-за небольшой и недостоверной информации, предоставленной до сих пор, это либо это ..

или...

B> Это попытка «дыма и обмана», вызывающая беспокойство по поводу 4.3. Почему? Что если вы, какая-то хакерская организация, найдете в sshd 5.2 действительно классный эксплойт нулевого дня.

Очень жаль, что только самые современные версии (Fedora) включают эту версию. Никакие существенные юридические лица не используют это в производстве. Много пользы RHEL / CentOS. Большие цели. Хорошо известно, что RHEL / CentOS поддерживают все свои исправления безопасности для сохранения своего рода базового контроля версий. Команды за этим не должны чихать. RHEL опубликовал (я читал, придется выкопать ссылку), что они исчерпали все попытки найти какой-либо недостаток в 4.3. Слова не следует воспринимать легкомысленно.

Итак, вернемся к идее. Хакер решил как-то вызвать ажиотаж около 4,3, вызвав массовую истерию UG до 5,2p1. Я спрашиваю: сколько из вас уже?

Чтобы создать какое-то «доказательство» для неправильного направления, все, что «сказала группа» должна сделать сейчас, это захватить некую ранее скомпрометированную систему ( WHMCS ? Предыдущий SSH?), Создать несколько журналов с некоторыми полуправдами (атака проверена «чем-то»). произошло, но некоторые вещи не поддаются проверке цели) надеясь, что кто-то "укусит". Все, что требуется, - это одна большая сущность, чтобы сделать что-то радикальное (... HostGator ...), чтобы сделать это немного более серьезным, среди растущей тревоги и растерянности.

Многие крупные организации могут делать бэкпорт, но некоторые могут просто обновиться. Те, которые обновляются, теперь открыты для реальной атаки нулевого дня без раскрытия.

Я видел странные вещи. Мол, куча знаменитостей, умирающих все подряд ...

Питер Мортенсен
источник
0

Переключиться на Telnet? :)

Если не считать шуток, если ваш брандмауэр правильно настроен, он уже разрешает доступ по SSH только нескольким хостам. Так что вы в безопасности.

Быстрое решение может состоять в том, чтобы установить SSH из исходного кода (загрузив его с openssh.org) вместо использования старых версий, присутствующих в последних дистрибутивах Linux.

sucuri
источник
Kerberized Telnet на самом деле достаточно безопасен. Хорошая вещь в Kerberos заключается в том, что вы можете централизованно отзывать ключ, если хотите, в отличие от ssh, где вы должны посещать каждый хост и удалять ключ из каждого файла author_keys.
Крис