Dirty Cow na Slackware Linux?

dirty_cow

Essa era uma dúvida que também me deixava com aquela coceirinha no cérebro, afinal a vulnerabilidade Dirty Cow é um dos assuntos mais comentados no campo da segurança em sistemas GNU/Linux, já que várias versões do kernel Linux se mostraram afetadas, porém alguns distribuidores começaram a disponibilizar pacotes com atualizações para a correção de suas respectivas distribuições, podendo ser citadas aqui a Red Hat, CentOS, Ubuntu, Debian, entre outras, por exemplo.

A busca sobre as versões afetadas ainda retornam informações confusas, mas como pode ser visto no site do CERT, a vulnerabilidade aparentemente afeta a grande maioria das versões do kernel Linux posteriores à versão 2.6.22, mas já corrigida nas versões 4.8.3, 4.7.9 e 4.4.26.

A mesma página que nos trás essas informações, oferece uma lista de distribuições onde consta, ao lado de cada uma, os seus respectivos status com relação à vulnerabilidade. Até o momento em que escrevo esse artigo, a Slackware Linux aparece na lista com status de “desconhecido” para a presença da vulnerabilidade.

Acessando a página oficial da Slackware, vemos que até o momento não há alertas de segurança para a vulnerabilidade, e a mais recente atualização nesse sentido foi em primeiro de outubro, relativa ao Mozilla Thunderbird.

Sabemos que o kernel Linux mais recente, disponibilizado até o momento na distribuição, é a versão de número 4.4.23, liberada também no dia primeiro de outubro, inclusive na árvore current, e que não consta entre as versões imunes, mas que devido a não existir confirmação de ser afetada nos perguntamos, o que fazer? Bem, temos algumas opções:

  • Aguardar o comunicado oficial dos mantenedores da distro, para então saber se há necessidade ou não de atualização, mas correndo o risco de ter a segurança de nossos sistemas comprometidos;
  • Baixar e aplicar o patch de atualização, alterando a versão atual para a qual é sabido não ser vulnerável, que é a 4.4.26;
  • Ou aproveitar a deixa e atualizar o kernel para a versão estável mais recente, que é a 4.8.4, e que também atende à nossa necessidade.

Já que de qualquer forma seria necessário reiniciar o equipamento, para que o kernel da versão corrigida passasse a ser utilizado no lugar do anterior, escolhi a última das três opções, atualizando para a versão estável mais recente no momento.

Compilando e instalando um novo kernel

O procedimento não é muito complicado, mas pode deixar o sistema inoperante caso seja conduzido de forma errada, portanto, caso queira realizá-lo, pode seguir os passos que realizei, porém por sua conta e risco.

De qualquer maneira, o recomendado é manter os backups sempre atualizados com os dados que deseja reter, facilitando a recuperação em caso de necessidade. Vai continuar? Então siga em frente!

Primeiramente verifique a versão do seu sistema:

# uname -a

Ou apenas:

# uname -m

Veja se aparecerá a informação de que é um kernel x86_64, para o caso de ser 64 bits, ou mesmo i686 ou x86 para versões de 32 bits.

Baixe o kernel Linux estável mais recente a partir do site The Linux Kernel Archives:

# wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.8.4.tar.xz

Mova o arquivo para a pasta do sistema onde fica o código fonte do kernel:

# mv linux-4.8.4.tar.xz /usr/src/

Vá para a pasta onde o mesmo foi movido e o descompacte:

# cd /usr/src/

# xz -d linux-4.8.4.tar.xz

# tar -xvf linux-4.8.4.tar

Remova o link simbólico existente:

# rm linux

Crie um link simbólico para o diretório com o novo código fonte do kernel:

# ln -s linux-4.8.4 linux

Acesse o diretório onde o conteúdo do arquivo foi descompactado:

# cd linux

A partir dele, temos algumas opções de configuração do novo kernel mas, primeiramente, só para o caso de não ser a primeira vez que um kernel é compilado em seu sistema, o ideal é “limpar” os arquivos anteriores, porém preservando a configuração, utilizando o comando a seguir:

# make clean

Agora, para evitar muita demora e maiores erros na hora de configurar o novo kernel, utilize a opção de comando de configuração que aproveita a configuração anterior e apenas questiona sobre as novas funcionalidades:

# make oldconfig

Com esse comando todas as configurações anteriormente selecionadas pelo time de desenvolvedores é preservada, e as perguntas sobre as novas funcionalidades também tem as respostas padrão previamente selecionadas. Caso não queira realizar modificações, basta manter a tecla enter pressionada e todas as opções padrão serão escolhidas durante a apresentação das perguntas.

No meu caso, a versão instalada é de 32 bits, portanto a primeira pergunta foi se eu desejava compilar um kernel de 64 bits, opção que deixei desmarcada. Outra pergunta era referente à compressão a ser usada, à qual escolhi a opção bzimage. Para o restante mantive as respostas padrão para as perguntas. Tão logo elas terminem, o arquivo com a configuração do novo kernel estará pronto.

Agora compile o kernel:

# make bzImage

Tenha atenção para a letra I maiúscula. Ela deve ser digitada desta forma mesmo.

Caso seu sistema possua mais de um processador, é possível acelerar esse processo dividindo a carga da compilação entre eles, por exemplo, para um sistema com 6 processadores você poderá usar o comando acima com a opção -j <nº de processadores>, o que conforme o exemplo sugerido seria:

# make -j6 bzImage

Tão logo o processo de compilação seja concluído, você pode compilar os módulos:

# make modules

Esse processo é bem mais rápido, e tão logo seja concluído você já poderá instalá-los:

# make modules_install

Agora é preciso mover a imagem do kernel compilado para a pasta à qual se destina, em /boot. Geralmente esta imagem tem o nome de vmlinuz, portanto ao mover a nova imagem, renomei-a de forma diferente, assim como fiz no exemplo abaixo. Isso facilitará sua vida nos passos seguintes:

# mv arch/x86/boot/bzImage /boot/vmlinuz-4.8.4-x86

Módulos instalados, e imagem no lugar, agora deve alterar o bootloader para que receba o novo kernel como opção de carregamento. É aqui que entra a facilidade citada anteriormente, pois caso simplesmente substituíssimos a imagem anterior pela nova, e algo desse errado, teríamos mais trabalho para restabelecer o sistema, ao passo de que agora só precisamos escolher o kernel que queremos carregar.

Para editar o lilo, acesse seu arquivo de configuração em /etc, como no exemplo abaixo:

# vi /etc/lilo.conf

Altere o conteúdo do arquivo, adaptando-o para a partição correspondente em seu sistema. As últimas linhas do arquivo anteriormente eram assim:

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only
# Linux bootable partition config ends

Agora ficaram assim:

# Linux bootable partition config begins
image = /boot/vmlinuz-4.8.4-x86
   root = /dev/sda2
   label = Slackware_4.8.4
   read-only

image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only
# Linux bootable partition config ends

Isso insere a opção de carregamento do novo kernel. Salve o arquivo e saia. Agora execute a gravação da nova configuração na MBR:

# lilo

Feito isso, basta reiniciar o sistema e escolher a opção no menu de inicialização que corresponde ao nome que definiu para o carregamento do novo kernel, verificando se o mesmo será carregado normalmente.

Caso o procedimento não funcione, ainda poderá carregar o sistema através da opção existente anteriormente e tentar realizar o procedimento novamente para ver onde pode ter ocorrido algo errado.

Se tudo correer bem ao final do carregamento do sistema, você pode confirmar a versão em uso através do terminal novamente com o comando uname, verá algo parecido com o exemplo a seguir:

# uname -r

4.8.4

Também é recomendável adicionar os pacotes referentes ao kernel à blacklist, evitando que o mesmo seja sobrescrito quando utilizar o slackpkg para realizar alterações no sistema:

# vi /etc/slackpkg/blacklist

kernel-generic
kernel-generic-smp
kernel-huge
kernel-huge-smp
kernel-modules
kernel-modules-smp

Salve o arquivo e saia. Replique o procedimento em todos os seus sistemas, e aplique as atualizações disponíveis para aqueles que não sejam Slackware Linux.

Como tudo funcionou por aqui, agora já sabe porque a dúvida não me perturba mais e, caso tenha realizado os procedimentos acima com sucesso, também pode voltar à tranquilidade pois a vulnerabilidade não afeta mais o seu ambiente.

Quando se sentir mais a vontade para explorar as opções disponíveis para a configuração do kernel, você poderá realizar o processo novamente, mas agora verificando as especificações do seu equipamento e desmarcando as opções que não se encaixam, como por exemplo drivers de rede que não sejam os que dispõe, sistemas de arquivos com os quais não lida, entre outros, deixando assim o núcleo do sistema mais enxuto e rápido.

Se a cada procedimento tomar o cuidado de adicionar a nova imagem com um nome diferente no diretório /boot, além de mais uma seção ao lilo, poderá sempre carregar o kernel anterior em caso de remover alguma funcionalidade essencial do sistema e, caso tudo dê certo, remover a entrada para o kernel anterior, bem como a sua imagem do diretório de inicialização.

Espero ter ajudado e até a próxima!

Dica de segurança em servidores Slackware com SSH habilitado

Slackware logo

Sim, você provavelmente já viu um texto com esse título, e vai notar que também trato do mesmo assunto, que é apenas uma dica trivial para a implementação de segurança básica e inicial em servidores que utilizem acesso via SSH, principalmente aqueles que estão disponíveis a acesso externo ( leia-se Internet ).

O artigo que escrevi anteriormente foi postado em outro blog, e foi uma pequena contribuição para a difusão de experiências que temos, e que optamos por compartilhar com a comunidade, facilitando a iniciação daqueles que tenham interesse em assuntos diversos, tratados pelos profissionais que lá queiram dividir seus conhecimentos.

No post original, eu tratei sobre a customização do arquivo de configuração do serviço de SSH em um servidor com sistema operacional GNU/Linux, mais especificamente a distribuição CentOS, então quis registrar o assunto aqui também, utilizando a nossa querida Slackware Linux.

Caso já tenha lido o post original, este não lhe trará nenhuma informação nova, sendo apenas uma adaptação para outra distribuição GNU/Linux, mas, caso ainda não o tenha lido, e assim como eu, utilize a distribuição Slackware, então talvez ache essa pequena dica algo interessante de se compartilhar com alguém que talvez precise. 🙂

Como é de conhecimento geral, uma das primeiras providências que possíveis invasores tomam, tão logo escolhem um alvo, é iniciar a coleta de informações a respeito deste, e quando este está disponível para acesso através da Internet, entre essas atividades de reconhecimento inicial está a varredura de portas, buscando possíveis pontos de entrada no sistema.

Um destes pontos de entrada pode ser o serviço de SSH, que geralmente é deixado habilitado como forma de acessar remotamente esses servidores, e é por isso que precisamos reconfigurar esse serviço para que não tentem utilizá-lo para obtenção deste acesso com o único usuário de que eles tem certeza que existe no sistema alvo, e esse usuário é o root. A dica é simplesmente configurar o serviço de forma que o acesso como superusuário não seja possível, e para tanto devemos seguir alguns passos. Para este tutorial, utilizei a versão estável mais recente da Slackware Linux, que é a 14.1, sendo que a versão 14.2 não deve demorar muito mais para ser lançada.

Através da linha de comando, já com privilégios de root, vamos acessar o arquivo de configuração do serviço, localizado no diretório /etc. Com o editor de textos para linha de comando de sua preferência, edite o arquivo /etc/ssh/sshd_config. Utilizando o vi seria:

# vi /etc/ssh/sshd_config

Localize a linha com a opção que precisamos alterar. Ainda utilizando o Vi bastaria utilizar o caractere “/” para realizar a busca:

/#PermitRootLogin

Isso nos levaria à linha que precisamos mudar. Ela estaria assim:

#PermitRootLogin yes

Utilize a tecla insert para entrar em modo de edição no Vi e navegue pela linha, alterando-a para deixá-la assim:

PermitRootLogin no

Em seguida vá até o final deste arquivo e adicione um campo chamado AllowUsers. Este campo será utilizado para explicitar quais usuários terão acesso remoto via SSH autorizado. Veja o exemplo utilizado em meu post anterior:

AllowUsers=fulanodetal

Isso faria com que apenas o usuário fulanodetal pudesse acessar o sistema utilizando o protocolo SSH, e outros usuários, mesmo tendo contas configuradas no servidor, não conseguiriam autorização de acesso. Caso queira que outros usuários tenham acesso, basta listá-los entre os permitidos, separando-os por vírgulas. Após o término de adições basta salvar o arquivo e voltar ao prompt do shell. No caso do Vi seria a combinação de teclas ctrl+x.

Essa deve, ou deveria ser, uma das primeiras medidas de segurança a ser implantada, e não demora quase nada para que se torne efetiva. Bastando agora que o serviço seja reiniciado para que as mudanças sejam efetivadas. O comando para reiniciar o SSH varia de acordo com a distribuição utilizada. No nosso caso, utilizamos os comandos a seguir:

# /etc/rc.d/rc.sshd stop

# /etc/rc.d/rc.sshd start

Como também esclareci no post anterior, existem outras opções que podem ser modificadas no arquivo, e que são interessantes para ampliar essa proteção, como por exemplo o tempo permitido pelo sistema para que a pessoa entre com as credenciais de acesso, a quantidade de tentativas em sequência que a pessoa pode tentar antes de ser desconectada, entre outras, portanto vale a pena explorá-las, modificá-las de acordo com as suas necessidades, não esquecendo é claro de sempre salvar o arquivo com essas modificações e reiniciar o serviço sempre que desejar aplicar novas alterações.

Recomendo ainda que coloque a porta, na qual o serviço está habilitado, sob a proteção do firewall. Em nosso caso, o IPTables é o firewall que acompanha a Slackware Linux, e para proteger o serviço SSH vamos adicionar algumas regras a ele. Essas regras foram retiradas de um outro artigo, publicadas em um outro blog, pertencente à rackAID, e que tem por objetivo proteger os sistemas contra ataques de força bruta:

# iptables -N LOGDROP

# iptables -A LOGDROP -j LOG

# iptables -A LOGDROP -j DROP

# iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –set

# iptables -I INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j LOGDROP

Isso fará com que um endereço IP seja bloqueado caso tente acesso mais de três vezes durante um minuto. As regras implicam somente os casos de novas conexões, não impactando as que sejam bem sucedidas. Além disso, a configuração permitirá o registro destas tentativas através de logs.

Para confirmar que as regras foram acrescidas, basta listá-las como normalmente faria:

# iptables – L

Bem essa era a dica, agora com foco na implementação em uma distribuição Slackware Linux. Espero que tenham gostado. Até a próxima!

Correção para a vulnerabilidade Ghost

Segurança na web

Uma vulnerabilidade crítica de segurança foi publicada dia 27 deste mês, por pesquisadores da Qualys, e que provavelmente afeta todos os sistemas GNU/Linux que utilizam a biblioteca glibc, em versões que datam desde o ano 2000. Esta vulnerabilidade permite a atacantes, que a explorem com sucesso, obter acesso completo à máquina vulnerável, sem a necessidade de nenhum conhecimento prévio de credenciais válidas na mesma. A falha de segurança foi registrada no site Common Vulnerabilities and Exposures sob o registro CVE – 2015 – 0235.

Como vetores principais de ataques, os pesquisadores da Qualys afirmam que podem ser visados agentes de transferência de mensagens como o Exim, além de outros que possibilitem a utilização de uma gama de ferramentas de diagnóstico de rede através da web, como por exemplo páginas que permitam a execução do comando ping ou traceroute.

Entre as distribuições GNU/Linux afetadas pelo problema, encontramos versões recentes, estáveis e de suporte extendido, como a Debian 7 (wheezy), Red Hat Enterprise Linux 6 e 7, CentOS 6 e 7, Ubuntu 12.04, por exemplo, além das versões 13.0, 13.1, 13.37, 14.0 e 14.1 da Slackware Linux, e todas as versões da Slax, só para citar algumas. Para uma lista mais extensa de distribuições afetadas, acessem este link, que aponta para o blog matasanosecurity.

Embora seja de menor potencial ofensivo que as recentes falhas no Bash ou a conhecida como Heartbleed, não significa que a mesma não deva ser corrigida, e os pesquisadores da Qualys trabalharam rápido, juntamente com as equipes de desenvolvimento das distribuições, e já disponibilizaram patch de correção para a biblioteca.

Segundo o CEO da Rapid7, e criador do Metasploit, HD Moore, esta não é uma vulnerabilidade fácil de ser explorada, mas que pode vir a ser desastroso caso seja, portanto ele recomenda que a correção seja aplicada aos sistemas imediatamente e que estes sejam reinicializados, pois sem uma reinicialização os serviços utilizando a antiga biblioteca não serão atualizados.

A correção de segurança já está disponível para todas as distribuições afetadas. Para maiores informações sobre o caso, acessem o artigo original, no site Threat Post.