Olá Habr!
Não publicamos nenhum livro novo no Linux para iniciantes há muito tempo - e agora estamos realizando a tradução de novos produtos desse plano. O livro de Clinton
Linux in Action , publicado por Manning, fala não apenas da
estrutura interna do Linux , mas também dos problemas mais comuns e de como corrigi-los.
O autor publicou um trecho do capítulo 9 no site Hackernoon, que sugerimos que você avalie.
A montagem de um servidor LAMP, como configurá-lo, garantir um processamento de dados confiável, configurar a área de assunto e cuidar de um certificado TLS é apenas a metade do caminho para a vitória. Você também precisa garantir que sua infraestrutura esteja protegida das muitas ameaças terríveis da Internet.
Neste artigo, examinamos a segurança de um site aprendendo a trabalhar adequadamente com grupos de sistemas, garantir o isolamento do processo e auditar regularmente os recursos do sistema. Obviamente, essa história não está completa (o livro Linux em ação também abordou outros tópicos, por exemplo, instalação de certificados TLS e trabalho com o SELinux), mas isso será suficiente para começar.
Grupos de sistemas e o princípio de privilégios mínimos
Os desenvolvedores que você está apoiando (finalmente) estão começando a perceber que é necessário limitar o acesso geral aos dados e arquivos de configuração localizados no servidor de aplicativos, mas, ao mesmo tempo, deixar esse acesso aberto para vários programadores e outras equipes de TI.
A primeira parte da solução são
grupos . Um grupo é um objeto no sistema (bem como um usuário) com a ressalva de que nenhum usuário jamais efetuará login no sistema como um grupo. A força dos grupos reside no fato de que eles, como usuários, podem ser "atribuídos" a arquivos ou diretórios, permitindo que cada membro do grupo use os privilégios fornecidos a ela. Isso é ilustrado abaixo.
Os desenvolvedores do grupo de desenvolvedores podem acessar um diretório específico e, para usuários que não são membros desse grupo, o diretório será fechado
Tente você mesmo: crie um novo arquivo em um editor de texto. Escreva texto simples nele, por exemplo, “Hello World”, para que você possa ver imediatamente quando o arquivo foi acessado com sucesso. Em seguida, edite as permissões usando o
chmod 770 para que o proprietário do arquivo e os membros do grupo ao qual ele pertence tenham plenos direitos para trabalhar com o arquivo, enquanto outros não poderão lê-lo.
$ nano datafile.txt $ chmod 770 datafile.txt
Se seu sistema ainda não possui outras contas de usuário, crie uma conta usando
adduser - isso é feito no Debian / Ubuntu - ou usando
useradd , como é habitual no CentOS. O comando
useradd também funcionará no Ubuntu.
O comando
useradd , diferente do
adduser Debian
adduser requer que a senha do usuário seja gerada separadamente:
# useradd otheruser # passwd otheruser Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
Usando o comando
su , mudamos para o novo usuário. Depois de inserir sua senha, todos os comandos a seguir serão executados em nome desse usuário. Você trabalhará em nome desse usuário específico; nem mais nem menos. Se você tentar ler o arquivo de dados
datafile.txt (usando
cat ), nada funcionará mais para você; como você se lembra, apenas membros do grupo têm direitos de leitura. Quando terminar, digite
exit para sair do novo shell do usuário e retornar ao seu shell original.
$ su otheruser Password: $ cat /home/ubuntu/datafile.txt cat: /home/ubuntu/datafile.txt: Permission denied $ exit
Tudo isso é esperado e bastante compreensível. Como você pode ver, quando você não pode ler um arquivo pertencente a outro usuário, isso às vezes é um problema. Vamos ver o que você pode fazer associando o arquivo ao grupo e configurando corretamente as permissões do arquivo.
Criaremos um novo grupo com o qual podemos gerenciar os dados do nosso aplicativo e, em seguida, editaremos as propriedades do nosso arquivo de dados usando o
chown . O argumento do ubuntu: app-data-group deixa a propriedade do arquivo para o usuário do Ubuntu, mas seu grupo muda para um novo: app-data-group.
# groupadd app-data-group # chown ubuntu:app-data-group datafile.txt
Execute ls para obter a saída "expandida" deste arquivo e ver suas novas permissões e status. Observe: como esperado, o arquivo pertence ao usuário
ubuntu pertencente ao
app-data-group .
$ ls -l | grep datafile.txt -rwxrwx — — 1 ubuntu app-data-group 6 Aug 9 22:43 datafile.txt
Você pode usar o
usermod para adicionar seu usuário ao
app-data-group e, em seguida, usar o comando
su para alternar para o shell no qual a conta de outro usuário está implantada. Agora, mesmo que os direitos de acesso ao arquivo o bloqueiem de todos os “outros” - e você é definitivamente um usuário “diferente” no momento -, você deve ler esse arquivo livremente, porque pertence ao grupo necessário.
# usermod -aG app-data-group otheruser $ su otheruser $ cat datafile.txt Hello World
Usando o comando
su , alternamos entre contas de usuário. Eles são gravados no meu arquivo
datafile.txt . Essa organização é a maneira correta e eficaz de eliminar uma variedade de problemas complexos com direitos de acesso que podem surgir em um sistema multiusuário.
De fato, ele é usado não apenas para fornecer os direitos de acesso necessários para usuários individuais - muitos processos do sistema também não seriam capazes de executar suas tarefas se eles não fossem membros prescritos nos grupos necessários. Você pode visualizar o arquivo / etc / group na diagonal - observe quantos processos do sistema pertencem aos seus próprios grupos ...
Listagem abreviada do conteúdo do arquivo / etc / group:
$ cat /etc/group root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4:syslog tty:x:5: disk:x:6: lp:x:7: mail:x:8: news:x:9: uucp:x:10: man:x:12: proxy:x:13: […]
Isolamento do processo de contêiner
Talvez você esteja preocupado que muitos serviços em execução no mesmo servidor estejam em risco se pelo menos um desses serviços estiver comprometido? Uma opção para amenizar os danos que usuários descuidados ou mal-intencionados podem causar é isolar os recursos e processos do sistema. Assim, mesmo que alguém deseje expandir sua autoridade além dos limites estabelecidos, ele não obterá acesso físico aos dados.
Anteriormente, foi decidido resolver esse problema da seguinte maneira: cada serviço foi alocado em sua própria máquina física. No entanto, a virtualização torna muito mais fácil e barato criar uma arquitetura "mesh". Hoje, essa arquitetura é geralmente chamada de
microsserviço e permite executar muitos contêineres de uma só vez, em um dos quais, por exemplo, um banco de dados pode funcionar, no outro - Apache e no terceiro - arquivos de mídia que podem ser incorporados às suas páginas da web. A arquitetura de microsserviço permite não apenas aumentar significativamente a produtividade e a eficiência, mas também reduzir significativamente o risco de invasão de cada componente individual.
Os “contêineres” de que estou falando não precisam ser convincentes com o LXC. Outras tecnologias de contêiner, como o Docker, estão se tornando muito mais populares hoje em dia.
Verificando valores perigosos de ID do usuário
Obviamente, qualquer usuário com direitos de administrador pode fornecer temporariamente acesso root com o
sudo , mas apenas o administrador é o administrador real. Como você já sabe, não é seguro executar funções regulares sob acesso root. No entanto, isso pode acontecer - puramente por acidente ou devido a fraude de dados maliciosos - que um usuário comum terá direitos administrativos sem interrupções.
Nesse caso, é bom que não seja difícil identificar esses impostores: o usuário e / ou o ID do grupo, como o do administrador, será "0". Dê uma olhada no arquivo passwd no diretório / etc /. Este arquivo contém um registro para cada conta de usuário normal e do sistema que já existe no sistema. O primeiro campo contém o nome da conta (neste caso, root e ubuntu), e no segundo campo x pode ser usado em vez da senha (se a senha existir, será criptografada no arquivo / etc / shadow). Mas os dois campos a seguir contêm o usuário e o ID do grupo. No caso do
ubuntu neste exemplo, os dois IDs são 1000. E o administrador, como você pode ver, possui zeros aqui.
$ cat /etc/passwd root:x:0:0:root:/root:/bin/bash […] ubuntu:x:1000:1000::/home/ubuntu:/bin/bash
Se você encontrar um usuário comum com um ID de usuário ou grupo = 0, tenha certeza de que o assunto não está limpo e que a situação precisa ser corrigida. Uma maneira rápida e fácil de identificar esse problema é verificar o
passwd com o comando
awk , que exibirá todas as linhas no terceiro campo em que não há nada além de 0. No meu caso (você pode exalar), havia apenas uma dessas linhas - a raiz. Você pode executá-lo novamente substituindo $ 4 por $ 3 - isso verificará o campo ID do grupo.
$ awk -F: '($3 == “0”) {print}' /etc/passwd root:x:0:0:root:/root:/bin/bash
Auditoria de Recursos do Sistema
Quanto mais coisas houver no seu sistema, maior a probabilidade de que algo nele se quebre. Portanto, é aconselhável acompanhar o que funciona e como. Nesse caso, estamos falando de portas de rede (se a porta estiver "aberta", então, por definição, deve ser uma entrada), serviços (se o serviço estiver ativo, deve ser possível usá-lo) e sobre programas instalados (se o programa estiver instalado, ele deve ser a capacidade de realizá-lo).
Para que uma auditoria seja benéfica, ela deve ser mais ou menos regular. Como todos nós esquecemos, é muito melhor escrever ferramentas de auditoria em um script especial que não apenas será executado regularmente, mas idealmente analisará os resultados para torná-los mais legíveis.
Aqui, no entanto, apresento três ferramentas-chave de auditoria que ajudarão a exibir portas abertas, serviços ativos e pacotes de software desnecessários. Sua tarefa é automatizar tudo isso.
Verificação de porta
Uma porta é considerada "aberta" se um host estiver executando um processo que escute solicitações nessa porta. De olho nas portas abertas, você entenderá melhor o que exatamente está acontecendo no seu servidor.
Você já sabe que as portas HTTP (80) e SSH (22) provavelmente devem estar abertas em um servidor Web comum, para que não surpreendam você. Mas é muito mais importante prestar atenção a outros resultados inesperados. O comando netstat exibe todas as portas abertas, bem como uma tonelada de informações sobre como elas são usadas.
Neste exemplo, estamos testando um servidor multiuso muito típico, e o comando
-n diz ao
netstat para ativar todas as portas e endereços numéricos.
-l inclui apenas soquetes de escuta e
-p adiciona o ID do processo do programa de escuta. Naturalmente, se você vê algo - aja.
# netstat -npl Active Internet connections (only servers) Proto Local Address Foreign Address State PID/Program name tcp 127.0.0.1:3306 0.0.0.0:* LISTEN 403/mysqld tcp 0.0.0.0:139 0.0.0.0:* LISTEN 270/smbd tcp 0.0.0.0:22 0.0.0.0:* LISTEN 333/sshd tcp 0.0.0.0:445 0.0.0.0:* LISTEN 270/smbd tcp6 :::80 :::* LISTEN 417/apache2 […]
Nos últimos anos, o
ss usado cada vez mais em vez do
netstat . Apenas no caso: se uma noite você se encontra em uma empresa e alguém pergunta sobre ss, então este exemplo (que lista todas as conexões SSH instaladas) deve ser informativo o suficiente para que você não possa enfrentar a sujeira:
$ ss -o state established '( dport = :ssh or sport = :ssh )' Netid Recv-Q Send-Q Local Address:Port Peer Address:Port tcp 0 0 10.0.3.1:39874 10.0.3.96:ssh timer:(keepalive,18min,0)
Verificando os Serviços Ativos
Se você tirar uma foto rápida dos serviços gerenciados pelo
system e atualmente ativos no seu computador, a máquina ajudará a identificar qualquer atividade indesejada. O comando
systemctl pode listar todos os serviços existentes e, em seguida, sua lista pode ser reduzida para aqueles cuja descrição contém
enabled . Portanto, apenas os serviços ativos serão retornados.
# systemctl list-unit-files — type=service — state=enabled autovt@.service enabled bind9.service enabled cron.service enabled dbus-org.freedesktop.thermald.service enabled docker.service enabled getty@.service enabled haveged.service enabled mysql.service enabled networking.service enabled resolvconf.service enabled rsyslog.service enabled ssh.service enabled sshd.service enabled syslog.service enabled systemd-timesyncd.service enabled thermald.service enabled unattended-upgrades.service enabled ureadahead.service enabled
Se você encontrar algo que obviamente não se
systemctl , é possível usar o comando
systemctl para interromper o serviço e garantir que ele não seja reiniciado na próxima inicialização.
# systemctl stop haveged # systemctl disable haveged
Na verdade, não há nada sombrio e sombrio no serviço
haveged que eu paro neste exemplo: é uma ferramenta que geralmente executo para criar atividade aleatória do sistema em segundo plano ao criar chaves de criptografia.
Procure programas instalados
Alguém poderia instalar programas no sistema sem o seu conhecimento? Bem, para descobrir - você precisa procurar. O comando
yum list installed ou, no caso do Debian / Ubuntu,
dpkg — list fornecerá um resumo detalhado e o comando remove deve remover todos os pacotes que não precisamos.
# yum list installed # yum remove packageName
Aqui está como a mesma coisa é feita no Ubuntu:
# dpkg --list # apt-get remove packageName
Também é útil acompanhar as alterações que estão sendo feitas nos arquivos de configuração do sistema - falaremos sobre isso no Capítulo 11.