[Segurança no Linux] – SUDO: aprecie com muita moderação!!

E aí pessoal??!! Tudo show??!!

Outro dia um aluno me perguntou o seguinte: “o Linux é mais seguro do que o Windows?”. Prontamente eu respondi:”depende muito de quem está no comando e das práticas adotadas!”, e é verdade mesmo pessoal!! Muitos especialistas em segurança preferem utilizar sistemas operacionais Open Source, como FreeBSD, OpenBSD, Debian, CentOS ou até RHEL por conta da diversidade de ferramentas estáveis de Firewall, Proxy  e IDS disponíveis. O simples fato de estas ferramentas existirem não credencia o servidor como intransponível ou infalível. Toda a infra deve ser verificada antes de pôr o servidor em produção, inclusive sua política de usuários e grupos, e é sobre isso que vamos falar neste primeiro instante.

SUDO

Esta ferramenta existe para que usuários comuns possam ter permissão de executar alguns aplicativos que são permitidos apenas para o super usuário (no caso do Linux, o root). A configuração deste recurso fica a cargo do arquivo /etc/sudoers.

Na figura acima, eu destaco a linha %admin ALL=(ALL) ALL, que significa que todo e qualquer usuário do sistema incluído no grupo admin poderá executar qualquer comando de root fornecendo apenas sua própria senha. Legal, só tem um problema: na instalação do Ubuntu (apenas um exemplo), o usuário que é criado na instalação é inserido no grupo admin, o que quer dizer que ele pode sim executar toda e qualquer tarefa como root. A prova está no resultado do comando id <usuário>, como abaixo:

 

Como exemplo, vamos tentar executar o firewall iptables com o usuário bruno :

$sudo iptables -nvL

Uma senha foi solicitada, só que foi a senha do próprio usuário bruno. Conclusão: o usuário padrão que é criado na instalação do Ubuntu, por exemplo, conseguiria excluir, criar ou consultar qualquer regra no Firewall Iptables. Para um sistema operacional de um Desktop não seria um grande transtorno mas para um servidor seria inadmissível!!

Agora vamos considerar que exista a necessidade de um determinado grupo de usuários ter acesso a alguns comandos administrativos, como por exemplo analistas de segurança responsáveis pelo firewall, em um servidor Linux. O que seria feito?? Seria criado um novo usuário com UID 0 (mesmo ID do root)?? Daria permissão de SUID para cada comando administrativo??? Nem uma solução, nem outra!! Vou explicar o porquê:

Quando você cria um usuário com UID 0 você está replicando a conta do root!! Para o sistema, não interessa o login do usuário, mas sim o UID dele, e se ele tem UID 0 ele é o próprio root. Por outro lado, dar permissão SUID para cada comando administrativo iria dar um trabalhão desnecessário e ainda iria dar permissão a TODO E QUALQUER USUÁRIO de executar estes comandos.

A solução mais sensata seria o uso do SUDO. Sim, ele mesmo!! Só que configurado de forma correta agora.

Vamos criar um grupo chamado security para agregar estes usuários:

#groupadd security

Vamos criar 2 usuários neste grupo:

#useradd -m -d /home/analista1 -s /bin/bash -g security analista1

#useradd -m -d /home/analista2 -s /bin/bash -g security analista2

#passwd analista1

#passwd analista2

Agora, vamos configurar o SUDO para que os usuários do grupo security possam executar os seguintes comandos administrativos:/sbin/iptables, /sbin/route e /sbin/ifconfig.

#visudo

%security ALL=NOPASSWD: /sbin/iptables,/sbin/route,/sbin/ifconfig

A opção NOPASSWD: indica que os usuários do grupo não precisarão fornecer as suas próprias senhas para executar os comandos.

Vamos testar agora:

analista1$sudo iptables -nvL

Perceba que outros comandos administrativos não podem ser executados:

analista1$sudo fdisk -l

 analista1$sudo su root

Nota: o comando su, quando executado como root, permite ao usuário fazer login em qualquer outra conta sem pedir senha da mesma, portanto, deixar o comando su liberado no sudo de um servidor pode ser nocivo demais!! Não faça isso nunca pois desta forma o usuário  com permissão no sudo pode fazer login como root sem que a sua senha seja solicitada.

Outra tática interessante seria, ao invés de liberar manualmente cada comando administrativo  que o usuário vai executar, liberar tudo e excluir alguns comandos. Vamos lá?

#visudo

%security ALL=NOPASSWD: ALL,!/sbin/fdisk,!/bin/su,!/sbin/mkfs

Neste caso, os usuários do grupo security poderão executar qualquer comando administrativo, com exceção de fdisk, su e mkfs.

Testando:

Aquele abraço a todos!!

 

www.brunoodon.com.br

 

  • Fala mestre, show o post. Grande abraço irmão, quando vier a Rio das Ostras traz a banda pra gente fazer um som.

  • Bruno, grande dica essa sua, porem no caso do Ubuntu que a conta de Root vem desativada por padrão, acho meio que desnecessário tudo isso. Esta é uma ótima politica realmente, quando se tem vários funcionários no setor de TI, porem apenas você como administrador principal tem acesso a todos os poderes e os demais pode apenas executar alguns comandos específicos.

    Agora em um ambiente onde apenas você é administrador, isso passa a ser meio que sem sentido, não acha?

    • Lógico, com certeza!! Tanto que no post eu cito que para um SO para usuário final isso não seria necessário mas não podemos esquecer que o Ubuntu tem a versão Server também, que muitos utilizam. Não podemos esquecer também que a coisa mais comum hoje nas empresas é ter mais de um administrador no setor de TI (níveis 1, 2 e 3) e, neste caso, para maior segurança e controle, é ideal que cada um tenha o seu login e o acesso à conta de root seja limitadíssimo. Isso pode não ter sentido para Desktops mas para Servers certamente tem sim, pois eu já presenciei várias situações onde vários administradores manipulavam o servidor Nagios, o BIND, o Squid, o Apache (principalmente) e às vezes todos os administradores tinham o acesso à conta de root com senha e quando acontece algum incidente não há como saber qual usuário foi responsável por aquilo pois todos possuam a senha de root.
      Essa com certeza não é a única dica de segurança a ser dada em Linux (nem tem essa pretensão) mas com certeza é uma baita falha de segurança em um servidor com múltiplos acessos, principalmente quando ele está de cara para a Internet e com acesso remoto habilitado.
      Abraço Tácio!!

      • Realmente nos casos de vários administradores é o melhor a ser feito. Eu mesmo atualmente não tenho nenhum ambiente com vários administradores, todos os servidores que administro, sou o único sysadmin do local, mais essa sua dica é boa para nós lembrar de nunca deixar um admin iniciante ou um funcionário “comun” da empresa com um poder destes nas mãos, apenas por necessitar as vezes reiniciar um unico serviço do servidor.

  • Supondo é claro que a banda já tenha comprado um ônibus…rsrs
    Abs