Назад | Перейти на главную страницу

Как найти порты или экземпляры SSL с поддержкой SSL в Linux RHEL 5.3

Я пытаюсь провести аудит портов / служб с поддержкой SSL, работающих на наших серверах Linux RHEL 5.3. Я пытаюсь найти, какие порты на наших серверах имеют ssl. Я не знаю, как это найти. Мне нужно знать, как проверить, какие порты используют ssl-сервисы.

Я выполнил команды ниже

lsof -i -n -P netstat -ntulp netstat -nap

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

Любая помощь, пожалуйста, я знаю об утилите SSLscan, но когда я запускаю ее, она не возвращает никаких значений и выдает ошибку ... не удалось открыть соединение с хостом 127.0.0.1 на порту 443

SSLscan Кажется, он работает в нашей среде Windows без каких-либо ошибок, но не в Linux. Я также знаю Nmap, но не могу использовать его в нашей среде по соображениям безопасности

Помогите, пожалуйста

Я не уверен, есть ли автоматический способ сделать это.

Сначала я бы перечислил все прослушиваемые порты и сопоставил порты с процессом / исполняемым файлом (например, с netstat -t -l -p, как root, чтобы видеть идентификатор процесса (PID)).

[РЕДАКТИРОВАТЬ]

Вы получите такие записи, где PID:

tcp        0      0 *:https            *:*                LISTEN      5221/apache2

Это говорит вам, какая программа работает на порту https. (Используйте netstat -t -l -p -n если вам просто нужен номер порта, и в этом случае вы увидите *:443 вместо того *:https). Это говорит о том, что порт 443 прослушивает сокет. Кроме того, здесь 5221 - это PID для apache2, так что он также сообщает вам, какое приложение используется. Иногда может быть не сразу видно, какое приложение используется (вы можете посмотреть содержимое /proc/5221/cmdline например, чтобы увидеть более подробную информацию).

Я бы сосредоточился только на записях, которые привязаны к внешним интерфейсам (и проигнорировал localhost записи).

Как правило, вы можете увидеть что-то, прослушивающее порт 22 (ssh), 80 (http), 443 (https), ...

Затем вам нужно будет протестировать их один за другим в зависимости от метода, описанного ниже.

Например echo "" | openssl s_client -connect your.host.name:80 должен отображать сообщение об ошибке, поскольку ваш веб-сервер не будет (или не должен) прослушивать запросы SSL / TLS на этом порту, echo "" | openssl s_client -connect your.host.name:443 должен работать и показать вам некоторую информацию о сертификате и подключении.

[/РЕДАКТИРОВАТЬ]

Для предварительный SSL / TLS, вы можете проверить, принимает ли он TLS ClientHello (т.е. быть TLS-сервером с самого начала соединения), но используя echo "" | openssl s_client -connect hostname:port (echo "" | не является обязательным, он просто остановит openssl, как только установит соединение, поскольку вы, вероятно, не хотите отправлять что-либо конкретное).

Для "обновленные" SSL / TLS-соединения, выполняется после команды на уровне протокола приложения (например, STARTTLS), это может быть сложнее.

Вы можете сделать это, добавив -starttls the_name_of_the_protocol к этому openssl s_client команда. Согласно документации OpenSSL, "В настоящее время поддерживаются только [имена протоколов]: «smtp», «pop3», «imap» и «ftp».".

Это не поможет вам для LDAP (если настроен на использование Start TLS, а не на предварительный TLS), MySQL, PostgreSQL, ... Для них вам может просто потребоваться изучить их соответствующие файлы конфигурации. Для автоматизации этого процесса потребуется инструмент, который сможет понять все эти протоколы, что может быть довольно сложно.

Пара дополнительных моментов, если это касается более общего аудита безопасности:

  • Включение SSL / TLS бывает достаточно редко. Вы также хотите убедиться, что он настроен правильно: действительный сертификат, SSLv2 отключен, попытка перейти на более высокие значения SSL / TLS (SSLv3, TLSv1.0, TLSv1.1 +), отключив более старые версии, если ваша база пользователей достаточно совместимые, небезопасное повторное согласование отключено, если возможно, достаточно надежные комплекты шифров.

  • Несмотря на использование библиотеки OpenSSL, OpenSSH (и SSH в целом) не основан на SSL / TLS. Возможно, вы все равно захотите сохранить этот, даже если ваша политика заключается в использовании служб только SSL / TLS.