Como encontro portas SSL ou instâncias SSL no Linux RHEL 5.3?

5

Estou tentando fazer uma auditoria de portas / serviços ativados por SSL em execução em nossos servidores Linux RHEL 5.3. Eu estou tentando encontrar quais portas em nossos servidores estão habilitadas para SSL. Eu não sei como encontrar isso. Eu preciso saber como verificar quais portas estão usando serviços habilitados para SSL.

Eu executei comandos abaixo

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

mas das saídas desses não sei como determinar quais portas estão executando ssl.Não tenho certeza do que procurar

Qualquer ajuda, por favor, estou ciente do utilitário SSLscan, mas quando eu o executo ele não retorna nenhum valor e cospe um erro ... não pôde abrir uma conexão com o host 127.0.0.1 na porta 443

SSLscan Parece funcionar em nosso ambiente Windows sem quaisquer problemas, mas não com Linux. Também estou ciente do nmap, mas não posso usá-lo em nosso ambiente por razões de segurança

Ajuda por favor

    
por Dominiqs 09.12.2011 / 13:11

1 resposta

6

Não tenho certeza se existe uma maneira automatizada de fazer isso.

Primeiro, eu listaria todas as portas que estão escutando e correspondesse as portas ao processo / executável (por exemplo, com netstat -t -l -p , como raiz para poder ver o ID do processo (PID)).

[EDITAR]

Você receberá entradas como essa, em que o PID é:

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

Isso informa qual programa está sendo executado na porta https . (Use netstat -t -l -p -n se você quiser apenas o número da porta e, nesse caso, você verá *:443 em vez de *:https ). Isso indica que há um soquete escutando na porta 443. Além disso, aqui, 5221 é o PID do apache2, de modo que também informa qual aplicativo está sendo usado. Às vezes, pode não ser imediatamente visível qual aplicativo está sendo usado (você pode ver o conteúdo de /proc/5221/cmdline para ver mais detalhes, por exemplo).

Gostaria de focar apenas as entradas que estão vinculadas a interfaces externas (e ignorar as entradas localhost ).

Normalmente, você pode ver algo escutando na porta 22 (ssh), 80 (http), 443 (https), ...

Você terá que testá-los um por um, dependendo do método descrito abaixo.

Por exemplo, echo "" | openssl s_client -connect your.host.name:80 deve mostrar uma mensagem de erro, uma vez que seu servidor da Web não escutaria (ou não deveria) solicitações SSL / TLS nessa porta, echo "" | openssl s_client -connect your.host.name:443 deveria funcionar e mostrar algumas informações sobre o certificado e a conexão.

[/ EDIT]

Para o SSL / TLS inicial , você pode verificar se aceita um TLS ClientHello (ou seja, um servidor TLS a partir do início da conexão), mas usando echo "" | openssl s_client -connect hostname:port ( echo "" | é opcional, ele apenas irá parar o openssl assim que tiver estabelecido a conexão, já que você provavelmente não deseja enviar nada específico).

Para conexões SSL / TLS "atualizadas" , feitas após um comando no nível do protocolo de aplicativo (como STARTTLS ), isso pode ser mais complicado.

Você pode fazer isso adicionando -starttls the_name_of_the_protocol a este comando openssl s_client . De acordo com a documentação do OpenSSL, " Atualmente, os únicos [nomes de protocolo] suportados são" smtp "," pop3 "," imap "e" ftp "".

Isso não irá ajudá-lo para o LDAP (se configurado para usar o TLS inicial e não o TLS), MySQL, PostgreSQL, ... Para estes, você pode simplesmente ter que examinar seus respectivos arquivos de configuração. A automação desse processo exigiria uma ferramenta que pudesse entender todos esses protocolos, o que pode ser bastante difícil.

Alguns pontos adicionais, se for para uma auditoria de segurança mais geral:

  • Ativar SSL / TLS raramente é suficiente. Você também quer certificar-se de que está configurado corretamente: certificado válido, SSLv2 desativado, tentando mover para os valores mais altos de SSL / TLS (SSLv3, TLSv1.0, TLSv1.1 +) desativando versões mais antigas se sua base de usuários for suficientemente renegociação compatível e insegura desativada, se possível, pacotes de criptografia razoavelmente strongs.

  • Apesar de usar a biblioteca OpenSSL, o OpenSSH (e o SSH em geral) não é baseado em SSL / TLS. Talvez você ainda queira manter esse, mesmo que sua política seja usar serviços somente SSL / TLS.

por 09.12.2011 / 14:21

Tags