Предотвратить SSH от рекламы своего номера версии

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

Если я подключаюсь к своему хосту через telnet на порту 22, он сообщает мне точную версию SSH, которую я использую (SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4). Аналогичная ситуация и с MySQL и Cyrus.

Есть ли какие-либо предложения? По крайней мере для SSH?

Спасибо

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

Хотя скрыть номер версии вашего SSH-демона крайне сложно, вы можете легко скрыть версию Linux (Debian-3ubuntu4).

Добавьте следующую строку в /etc/ssh/sshd_config

DebianBanner no

И перезапустите ваш SSH-демон: /etc/init.d/ssh restart или service ssh restart

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

http://www.snailbook.com/faq/version-string.auto.html

Как уже говорилось выше, изменить номер версии это

1. Сложно
2. Безопасность через неявность
3. Неконструктивно

Я предлагаю реализовать Port Knocking. Это довольно простая техника, чтобы скрыть что-либо, что работает на вашем сервере.

Вот хорошая реализация: http://www.zeroflux.org/projects/knock

Вот как я реализовал это на своих серверах (другие номера), чтобы открыть SSH только для тех, кто знает ‘секретный стук’:

[openSSH]
    sequence = 300,4000,32
    seq_timeout = 5
    command = /opencloseport.sh %IP% 2305
    tcpflags = syn

Это даст 5-секундное окно, в течение которого три SYN-пакета должны быть получены в правильном порядке. Выбирайте порты, которые находятся далеко друг от друга и не последовательные. Таким образом, сканер портов не может случайно открыть порт. Эти порты не нужно открывать с помощью iptables.

Скрипт, который я вызываю, выглядит так. Он открывает определенный порт на 5 секунд для IP, отправляющего SYN-пакеты.

#!/bin/bash
/sbin/iptables -I INPUT -s $1 -p tcp --dport $2  -j ACCEPT
sleep 5
/sbin/iptables -D INPUT -s $1 -p tcp --dport $2  -j ACCEPT

Отправить SYN-пакеты может быть настоящей мучительницей, поэтому я использую скрипт для подключения к SSH своих серверов:

#!/bin/bash
knock $1 $2
knock $1 $3
knock $1 $4
ssh $5@$1 -p $6

(Здесь довольно очевидно, что происходит…)

После установления соединения порт можно закрыть. Подсказка: используйте ключевую аутентификацию. В противном случае вам придется очень быстро вводить свой пароль.

Я почти уверен, что вы не можете на самом деле изменить объявление версии.

Лучшие способы усилить безопасность sshd:

1. Измените номер порта по умолчанию.
2. Запретите вход от пользователя root.
3. Принудите использовать протокол 2 (если это не сделано по умолчанию).
4. Сделайте белый список серверов, которым разрешено подключаться по SSH.

Первые три можно сделать, изменив /etc/sshd_config.

Четвертое зависит от используемого вами программного обеспечения для брандмауэра.

После многих часов усилий я нашел окончательное решение на сайте Rapid7. Поскольку скрытие версии усложнит переговоры между клиентом и сервером, настройка Port Knocking будет единственным решением для устранения всех открытых сервисов (например, версии OpenSSH) и их раскрытия версий против инструментов разведки, таких как nmap и т. д.

Проблема

OpenSSH (и на самом деле каждая другая реализация SSH) передает важную информацию о безопасности каждому входящему соединению. Обратите внимание:

# telnet localhost 22
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3

Это сообщает о версии OpenSSH и версии операционной системы всем желающим.

Это представляет собой проблему с двух сторон: безопасность и конфиденциальность.

Безопасность

Утомительно повторяемые утверждения тех, кто не понимает смысл фразы, говорят о том, что воздержание от предоставления информации, аналогичной конфиденциальным данным, является “безопасностью через неявность”. Это не так. Эта фраза имеет отношение только к идее о том, что если криптографическая примитивная конструкция безопасна только в том случае, если не известен алгоритм, то она не безопасна. Эта фраза не говорит и никогда не собиралась говорить о том, что воздержание от раскрытия информации о вашей криптосистеме, реализации или операционной системе является плохим делом. Все, что увеличивает активационную энергию, необходимую для того, чтобы противник проник, – это хорошее дело. На самом деле, это, полностью и полностью, всё, что делает любой замок (криптографический или физический) в любом случае. Идея о том, что усилия по увеличению сложности для противника неправильны, – это неверное применение в остальном важного принципа поддержания безопасности (среди прочих способов) с помощью должной криптографии.

Конфиденциальность

Предположим, вы поддерживаете приватный VPS, который мы назовем JOURNALISTHAVEN в скрытом месте. Предположим, вы хотите скрыть тот факт, что подключаетесь к нему, но все равно можете подключаться к нему по ssh из любого места. Вы перенаправляете порт с другого VPS, PUBLICVILLE, через коммерческую VPN к JOURNALISTHAVEN. Теперь вы можете использовать любой компьютер где угодно, чтобы подключиться к вашему приватному VPS, не делая очевидным, что вы к нему подключаетесь. Теперь представьте, что версия реализации ssh на PUBLICVILLE отличается от версии на JOURNALISTHAVEN – теперь становится очевидно, что перенаправленный порт – это не просто еще один порт, на который слушает SSH-демон PUBLICVILLE, а что он идет куда-то еще. Да, есть и другие способы, которыми эта информация может быть раскрыта проницательным и целеустремленным противником, но действительно ли нам нужно раздавать эту информацию каждому первому встречному? Никто не может утверждать, что конфиденциальность через неявность является чем-либо, кроме единственной формы конфиденциальности, которая существует.

Вопрос

Возможно ли предотвратить OpenSSH от объявления своего номера версии?

Ответ – да, в основном – на 50% через конфигурационные средства. Остальное – либо перекомпилирование, либо редактирование вашего двоичного файла.

Строка подключения

RFC 4253 раздел 4.2 требует, чтобы строка подключения имела:

SSH-2.0-softwareversion

…где softwareversion не содержит пробелов и не содержит символа “-“. Поэтому она не может быть полностью опущена, и не может быть просто пробелом или “-“. Она должна содержать хотя бы один печатаемый символ. К сожалению, OpenSSH слишком строго относится к этому, так что если вы полностью уберете softwareversion, клиент OpenSSH действительно откажется подключаться к серверу.

Сервер OpenSSH

К сожалению, нельзя сказать серверу OpenSSH молчать о своей версии или настроить это через параметр конфигурации. Вы можете заставить его умолчать о ОС, используя опцию /etc/ssh/sshd_config.d/*:

DebianBanner no

Это лишь частично решает проблему. Он все еще оставляет OpenSSH объявляющим свою версию и даже уровень патча каждому желающему.

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

Редактирование исходного кода и перекомпиляция

OpenSSH доступен здесь. Полные инструкции по сборке находятся за рамками этого текста, но вы можете найти строку версии для редактирования в version.h:

#define SSH_VERSION "OpenSSH_9.9"

Вы можете изменить это в соответствии с вашими требованиями. Строка “SSH” является довольно общей.

Редактирование двоичного файла

ПРЕДУПРЕЖДЕНИЕ: Есть последствия для этого.

Недавние версии двоичного файла OpenSSH могут быть отредактированы. Для этого:

1. Узнайте точную строку подключения, которую нужно отредактировать. sshd -x – это на самом деле неверная команда, но это единственный способ заставить sshd вывести свою информацию о версии соединения и строку подключения (sshd -V не выводит ту же строку)
2. Используйте шестнадцатеричный редактор (hexcurse или подобный) на копии /usr/sbin/sshd и найдите ВТОРОЕ вхождение строки.
3. Замените первые три символа на ‘SSH’, за которыми следует нулевой символ.
4. mv /usr/sbin/sshd /usr/sbin/sshd.orig
5. Скопируйте отредактированный двоичный файл в /usr/sbin/sshd
6. Перезапустите службу. Для большинства это будет systemctl restart sshd
7. Проверьте новую версию. systemctl status sshd, чтобы убедиться, что служба работает, и telnet localhost 22 для тестирования строки версии. Если вы редактируете двоичный файл, вам все равно нужно будет отключить DebianBanner.

Если вы не хотите редактировать двоичный файл в шестнадцатеричном формате, этот скрипт сделает то же самое для большинства недавних версий sshd на Linux:

# VERSION="OpenSSH_9.2p1" NEW="SSH" perl -0777 -pe 'BEGIN { $version = $ENV{VERSION}; $new = $ENV{NEW} . "\0"; } 
    $pos = index($_, $version, index($_, $version) + 1);
    substr($_, $pos, length($new), $new) if $pos != -1;' /usr/sbin/sshd > sshd_patched

VERSION должен быть установлен на точную строку версии, полученную в шаге 1 выше. NEW должен быть установлен на то, что вы хотите, чтобы отображалось вместо этого.

Следуйте шагам 5, 6 и 7 выше.

Последствия редактирования двоичного файла

• Менеджеры пакетов могут иметь проблемы с обновлением sshd в будущем. Прежде чем вы обновите пакет sshd, вы должны:
  1. systemctl stop sshd
  2. mv /usr/sbin/sshd.orig /usr/sbin/sshd
  3. systemctl start sshd
• Указанный выше метод редактирования шестнадцатеричных данных или скрипт могут не работать на будущих версиях sshd или на довольно старых версиях. Его следует протестировать, прежде чем на него полагаться.

Заключение

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

RFC 4253 на самом деле подразумевает требование о строке версии программного обеспечения на ssh-подключениях для диагностических целей. Что-то, что клиент, испытывающий трудности с подключением к серверу, может телнетом проверить, чтобы определить, возникают ли проблемы с совместимостью. Это не так для некоторых времени. Это было сомнительным полезным 18 лет назад, когда был написан RFC, и это не было таким же военным климатом тогда, как сейчас для ssh. Вы не можете поднять сервер ssh на новом IP-адресе более чем на две минуты, не попадая под прицел ботнетов. Когда бомбы падают, выключите свет и закройте черные шторы. Если, конечно, некоторые военные криптогенераторы не хотят обозначить это как безопасность через неявность. В таком случае они могут выставить голову из окопа и закурить сигарету. Или включить свет во время воздушной тревоги.