Aula #18 - Segurança do Sistema Local



Uma tarefa essencial de qualquer administrador de sistemas é o de garantir a segurança do(s) sistema(s) contra ameaças internas e externas. O trabalho começa com a concepção de uma política de segurança adequada, projetada para se defender de ameaças esperadas e inesperadas. 


A higiene básica dos sistemas deve fazer parte da política de segurança, uma vez que ela deve ser feitas de forma periódica; Sistemas precisam ser mantidos e atualizados, bem como fisicamente protegidos. 

Além disso, políticas sensatas têm que garantir que privilégios potencialmente perigosos sejam garantidos a apenas aos usuários que precisam delas, e apenas quando absolutamente necessário.

 Os computadores são inseguros por natureza e precisam de proteção contra pessoas que podem invadir ou atacar o sistema. Isso pode ser feito simplesmente para prejudicar o sistema, interromper serviços, ou roubar informações.

Nenhum computador pode ser absolutamente seguro. Tudo o que podemos fazer é desacelerar e/ou desencorajar intrusos para que eles partam em busca de alvos mais fáceis, ou nos preparar para pegá-los em flagrante e tomar as medidas adequadas.

A segurança pode ser definida em termos da capacidade do sistema de fazer regularmente o que se espera que ele faça, a integridade e exatidão do sistema, e garantir que o sistema está disponível apenas para as pessoas autorizadas a usá-lo.

O maior problema com a segurança é encontrar o balanço adequado entre segurança e produtividade; se restrições de segurança são extremas e ineficientes, os usuários vão burlar os procedimentos.

As quatro áreas que precisamos proteger incluem física, local, remota e pessoal.
Não vamos concentrar na segurança de rede, vamos nos concentrar nos fatores locais.


Como criar uma política de segurança?



É importante criar uma política de segurança clara e publicá-la na sua empresa. Ela deve:

  •     Ser simples e fácil de entender.
  •     Ser constantemente atualizada.
  •     Estar na forma de um documento escrito além da documentação on-line, se necessário.
  •     Descreva as políticas e os procedimentos.
  •     Especificar ações de execução.
  •     Especificar ações a serem tomadas em resposta a violações de segurança.


As políticas devem ser genéricas e não podem ser difíceis de entender e seguir. Elas devem proteger os dados que precisam de proteção, negar acesso a recursos sensíveis e proteger a privacidade do usuário.

Essas políticas devem ser atualizadas regularmente; políticas precisam mudar junto com os requisitos. Ter uma política desatualizada pode ser pior do que não ter nenhuma política.

Uma política de segurança deve incluir métodos para impedir que informações sejam lidas ou copiadas por pessoas não autorizadas. Ela também deve prover proteção para que informações não sejam alteradas ou apagadas sem a permissão do dono. Todos os serviços devem ser protegidos de forma que estejam disponíveis e que não sejam afetados de qualquer maneira não autorizada.

Aspectos essenciais:
  •     Confidencialidade
  •     Integridade dos Dados
  •     Disponibilidade
  •     Consistência
  •     Controle
  •     Capacidade de Auditoria

Você deve garantir que os dados são corretos e que o sistema se comporta como esperado. Devem existir processos efetivos para determinar quem tem acesso ao sistema.
O fator humano é o link mais frágil do sistema em uma cadeia de segurança, e por isso requer mais atenção com auditorias constantes.



Quais riscos avaliar?


 A análise de risco é baseada nas três questões:

  1.     O que eu quero proteger?
  2.     Do que estou me protegendo?
  3.     Quanto tempo, pessoal e dinheiro é necessário para assegurar uma proteção adequada?


Este é o primeiro passo na construção de uma política de segurança. É um pré-requisito para o planejamento e para aplicar as políticas e procedimentos para proteger seus sistemas.


 Existem duas filosofias básicas em uso na maioria dos ambientes de computação:

  •     Qualquer coisa que não seja expressamente permitido é negada.
  •     Qualquer coisa que não seja expressamente proibida é permitida.


Você deve decidir qual a filosofia é o melhor para a sua organização.

A primeira opção é mais restritiva: um usuário tem permissão para fazer apenas o que é clara e explicitamente permitido. Esta é a filosofia mais comumente usada.

A segunda opção cria um ambiente mais liberal, onde os usuários estão autorizados a fazer qualquer coisa, exceto o que é expressamente proibido. Isso implica em um elevado grau de confiança assumido e é menos frequente por razões óbvias.



 Algumas diretrizes gerais para lembrar quando for desenvolver filosofias de segurança:

  •     O fator humano é o elo mais fraco. 
Você deve educar seus usuários e mantê-los felizes(? kkk). A maior parte das violações tem origens internas e na maioria das vezes não são mal-intencionadas. (Mas nem sempre!)    
  •     Nenhum ambiente de computação é 100% seguro. 
O único sistema seguro é aquele que não está conectado a nada, trancado em um quarto seguro, e desligado.    
  •     A paranoia é uma coisa boa. 
Suspeite, seja vigilante e persistente para tornar um ambiente seguro. É um processo contínuo que deve ser constantemente revisitado. Verifique o processo, usuários e qualquer coisa fora do comum.

Algumas Medidas de Segurança

Os usuários nunca devem colocar o diretório atual no PATH, ou seja, não devem ter no ~/.bashrc algo como:

. PATH=./:$PATH

Isso é um risco de segurança significativo; uma pessoa mal-intencionada pode criar arquivos executáveis com nomes de outros aplicativos o que pode fazer estragos. Imagine o dano que um script chamado ls pode causar se ele tiver apenas essa linha:
/bin/rm -rf $HOME

Se você digitasse ls no diretório que contém o script malicioso você iria apagar seu diretório home!


Atualizações e Patchs de segurança:
É importante ficar atento com as atualizações da sua distribuição Linux e aplicá-las o mais rápido possível.

A maioria dos ataques exploram falhas de segurança conhecidas e são normalmente executados no período entre o problema ser publicamente revelado e a correção ser aplicada. Exploits Zero Day são muito raros, porque o invasor usa uma brecha de segurança que ainda não foi descoberta e que ainda não tem um patch com a correção para o problema.

Os administradores do sistema podem ser relutantes em aplicar correções imediatamente após a libertação, com base em experiências negativas com sistemas operacionais proprietários, em que as atualizações podem causar mais problemas do que resolver. No entanto, no Linux, tais regressões de segurança são extremamente raras, e atrasar a aplicação de um patch de segurança provavelmente não é justificável.


Acesso físico:
Quando o hardware é fisicamente acessível a segurança pode ser comprometida por:

  1. Key Logging: Gravar a atividade dos usuários, incluindo as teclas pressionadas. Os dados capturados podem ser armazenados localmente ou transmitida para computadores remotos.
  2. Sniffing de rede: 
  • capturar e ver os dados no nível de pacotes de rede. 
  • Iniciar com uma mídia live. 
  • Remontar e modificar o conteúdo do disco.

O acesso físico a um sistema facilita a vida dos atacantes, tornando irrelevantes a maioria das medidas de segurança no nível do sistema operacional.
Assim, a política de segurança deve começar com a definição de como proteger adequadamente o acesso físico aos servidores e estações de trabalho.

Medidas necessárias incluem:
  •     Bloquear estações de trabalho e servidores.
  •     Proteger seus links de rede contra o acesso de pessoas que você não confia.
  •     Proteger seus teclados onde senhas são digitadas para garantir que não possam ser alterados.
  •     Configurar a proteção por senha da BIOS de tal forma que o sistema não possa ser inicializado com uma mídia live ou de rescue/recovery como CD/DVD ou pendrive USB.
  •     Senha no GRUB para acesso a recursos e alteração da inicialização (não precisa dizer sobre guardar estas senhas!!)


Para computadores de usuários individuais e aqueles em um ambiente doméstico, algumas das recomendações acima (como impedir a inicialização a partir de mídia removível) pode ser exagero, e você não precisa fazê-lo. No entanto, se a informação que requer proteção cuidadosa, está em seu sistema ou ela não deveria estar no seu sistema, ou o seu sistema deve ser melhor protegido, seguindo as orientações acima.


Proteção da BIOS e/ou UEFI

 A BIOS é o nível de software mais baixo, próximo do hardware, que configura e manipula o seu sistema. A BIOS:
  •     É o nível mais baixo de segurança.
  •     Deve ser protegida com o uso de uma senha.
  •     Deve ser atualizada.

Configurar uma senha na BIOS protege contra pessoas não autorizadas que poderiam mudar opções de inicialização para obter acesso ao seu sistema. No entanto, só é relevante para o caso de alguém ter acesso físico à máquina, pois requer presença física no local.

Além disso, recomenda-se que a BIOS seja mantido atualizada. Atualizações de BIOS devem ser feitas com cuidado e atenção.


Proteção do GRUB

Você pode proteger o processo de inicialização com uma senha para impedir que alguém ignore a etapa de autenticação do usuário. Isto funciona de forma eficiente quando usado em conjunto com uma senha para a BIOS.

Note que o uso de uma senha no bootloader só vai impedir que um usuário edite a configuração do gerenciador de inicialização durante o processo de inicialização, não vai impedir que um usuário dê boot a partir de uma mídia de inicialização, tal como discos ópticos ou pendrives. Por isso a senha da BIOS é importante.


Para sistemas que utilizam GRUB:

    Para o GRUB mais velho versão 1, você pode usar o grub-md5-crypt. Ele vai pedir uma senha e, em seguida exibir o hash criptografado.
    Edite o /boot/grub/grub.conf e adicione a seguinte linha abaixo da entrada timeout:
    password --md5 $1$Wnvo.1$qz781HRVG4jUnJXmdSCZ30

    onde você deve colocar a senha que foi gerada pelo grub-md5-crypt. É possível forçar o uso de senha apenas para algumas escolhas de inicialização ao invés de todas.

    Para a versão 2 do GRUB, as coisas são mais complicadas. No entanto, você tem mais flexibilidade e pode fazer coisas como configurar senhas específicas para usuários individuais (que podem ser os normais de login.)

Como de costume com a versão 2, você nunca deve editar o arquivo de configuração, (/boot/grub/grub.cfg) diretamente. Edite arquivos de configuração do sistema em /etc/grub.d e depois execute update-grub. Uma explicação detalhada pode ser encontrada em https://help.ubuntu.com/community/Grub2/Passwords .



Proteção na Montagem de sistemas de arquivos:
Quando um sistema de arquivos é montado, seja na linha de comando com o mount ou pelo arquivo
/etc/fstab, várias opções podem ser usadas para melhorar a segurança:

    nodev
    Ignora arquivos especiais neste sistema de arquivo. Arquivos que representam dispositivos char e de blocos serão ignorados.
    
    nosuid
    Os bits set-user-identifier ou set-group-identifier serão ignorados. (Em breve falaremos sobre o setuid e setgid).

    noexec
        Restringe a execução de arquivos neste sistema de arquivos.

    ro
    Monta o sistema de arquivos no modo somente leitura como em:
    $ mount -o ro,noexec,nodev /dev/sda2 /meu_mnt


    ou no /etc/fstab:
    /dev/sda2 /meu_mnt  ext4 ro,noexec,nodev 0 0
   
   
Analise cada caso para aplicar estas alterações na montagem deles.



SETUID e SETGID


 Normalmente, os programas são executados com os privilégios do usuário que executou ou chamou o programa. Isto significa que não importa quem é o dono do arquivo binário executável que está sendo executando, os privilégios do processo são determinados pelo usuário que chama o programa.

Ocasionalmente, pode ser necessário que os usuários normais tenham poderes adicionais, que eles normalmente não teriam, como conseguir iniciar ou parar uma interface de rede, ou editar um arquivo do usuário root.

Ao definir a flag setuid (set user ID ou definir o id do usuário) em um arquivo executável, o comportamento normal é modificado, dando ao programa os privilégios do dono do arquivo ao invés de usar os privilégios do usuário que executou o programa.

Além disso, também é possível definir o bit setgid para que o processo seja executado com os privilégios do grupo que detém o arquivo ao invés de usar os privilégios do usuário que rodou o processo.

Devemos ressaltar que isso é geralmente uma má ideia que deve ser evitada na maioria das circunstâncias. Muitas vezes, é melhor escrever um programa daemon com menos privilégios para estes casos. Algumas distribuições recentes desativaram este recurso inteiramente.

Isso é simples de fazer:

$ chmod u+s arquivo
$ chmod g+s arquivo

o primeiro exemplo faz a operação setuid enquanto o segundo faz a operação setgid .

Para diretórios, configurar os bits do grupo tem um efeito bem diferente; esses bits são usados para criar um diretório compartilhado, como em:

$ chmod g+s pasta

Arquivos criados nesta pasta serão do mesmo grupo que o grupo do diretório.

Observe que não é possível alterar o setuid em um script Bash; na verdade, não terá efeito algum a não ser que você altere o bit setuid do Bash, o que seria um falha de segurança grave. Você só pode fazer esta alteração em arquivos binários executáveis.


Mais vistos no mês:

As melhores distribuições Linux para 2017

Teste de Performance de Rede com Iperf

TuxMath - Tux, do Comando da Matemática. Ensino e diversão a crianças.

Aula #14 - Os sistemas de arquivos ext2/ext3/ext4

Modelo Firewall Completo em Iptables para pequena rede/office

OPNsense - Firewall Open Source

DHCP - Guia Completo

SSD no linux

Administração de sistema e Deploys: Ansible, Chef, Fabric, Puppet ou Salt?