A Slackware Linux precisa de nós!

Slackware logo

Hoje trago a vocês um assunto que muitos de nós ignora, na maior parte do tempo, quando lidamos com softwares livres: projetos precisam de suporte. Não digo apenas suporte colaborativo, onde usuários e entusiastas destes projetos contribuem com tempo e esforço para manter determinado sistema operacional, ou aplicação, sempre atualizado, mas também necessitam de suporte financeiro.

Afinal, servidores de desenvolvimento, teste e produção, bem como links de internet, armazenamento em repositórios principais, energia elétrica, entre outros recursos, e só para citar alguns, não se mantêm apenas com boa vontade, é preciso investimento monetário, além de manutenção.

Esta semana, mais especificamente no dia 27 de julho, acompanhando o changelog da distribuição Slackware Linux como costumo fazer, me deparei com uma postagem do Patrick Volkerding a respeito da dificuldade financeira enfrentada por ele e sua família, e que sem sombra de dúvida afetam diretamente o desenvolvimento da distribuição.

A postagem me deixou boquiaberto com a situação relatada, onde o mantenedor da distribuição informa que há dois anos não recebe qualquer contrapartida referente à Slackware Store, que só agora fiquei sabendo se tratar de uma empresa gerida por terceiros, e da qual o Patrick deveria receber 40% dos lucros, além de convênio médico para ele e sua família, mas que também foi suspenso desde o nascimento da filha. Essas informações complementares foram oferecidas também pelo Pat em uma discussão aberta no LinuxQuestions.org.

A situação financeira do Patrick é crítica, e demandou uma grande humildade de sua parte para ser exposta à comunidade que, assim como eu, também desconhecia o acordo comercial para exploração da marca, imaginando se tratar de algo gerido diretamente pelo idealizador da distribuição.

O desapontamento fica ainda maior quando sabemos que o parceiro comercial repassou a titularidade da empresa sem ao menos informar essa mudança ao Patrick, e que a última contrapartida recebida, volto a frisar, que ocorreu há dois anos, foi de apenas quinze mil dólares para vendas no valor de cem mil dólares!

Sim, a conta não faz sentido para ninguém, e o que o “parceiro” alega é que a diferença foi “investida” em produtos que ele achou que deveria, e que portanto, na verdade, ele acredita que o Patrick recebeu um valor maior do que deveria! Pode isso Arnaldo?! Claro que não! E muitos de nós, usuários ou não da distribuição, concordam que não!

Em resposta a esses relatos, vários dos assinantes estão cancelando suas subscrições junto à loja que achávamos ser de propriedade do projeto, e discutindo formas alternativas de contribuir diretamente para a manutenção do mesmo, sem que exista um intermediário sugando quase a totalidade dos valores arrecadados.

Um link foi disponibilizado para contribuição via PayPal, e através do qual podemos doar diretamente ao Patrick, ajudando a manter a distribuição viva, bem como colaborando para a manutenção pessoal de seu mantenedor principal e sua família.

Conforme pode ser visto no post do dia 26 de julho, no blog Alien Pastures, mantido pelo Alien Bob, outro dos principais desenvolvedores da Slackware Linux, a discussão sobre o futuro da distribuição tomou grandes proporções, partindo do financeiro para outras frentes, como a inclusão de funcionalidades como PAM, atualização do KDE para o Plasma 5, entre outras.

Eu também estava pensando que poderia fazer pouco, visto que sou apenas uma pessoa, mas uma conta simples feita pelo Alien Bob mostrou que hoje existe algo em torno de dois mil assinantes de atualizações da distribuição e que, se cada um doasse apenas um Euro por mês, já seria possível arrecadar dois mil Euros por cada período, o que já seria um belo começo!

Essa discussão também envolve outras formas de colaboração, e está sendo realizada no LinuxQuestions.org, incluindo sugestões como a utilização do Patreon, envio para caixa postal pessoal do Patrick, Liberapay, entre outras, porém a forma oficial de contribuir, pelo menos por enquanto, é usando o link para doação através do PayPal.

Outras necessidades foram relatadas, como a manutenção da página oficial da Slackware Linux, que precisa de atenção e reorganização através de habilidades que o Patrick não dispõe, sendo algo que a meu ver pode ser realizado por voluntários dispostos a ajudar, mas que ainda deve ser objeto de discussão mais profunda.

Se você, assim como eu, acha que a Slackware Linux é uma distribuição que vale a pena ser mantida, contribua! Participe da discussão! Ofereça sugestões! Eu já estou me organizando para passar a contribuir de forma mais direta do que apenas escrevendo sobre a distro. Juntos podemos manter viva a chama desta que, ainda é, a distribuição mais antiga ainda em desenvolvimento, tendo completado 25 anos na semana passada. Até a próxima!

Anúncios

Red Team vs Blue Team? O que isso quer dizer na segurança da informação?

team_blue_vs_team_red_logo

No mundo da segurança cibernética, estar um passo a frente dos possíveis atacantes à nossa infraestrutura pode ser o que definirá as nossas chances de sucesso na reação quando um ataque surgir, e para tanto muitas empresas utilizam táticas de simulação para a realização de testes quanto a capacidade de resposta a incidentes de segurança.

Um exemplo desse tipo de procedimento envolve utilizar grupos de profissionais de TI, divididos em times, e que objetivam atacar ou defender a infraestrutura das empresas envolvidas para tentar evidenciar pontos fracos e fortes de suas soluções de proteção de dados.

Nesse tipo de verificação, a equipe responsável pelo ataque deve valer-se de sua expertise para tentar atingir um objetivo definido pela alta direção, realizando sofisticados testes de penetração e buscando pontos de falha nos processos, pessoas e tecnologias que compõem as defesas atualmente em uso na empresa para o cumprimento da missão. Essa equipe é apelidada de Red Team.

Neste cenário, o Red Team agiria como uma ameaça externa, que buscaria localizar quaisquer vulnerabilidades possíveis de serem exploradas, objetivando, por exemplo, extrair dados da localidade predeterminada pela alta direção. Idealmente este time deve ser composto por profissionais que não tenham contribuído para a estratégia de defesa atualmente aplicada na empresa, pois isto poderia gerar um conflito de interesses em relação aos testes, a partir da atitude de não querer buscar realmente, ou mesmo expor, as fraquezas disponíveis na infraestrutura da corporação, e que não tenham sido cobertas pelas defesas que ajudaram a implantar.

O foco em realmente “quebrar” a segurança implantada deve dirigir a vontade do Red Team na busca por brechas de segurança, o que pode envolver as mais diversas táticas, desde a utilização de ataques spear phishing, ou até mesmo a simples tática da utilização de pendrives infectados, deixados nos arredores da empresa.

Em contrapartida, a equipe responsável por defender essa infraestrutura, apelidada de Blue Team, deve buscar identificar através de logs, monitoramento de ativos, tráfego de dados, comportamento anômalo, entre outros recursos, os possíveis vetores de acesso que o time ofensivo utilizará para tentar obter êxito na invasão, e buscando frustrar estes planos de acesso. Esse time é geralmente formado pela equipe de resposta e tratamento de incidentes de empresa avaliada, apoiada pelo centro de operações de segurança.

O desenvolvimento deste tipo de atividade permite a realização de testes controlados de invasão, bem como a efetividade dos procedimentos de segurança adotados e do treinamento da equipe de resposta a incidentes na proteção do ambiente corporativo pois, através dos relatórios de ação e reação de cada uma das equipes, é possível identificar pontos fortes e fracos na infraestrutura e estratégia de defesa, permitindo a antecipação do que poderia vir a ser uma exploração real de vulnerabilidades, além dos ajustes necessários para uma proteção ou treinamento mais eficiente.

É recomendável a realização periódica deste tipo de teste, bem como a revisão dos procedimentos previstos para os casos de incidentes de segurança, a atualização constante do conhecimento das equipes sobre os diversos tipos de ataques, além de treinamento e aperfeiçoamento na utilização de técnicas e ferramentas de defesa disponíveis, buscando sempre a elevação dos níveis de segurança no ambiente corporativo.

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 atualmente 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 correr bem, ao final do carregamento do sistema você poderá confirmar a versão do kernel 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 os mesmos sejam sobrescritos 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

Insira as linhas acima, salve o arquivo e saia. Replique o procedimento em todos os seus sistemas Slackware Linux, e aplique as atualizações disponíveis para aqueles que não sejam desta mesma distribuição.

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 afetará mais o seu ambiente atualizado.

Quando se sentir mais a vontade em 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 compatíveis com os equipamentos de que dispõe, sistemas de arquivos com os quais não lida, entre outras, 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 arquivo lilo.conf, poderá sempre carregar o kernel anterior em caso de remover alguma funcionalidade essencial do sistema. Caso tudo dê certo, poderá 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!