Segurança em servidores Linux by Novatec Editora

Chris Binnie

Novatec

All rights reserved. This translation is published under license with the original publisher John Wiley & Sons, Inc. Copyright © 2016 by John Wiley & Sons, Inc., Indianapolis, Indiana. Todos os direitos reservados. Tradução autorizada da edição em inglês intitulada Linux® Server Security: Hack and Defend, publicada pela John Wiley & Sons, Inc. Copyright © 2016 por John Wiley & Sons, Inc., Indianapolis, Indiana. Nenhuma parte deste livro pode ser reproduzida, armazenada ou transmitida em qualquer formato ou por qualquer meio, eletrônico, físico e etc., sem a autorização por escrito do titular original do copyright, John Wiley & Sons, Inc. http://www.wiley.com/go/permissions Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora. Editor: Rubens Prates Tradução: Henrique Cesar Ulbrich Revisão gramatical: Priscila A. Yoshimatsu Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-335-6 Histórico de impressões: Janeiro/2017

Primeira edição

Novatec Editora Ltda. Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 E-mail: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Manto de invisibilidade

Imagine que se possa deixar um servidor invisível para a internet, porém tendo ainda acesso à largura de banda superior do seu provedor. Sem fazer qualquer alteração, seria possível usá-lo de forma segura como um dispositivo de armazenamento de arquivos, entre muitas outras opções. Seria também possível ter acesso total à linha de comando, de modo a inicializar ou interromper ou até mesmo instalar quaisquer serviços que se deseje usar. Haveria liberdade de opção, seja para rodar esses serviços de forma breve e logo fechá-los, ou deixá-los rodando de forma visível ao mundo exterior por um determinado período de tempo. Isso pode ser conseguido usando uma técnica chamada port knocking. O servidor pode ser camuflado pelo fechamento de todas as portas de rede para o mundo externo, tornando-o efetivamente invisível. Uma determinada porta que se deseje abrir arbitrariamente, usando um “door-knock”1 pré-arranjado, pode ser a do servidor SSH ou de algum outro serviço. Este capítulo mostra como criar um servidor invisível e mais algumas opções.

Contexto Pela simples camuflagem da existência de um servidor na internet, podemos no mínimo fazer uma máquina rodar em privado e, no pior caso e mesmo com sua existência conhecida, é possível reduzir a superfície 1 N. do T.: Não traduzimos door-knock por ser considerado jargão técnico, mas, resumidamente, seria como aquelas senhas que combinamos com os amigos ou familiares para avisar quem está batendo à porta ou tocando a campainha. Por exemplo, se ouvirmos um toque curto e três longos na campainha, já sabemos que é o primo trazendo a pizza.

Segurança em Servidores Linux

de ataque explorada por um invasor pela limitação do tempo em que as portas estejam abertas ou mesmo parcialmente visíveis.

Sondagem de portas Antes de começar, é oportuno olhar mais atentamente para as portas de rede de um servidor, assim conseguimos um panorama de referência. Quem já usou alguma ferramenta de segurança, como a Nmap, deve estar familiarizado com a premissa inicialmente confusa de que algumas portas parecem estar fechadas quando de fato não estão. Ao se deparar com uma porta aparentemente fechada, o Nmap consegue distinguir se ela está verdadeiramente fechada ou se há um serviço escondido por trás dela. O Nmap chama de fechadas as portas que não têm um daemon associado a ela, porém parecem estar abertas ou, pelo menos, potencialmente disponíveis. Se o Nmap se referir a portas filtradas, pode significar algum tipo de firewall prevenindo acesso ao endereço IP do agressor que está escaneando o sistema em questão. Isso tem a ver parcialmente com pacotes TCP RST2 e também com a existência de três outros estados informados pelo Nmap: unfiltered (não filtrado), open|filtered (aberto|filtrado) e closed|filtered (fechado|filtrado). Mais informações acerca das diferenças entre esses três estados podem ser obtidas em https://nmap.org/book/manport-scanning-basics.html.

Como confundir um scanner de porta Agora que sabemos como as portas podem se apresentar aos scanners de portas, vamos dar uma olhada em como ofuscar a resposta retornada, objetivando confundir as técnicas sofisticadas de escaneamento. A ferramenta mais óbvia a ser escolhida, graças ao seu poderoso conjunto de funcionalidades, é o firewall embutido no próprio kernel do Linux, o Netfilter, mais conhecido como iptables. A ideia é simples. No caso de pacotes TCP, é desejável ter o controle sobre como uma porta responde a sondagens, e para isso usamos o iptables 2 N. do T.: O autor considera que o leitor tem uma boa base teórica a respeito dos mecanismos de roteamento IP, conexão TCP, especialmente o processo de sincronismo inicial (three-way handshake), e comunicação UDP. Sugerimos ao leitor fazer uma revisão prévia desses conceitos para melhor entendimento deste capítulo.

Capítulo 1 ■ Manto de invisibilidade

com regras do tipo REJECT. No caso de outros protocolos, pode ser desejado somente aplicar DROP aos pacotes. Desta forma, o Nmap do agressor descreve essas portas TCP como fechadas e não como filtradas. Com base na maioria das opiniões coletadas em fóruns na internet (e este parece ser um argumento controverso, que muda o tempo todo), uma informação de porta fechada é a melhor resposta que se pode enviar ao Nmap de quem estiver escaneando nossos sistemas. Fazendo isso, não revelamos abertamente ao possível invasor o bloqueio, por um firewall, de qualquer porta, nem que a porta está simplesmente aberta por um daemon rodando por trás dela. Para explicar um pouco mais, sob circunstâncias normais uma porta inatingível emite geralmente uma resposta ICMP de Porta Inacessível (ICMP Port Unreachable). Porém, não é desejável que esses erros sejam gerados porque isso poderia indicar a presença de um serviço que estava rodando nessa porta e, por algum motivo, está inacessível. Em vez disso, é preferível gerar uma resposta REJECT, aplicada da seguinte forma: --reject-with tcp-reset. Com isso, a resposta que o Nmap recebe mostra a porta como não utilizada e fechada (portanto sem um serviço por trás) e também como não filtrada (portanto não revelando a existência do firewall). Basta anexar o seguinte fragmento ao final de cada um dos comandos iptables: -j REJECT—reject-with tcp-reset

Usando esta técnica, podemos ficar seguros de que nenhuma informação desnecessária sobre o sistema está sendo revelada. Observe que, no exemplo de port knocking que veremos a seguir, aquela opção do iptables não será usada, pois o servidor físico que roda o SSH não vai oferecer nenhum outro serviço (portanto não há nada para rejeitar). No entanto, essas informações básicas ajudarão a entender a forma de abordagem de um invasor nas portas da máquina e como podemos aplicar uma opção --reject-with tcp-reset a outros serviços. Há algum debate sobre o uso de regras DROP versus REJECT no iptables. Caso haja interesse, informações detalhadas sobre esse tema podem ser encontradas em www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject.

Segurança em Servidores Linux

Instalação do knockd Agora que já conhecemos o básico, veremos como instalar um port knocker no servidor. No decorrer da explicação, devemos considerar quais serviços desejamos rodar de forma escondida da internet. Pode ser que precisemos rodar um servidor web ou um servidor de emails em uma porta não usual por um período de poucas horas, por exemplo.

Pacotes O serviço que oferece a funcionalidade de port knock chama-se knockd. Esse pacote é instalado de diferentes formas, dependendo do sistema. Em derivados de Debian o pacote é instalado da seguinte maneira: # apt-get install knockd

Em derivados Red Hat a instalação é: # yum install knockd

Um arquivo de configuração principal controla a maioria das configurações necessárias para o knockd. Em um servidor Debian Jessie, esse arquivo reside em /etc/knockd.conf. A Listagem 1.1 mostra meu arquivo config principal para vermos como o knockd funciona.

Listagem 1.1 – Arquivo de configuração principal. As sequências de portas e (principalmente) -I INPUT foram alteradas em relação aos defaults. [options] UseSyslog [openSSH] sequence = seq_timeout = command = tcpflags =

6,1450,8156,22045,23501,24691 5 /sbin/iptables -I INPUT -s %IP% -p tcp—dport 22 -j ACCEPT syn

Capítulo 1 ■ Manto de invisibilidade [closeSSH] sequence = seq_timeout = command = tcpflags =

3011,6145,7298 5 /sbin/iptables -D INPUT -s %IP% -p tcp—dport 22 -j ACCEPT syn

Alteração dos ajustes default A Listagem 1.1 mostra, na parte superior, uma seção para ajustar as opções do knockd. As duas outras seções são as ações a serem executadas quando o knockd abre a porta para o serviço SSH ou quando fecha o acesso a essa porta. Ambas as seções incluem também a sequência default de port knocking para a execução dessas ações com a opção sequence. Após a instalação do knockd, alterei imediatamente estas portas em relação ao default para evitar a redução de eficácia na segurança do meu servidor. Os defaults são as portas 7000, 8000 e 9000 para abrir o acesso SSH e as portas 9000, 8000 e 7000 para fechar o acesso. Como podemos ver, acrescentei mais portas para abrir o acesso. Assim, reduzimos a possibilidade de que alguém se depare arbitrariamente com essa combinação por meio de um scanner de portas. Após a alteração de qualquer ajuste, basta reiniciar o knockd em sistemas operacionais baseados em systemd da seguinte forma: # systemctl restart knockd.service

Após a instalação do knockd, caso deseje mais informações básicas sobre o pacote, o Debian Jessie fornece um pequeno arquivo README que pode ser encontrado em /usr/share/doc/knockd/README. Entre outras coisas, esse arquivo README útil discute como o knockd funciona. Ele usa uma biblioteca denominada libpcap, que é também empregada por diversos outros pacotes como o tcpdump, ngrep e o iftop (que captura pacotes para inspeção). Graças à sua concepção inteligente, o knockd não precisa sequer se conectar às portas, realizando uma escuta sigilosa para a monitoração do tráfego bruto.

Segurança em Servidores Linux

Alteração dos locais do sistema de arquivos Eventos do tipo conexões, desconexões ou erros são registrados diretamente no syslog do seu sistema, que podem ser gravados no arquivo / var/log/messages ou no arquivo /var/log/syslog. Para que essas informações não sejam soterradas no meio de outras atividades do system log, pois é um aborrecimento analisar um arquivo com registros complicados, podemos criar um arquivo de registros personalizado. Prefiro fazer dessa forma, o que torna a depuração mais clara, e posso usar uma ferramenta automatizada ou um shell script que eu mesmo escrevi para me enviar emails diariamente, o que me permite monitorar eventos suspeitos. Por manter todos os registros do knockd em um único lugar, fica mais fácil analisar as informações usando scripts ou outras ferramentas. [options] LogFile = /var/log/portknocking.log

A alteração do local dos arquivos de log é uma solução comum, porém podemos também alterar o local em que o arquivo Process ID é gravado quando o serviço knockd é iniciado. O local pode ser alterado na seção [options] do arquivo de configuração: [options] PidFile = /var/tmp/run/file

Algumas opções de configuração Agora que já conhecemos melhor o arquivo de configuração principal, podemos ajustá-lo para atender às necessidades. Entre diversas outras tarefas, devemos considerar como as temporizações de certas opções influem na configuração do servidor.

Inicialização do serviço Não se assuste ao ver uma mensagem de erro dizendo que o knockd está desabilitado. Isto é uma precaução: até que se tenha concluído sua configuração, o knockd não introduzirá alterações indesejadas no iptables.

Capítulo 1 ■ Manto de invisibilidade

No Debian Jessie a mensagem de erro sugere definir, no arquivo /etc/default/knockd, o valor 1 para o parâmetro: START_KNOCKD = 1

Evidentemente, isso somente deve ser feito após conferir as configurações no mínimo duas vezes ou assegurando-se que o acesso ao serviço desejado está funcionando conforme esperado sem o knockd.

Alteração da interface de rede default Estando a sequência de portas preferida já configurada, talvez desejemos refinar outros parâmetros. O arquivo de configuração (/etc/default/knockd) oferece a oportunidade de alterar os valores da variável KNOCKD_OPTS. No arquivo, a variável está comentada, ou seja, desabilitada, e mostra um exemplo de como podemos definir a interface de rede na qual aquele knockd está “escutando”: KNOCKD_OPTS = "-i eth1"

Essas opções serão acrescentadas ao serviço knockd, que deve ser reiniciado para efetivar as alterações, conforme mostrado a seguir (em máquinas systemd): # systemctl restart knockd

Tipos de pacotes e temporizações O arquivo /etc/knockd.conf permite a alteração de algumas configurações para fazer um ajuste fino na forma como os clientes podem se conectar. Voltando à Listagem 1.1, na seção [openSSH], mais opções podem ser acrescentadas, conforme mostrado a seguir: [openSSH] tcpflags = syn seq_timeout = 10 cmd_timeout = 15

Segurança em Servidores Linux

A opção tcpflags significa que podemos esperar um tipo específico de pacote TCP sendo enviado ao knockd para que seja aceito. Trata-se de um “SYN” TCP neste caso. As flags TCP que podem ser usadas são fin, syn, rst, psh, ack e urg. O knockd simplesmente ignora qualquer pacote recebido que não traga o tipo especificado de pacote TCP. Devemos estar cientes de que, geralmente, o knockd não trabalha desta forma. Normalmente, um pacote incorreto pode interromper o trabalho de uma sequência completa de knocking, e neste caso o cliente deve reiniciar a conexão. A separação de múltiplos tipos de pacotes TCP deve ser feita usando vírgulas; nas versões mais recentes do knockd (desde a 0.5 conforme o changelog) a representação é feita com pontos de exclamação para negar o tipo de pacote, como, por exemplo, !ack. Observe que seq_timeout está presente na Listagem 1.1 por default. No entanto, devido ao acréscimo do número de portas da sequência de knocking, o valor de seq_timeout foi aumentado de 5 para 10. Isso é necessário porque, em uma conexão lenta, como a de um smartphone, o tempo máximo entre cada “knock” pode se esgotar (timeout). A opção final no exemplo é cmd_timeout, que ajusta o tempo máximo em que a porta desejada deve ficar aberta depois que o knockd recebeu um knock com sucesso. A sequência de eventos é mostrada a seguir. Em primeiro lugar, uma vez que o port knocking foi confirmado como válido, o knockd roda start_command (Releia a Listagem 1.1 para refrescar a memória). Se este ajuste estiver presente, e após a execução da opção start_command, resta somente esperar pelo tempo especificado em cmd_timeout antes de rodar a ação stop_command. Essa é a forma preferencial para abrir o servidor SSH para acesso, com seu fechamento sendo feito logo na sequência, assim que a conexão estiver estabelecida. O prosseguimento da sessão deve ocorrer sem maiores problemas, porém qualquer nova conexão deve efetuar outra sequência de port knocking para que se estabeleça. Essa ação deve ser entendida como o ato de fechar imediatamente uma porta assim que você entrar. O servidor se tornará invisível outra vez, e somente o tráfego das conexões já estabelecidas será visível.

Capítulo 1 ■ Manto de invisibilidade

Teste da instalação Como estamos lidando com a segurança de um servidor, alguns testes devem ser executados para garantir o funcionamento do knockd conforme esperado. O ideal é ter acesso a outra máquina cliente, via internet, para rodar alguns testes a partir dela. Para ter certeza de que o knockd abre e fecha as portas da forma correta, gosto de fazer o teste me conectando várias vezes ao serviço, cada vez a partir de um endereço IP público completamente diferente. Se o acesso a uma conexão com um endereço IP público diferente do anterior não for possível, a conexão à internet do cliente que está fazendo o teste contra o knockd deve ser derrubada periodicamente, fazendo com que um novo IP para teste seja alocado pelo provedor de serviços. Alguns provedores de banda larga e de internet móvel fazem isso após uma reinicialização – mas às vezes não; consulte seu provedor.

Clientes de port knocking Podem ser usados clientes diferentes para criar uma sequência de knocking e, com ela, iniciar uma conexão de abertura da porta SSH. Podem ser usadas até mesmo ferramentas como Nmap, netcat ou Telnet para “bater” manualmente na sequência de portas que dispara o serviço. A documentação também menciona que os pacotes hping, sendip e packit podem ser usados se estiverem disponíveis. Vamos dar uma olhada em um exemplo do comando knock incluído no pacote knockd. A sintaxe do comando knock é bem simples: # knock [options] <host> <port[:proto]> <port[:proto]> <port[:proto]>

Na Listagem 1.1, configuramos uma sequência de portas para abrir uma seção do openSSH, portanto o comando knock fica assim: # knock 11.11.11.11 6:tcp 1450:tcp 8156:tcp 22045:tcp 23501:tcp 24691:tcp

O host-alvo tem o endereço IP 11.11.11.11 neste exemplo. Caso deseje, uma combinação de portas UDP e TCP pode ser colocada na Listagem 1.1; nesse caso, a sequência de knocking no lado cliente ficaria assim: # knock 11.11.11.11 6:tcp 1450:udp 8156:udp 22045:tcp 23501:udp 24691:tcp

Segurança em Servidores Linux

Um bom atalho é, caso deseje usar somente portas UDP, simplesmente acrescentar -u no início do comando, em vez de especificá-lo de forma explícita. Um comando para portas UDP pode rodar de uma forma parecida com esta: # knock -u 11 22 33 44 55

Voltemos ao arquivo de configuração do servidor para ver como TCP e UDP podem ser intercambiados dentro da sequência de knocking válida. Para misturar os protocolos, basta alterar a linha sequence na seção openSSH conforme explicado a seguir: [openSSH] sequence = 6:tcp 1450:udp 8156:udp 22045:tcp 23501:udp 24691:tcp

Como tornar o servidor invisível Quando estiver confiante de que a instalação está funcionando da forma desejada, o servidor deve ser bloqueado para escondê-lo de invasores. Um invasor pode estar ciente do endereço IP do servidor e, de alguma forma, conseguir enxergar o tráfego enviado e recebido por meio dele (por exemplo, o agressor pode trabalhar para o provedor de serviços de hospedagem). Por isso, o servidor deve estar invisível a usuários da internet. Se estiver à vista de todos, qualquer um pode fazer experiências com o seu firewall – incluindo eu. No entanto, para obter o status de porta fechada no Nmap, adoto a abordagem a seguir.

Teste do iptables Como disse antes, uso o iptables, que é, na opinião de quase todo mundo, bastante confiável. O ideal é ter acesso físico ao servidor antes de bloqueá-lo, pois se o estivermos operando remotamente ficaríamos trancados do lado de fora caso criemos uma regra errada. Na eventualidade de um problema, devemos contar com um acesso local, que independa de conexão com a internet, como o console de uma máquina virtual, uma interface de rede secundária na qual se possa fazer o login ou um modem discado (dial-up) acoplado à máquina. É preciso estar ciente de que, salvo por

Capítulo 1 ■ Manto de invisibilidade

um teste prévio da configuração em uma máquina de desenvolvimento, há uma chance muito grande de cometer um erro e arranjar problemas. Mesmo tendo usado o port knocking antes, ocasionalmente ainda sou pego de surpresa e fico sem acesso a um servidor. Com esse alerta em mente, vamos começar olhando os comandos do iptables. É preciso tomar cuidado ao integrar estas regras com quaisquer outras regras anteriores. É aconselhável somente sobrescrever as regras existentes após a realização de um backup. Em primeiro lugar, é preciso assegurar que o servidor pode conversar com ele próprio pela interface localhost: # iptables -A INPUT -s 127.0.0.0/8 -j ACCEPT

É preciso agora estar seguro de que quaisquer conexões existentes são reconhecidas e podem emitir respostas: # iptables -A INPUT -m conntrack—ctstate ESTABLISHED,RELATED -j ACCEPT

O conntrack está sendo usado para rastrear as conexões existentes. Uma vez inicializadas com sucesso, as conexões podem continuar a operar. Agora, assumindo que somente a porta TCP 22 do servidor SSH vai ser aberta e que o servidor não oferecerá nenhum outro serviço, podemos prosseguir. Lembre-se de que, na Listagem 1.1, usamos o seguinte comando para abrir a porta TCP 22: command = /sbin/iptables -I INPUT -s %IP% -p tcp—dport 22 -j ACCEPT

Preste atenção a essa linha. Se usarmos a ação “append” do iptables, ou seja, -A INPUT no comando, seremos trancados para fora, pois a regra será inserida no final da lista de regras. Um -I de “insert” deve ser digitado para que a regra seja introduzida na primeira posição da lista e tenha precedência sobre as demais. Você deve estar se perguntando o que significa a variável %IP%. O port knocking tem inteligência suficiente para substituir a variável %IP% pelo endereço IP da conexão no campo -s. Agora chegamos ao ponto em que deve ser tomado muito cuidado. Não há retorno caso as coisas não funcionem como esperado, portanto neste caso as regras devem ter sido testadas em uma máquina virtual ou o

Segurança em Servidores Linux

servidor deve poder ser acessado por caminhos alternativos. O bloqueio de todo o tráfego entrante no servidor pode ser feito da seguinte maneira: # iptables -A INPUT -j DROP

O comando a seguir lista todas as regras do iptables. Em condições normais, não veremos qualquer menção à porta TCP 22 e à sua porta SSH: # iptables -nvL

No entanto, quando fazemos login via SSH e usando o port knocking, a regra liberando a porta 22 será vista no iptables (o tempo em que a regra estará ativa depende do valor usado em cmd_timeout; um valor muito baixo fará com que a regra apareça muito brevemente na lista) se o login tiver sido feito com sucesso. Se houver problemas a esta altura, continue lendo: veremos mais adiante algumas formas de testar a configuração e aumentar os níveis de logging. Caso contrário, temos um servidor cujas portas são todas informadas como não existentes, tornando assim o servidor invisível, conforme mostrado na Figura 1.1.

Figura 1.1 – O Nmap parece considerar que não existe máquina naquele endereço IP.

Gravando as regras do iptables As regras do iptables só existem na memória; não estão gravadas em nenhum arquivo ainda. Para assegurar que sobrevivam a uma reinicialização, um pacote denominado iptables-persistent deve ser instalado em derivados do Debian: # apt-get install iptables-persistent

As regras podem então ser salvas com o comando: # /etc/init.d/iptables-persistent save

Capítulo 1 ■ Manto de invisibilidade

A configuração salva pode ser recarregada na memória rodando este comando: # /etc/init.d/iptables-persistent reload

Em derivados do Red Hat (em máquinas que ainda não têm systemd), este comando pode ser usado: # /sbin/service iptables save

E para restaurar as regras, o comando é: # /sbin/service iptables reload

Para que o exposto anteriormente funcione em derivados do Red Hat que já tenham systemd, é preciso instalar este pacote primeiro: # yum install iptables-services

Outras considerações Há alguns aspectos relacionados ao port knocking que podem ser úteis. Vamos dar uma olhada neles agora.

Cliente para smartphone Em meu smartphone Android, meu app SSH preferido é o JuiceSSH (https://juicessh.com). Ele tem um plugin de terceiros que permite configurar uma sequência de knocking como parte do handshake SSH. Isso significa que não há desculpa para não empregar o port knocking, mesmo se estiver na rua e sem um laptop.

Pesquisa de problemas O comando tail -f logfile.log permite examinar arquivo de log do port knocking em tempo real. Com ele, podemos observar diversos estágios do processo sendo escritos no log, o que inclui o fato de uma porta válida ter sido acessada e, muito importante, se as portas configuradas foram “batidas” na sequência correta ou não.

Segurança em Servidores Linux

Podemos aumentar os níveis de logging produzidos pelo knockd ativando a opção de depuração. Abra o arquivo /etc/init.d/knockd (com cuidado para não modificar nada) e procure pela linha OPTIONS. É possível acrescentar um caractere D maiúsculo (Shift+d) em quaisquer valores existentes nesta linha, conforme mostrado a seguir: OPTIONS = "-d -D"

O logging adicional deve ser desativado depois da realização do diagnóstico e da solução do problema, para evitar perda desnecessária de espaço em disco. O -d significa que o knockd roda como um daemon, caso alguém esteja se perguntando. Ele deve ser deixado como está para operação normal. Retornemos ao cliente por um momento. O nível de detalhes na saída também pode ser aumentado, algo que o cliente “knock” gera pelo acréscimo de uma opção -v. Em conjunto com a opção de depuração no servidor, isso deve fornecer informação proveitosa dos dois lados da conexão.

Considerações de segurança Quando as informações associadas a um servidor são divulgadas, devemos ter em mente que é necessário solicitar ao provedor de conexão à internet para não publicar diretamente seu endereço IP público, seja por DNS direto, seja por DNS reverso. Seu endereço IP deve aparecer como não usado ou não alocado, ficando dessa forma invisível. Mesmo em serviços públicos como HTTP, as versões dos daemons sendo utilizadas devem ser ofuscadas. A forma corriqueira de fazer isso no servidor mais popular da web, o Apache, é alterar o ServerTokens para “Prod” e configurar ServerSignature para “Off”. Estas são alterações de configuração altamente avançadas, porém podem significar que um ataque automatizado ignore seu servidor quando um novo ataque de dia zero (zero-day exploit) é descoberto, pois o número de versão do seu Apache não estava no banco de dados do agressor. Outro aspecto a ser considerado é discutido na documentação do knockd. Ela menciona que se você usar as opções -l ou --lookup para resolver nomes de máquina em suas entradas de log, pode estar incorrendo em um risco

Capítulo 1 ■ Manto de invisibilidade

de segurança. Se isso for feito, há uma chance de vazamento de informações para um invasor, que pode ter condições de determinar a primeira porta de uma sequência se conseguir capturar o tráfego DNS do servidor.

Sequências efêmeras Que tal usar uma abordagem diferente para as sequências de knocking? Também é possível usar o port knocking com uma lista predefinida de sequências de porta que expiram depois que foram usadas apenas uma vez. Consultando novamente a Listagem 1.1 e o arquivo de configuração principal, podemos acrescentar, caso assim desejemos, a opção a seguir às seções open e close para habilitar as sequências de evento único: [openSSH] One_Time_Sequences = /usr/local/etc/portknocking_codes

Se a linha sequence for removida da Listagem 1.1 e substituída por esse código, o knockd então seguirá as sequências conforme o arquivo especificado no caminho. O knockd lida com as sequências de tempo único de uma forma não usual. Ele lê a próxima sequência disponível do arquivo e comenta aquela linha, seguida de uma conexão realizada com sucesso com um knock válido. Ele simplesmente acrescenta um caractere # ou hash ao início da linha que tiver a sequência presente. A próxima conexão aciona a mesma sequência. A documentação estabelece que deve ser deixado um espaço no início de cada linha. Caso contrário, quando o caractere # for acrescentado ao início da linha, pode-se pensar que ele foi sobrescrito de forma não intencional, significando então a ocorrência de um bloqueio. No arquivo de sequências, podemos acrescentar uma sequência por linha. Esse arquivo segue o mesmo formato que na opção sequences dentro do arquivo de configuração principal. A documentação também ressalta que podem ser inseridos comentários colocando na frente deles o caractere #, porém isso pode acarretar problemas (como ficar com o acesso ao servidor bloqueado) se o arquivo de sequências for editado enquanto o knockd ainda estiver rodando.

Segurança em Servidores Linux

Uma vez compreendidos os recursos básicos do knockd, é uma excelente hora de experimentá-lo. Durante o teste, podem ser digitados números de telefone ou alguma outra sequência de números que possa ser memorizada depois, de modo a garantir que não estamos lidando continuamente com uma lista insegura. Por exemplo, uma rotatividade entre cinco números telefônicos pode ser considerada, dividindo-os entre números de porta válidos.

Resumo Além de tornar um servidor invisível, expliquei como esse servidor aparece na internet antes do lançamento de um ataque. Para que um servidor seja totalmente ofuscado com o uso do port knocking, o uso de informações públicas, como entradas de DNS reverso, deve ser pensado com muito cuidado, o que pode levar à desistência de um endereço IP como se ele estivesse em uso. O uso de NAT para esconder um servidor e fazer a troca dinâmica periódica do endereço IP pode também ser considerado, deixando que somente administradores conheçam qual endereço IP está em uso em um determinado momento por meio de um nome de usuário secreto, publicado de forma sigilosa em DNS em um Nome de Domínio não usual. Há muitas outras maneiras de proteger um servidor. De qualquer modo, espero ter dado informações suficientes para fazer o leitor considerar que tipo de informação é vazada publicamente e que possa ser potencialmente usada em ataques futuros, bem como para esconder um servidor caso seja necessário fazê-lo.