Melhorando a segurança de servidores GNU/Linux (Parte 1)

Você acredita que para que possamos configurar um servidor, precisamos somente configurar os serviços e o sistema e já colocar o "menino para pular"? Se você pensa assim, está muito enganado! Servidores que vão para produção precisam passar por um processo de mapeamento das falhas e melhoria da segurança. Este procedimento chama-se Hardening.

[ Hits: 32.272 ]

Por: Flavio Milan em 28/11/2012


Configurações do usuário root - Personalizando login



Devemos ter muito cuidado com esse usuário, pois, como ele tem acesso ilimitado a nosso sistema, deve ser muito bem protegido, desde sua senha, até como quem poderá utilizar ele, garantindo assim, uma rastreabilidade dos problemas.

É altamente recomendado que o usuário root não faça login no sistema de forma direta, ou seja, o ideal é que outro usuário logue-se no sistema e suba os privilégios com o comando su. O motivo disso é a rastreabilidade, posterior a qualquer evento, seria mais fácil descobrir qual foi o autor da tragédia. ;D

Para evitar que o usuário root faça login no sistema, devemos limpar o arquivo /etc/securetty, que contém os terminais seguros - no nosso caso, nenhum é seguro:

# echo " " > /etc/securetty

Vamos alterar suas permissões, para que ninguém possa acrescer o terminal seguro depois:

# chmod 400 /etc/securetty
# chown root:root /etc/securetty


* Vale lembrar, que para você fazer esta alteração, deve ter um usuário comum no sistema (haha), caso contrário, você aprenderá a utilizar o single mode. Boa sorte! :D

Bloqueio do login direto do usuário root via SSH

Para fechar brechas, o bloqueio do acesso root direto por SSH é fundamental, afinal, hoje a maioria dos sistemas são administrados via SSH, então, ele deve seguir o mesmo padrão do sistema, o usuário deve autenticar-se e depois subir privilégios via su.

Para alterar esta configuração, vamos acessar o arquivo de configuração direto do SSH.

# vi /etc/ssh/sshd_config

Descomente e altere a linha:
# PermitRootLogin yes

Para:

PermitRootLogin no


Reinicie o serviço SSH:

# service sshd restart

Restringindo o comando su

Pensando na proteção do usuário root, outra configuração muito interessante é a restrição do comando su somente para usuários permitidos. Isso garante que mesmo que um usuário descubra a senha do root, ele tenha dificuldades de adquirir privilégios máximos no sistema, precisando de uma senha de um usuário habilitado a utilizar o su.

Para fazer esta configuração, primeiro vamos adicionar o usuário ao grupo wheel que terá a permissão de acesso ao su.

Execute o comando:

# usermod -G wheel <nome_do_usuario>

Feito a inclusão do usuário no grupo wheel, acesse o arquivo /etc/pam.d/su e descomente a seguinte linha:

auth required /lib/security/$ISA/pam_wheel.so use_uid

A configuração estará funcionando, e somente usuários do grupo wheel conseguirão o acesso máximo ao sistema.

Personalizando login

Um ponto importante é avisar o usuário que o servidor que está sendo acessado é de uso restrito e que deve-se tomar muito cuidado com as configurações que podem ser feitas nele.

Para configurarmos as mensagens que serão mostradas ao usuário, podemos utilizar os arquivos:
  • /etc/issue → Mostra uma mensagem antes do login.
  • /etc/motd → Mostra uma mensagem após o login.

Basta fazer sua alteração, colocando sua mensagem personalizada, que a mensagem passará a ser mostrada a todos que utilizarem o servidor.

Conclusão

Bom amigos, neste primeiro artigo é só.

Posteriormente irei postar mais configurações do SELinux, IPtables, logs e mais algumas configurações que podem melhorar a segurança de nosso servidor.

Espero que este documento seja útil a vocês. Estou aberto a dúvidas, críticas, sugestões e também a elogios.

Forte abraço.

Página anterior    

Páginas do artigo
   1. Introdução e configurações do sistema
   2. Configurações do usuário root - Personalizando login
Outros artigos deste autor

Configuração de Servidor Web no FreeBSD 9

Configurando Servidor Web Cherokee no Centos 6.3

Leitura recomendada

Entendendo o ataque ARP spoofing + SSLStrip

Biometria facial na autenticação do usuário root

Traduzindo plugins do OpenVAS/Nessus para português

ClamAV, o kit de ferramentas antivírus

Enviando e recebendo e-mails criptografados através do Thunderbird

  
Comentários
[1] Comentário enviado por removido em 28/11/2012 - 14:27h

Gostei das dicas !

São configurações que administradores de nível intermediário e avançado sabem, mas que muitos ignoram.

bom trabalho.

[2] Comentário enviado por thyagobrasileiro em 29/11/2012 - 14:10h

Ganhou meu favorito.


Na parte de configuração de usuario ROOT, o que acontece na pratica de nao ter um usuario comum no sistema?

[3] Comentário enviado por flaviomilan em 29/11/2012 - 18:54h


[1] Comentário enviado por eabreu em 28/11/2012 - 14:27h:

Gostei das dicas !

São configurações que administradores de nível intermediário e avançado sabem, mas que muitos ignoram.

bom trabalho.



Muito obrigado amigo, é verdade que muitos ignoram mais isso é básico para garantir um pouco de segurança.

Estou a sua disposição!

abraço

[4] Comentário enviado por flaviomilan em 29/11/2012 - 19:05h


[2] Comentário enviado por thyagobrasileiro em 29/11/2012 - 14:10h:

Ganhou meu favorito.


Na parte de configuração de usuario ROOT, o que acontece na pratica de nao ter um usuario comum no sistema?


Fico muito feliz

No caso você deve criar um usuário para o sistema, acesso direto ao usuario ROOT deve ser evitado sempre pois se caso for descoberta a senha do usuário o invasor ainda não terá a senha do ROOT, é claro que com a senha do usuário poderia ser feita a elevação de privilégio com algum exploit, mas você ainda dificulta muito.

Falando em exploit é extremamente importante não deixar compiladores instalados justamente para evitar a compilação de exploits.

Vou falar disso na parte 2.

Fico a sua disposição

abraço

[5] Comentário enviado por geraldoquites em 04/12/2012 - 13:36h

Muito legal este seu tutorial, com ele, já implementei algumas mudanças nos nossos servidores. Como disse o Thyago, já ganhou meu favorito também... rs rs...

Adicionando ao seu tutorial, sempre gosto de usar no SSH a linha de usuários que tem permissão de acesso, inibindo assim o usuário root.

vi /etc/ssh/sshd_config

AllowUsers usuario1, usuario2 ...

Desta forma, somente estes usuários terão acesso ao SSH.

abraços,

Geraldo.

[6] Comentário enviado por removido em 10/12/2012 - 11:19h

No Debian e derivados, para habilitar o sulogin, edite o /etc/default/rcS:
de
SULOGIN=no
para
SULOGIN=yes

Abraços.

[7] Comentário enviado por flaviog em 19/02/2013 - 11:17h

Gostei muito do artigo, meus sinceros parabéns. Sou iniciante em linux e é de extrema importância adotarmos medidas de segurança para evitar possiveis transtornos. Esperando ancioso a segunda parte.

Abraço.

Conhecimento nunca é demais e sempre muito bem vindo...

[8] Comentário enviado por removido em 11/03/2013 - 13:50h

parabens cara, ótimo artigo! favoritei!

[9] Comentário enviado por saitam em 15/04/2013 - 08:20h

Boa dica!

É bom ressaltar também que no RHEL e CentOS tem uma falha grave de segurança...

Por default o CentOS/RHEL os comandos halt e reboot são permitidos com usuário comum, achei uma falha de segurança, pois foge do padrão de outras distros tradicionais como Debian e Slackware.

Como resolver então ?

verifique se tem o link no /sbin/halt, /sbin/poweroff no /bin/halt, /bin/poweroff
remove o link rm -d /bin/halt ; rm -d /bin/poweroff
altere a permissão para apenas o root ter acesso - chmod 700 /sbin/halt ; chmod 4700 /sbin/poweroff

[10] Comentário enviado por pqd em 16/06/2013 - 23:40h

Muito bom Flavião show de bola os seus how tos esta de parabéns.

[11] Comentário enviado por QuestLoder em 17/09/2013 - 13:22h

Boa tarde Flavio,

Rapaz você era da 3D Informática não?
hfuasdhfhuadsfhuasduhu, bom te encontrar por aqui.

Seguite parabéns pelo tutorial, muito bem feito e explicado, na parte de tirar acesso ao teclado fisico não acho legal, já aconteceu algumas coisas relacionadas por isso estou compartilhando isso contigo.

Em alguns clientes que administro chegou a acabar a energia e o nobreak segurou por algum tempo, mas o cliente viu a necessidade de desligar o servidor manualmente sem precisar da minha intervenção, então a única solução que encontrei é o Ctrl + Alt + Del, para desligar todos os processos que utilizo e realizar o sistema.

Se alguém tiver uma outro solução posta ai.

Abraço

[12] Comentário enviado por icaroaron em 07/11/2013 - 09:11h

Muito bom o artigo, outra coisa que pode dar um pequeno aumento no nível de segurança e altera a porta padrão do acesso ssh e por uma de sua escolha. com isso Dificultara a tentativa de acesso não autorizado.

[13] Comentário enviado por removido em 16/05/2014 - 09:22h

Excelente!

[14] Comentário enviado por radolpho em 21/05/2014 - 13:42h

muito bom o atigo

[15] Comentário enviado por luizcarlos18rj em 21/05/2014 - 14:40h

Muito legal parceiro!!!

Eu que sou iniciante, agora q to lendo bastante e começando a entender os termos técnicos, tá me esclarecendo...não sabia q tinha tanta porta de entrada assim em um servidor.

Gostaria de saber qual é a previsão de sair a segunda parte do artigo e se é possível criar um script que faça tudo isso pra mim tipo se eu reinstalar um sistema operacional do zero.

Existe algum modelo disponível? ou dá pra fazer um colocando essas linhas q vc disse pra alterar? pensei em acessar os devidos diretórios com o comando "cd" e logo após aplicar os comandos do tutorial.., mas antes ia ter q ver se a minha distro tem os mesmo caminhos, eu já comparei uma vez e vi que existem pequenas diferenças entre distros.

[16] Comentário enviado por corrosiontears em 29/06/2014 - 12:32h

Dicas simples porém essenciais! Pretendo atualizar um Server Linux em breve! Vou me apoiar em seus tutoriais! Muito obrigado!

[17] Comentário enviado por avonni em 08/09/2014 - 18:02h

Excelente artigo. Parabéns!

[18] Comentário enviado por mastergbi em 20/03/2015 - 09:41h

Muito bom! uma coisa que eu ia acrescentar na segurança, que o amigo icaro já comentou é mudar a porta do ssh, indo no arquivo "/etc/ssh/sshd_config", isso evita muita coisa que acontece debaixo dos panos, analisando os logs, percebi um "estranho" tentando brute force na minha porta ssh, dai neguei acesso direto a root, limitei usuários que poderia subir privilégios, verifiquei se o protocolo do ssh estava 2(o 1 geralmente eh vulnerável) e ainda mudei a porta do ssh, saindo de vez da lista de "scanners" que ficam rodando na internet o dia todo atrás de portas vulneráveis.

Adriano Santos


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts