Secure Shell - SSH. Como funciona o SSH?

Transcrição

1 Secure Shell - SSH SSH é um protocolo para login remoto seguro e outros serviços contextualizados em redes abertas. Esse protocolo é dividido em três componentes básicos: Camada de Transporte: Provê sigilo, integridade e autenticação do servidor. Opcionalmente, pode ser oferecido um serviço de compressão de dados. Essa camada geralmente é rodada em cima de uma conexão TCP/IP, mas é possivel que ela seja usada em cima de qualquer outro tipo de protocolo confiável e orientado a conexão. Protocolo de Autenticação: Autentica o usuário perante o servidor. Esse protocolo necessita da camada de transporte para o seu funcionamento. Protocolo de Conexão: Permite a multiplexação da conexão entre vários canais lógicos. Esse protocolo depende do protocolo de autenticação. Nessa camada encontramos recursos como shell interativo, tunelamento de portas TCP/IP e conexões X11. Como funciona o SSH? SSH utiliza um poderoso método de criptografia chamado de Public Key Cryptography que fornece autenticação e encriptação entre os hosts (cliente e servidor) de maneira que nenhum password e nenhum envio de dados sejam facilmente interceptados por outros hosts. Esse método usa uma chave pública (public key) para encriptação dos dados e uma chave privada (private key) para desencriptação. Assim, antes de o PC do João estabelecer conexão com o Mac da Joana, eles passam por um processo de "reconhecimento"de troca de chaves públicas: o PC envia sua chave pública para o Mac reconheçe-la, e o Mac faz o mesmo com o PC. Feita a troca, a comunicação pode ser feita com segurança. Existem, até o momento, duas versões desse protocolo, sendo a primeira, o SSH1 já considerada ultrapassada. Assim, a versão que está sendo utilizada atualmente é a SSH2. Diferenciando-se de outras ferramentas como rsh, rcp, rlogin e telnet, o SSH codifica

2 toda a comunicao. Dessa forma, ele impede a interceptação por invasores. Ele também pode ser usado para encriptar comunicações ftp e pop, protegendo os usuários contra DNS e IP spoofing. Outra vantagem é que existem implementações do ssh para a maioria dos sistemas operacionais. A versão aberta, chamada de OpenSSH possui interoperabilidade, podendo funcionar comunicando o servirdor 2.X com qualquer versão dos protocolos. As principais características desse aplicativo são: Cifragem: Todas as conexões são criptografadas de forma transparente e automática. Utiliza algoritmos de livre patente como o DES, 3DES, Blowfish, Twofish, Arcfour, entre outros, que serão discutidos mais adiante. X11 Forwarding : Protege o DISPLAY das conexões X11 Port Forwarding: Permite a comunicação utilizando TCP através de um canal cifrado. Pode criptografar outros serviços, como o ftp, tftp, pop etc. Autenticação forte: Protege contra IP spoofing, falsos encaminhamentos e DNS spoofing. Agent Forwarding: Um agente de auntenticação que permite que o usuário utilize chaves RSA de um computador portátil sem que seja necessário transferi-las para a máquina. Compressão de dados: Comprime a informção antes de enviá-la, o que é útil para ligações com pouca largura de banda. Ao se utilizar qualquer implementacao do ssh, antes do pacote ser enviado, ele pode ser comprimido, em seguida será encritado e, por fim, autenticado. Ao ser recebido, é conferida a autenticação, desencripta-se os dados e, em seguida, é feita, caso seja necessário, a descompressão dos dados. O algoritmo de encriptação a ser utilizado será escolhido pelo cliente, dentro das possibilidades da implementacao do ssh utilizada tanto pelo cliente quanto pelo servidor. Caso ele selecione uma opcao nao disponivel no servidor, lhe será requisitada uma outra opção. O mesmo acontece com os algoritmos de compressão.

3 Protocolos SSH1 e SSH2: O objetivo principal desses protocolos é fazer a autenticação do cliente e do servidor, e trocar a chave que será utilizada durante a sessão. Existem muitas diferenças entre esses dois protocolos, que foram criadas a fim de possibilitar um maior grau de segurança. O protocolo SSH1 já é considerado por muitos como ultrapassado, de forma que os novos aplicativos utilizam apenas o SSH2. O SSH2 tem como vantagens, quando comparado ao SSH1, uma maior segurança, um novo design que requer um código mais simples para ser rodado, maior velocidade na criptografia, suporta diferentes algoritmos de chave pública, incluindo o DSA e Diffie-Hellman key exchange, além de facilitar o uso de aplicativos para transferência de arquivos tanto em UNIX(SFTP - Secure File Transfer Protocol e SCP- Secure File Copy) quanto em Windows. Uma das falhas do SSH1 permite que a chave de sessão seja recuperada por aquele que está atacando, de modo que deixa vulnerável as próximas conexões. O que acontece, de fato, é que é feita uma escuta de todas as informações que estão sendo transmitidas, e se observa problemas de design ou implementação no cliente ou no servidor que permitam obter a chave de sessão. Apartir daí o texto pode ser decifrado. Outra falha já documentada é relacionada a um overflow de inteiros no código, que foi criada para detectar ataques contra uma outra falha já detectada no SSH1, envolvendo o CRC checksum dos pacotes de dados. O problema é que esse overflow pode resultar em uma inscrição de dados sobre uma área de memória já utilizada para outros fins. O ataque é feito colocando pacotes maliciosos entre as informações trocadas, permitindo a execução de comandos arbitrários tanto no servidor quanto no cliente. Essa questão se torna ainda mais complexa quando quem está rodando o arquivo é o root, o que pode gerar um dano ainda maior. Basicamente, ambos os protocolos tem por princípio fazer a autenticação do usuário, e, em seguida, trocar a chave de sessão. Assim, é possível transmitir todas as informações totalmente encriptadas. Port Forwarding:

4 Port forwarding, ou, em português, redirecionamento de portas, é o ato de direcionar uma porta da rede (network port) de um nó de rede para outro. Esta técnica pode permitir que um usuario alcance uma porta em um endereço de IP privado (como o de uma LAN) mesmo estando fora dessa rede, através de um roteador com NAT habilitado. Desta forma é possível disponibilizar na rede pública serviços internos, minimizando as probabilidades de compromisso das máquinas internas. Essa técnica constitui-se de criar uma conexão por túnel TCP/IP protegido pelo ssh, a fim de evitar ataques pela rede. O Port Forwarding pode ser usado para criar uma espécie de rede virtual privada (VPN - Virtual Private Network). Portanto, ele deve ser usado quando se deseja evitar o eavesdropping entre cliente e servidor. Assim, pode-se configurar a rede a se comunicar a distância de cliente para servidor SSH2, onde são estabelecidos regras contendo os IPs e portas correspondentes que podem se comunicar, transferindo informação segura. Assim, é necessário configurar o cliente em relação a porta e a interface que ele irá escutar o servidor, e este deverá ser configurado com o host de destino, contendo o IP ao qual ele deverá se conectar sempre que for necessário fazer um forwarding. Além disso, deve-se também configurar a porta por onde o servidor fará a comunicação. Para fazer um port forwarding servidor cliente, é necessário fazer as mesmas confiurações anteriores, só que trocando o servidor pelo cliente e o cliente pelo servidor. Caso se deseje utilizar mais máquinas, elas devem ser ligadas ao servidor e ao cliente, embora essas ligações não estejam seguras.

5 Existem dois tipos de Port Forwarding, o local, também chamado de outgoing tunnel, e o à distância, conhecido também por income tunnel. O primeiro transfere todos o tráfego que chega a uma porta local para uma porta distante. O segundo faz o contrário, enviando para uma porta local todo o tráfego que chega em uma porta distante. Existe ainda o chamado Dinamic Port Forwarding. Esse consiste de um mecanismo que suporta os protocolos de cliente Socks4 e Socks5. Na configuração dinâmica, ao invés de configurar portas específicas no host local e portas específicas para o servidor, pode-se configurar um servidor socks. Assim, todas as aplicações terão suas configurações normais, exceto pela escolha do uso do servidor socks na porta do local host. O cliente SSH, então, abre a porta no local host e copia um servidor socks4 ou socks5 para as aplicações que incluem socks do cliente. Quando essas aplicações estão se conectando com serviços como IMAP4, POP3, SMTP, HTTP e FTP, eles provêem as informações necessárias para o servidor socks que foi copiado pelo cliente. Este, então, utilizará essas informações para criar um port forwarding para o servidor SSH, criando uma conexão segura, assim como acontece com a utilização de portas específicas. X11 Forwarding: O protocolo X especifica a relação cliente-servidor entre uma aplicação e seu display. Em X, o software que comanda uma tela, o teclado e o mouse são conhecidos como X servers, enquanto o cliente é uma aplicação que é mostrada no X server. O cliente envia um pedido para o servidor X, esse aceita o pedido de múltiplos clientes e responde com pedidos de informação, entradas do usuário, e erros. Mais especificamente, as funções do servidor, que roda na máquina local, são: Aceitar e demultiplexar a rede baseado nos pedidos e ações do cliente. Mostrar na tela pedidos gráficos Repotar os erros nos pedidos dos clients Controlar o teclado, o mouse e o display. Isso inclui rotear as entradas de mouse e teclado na rede para os respectivos clients X. Criar, mapear e destruir janelas Escrever e desenhar nas janelas O cliente X pode ser descrito pelas atividades que executa. Dessa forma, consiste da aplicação, criada com o auxílio de bibliotecas como xlib e xt, capaz de tirar vantagem do

6 protocolo X através das seguintes ações: Enviar pedidos ao servidor Receber eventos do servidor Receber mensagens de erro do servidor O protocolo X é capaz de gerenciar o envio de pedidos, respostas, eventos e erros, como já foi explicitado anteriormente. O pedido é feito pelo cliente X para o servidor X para que certa ação, como criar uma janela, seja realizada. O envio do pedido normalmente fica a cargo da camada de rede, e dependendo do pedido, nenhuma resposta é esperada. A resposta, assim como o pedido, tem o tamanho de múltiplos de 4 bytes. Os eventos são transmitidos pelo servidor X de acordo com a expectativa gerada pela aplicação, podendo incluir entrada de mouse ou de teclado. Os erros são enviados em resposta aos pedidos, sendo semelhantes aos eventos. O X11 Forwarding do SSH é uma ferramenta baseada na tecnologia X, permitindo que aplicações sejam realizadas a distância. Nesse caso, o cliente, que é aplicação que está sendo usada fica na máquina que está requisitando a conexão pelo SSH, e o servidor X será o próprio servidor. A vantagem de usar esse mecanismo pelo SSH é que todas as operações feitas entre cliente e servidor serão encriptadas, apesar de ser uma aplicação gráfica, através de uma conexão virtual. Para utilizar essa ferramenta, é preciso que o servidor esteja configurado para permitir tais trocas. Em uma aplicação de ssh em Linux, isso pode ser feito modificando o arquivo /etc/ssh/sshd_config nas seguintes linhas: X11Forwarding yes X11DisplayOffset 10 A primeira linha habilita o X11 Forwarding, enquanto a segunda estabelece como serão repassados os displays na conexão.

7 É necessário ainda habilitar a máquina local a receber aplicações X de um determinado servidor, através do comando: xhost +{nome ou IP da estação remota}. Em seguida, deve-se conectar e mudar a varável de sistema display da máquina local através do comando: export DISPLAY=(nome ou IP da estação local):(n), onde n é a sessão de X que será usada. Em geral, utiliza-se n = 0. Assim, estando habilitado o X11 Forwarding no servidor, e o usuário utilizando X11 com a variável de sistema setada, a conexão para o display X11 é automaticamente enviada para o servidor de maneira a fazer com que todas as aplicações X11 iniciadas pelo shell ou pela linha de comando passará por uma canal encriptado, e a conexão com o Xserver será feita diretamente através da máquina local. O valor do display setado pelo ssh, que será maior que zero, apontará para a máquina do servidor. A razão de o display ser maior do que zero se deve ao fato de o SSH criar um "proxy" X server na máquina do servidor, a fim de que as informações possam ser trocadas através de um canal encriptado. O programa também instalará os dados do Xauthority automaticamente na máquina do servidor. Para isso, ele gerará um cookie de autorização de forma randômica, guardará no Xauthority do servidor, e, em seguida, verificará se nenhuma outra conexão enviada usa o mesmo cookie. Caso ele seja único, ele é trocado por um cookie real quando a conexão é aberta. É importante notar que o cookie real de autenticação nunca será enviado ao servidor, e também que nenhum cookie é enviado sem estar encriptado. Caso o usuário esteja utilizando um agente de auntenticação, a conexão com a outra máquina é feita automaticamente. É importante observar também que, para utilizar essa ferramenta em Windows, é necessário instalar um emulador X, como o Exceed ou o Reflection X, no modo passivo na máquina, para que o túnel possa ser estabelicido pelo SSH. Outro ponto interessante é que, uma vez a conexão com o servidor X feita, as aplicações X não são passadas todas de uma vez. É necessário fazer o pedido de cada aplicação que se queira utilizar. Assim, para se reproduzir a tela do XWindow, é preciso chamar todas as aplicações, uma por uma. Esse é um incoveniente, já que se gastaria muito tempo, e seria necessário saber o nome de todos as aplicações. Por outro lado, se isso não for feito, ou seja, não se utilizar o SSH para fazer a conexão com o servidor X, a segurança não será garantida.

8 Instalando e configurando servidor SSH 1 - Para instalar o sevidor SSH no Ubuntu Server, basta digitar no terminal do servidor o comando: # apt-get install openssh-server 2 - Após finalizado a instalação editar o arquivo /etc/ssh/sshd_config, lembrando que não temos interface gráfica, utilize o editor de texto de sua preferência: # vi /etc/ssh/sshd_config Apenas retirar o comentário "#" da linha 71, com isso podemos customizar o arquivo issue.net com uma mensagem de saudação quando logarmos de outra máquina:

9 3 - Agora deve editar o arquivo issue.net e adicionar uma mensagem de saudação: # vi /etc/issue.net 4 - Para finalizar deve reiniciar o serviço SSH com o seguinte comando: #service ssh restart Ambiente de teste Servidor - Ubuntu Server (Máquina virtual, placa de rede em modo Bridge) Cliente 1 - Windows Seven (Máquina virtual, placa de rede em modo Bridge)

10 Cliente 2 - Fedora 18 (Máquina física) Acessando do Fedora 18 informando usuário@ip_servidor via terminal, será solicitado a senha do usuário que possui conta no servidor, observem a mensagem que configuramos. ssh william@

11 Acessando via Windows Seven utilizando o programa PuTTY, basta clicar no executável do programa, informar o IP do servidor e pressionar o botão Open: Será aberto um prompt onde informamos usuário e senha que possuem conta no servidor:

12 Foi demonstrado como configurar e acessar um servidor SSH no Ubuntu Server, foi possível acessar remotamente o servidor pelo Windows Seven com o auxílio do programa PuTTY e também acessar via terminar do Fedora. É claro que existem diversas configurações que podem ser feitas no servidor SSH, como restringir o acesso para apenas um usuário, mas deixo aberto essas possibilidades para serem configuradas conforme a necessidade do administrador. Segurança dentro SSH: Para deixar o seu sistema seguro, seguem passos que ajudarão: Escolher uma senha forte; Instalar o DenyHosts para bloqueio automático de intrusos; Modificar a porta padrão; Desabilitar protocolo inseguro;

13 Desabilitar login como root; Reduzir o número da conexões autenticadas; Reduzir o tempo de espera para login; Autorizar somente específicos usuários e/ou grupos; Autorizar conexões de um único IP; Somente autorizar usuários com chaves, proibir o uso de senhas; Ligar o SSH à uma interface de rede específica. Estes passos envolvem modificação do arquivo de configuração global /etc/ssh/sshd_config e o empacotamento TCP através do host /etc/hosts.allow e /etc/hosts.deny. Passo I: Senha forte Se você não está nem aí para segurança, se você não acredita que o seu sistema sequer pode ser invadido porque você acha que seus documentos são irrelevantes para qualquer um, então, pelo menos escolha uma senha decente para proteger o mínimo do seu sistema. Ainda que você pense que seus arquivos são irrelevantes para qualquer um, para você eles podem ter um valor e isso já é motivo suficiente para você escolher uma senha para o seu usuário e, principalmente, para o root, já que esse é o mais atacado. Se você está em um computador que você crê que alguém pode estar tentando invadir, use estes comandos para fazer uma auditoria e veja se o root não é o alvo principal. Top 5 mais recentes ataques: # lastb awk '{print $1}' sort uniq -c sort -rn head -5

14 Top 5 contas mais atacadas de todos os tempos: # awk 'gsub(".*sshd.*failed password for (invalid user )?", "") {print $1}' /var/log/secure* sort uniq -c sort -rn head -5 Top 5 IPs de atacantes (estes devem entrar na sua lista negra): # awk 'gsub(".*sshd.*failed password for (invalid user )?", "") {print $3}' /var/log/secure* sort uniq -c sort -rn head -5 Para que você possa dormir tranquilo sabendo que sua senha é segura, rode o John the Ripper no seu sistema, se demorar muito para descobrir a senha, é porque a senha é boa, caso o John encontre a senha rápido, é bom trocar... Passo II: Instale DenyHost Esta aplicação vai observar os usuários que tentam logar no sistema e falham, ao perceber que um determinado host está tentando muito e falhando, ele automaticamente inclui esse host na lista negra. No Fedora instale assim: # yum install denyhosts # chkconfig denyhosts on # /etc/init.d/denyhosts start

15 No Ubuntu: $ sudo apt-get install denyhosts $ sudo service denyhosts start Dê uma olhada no arquivo de configuração e faça a alteração que você achar necessária. Caso o seu sistema não tenha, crie os arquivos /etc/hosts.allow e /etc/hosts.deny, onde em: allow Deve-se colocar o IP das máquinas que você usará para conectar. deny Máquinas que você já sabe que são de invasores ou pessoas que você deseja bloquear. Passo III: Mude a porta padrão Quando você instala o SSH por padrão, ele escuta a porta 22, assim, por medida de segurança, mude para uma porta maior que No SSH, vamos editar o arquivo /etc/ssh/sshd_config, procure a linha onde indica a porta e coloque um "#" antes, copie para a linha debaixo mudando o numero da porta: # Port 22 Port 2200 Quando conectar, use a porta escolhida: $ ssh mauricio@ p 2200

16 Características do ataque Cada dia mais são verificadas tentativas de ataques de dicionário contra servidores SSH. Algumas bases de usuário/senha estão disponíveis em sítios na Internet e vários atacantes estão montando suas próprias listas e ferramentas para perpetrar este tipo de ataque. Têm-se observado o uso não somente de dicionários na língua inglesa, mas também em outros idiomas, PORTUGUÊS inclusive. Um exemplo de um registro de tentativas de ataque pode ser visto abaixo: Sep 21 12:02:06 srv sshd[48770]: Failed password for invalid user ricky from port ssh2 Sep 21 12:02:08 srv sshd[48772]: Failed password for invalid user ricky from port ssh2 Sep 21 12:02:09 srv sshd[48774]: Failed password for invalid user ricky from port ssh2 Sep 21 12:02:10 srv sshd[48776]: Failed password for invalid user ricky from port ssh2 Sep 21 12:02:11 srv sshd[48778]: Failed password for invalid user ricky from port ssh2 Sep 21 12:02:13 srv sshd[48780]: Failed password for invalid user ricky from port ssh2 Sep 21 12:02:14 srv sshd[48782]: Failed password for invalid user roy from port ssh2 Sep 21 12:02:15 srv sshd[48784]: Failed password for invalid user roy from port ssh2 Sep 21 12:02:17 srv sshd[48786]: Failed password for invalid user roy from port ssh2 Sep 21 12:02:18 srv sshd[48788]: Failed password for invalid user roy from port ssh2 Sep 21 12:02:19 srv sshd[48790]: Failed password for invalid user roy from port ssh2 Sep 21 12:02:20 srv sshd[48792]: Failed password for invalid user roy from port ssh2 Deve-se notar, também, que cada tentativa de conexão faz com que o servidor SSH abra uma nova instância para atender ao possível acesso, fato que pode comprometer seriamente o desempenho do servidor, em função da quantidade de tentativas e freqüência da incidência dos ataques. Na seção Assinatura para o Snort está disponível uma assinatura para detectar ataques gerados por uma ferramenta que têm sido bastante utilizada para desferir estes ataques.

17 Sugestões para defesa As sugestões para defender-se deste tipo de ataque são de vários tipos, que vão desde simples troca de porta do serviço até configurações de novos serviços e regras em firewall. As sugestões podem ser adotadas de forma isolada, mas não existe nenhum impedimento em combiná-las, muito pelo contrário, a adoção de várias delas combinadas é altamente recomendável. Redução no número de equipamentos com serviço aberto para Internet Esta sugestão se baseia no simples fato de que quanto menos máquinas expostas, menor será o risco. Isso torna mais fácil o monitoramento, dada a menor quantidade de equipamentos a serem vigiados. A implantação desta sugestão não evita a varredura e ataques aos equipamentos que ainda permanecerem expostos. Filtragem de origem Vários servidores SSH não têm a real necessidade de manter o serviço exposto para qualquer origem, em geral um número limitado de redes/usuários deveriam acessar, remotamente, um determinado servidor, mas estes costumam ser deixados sem limites por conta da conveniência. Uma vez definidas de quais redes que o administrador efetivamente necessitaria ter acesso remoto, os filtros podem ser implementados de mais de uma maneira, pode ser um bloqueio no roteador ou firewall de borda. Outra possibilidade é a seleção das origens permitidas por serviço, usando recursos como tcpwrappers. Limitação de recursos Outra sugestão interessante é a de limitar a utilização dos recursos do serviço, no caso do OpenSSH isso pode ser feito através de cláusulas como MaxStartups e MaxAuthTries, que definem, respectivamente, a quantidade de instâncias não autenticadas simultâneas (por padrão são 10), e quantas tentativas sem sucesso são permitidas por usuário (por padrão são 6). Mover o serviço para uma porta não padrão

18 De simples implementação, no caso do OpenSSH basta editar o arquivo sshd_config e substituir, na cláusula Port, a porta 22 por outro valor. Note que este artifício é considerado "segurança por obscuridade", ou seja, não é exatamente uma medida corretiva, apenas um paliativo, visto que os ataques, por uma questão de conveniência, tendem a buscar somente a porta padrão (22/tcp). Outra questão é sobre a necessidade de substituir rotinas automatizadas como cópias de segurança remotas, retreinamento do usuário e uma coisa a mais para lembrar (documentar) quando da atualização do pacote, ou instalação de um novo servidor. Por fim é preciso lembrar que alguns firewalls de empresas bloqueiam portas de serviços que não são utilizadas, o que pode ser um problema para um acesso remoto emergencial, visto que um administrador pode não conseguir alcançar sua rede, por conta de um bloqueio feito na rede onde ele está no momento que foi avisado de algum problema. Acesso somente via chaves públicas De fácil configuração, bastando (no OpenSSH) mudar para "no" as cláusulas PasswordAuthentication e UsePAM, além de gerar o par de chaves para os usuários e equipamentos envolvidos na autenticação (clientes e servidores). Os principais inconvenientes ficam por conta da dificuldade de conexão via equipamento de terceiros e o treinamento dos usuários. Vale lembrar que este recurso pode não ser de uso simples em alguns clientes SSH e que outros sequer possuem esta funcionalidade. Limitar início de conexão (SYN) Algumas ferramentas de ataque, para ganhar eficiência, disparam várias cópias de si mesmas, sendo deste modo interessante configurar no firewall alguns limitadores. Por exemplo, usando o firewall padrão do FreeBSD, é possível criar uma regra com a cláusula "limit" associada, para informar quantas conexões simultâneas são permitidas para aquela regra, por exemplo: ipfw add allow tcp from any to 200.XX.XX.6 22 limit src-addr 1 Quando utilizado o IPFilter (FreeBSD/NetBSD/Sun/Solaris/HP-UX), um exemplo de uso seria: pass in quick proto tcp from any to 200.XX.XX.6 port = 22 keep limit 1 No caso do PF (OpenBSD), o exemplo abaixo poderia ser usado: pass in quick proto tcp from any to 200.XX.XX.6 port 22 flags S/SA \ keep state (max-src-states 1) Existe uma extensão disponível para netfilter (chamada ipt_recent) que permite configurar um período de tempo no qual uma determinada conexão pode ocorrer, por exemplo a cada 120 segundos:

19 iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp --dport ssh -m recent --update --seconds 120 -j DROP iptables -A INPUT -p tcp --dport ssh --tcp-flags syn,ack,rst syn -m recent --set -j ACCEPT Essa abordagem tem um efeito colateral positivo interessante, pois permite bloquear um ataque já no momento da varredura, que normalmente precede o ataque de força bruta do serviço SSH. Configurar pacote knockd O programa KNOCKD está disponível atualmente para sistemas Linux, e atua de forma a permitir que, somente após o usuário enviar uma seqüência previamente conhecida de pacotes, o programa ative um serviço pré-determinado, SSH no nosso caso. É composto de um servidor (knockd) e um cliente (knock) responsável por enviar os pacotes da maneira como o knockd espera receber. No exemplo abaixo foi inventada uma seqüência de pacotes que indicasse, ao knockd, que ele deveria iniciar a execução do serviço SSH. O arquivo de configuração knock.conf foi configurado de maneira que, para iniciar o serviço, o programa deve receber um pacote (SYN) tcp nas portas 100 e 200 e um pacote UDP na porta 300: [openssh] sequence = 100:tcp,200:tcp,300:udp seq_timeout = 5 command = /etc/init.d/ssh start tcpflags = syn [closessh] sequence = 300:udp,200:tcp,100:tcp seq_timeout = 5 command = /etc/init.d/ssh stop tcpflags = syn E para finalizá-lo deve receber a seqüência inversa. Foi então executado: # knock sitio.org.br 100:tcp 200:tcp 300:udp Para fechar o serviço foi executado na ordem inversa: # knock sitio.org.br 300:udp 200:tcp 100tcp Nos logs ficou registrado: [ :47] starting up, listening on eth0 [ :47] : openssh: Stage 1 [ :47] : openssh: Stage 2 [ :47] : openssh: Stage 3 [ :47] : openssh: OPEN SESAME [ :47] openssh: running command: /etc/init.d/ssh start

20 [ :00] : closessh: Stage 1 [ :00] : closessh: Stage 2 [ :00] : closessh: Stage 3 [ :00] : closessh: OPEN SESAME [ :00] closessh: running command: /etc/init.d/ssh stop Esta solução tem alguns inconvenientes, uma vez que além de tornar mais complexa a ação de login remoto, pois necessita de um passo adicional, o administrador ainda deve escolher com bastante cuidado as portas usadas na sinalização, por conta de possíveis bloqueios quando atrás de firewalls. Outro dificultador é o fato de que em alguns ambientes o acesso à Internet se dá somente através de proxy, entre outras limitações de protocolos e portas, tornando ainda mais complicado o envio de uma seqüência, de pacotes, para um equipamento remoto. Assinatura para o Snort Têm sido observada a utilização, em larga escala, de uma ferramenta para realizar ataques de força bruta de SSH, que gera tráfego com características peculiares. Estas características podem ser identificadas no tráfego de rede através de sistemas de detecção de intrusão (IDS). A seguir é apresentada uma assinatura para o IDS Snort que identifica ataques na porta 22 gerados por esta ferramenta: alert tcp $EXTERNAL_NET any -> $HOME_NET 22 \ (msg:"possible SSH brute force attempt"; \ flow:to_server,established; \ threshold:type threshold, track by_src, count 5, seconds 60; \ content:"ssh-2.0-libssh-0.1"; offset: 0; depth: 18;) Vale ressaltar que o tráfego só é detectado nos casos em que a ferramenta conseguir estabelecer conexões na porta 22/tcp (SSH).

21 THC-Hydra Brute Force Attack FTP e SSH O Hydra é uma excelente ferramenta para realizar ataques para testar a segurança, os ataques podem ser realizados através de uma lista de palavras wordlist contendo possíveis usuários ou senhas. Por isso que é importante reforçar que manter a documentação atualizada de sistemas, equipamentos, aplicações é importante. Veja alguns exemplos básicos de como utilizar o Hydra: Passo 01 Crie o arquivo senhas.txt contendo senhas aleatórias que possivelmente possa pertencer a um determinado usuário.

22 Ataque a um servidor FTP ( ) Passo 02 root@kali:~# hydra -l 100security -P senhas.txt ftp -l : Define o login do usuário 100security : Login do usuário a ser verificado -P : Define o arquivo contendo as possíveis senhas wordlist senhas.txt : Arquivo que contém as possíveis senhas do usuário informado : IP do servidor FTP ftp : Tipo do serviço a ser verificado Ao realizar o ataque a senha do usuário informado é revelada caso esteja no arquivo senhas.txt Login: 100security Password: P@ssw0rd Passo 03 Realizando o acesso via FTP para certificar o usuário e a senha

23 ftp Como pode observar o acesso é realizado com sucesso Ataque a um servidor SSH ( ) Passo 01 root@kali:~# hydra -l 100security -P senhas.txt ssh -l : Define o login do usuário 100security : Login do usuário a ser verificado -P : Define o arquivo contendo as possíveis senhas wordlist senhas.txt : Arquivo que contém as possíveis senhas do usuário informado : IP do servidor SSH ssh : Tipo do serviço a ser verificado Ao realizar o ataque a senha do usuário informado é revelada caso esteja no arquivo senhas.txt Login: 100security Password: P@ssw0rd

24 Passo 02 Realizando o acesso via SSH para certificar o usuário e a senha root@kali:~# ssh -l 100security Informe a senha encontrada P@ssw0rd

25 Passo 03 Acesso ao servidor via SSH realizado com sucesso

26 Sistemas Operacionais Aceder por SSH a partir de Linux é extremamente simples uma vez que qualquer distribuição deste sistema operativo já tem incluida esta aplicação. O SSH não passa de um serviço parecido com telnet e ftp, a única diferença entre eles está na segurança. O SSH envia dados criptografados e dependendo da sua configuração, pode implantar autenticação de chaves, por isso ele se torna uma ótima opção em relação aos outros que enviam dados em texto puro, dificultando facilitando ataque de spoofing e snifers. O serviço SSH não é exclusividade de plataformas derivadas de UNIX, podendo também ser acessado por máquinas contendo o Microsoft Windows. Para isto, é necessário o download de softwares específicos, visto que o sistema em si não possui suporte a este serviço nativamente. Ressaltam-se também que existem certas incompatibilidades entre as chaves criptográficas usadas em programas diferentes. Portanto estas devem ser convertidas para um formato que o cliente SSH que será utilizado no Windows seja capaz de compreender. A utilização do serviço de SSH no Windows requer que a chave criptográfica obtida em um servidor Linux/Unix (criada pelo OpenSSH ou SSH proprietário) seja convertida para um formato que possa ser utilizado neste sistema operacional. É importante observar também que, para utilizar essa ferramenta em Windows, é necessário instalar um emulador X, como o Exceed ou o Reflection X, no modo passivo na máquina, para que o túnel possa ser estabelicido pelo SSH.