Недавно я просил включить telnet-клиент при установке Windows. Парень DevOps сказал мне, что это было ограничено, потому что имена пользователей и пароли передавались в виде открытого текста. Я предполагаю, что он имеет в виду использовать его для подключения к незащищенному серверу telnet, но я не буду использовать его для этого, а вместо этого буду использовать его только для некоторых быстрых проверок TCP.
Я также заметил, что OWASP упоминает именно это в своей документации.
https://www.owasp.org/index.php/Test_HTTP_Methods_(OTG-CONFIG-006)
Так что мне не хватает, есть ли проблема с безопасностью клиента?
Нет никаких прямых проблем с безопасностью, если просто установить клиент. Проблема здесь в сочетании клиента и пользователя, использующего его для доступа к серверам с незашифрованными соединениями. Легче ввести технические ограничения, чем изменить поведение человека.
Является ли удаление клиентского программного обеспечения единственным способом решить эту проблему? Конечно, нет, и, например, блокировка незашифрованных протоколов на брандмауэре может работать даже лучше, а также против запуска собственных исполняемых файлов или использования собственных устройств для обхода этого ограничения. Но все же это аргументированная политика компании, вероятно, основанная на опыте.
Есть способы выполнить базовую проверку соединения, не использующую незашифрованный протокол: Как в Windows с помощью командной строки проверить, открыт ли удаленный порт?
Из них мне нравится, что Test-NetConnection включен в PowerShell. Nmap более мощный, но сторонний.
Я говорю это, используя telnet для отправки тестовых писем SMTP на ящики UNIX. Это тупо низкий уровень, но я вижу, что происходит. Никогда не использовался для входа в систему, служба Telnet всегда отключена.