110.2 Lição 1
Certificação: |
LPIC-1 |
---|---|
Versão: |
5.0 |
Tópico: |
110 Segurança |
Objetivo: |
110.2 Configurar a segurança do host |
Lição: |
1 de 1 |
Introdução
Este capítulo explica quatro maneiras básicas de melhorar a segurança do host:
-
Alguns comandos e definições de configuração básicas para aperfeiçoar a segurança da autenticação com senhas ocultas.
-
Como usar superdaemons para ouvir conexões de rede de entrada.
-
Verificação dos serviços de rede em busca de daemons desnecessários.
-
Uso de TCP wrappers como uma espécie de firewall simples.
Melhorar a segurança da autenticação com senhas ocultas
Os componentes básicos dos dados da conta de um usuário são armazenados no arquivo /etc/passwd
. Este arquivo contém sete campos: nome de login, espaço reservado para senha, ID do usuário, ID do grupo, comentário (também conhecido como GECOS), local do diretório inicial e o shell padrão. Uma maneira simples de lembrar a ordem desses campos é pensar sobre o processo de login de um usuário: primeiro você insere um nome de login e uma senha (aqui normalmente representados por um x
). O sistema mapeará esses dados para um ID de usuário (uid) e um ID de grupo (gid). Quando um comentário ou campo GECOS é fornecido, o diretório inicial do usuário é atribuído e, finalmente, o shell padrão é especificado.
Porém, nos sistemas modernos, a senha não é mais armazenada no arquivo /etc/passwd
. Em vez disso, o campo de senha contém apenas um x
minúsculo. O arquivo /etc/passwd
precisa ser legível por todos os usuários; portanto, não é uma boa ideia armazenar senhas nele. O x
indica que a senha criptografada (com hash) está na verdade armazenada no arquivo /etc/shadow
. Este arquivo não deve ser legível para todos os usuários.
As configurações de senha são definidas com os comandos passwd
e chage
. Ambos os comandos alteram a entrada referente à usuária emma
no arquivo /etc/shadow
. Como superusuário, você pode definir a senha da usuária emma
com o seguinte comando:
$ sudo passwd emma New password: Retype new password: passwd: password updated successfully
Em seguida, o sistema pede que a nova senha seja confirmada duas vezes.
Para listar o tempo de expiração da senha e outras configurações de expiração de senha para a usuária emma
, use:
$ sudo chage -l emma Last password change : Apr 27, 2020 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
Para evitar que a usuária emma
faça login no sistema, o superusuário pode definir uma data de expiração da senha anterior à data atual. Por exemplo, se a data de hoje fosse 27/03/2020, poderíamos definir uma data mais antiga para a expiração da senha da usuária:
$ sudo chage -E 2020-03-26 emma
Como alternativa, o superusuário poderia usar:
$ sudo passwd -l emma
para bloquear a conta temporariamente através da opção -l
em passwd
. Para testar os efeitos dessas alterações, tente fazer o login como a conta emma
:
$ sudo login emma Password: Your account has expired; please contact your system administrator Authentication failure
Para evitar que todos os usuários, exceto o usuário root, se loguem no sistema temporariamente, o superusuário pode criar um arquivo chamado /etc/nologin
. Esse arquivo pode conter uma mensagem para os usuários notificando-os sobre o motivo pelo qual não podem fazer login no momento (por exemplo, notificações de manutenção do sistema). Para saber mais, consulte man 5 nologin
. Note que também existe um comando nologin
que pode ser usado para impedir um login quando definido como o shell padrão de um usuário. Por exemplo:
$ sudo usermod -s /sbin/nologin emma
Consulte man 8 nologin
para saber mais.
Como usar um superdaemon para ouvir conexões de rede de entrada
Os serviços de rede, como os servidores web, servidores de email e servidores de impressão, geralmente funcionam como um serviço autônomo que escuta em uma porta de rede dedicada. Todos esses serviços autônomos são executados lado a lado. No sistema clássico baseado em Sys-V-init, cada um desses serviços pode ser controlado pelo comando service
. Nos sistemas atuais baseados em systemd, usamos systemctl
para gerenciar o serviço.
Antigamente, a disponibilidade de recursos do computador era muito menor. Não era aconselhável executar muitos serviços em modo autônomo ao mesmo tempo. Em vez disso, um superdaemon era usado para escutar as conexões de rede de entrada e iniciar o serviço apropriado sob demanda. Este método de construção de uma conexão de rede era um pouco mais demorado. inetd
e xinetd
são superdaemons bastante conhecidos. Nos sistemas atuais baseados em systemd, a unidade systemd.socket
pode ser usada de maneira semelhante. Nesta seção, usaremos o xinetd
para interceptar conexões com o daemon sshd
e iniciar este daemon no momento adequado para demonstrar como o superdaemon era usado.
Antes de configurar o serviço xinetd
, é necessária uma pequena preparação. Não importa se você usa um sistema baseado em Debian ou Red Hat. Embora estas explicações tenham sido testadas no Debian/GNU Linux 9.9, elas devem funcionar em qualquer sistema Linux atual com systemd sem nenhuma alteração significativa. Primeiro, verifique se os pacotes openssh-server
e xinetd
estão instalados. Em seguida, confira se o serviço SSH funciona com:
$ systemctl status sshd ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-04-27 09:33:48 EDT; 3h 11min ago Docs: man:sshd(8) man:sshd_config(5) Process: 430 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS) Main PID: 460 (sshd) Tasks: 1 (limit: 1119) Memory: 5.3M CGroup: /system.slice/ssh.service └─460 /usr/sbin/sshd -D
Verifique também se o serviço SSH está escutando em sua porta de rede padrão 22:
# lsof -i :22 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sshd 1194 root 3u IPv4 16053268 0t0 TCP *:ssh (LISTEN) sshd 1194 root 4u IPv6 16053270 0t0 TCP *:ssh (LISTEN)
Finalmente, interrompa o serviço SSH com:
$ sudo systemctl stop sshd.service
No caso de você querer tornar esta mudança permanente, sobrevivendo à reinicialização, use systemctl disable sshd.service
.
Agora você pode criar o arquivo de configuração do xinetd /etc/xinetd.d/ssh
com algumas configurações básicas:
service ssh { disable = no socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/sshd server_args = -i flags = IPv4 interface = 192.168.178.1 }
Reinicie o serviço xinetd com:
$ sudo systemctl restart xinetd.service
Verifique nas conexões SSH de entrada qual serviço está escutando no momento.
$ sudo lsof -i :22 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME xinetd 24098 root 5u IPv4 7345141 0t0 TCP 192.168.178.1:ssh (LISTEN)
Podemos ver que o serviço xinetd assumiu o controle do acesso à porta 22.
Eis mais alguns dados sobre a configuração do xinetd
. O arquivo de configuração principal é /etc/xinetd.conf
:
# Simple configuration file for xinetd # # Some defaults, and include /etc/xinetd.d/ defaults { # Please note that you need a log_type line to be able to use log_on_success # and log_on_failure. The default is the following : # log_type = SYSLOG daemon info } includedir /etc/xinetd.d
Além das configurações padrão, há apenas uma diretiva para definir um diretório de inclusão. Neste diretório você pode definir um arquivo de configuração único para cada serviço que deseja que o xinetd
gerencie. Fizemos isso acima para o serviço SSH e chamamos o arquivo de /etc/xinetd.d/ssh
. O nome dos arquivos de configuração pode ser escolhido arbitrariamente, exceto por nomes de arquivos que contenham um ponto (.
) ou que terminem com um til (~
). Mas é comum atribuir ao arquivo o nome do serviço que se deseja configurar.
Alguns arquivos de configuração no diretório /etc/xinet.d/
já são fornecidos pela distribuição:
$ ls -l /etc/xinetd.d total 52 -rw-r--r-- 1 root root 640 Feb 5 2018 chargen -rw-r--r-- 1 root root 313 Feb 5 2018 chargen-udp -rw-r--r-- 1 root root 502 Apr 11 10:18 daytime -rw-r--r-- 1 root root 313 Feb 5 2018 daytime-udp -rw-r--r-- 1 root root 391 Feb 5 2018 discard -rw-r--r-- 1 root root 312 Feb 5 2018 discard-udp -rw-r--r-- 1 root root 422 Feb 5 2018 echo -rw-r--r-- 1 root root 304 Feb 5 2018 echo-udp -rw-r--r-- 1 root root 312 Feb 5 2018 servers -rw-r--r-- 1 root root 314 Feb 5 2018 services -rw-r--r-- 1 root root 569 Feb 5 2018 time -rw-r--r-- 1 root root 313 Feb 5 2018 time-udp
Esses arquivos podem ser usados como modelos no raro caso de ser necessário usar alguns serviços legados, como o daytime
, uma implementação ainda incipiente de um servidor de horário. Todos esses arquivos de modelo contêm a diretiva disable = yes
.
Eis mais alguns detalhes sobre as diretivas usadas para ssh no arquivo de exemplo /etc/xinetd.d/ssh
, acima.
service ssh { disable = no socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/sshd server_args = -i flags = IPv4 interface = 192.168.178.1 }
service
-
Lista o serviço que o xinetd deve controlar. Podemos usar um número de porta, como 22, ou o nome mapeado para o número da porta em
/etc/services
, por exemplossh
. {
-
Abrimos uma chave para iniciar as configurações detalhadas.
disable
-
Para ativar essas configurações, defina esta diretiva como
no
. Se quiser desabilitar a configuração temporariamente, useyes
. socket_type
-
Escolha
stream
para os sockets TCP oudgram
para os sockets UDP e outros. protocol
-
Escolha TCP ou UDP.
wait
-
Para as conexões TCP, esta diretiva costuma estar definida como
no
. user
-
O serviço iniciado nesta linha será propriedade deste usuário.
server
-
Caminho completo para o serviço que deve ser iniciado por
xinetd
. server_args
-
Aqui, podemos adicionar opções para o serviço. Quando iniciados por um super-servidor, muitos serviços requerem uma opção especial. Para o SSH, essa opção seria
-i
. flags
-
Você pode escolher IPv4, IPv6 e outros.
interface
-
A interface de rede que o
xinetd
deve controlar. Nota: você também pode escolher a diretivabind
, que é simplesmente um sinônimo parainterface
. }
-
Por fim, fechamos a chave.
Os sucessores dos serviços iniciados pelo super-servidor xinetd
são as unidades de socket do systemd. Configurar essas unidades é muito simples, porque já existe uma unidade de socket do systemd predefinida para SSH. É preciso garantir que os serviços xinetd
e SSH não estejam em execução.
Agora basta iniciar a unidade de socket SSH:
$ sudo systemctl start ssh.socket
Para verificar qual serviço está escutando agora na porta 22, usamos lsof
novamente. Observe que a opção -P
foi usada para mostrar o número da porta em vez do nome do serviço na saída:
$ sudo lsof -i :22 -P COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemd 1 root 57u IPv6 14730112 0t0 TCP *:22 (LISTEN)
Para completar esta sessão, tentamos fazer o login no servidor com um cliente SSH à escolha.
Tip
|
Caso |
Em busca de daemons desnecessários nos serviços
Por motivos de segurança, bem como para controlar os recursos do sistema, é importante ter uma visão geral dos serviços que estão em execução. Serviços desnecessários e não utilizados devem ser desativados. Por exemplo, caso você não precise distribuir páginas da web, não há necessidade de executar um servidor web como o Apache ou o nginx.
Nos sistemas baseados em SyS-V-init, podemos verificar o status de todos os serviços com o seguinte comando:
$ sudo service --status-all
Verifique se cada um dos serviços listados na saída do comando são necessários e desative todos os que forem desnecessários com (para sistemas baseados em Debian):
$ sudo update-rc.d SERVICE-NAME remove
Ou, nos sistemas baseados em Red Hat:
$ sudo chkconfig SERVICE-NAME off
Nos sistemas modernos baseados em systemd, podemos usar o seguinte comando para listar todos os serviços em execução:
$ systemctl list-units --state active --type service
Em seguida, desativamos as unidades de serviço desnecessárias com:
$ sudo systemctl disable UNIT --now
Este comando interrompe o serviço e o remove da lista de serviços, evitando assim que seja lançado na próxima inicialização do sistema.
Além disso, para obter um levantamento dos serviços de rede que estão à escuta, podemos usar netstat
em sistemas mais antigos (desde que o pacote net-tools
esteja instalado):
$ netstat -ltu Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN tcp 0 0 localhost:mysql 0.0.0.0:* LISTEN tcp6 0 0 [::]:http [::]:* LISTEN tcp6 0 0 [::]:ssh [::]:* LISTEN udp 0 0 0.0.0.0:bootpc 0.0.0.0:*
Ou, nos sistemas modernos, rodamos o comando equivalente ss
(que significa “serviços de socket”):
$ ss -ltu Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port udp UNCONN 0 0 0.0.0.0:bootpc 0.0.0.0:* tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* tcp LISTEN 0 80 127.0.0.1:mysql 0.0.0.0:* tcp LISTEN 0 128 *:http *:* tcp LISTEN 0 128 [::]:ssh [::]:*
Usando TCP wrappers como uma espécie de firewall simples
Nos tempos em que não havia nenhum firewall disponível para Linux, TCP wrappers eram usados para proteger as conexões de rede em um host. Hoje em dia muitos programas não obedecem mais a TCP wrappers. Nas distribuições recentes baseadas em Red Hat (por exemplo, o Fedora 29), o suporte a TCP wrappers foi removido completamente. Porém, para oferecer suporte aos sistemas Linux legados que ainda usam TCP wrappers, vale a pena ter algum conhecimento básico sobre essa tecnologia específica.
Usaremos novamente o serviço SSH como exemplo básico. O serviço em nosso host de exemplo deve ser acessível apenas a partir da rede local. Primeiro, verificamos se o daemon SSH usa a biblioteca libwrap
, que oferece suporte a TCP wrappers:
$ ldd /usr/sbin/sshd | grep "libwrap" libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f91dbec0000)
A seguir, adicionamos a seguinte linha ao arquivo /etc/hosts.deny
:
sshd: ALL
Finalmente, configuramos uma exceção no arquivo /etc/hosts.allow
para conexões SSH da rede local:
sshd: LOCAL
As alterações entram em vigor imediatamente, sem a necessidade de reiniciar qualquer serviço. Para verificar, use o cliente ssh
.
Exercícios Guiados
-
Como desbloquear a conta
emma
, anteriormente bloqueada? -
Anteriormente, a conta
emma
tinha uma data de expiração definida. Como definir a data de expiração comonever
(nunca)? -
Imagine que o serviço de impressão CUPS, que lida com trabalhos de impressão, não é necessário em seu servidor. Como desativar o serviço permanentemente? Como verificar se a porta apropriada não está mais ativa?
-
Você instalou o servidor web nginx. Como verificar se o nginx suporta TCP wrappers?
Exercícios Exploratórios
-
Verifique se a existência do arquivo
/etc/nologin
impede o login do usuárioroot
. -
A existência do arquivo
/etc/nologin
impede logins sem senha com chaves SSH? -
O que acontece no login quando o arquivo
/etc/nologin
contém somente esta linha de texto:login currently is not possible
? -
A usuária comum
emma
seria capaz de obter informações sobre o usuárioroot
contidas no arquivo/etc/passwd
, por exemplo com o comandogrep root /etc/passwd
? -
A usuária comum
emma
seria capaz de recuperar informações sobre sua própria senha com hash contida no arquivo/etc/shadow
, por exemplo com o comandogrep emma /etc/shadow
? -
Quais etapas devem ser executadas para habilitar e verificar o antigo serviço daytime a ser gerenciado pelo xinetd? Observe que este é apenas um exercício exploratório, não faça isso em um ambiente de produção.
Resumo
Nesta lição, você aprendeu:
-
Em qual arquivo são armazenadas as senhas, bem como algumas configurações de segurança de senhas, por exemplo o tempo de expiração.
-
A finalidade do superdaemon
xinetd
e como colocá-lo em execução e iniciar o serviçosshd
sob demanda. -
Verificar quais serviços de rede estão em execução e desabilitar os serviços desnecessários.
-
Usar TCP wrappers como uma espécie de firewall simples.
Comandos usados na lição e nos exercícios:
chage
-
Altera a idade da senha de um usuário.
chkconfig
-
Um comando clássico inicialmente empregado nos sistemas baseados em Red Hat para definir se um serviço deve ser lançado no momento da inicialização ou não.
netstat
-
Um utilitário clássico (agora no pacote
net-tools
) que exibe os daemons que acessam as portas de rede do sistema e seu uso. nologin
-
Um comando que pode ser usado no lugar do shell do usuário para impedir que ele faça login.
passwd
-
Usado para criar ou alterar a senha de um usuário.
service
-
Método antigo de controlar o status de um daemon, como interromper ou iniciar um serviço.
ss
-
O equivalente moderno de
netstat
, mas que também exibe mais informações sobre os diversos sockets em uso no sistema. systemctl
-
Comando de controle do sistema, usado para controlar diversos aspectos dos serviços e sockets em um computador baseado em systemd.
update-rc.d
-
Um comando clássico, semelhante ao
chkconfig
, que habilita ou desabilita o lançamento de um sistema no momento da inicialização nas distribuições baseadas em Debian. xinetd
-
Um superdaemon capaz de controlar sob demanda o acesso a um serviço de rede, deixando assim o serviço inativo até que ele seja realmente chamado para realizar alguma tarefa.
Respostas aos Exercícios Guiados
-
Como desbloquear a conta
emma
, anteriormente bloqueada?O superusuário pode executar
passwd -u emma
para desbloquear a conta. -
Anteriormente, a conta
emma
tinha uma data de expiração definida. Como definir a data de expiração comonever
(nunca)?O superusuário pode usar
chage -E -1 emma
para definir a data de expiração como nunca. Essa configuração pode ser conferida comchage -l emma
. -
Imagine que o serviço de impressão CUPS, que lida com trabalhos de impressão, não é necessário em seu servidor. Como desativar o serviço permanentemente? Como verificar se a porta apropriada não está mais ativa?
Como superusuário, execute
systemctl disable cups.service --now
E para verificar
netstat -l | grep ":ipp "` or `ss -l | grep ":ipp "
-
Você instalou o servidor web nginx. Como verificar se o nginx suporta TCP wrappers?
O comando
ldd /usr/sbin/nginx | grep "libwrap"
mostra uma entrada, caso o nginx suporte TCP wrappers.
Respostas aos Exercícios Exploratórios
-
Verifique se a existência do arquivo
/etc/nologin
impede o login do usuárioroot
.O usuário
root
ainda é capaz de fazer login. -
A existência do arquivo
/etc/nologin
impede logins sem senha com chaves SSH?Sim, e os logins sem senha também são impedidos.
-
O que acontece no login quando o arquivo
/etc/nologin
contém somente esta linha de texto:login currently is not possible
?A mensagem
login currently is not possible
será exibida e o login não será possível. -
A usuária comum
emma
seria capaz de obter informações sobre o usuárioroot
contidas no arquivo/etc/passwd
, por exemplo com o comandogrep root /etc/passwd
?Sim, pois todos os usuários têm permissão de leitura para esse arquivo.
-
A usuária comum
emma
seria capaz de recuperar informações sobre sua própria senha com hash contida no arquivo/etc/shadow
, por exemplo com o comandogrep emma /etc/shadow
?Não, pois os usuários comuns não têm permissão de leitura para esse arquivo.
-
Quais etapas devem ser executadas para habilitar e verificar o antigo serviço daytime a ser gerenciado pelo xinetd? Observe que este é apenas um exercício exploratório, não faça isso em um ambiente de produção.
Primeiro, altere o arquivo
/etc/xinetd.d/daytime
definindo a diretivadisable = no
. Depois, reinicie o serviço xinetd comsystemctl restart xinetd.service
(ouservice xinetd restart
nos sistemas com SyS-V-Init). Confira se funcionou comnc localhost daytime
. Em vez denc
também é possível usarnetcat
.