Общеизвестно, что sshdзапуск на общедоступной машине — это восхитительный вектор атаки, поэтому его следует защищать как можно лучше. Помимо очевидных советов, таких как «установить PermitRootLoginна no» и «переключиться на аутентификацию с открытым ключом», я нашел следующие методы ограничения доступа к моей машине для скрипт-кидди, вооруженных nmap:
- Измените порт на какой-либо другой, кроме 22. Из вышеперечисленного это не особо помогает
nmap. - Оставьте порт 22 открытым, но просто отбросьте все, что туда приходит, и вместо этого принимайте SSH-подключения с другого порта, используяэтот костыль. Лучше, чем предыдущий метод, но все равно не более чем помеха.
- Установить порт стук. Громоздкий ивсе ещене совсем безопасно, так как «стучащий» трафик может быть перехвачен.
Если бы я проектировал систему удаленного доступа к своей машине, она бы выглядела так:
- Сгенерируйте случайный секрет.
- Вручную скопируйте его на оба устройства, которые должны быть соединены (это можно сделать даже с помощью флэш-накопителя для максимальной сохранности данных).
- Theсамый первый пакет(т.е. инициация SSH-рукопожатия), которое клиентская машина отправляет на сервер,ужезашифрованный этим секретом.
- Если сервер получает пакет, не зашифрованный правильно с помощью этого секрета, он просто молча закрывает TCP-соединение.
Результатом является то, что этофизически невозможнодля злоумышленника даже узнать, что на сервере запущена служба SSH. В моем хедканонеэтотименно это и означает «предварительно предоставленный ключ».
Вместо этого, когда я пытаюсь найти «ssh с предварительным ключом», я не получаю ничего, кроме ссылок на статьи о том, как перейти с PasswordAuthenticationна PubkeyAuthentication.
решение1
Нет, не делает. На уровне протокола каждое стандартное соединение SSHv2 всегда начинается с 1) «баннера» версии протокола в виде простого ASCII, 2) незашифрованного пакета, в котором перечислены все поддерживаемые шифры и методы обмена ключами.
Начиная с шага 3 вымогреализовать собственный метод обмена ключами, включающий PSK (в идеалекроме тогок обычному динамическому обмену ключами DH), но это потребует настраиваемого демона sshd, а также настраиваемых клиентов. В настоящее время такой функции нет ни в OpenSSH, ни в PuTTY, ни в Bitvise WinSSHD, ни в любой другой реализации SSHv2, с которой я пока что поигрался.
Простейшей альтернативой было бы использование системы VPN, поскольку они часто поддерживают PSK (но чаще как ключи HMAC для защиты первоначального обмена ключами – а не как ключи AES для шифрования фактического канала данных, поскольку это лишило бы вас функции «прямой секретности»). После того, как у вас запущена служба VPN, вы можете просто полностью отключить прямые соединения SSH: никто не сможет обнаружить sshd, который буквально больше не слушает.
Например, среди популярных WireGuard и OpenVPN поддерживают использование предварительного общего MAC-ключа для аутентификации всех попыток подключения. Поскольку оба используют UDP для начального согласования, они просто не отвечаютсовсемк непроверяемым пакетам, что делает службу необнаружимой. (Хотя я полагаю, что WireGuard уже делает это даже без режима PSK...) Обратите внимание, что OpenVPN называет эту функцию режимом «tls-auth» — не путайте ее с режимом «static-key».
Здесь также можно было бы использовать IPsec AH – если вам нужен только полностью статический ключ аутентификации, можно было бы вручную настроить SA на обоих концах, без необходимости в динамическом рукопожатии IKE, просто с помощью команды ip xfrm. Но это может раздражать.
В качестве еще одной альтернативы некоторые операционные системы поддерживаютTCP-уровеньаутентификация с предварительным общим ключом с использованием TCP-MD5 (RFC1321) или TCP-AO (RFC5925). Это было бы легко взломать программное обеспечение SSH, поскольку ему нужен только один sockopt, хотя это снова входит в область пользовательских клиентов. Кроме того, поддержка на уровне ОС плохая — хотя TCP-MD5 все еще поддерживается, поскольку люди хотят использовать его с BGP, поддержка TCP-AO может быть практически несуществующей.