14.6. Outras Considerações Relacionadas a Segurança
Segurança não é apenas um problema técnico, mais do que qualquer coisa, é sobre as boas práticas e compreensão dos riscos. Esta seção examina alguns dos riscos mais comuns, bem como algumas das melhores práticas que deverão, dependendo do caso, aumentar a segurança ou diminuir o impacto de um ataque bem sucedido.
14.6.1. Riscos Inerentes a Aplicações Web
O caráter universal das aplicações web levou à sua proliferação. Diversas são frequentemente executadas em paralelo: um webmail, um wiki, algum sistema de groupware, fóruns, uma galeria de fotos, um blog, e assim por diante. Muitas dessas aplicações dependem da pilha "LAMP" (Linux, Apache, MySQL, PHP). Infelizmente, muitas dessas aplicações também foram escritas sem considerar muito os problemas de segurança. Dados provenientes do exterior são, muitas vezes, utilizados com pouca ou nenhuma validação. Proporcionando valores criados especialmente para serem usados para destruir uma chamada para um comando de modo que um outro seja executado em vez disso. Muitos dos problemas mais óbvios foram corrigidos com o parrar do tempo, mas novos problemas de segurança surgem regularmente.
Updating web applications regularly is therefore a must, lest any cracker (whether a professional attacker or a “script kiddy“) can exploit a known vulnerability. The actual risk depends on the case, and ranges from data destruction to arbitrary code execution, including web site defacement.
14.6.2. Sabendo O Que Esperar
A vulnerabilidade em uma aplicação web é frequentemente utilizada como ponto de partida para as tentativas de craqueamento. O que se segue são uma breve revisão das possíveis consequências.
As consequências de uma intrusão terão vários níveis de obviedade, dependendo das motivações do invasor. Os “script-kiddies” só aplicam receitas que encontram em sites; na maioria das vezes, eles desfiguram uma página da web ou excluem dados. Em casos mais sutis, eles adicionam conteúdos invisíveis às páginas da web para melhorar as referências aos seus próprios sites nos mecanismos de busca.
Um atacante mais avançado vai além disso. Um cenário de desastre poderia continuar da seguinte maneira: o atacante ganha a habilidade de executar comandos como o usuário www-data
, mas a execução de um comando requer muitas manipulações. Para tornar sua vida mais fácil, eles instalam outras aplicações web especialmente concebidas para executar remotamente vários tipos de comandos, como a navegação no sistema de arquivos, examinando as permissões de upload, ou download de arquivos, execução de comandos, e até mesmo fornecer um escudo de rede. Muitas vezes, a vulnerabilidade permite execução de um wget
que vai baixar algum malware em /tmp/
, então o executa. O malware geralmente é baixado de um site estrangeiro que foi previamente comprometido, a fim de cobrir faixas e tornar mais difícil encontrar a verdadeira origem do ataque.
Neste ponto, o invasor tem bastante liberdade de movimento que muitas vezes instalar um IRC bot (um robô que se conecta a um servidor IRC e pode ser controlado por este canal). Este robô é frequentemente usado para compartilhamento de arquivos ilegais (cópias não autorizadas de filmes ou software, entre outros). Um determinado invasor pode querer ir ainda mais longe. A conta www-data
não permite o acesso total à máquina, e o invasor vai tentar obter privilégios de administrador. Ora, isso não deve ser possível, mas se a aplicação web não está atualizada, as chances são de que os programas do kernel e outros também estejam desatualizados, o que às vezes se segue uma decisão do administrador que, apesar de saber sobre a vulnerabilidade, negligenciado para atualizar o sistema, pois não existem usuários locais. O atacante pode então aproveitar essa segunda vulnerabilidade para obter acesso root.
Agora o invasor é o dono da máquina; eles geralmente tentarão manter esse acesso privilegiado pelo maior tempo possível. Isso envolve a instalação de um
rootkit, um programa que substituirá alguns componentes do sistema para que o invasor possa obter novamente os privilégios de administrador posteriormente (consulte também
OLHADA RÁPIDA os pacotes checksecurity e chkrootkit/rkhunter); o rootkit também tenta esconder sua própria existência, bem como quaisquer vestígios da intrusão. Um programa
ps
subvertido omitirá a lista de alguns processos, o
netstat
não listará algumas das conexões ativas e assim por diante. Usando as permissões de root, o invasor conseguiu observar todo o sistema, mas não encontrou dados importantes; assim eles tentarão acessar outras máquinas da rede corporativa. Analisando a conta do administrador e os arquivos do histórico, o invasor descobre quais máquinas são acessadas rotineiramente. Ao substituir
sudo
ou
ssh
por um programa subvertido, o invasor pode interceptar algumas das senhas do administrador, que serão usadas nos servidores detectados… e a invasão pode se propagar a partir daí.
Este é um cenário de pesadelo pode ser evitado através de várias medidas. As próximas seções descrevem algumas dessas medidas.
14.6.3. Escolhendo o Software Sabiamente
Uma vez conhecidos os possíveis problemas de segurança, eles devem ser levados em consideração em cada etapa do processo de implantação de um serviço, principalmente na hora de escolher o software a ser instalado. Muitos sites mantêm uma lista de vulnerabilidades descobertas recentemente, o que pode dar uma ideia do histórico de segurança antes que algum software específico seja implantado. Obviamente, essas informações devem ser ponderadas com a popularidade do referido software: um programa mais amplamente usado é um alvo mais tentador e, como consequência, será examinado mais de perto. Por outro lado, um programa de nicho pode estar cheio de falhas de segurança que nunca são divulgadas devido à falta de interesse em uma auditoria de segurança.
No mundo do software livre, geralmente há um amplo espaço para a escolha, e escolher um pedaço de software em detrimento de outro deve ser uma decisão com base nos critérios que se aplicam localmente. Mais características implicam num aumento do risco de um vulnerabilidade escondida no código; escolher o programa mais avançado para uma tarefa pode realmente ser contraproducente, e uma melhor abordagem é, geralmente, para escolher o programa mais simples que atenda aos requisitos.
14.6.4. Gerenciando uma Máquina como um Todo
A maioria das distribuições Linux instalam por padrão uma série de serviços Unix e muitas ferramentas. Em muitos casos, estes serviços e ferramentas não são necessários para os fins de reais para que o administrador configure a máquina. Como orientação geral em matéria de segurança, softwares desnecessários é melhor desinstalado. Na verdade, não tem sentido garantir um servidor FTP, se uma vulnerabilidade em um serviço diferente, não utilizado pode ser usado para obter privilégios de administrador na máquina inteira.
Seguindo o mesmo raciocínio, firewalls, frequentemente sao configurados para permitir apenas acesso aos serviços que se destinam a ser acessíveis ao público.
Computadores atuais são poderosos o suficiente para permitir a hospedagem de vários serviços na mesma máquina física. De um ponto de vista econômico, uma tal possibilidade é interessante: um só computador para administrar, menor consumo de energia, e assim por diante. Do ponto de vista da segurança, no entanto, esta escolha pode ser um problema. Um serviço comprometido pode levar o acesso a toda a máquina, que por sua vez compromete os outros serviços hospedados no mesmo computador. Este risco pode ser atenuado através do isolamento dos serviços. Isto pode ser alcançado tanto com virtualização (cada serviço sendo hospedado em uma máquina virtual dedicada ou um container), ou com o AppArmor/SELinux (cada serviço daemon tendo um conjunto de permissões adequadamente projetado).
14.6.5. Os Usuários São Jogadores
Discutir segurança imediatamente traz à mente proteção contra ataques de crackers anônimos escondidos na selva da Internet, mas um fato muitas vezes esquecido é que corre o risco de vir também de dentro: um funcionário prestes a deixar a empresa poderia baixar arquivos confidenciais sobre os projetos importantes e vendê-los aos concorrentes, um vendedor de negligente poderia deixar sua mesa sem bloquear a sessão durante um encontro com uma nova perspectiva, um usuário desajeitado poderia excluir o diretório errado por engano, e assim por diante.
A resposta a estes riscos podem envolver soluções técnicas: não mais do que as permissões necessárias devem ser concedidas aos usuários, e backups regulares são uma obrigação. Mas em muitos casos, a proteção adequada vai envolver treinamento de usuários para evitar os riscos.
Não faz sentido garantir os serviços e redes, se os próprios computadores não estiverem protegidos. Dados importantes merecem ser armazenados em discos rígidos hot-swappable em RAID, por que discos rígidos falham eventualmente e a disponibilidade dos dados é um ponto obrigatório. Mas se qualquer entregador de pizza pode entrar no prédio furtivo, na sala do servidor e fugir com alguns discos rígidos, uma parte importante da segurança não está cumprida. Quem pode entrar na sala do servidor? O acesso está monitorado? Estas questões merecem ser consideradas (e uma resposta) quando a segurança física está sendo avaliada.
A segurança física inclui levar em consideração também os riscos de acidentes, como incêndios. Este risco particular é o que justifica armazenar as mídias de backup em um prédio separado, ou pelo menos em um cofre à prova de fogo.
14.6.7. Responsabilidade legal
Um administrador tem, mais ou menos implicitamente, a confiança de seus usuários, bem como os usuários da rede em geral. Eles devem, portanto, evitar a negligência que as pessoas malignas poderiam explorar.
Um invasor assume o controle da sua máquina, em seguida, a utiliza como uma base para avançar (conhecido como “relay system - sistema de revezamento") a partir da qual realizar outras atividades nefastas pode causar problemas legais para você, uma vez que a parte que atacou inicialmente iria ver o ataque proveniente de seu sistema e, portanto, considerá-lo como o atacante (ou como cúmplice). Em muitos casos, o atacante usará o servidor como um relé para enviar spam, que não deve ter muito impacto (exceto possivelmente registro em listas negras que poderiam restringir a sua capacidade de enviar e-mails legítimos), mas não vai ser agradável, no entanto. Em outros casos, o problema mais importante pode ser causado a partir de sua máquina, por exemplo, seria ataques de negação de serviço. Isso, às vezes, induz a perda de receitas, uma vez que os serviços legítimos não estará disponível e os dados podem ser destruídos, às vezes isso também implicaria um custo real, porque a parte atacada pode iniciar um processo judicial contra você. Os detentores dos direitos podem processá-lo se uma cópia não autorizada de uma obra protegida por direitos autorais é compartilhada a partir do servidor, bem como outras empresas obrigadas por acordos de nível de serviço, se eles são obrigados a pagar multas após o ataque de sua máquina.
Quando estas situações ocorrem, afirmar inocência não é geralmente suficiente; no mínimo, você vai precisar de provas convincentes que mostram a atividade suspeita em seu sistema que vem de um determinado endereço IP. Isso não será possível se você negligenciar as recomendações deste capítulo e deixar o invasor obter acesso a uma conta privilegiada (root, em particular) e usá la para cobrir seus rastros.