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

flaviomilan

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.335 ]

Por: Flavio Milan em 28/11/2012

6 0

Denuncie Favoritos Indicar Impressora

Introdução e configurações do sistema

Neste primeiro artigo, iremos abordar a melhoria da segurança do servidor limitando acesso ao usuário root, melhorando a inicialização, corrigindo algumas configurações do servidor e configurando uma mensagem personalizada para os usuários. Vamos lá!

O sistema utilizado para a elaboração deste artigo foi o CentOS 6.3, acredito que todos os procedimentos contidos neste artigo podem ser aplicados a sistemas como Debian, Ubuntu e outros.

Melhorando nosso inittab

Vamos começar pelo ambiente gráfico, o mesmo não poderia sequer ser instalado pelo fato de elevar muito a exposição do servidor a novas ameaças. Vale lembrar que a configuração de um servidor seguro começa pela sua instalação, escolhendo bem todos os pacotes que serão instalados.

Mas, caso você tenha instalado um ambiente gráfico, a melhor coisa a fazer é com que o sistema não inicie o modo gráfico na inicialização, ou seja, vamos trocar o runlevel que o sistema irá iniciar.

Para isso, altere a seguinte linha:

id:5:initdefault:

Para:

id:3:initdefault:

Habilitando a senha no Modo Single

Modo Single é o modo de manutenção do sistema GNU/Linux, ele é o runlevel de numero 1. No modo single, o sistema carrega somente os processos que são essenciais para ele, ou seja, nada além irá funcionar.

Por padrão, este modo single pode ser acessado sem a senha de root, o que é um risco, pois o usuário teria acesso completo a todos os arquivos de configuração do sistema.

Para fazer com que o sistema passe a pedir senha no modo single, você deve editar o arquivo de configuração localizado em /etc/sysconfig/init:

# vi /etc/sysconfig/init

Altere a linha:

SINGLE=/sbin/sushell

Para:

SINGLE=/sbin/sulogin

Feita esta configuração, sempre que o servidor iniciar em modo single, será solicitado a senha de usuário root, caso contrário, você deverá pressionar CTRL+D para sair do modo single.

Desabilitando o desligamento por CTRL+ALT+DEL

Por padrão, o sistema GNU/Linux pode ser desligado apertando a sequência de teclas CTRL+ALT+DEL, e isso é um grande problema, pois qualquer pessoa com acesso físico ao servidor poderia desligar o sistema.

Para evitar que isso aconteça, podemos alterar o arquivo /etc/init/control-alt-delete.conf:

# vi /etc/init/control-alt-delete.conf

Comente a linha:

exec /sbin/shutdown -r now "Control-Alt-Delete pressed"

Deixe-a assim:

# exec /sbin/shutdown -r now "Control-Alt-Delete pressed"

Com esta linha comentada, seu sistema ignora a sequência de teclas e passará a não reinicializar o sistema.

Próxima página

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

Configurando Servidor Web Cherokee no Centos 6.3

Configuração de Servidor Web no FreeBSD 9

Leitura recomendada

Firewall com Iptables + Squid

Vírus? Checando base de dados de fabricantes proprietários como McAfee e Symantec e aplicando em distribuições Red Hat

Servidor de logs em Debian Linux

Melhorando a segurança do seus servidores em FreeBSD

Configurando um servidor Freeradius + openLDAP

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.

0 0

[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?

0 0

[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

0 0

[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

0 0

[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.

0 0

[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.

0 0

[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...

0 0

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

parabens cara, ótimo artigo! favoritei!

0 0

[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

0 0

[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.

0 0

[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

0 0

[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.

0 0

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

Excelente!

0 0

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

muito bom o atigo

0 0

[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.

0 0

[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!

0 0

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

Excelente artigo. Parabéns!

0 0

[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

0 0