Комментарии 20
Я верно понимаю что для защиты сервера сейчас нужно в насройках SSH сервера жестко указать используемые шифры в /etc/ssh/ssh_config убрав все что с -CBC на конце оставив так:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
А для защиты VPN убрать галочку: подключаться к локальным сетям напрямую к без VPN
т.е. паниковать рано, на вид все просто можно починить и защититься.
Я верно понимаю что для защиты сервера сейчас нужно в насройках SSH сервера жестко указать используемые шифры в /etc/ssh/ssh_config убрав все что с -CBC на конце оставив так:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr
Проверялка этой уязвимости имеет следующий код:
УязвимостьПрисутсвует = (report.SupportsChaCha20 || report.SupportsCbcEtm) && !report.SupportsStrictKex
StrictKex это kex-strict-c-v00@openssh.com или kex-strict-s-v00@openssh.com - псевдоалгоритмы, появившиеся еще в OpenSSH 9.6 еще в декабре 2023. То есть это все уже пофикшено, надо только обновиться.
для тех кто сидит на LTS придётся самим делать :(
Например, в Ububtu 22.04 хоть и используется OpenSSH 8.9, но утилита проверки сообщает, что strict key exchange уже поддерживается.
не охота ставить утилиту, а конкретно тех (псевдо)алгоритмов "kex-strict-c-v00@openssh.com или kex-strict-s-v00@openssh.com" в моей конфигурации sshd_config нет.
Алгоритма ChaCha в нем не было, а вот -cbc удалял ручками.
в насройках SSH сервера жестко указать используемые шифры в /etc/ssh/ssh_config
эээ, ssh_config? разве для сервера не sshd_config?
Да все верно, там два файла, оба отвечают за настройку SSH но ssh_config - содержит настройки конфигурации для SSH клиента, если мы клиенты то мы будем использовать эту настройку и нужно туда прописывать. sshd_config - содержит настройки конфигурации для SSH сервера, туда тоже нужно прописывается Ciphers. Можно прописать в оба файла для надежности.
насчёт в оба прописать, я так и сделал. Но насчёт клиента - есть ньюанс. Они скомпилированны с поддержкой всех (в том числе и небезопасных) шифров, это можно видеть задав команду после переконфигурирования
ssh -Q chiphersболее того, устаревшие шифры можно будет всё ещё использовать при явном указании в команде запуска. Как пишут, сделано это для возможности подключения даже к устаревшим необновляемым терминалам.
Эта команда показывает что поддерживается, но не факт что это будет использоваться. чтобы не использовать что-то очень старое и небезопасное нужно в ssh_config и sshd_config прописать только то что безопасно. вот что я прописал в оба файла для подстраховки:
# два алгоритма шифрования что не скомпрометированы (можно добавить еще из этого списка набрав в консоли: ssh -Q cipher )
Ciphers aes128-gcm@openssh.com,aes128-ctr
# Подпись вполне хватает SHA-256 (можно добавить еще из этого списка набрав в консоли: ssh -Q mac )
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-256
# обмен ключами только через кривую curve25519
# важно чтобы был ключ для это кривой в файле /etc/ssh/ssh_host_ed25519_key
# (можно добавить еще из этого списка набрав в консоли: ssh -Q kex )
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Aж корёжит когда грязными руками лезут в системные конфиги поставляемые пакетами. Как потом систему обновлять будете ? Тысячу конфликтов решать ?
Переопределяйте в *.d директориях локальными конфигами.
Да меня укусил debian way )
Атака ServerIP использует тот факт, что многие VPN не шифруют трафик от клиента на IP-адрес сервера VPN:
Можно подробнее, о чем речь? Это pptp без шифрования какой-то? Что вообще подразумевается под vpn? Какой конкретно протокол? Или речь о распространенных программах для vpn и их кастомных протоколах?
это SSH2, который работает по протоколу HTTP/3 <..>
Значительно более быстрое установление сеанса
Я не понимаю как оно может быть быстрее если оно в HTTP (который plain text) заворачивает бинарный трафик SSH2? Я б понял если бы речь шла за обычный QUIC+TLS, но у вас оно "И", да ещё и с Http Auth. Также непонятно какой профит от более быстрого установления сессии, если всё остальное не меняется.
За секурити решения тоже вопросы. В репе есть кучка дисклеймеров по теме, но нет в статье.
Ок. Что там по quic в России? Лежит ?!
Новые механизмы защиты от взлома? - Запретить!
А вообще, kill switch в VPN решает проблемы, трафик только может в туннель.
По поводу уязвимости SSH, она относится жёстко настроенный аутентификации по токенам? Нет токена - не авторизации. Poli cha cha нужен только для маломощных устройств, в остальном же aes решает проблемы, сейчас практически все имеют ускорение aes, пользуйтесь aes шифром.
И главное, не используйте пароли и дефолтные порты для авторизации ssh...
Пока не найдут фундаментальную уязвимость в OpenSSH не стоит сильно переживать, грамотно настроенный сервер справится с защитой самого себя, пока не будет найдена 0 day уязвимость, или кто не забудет обновить сервер после выхода заплатки
Атака на SSH и взлом туннелей VPN