110.2 Lição 1

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:

  1. Alguns comandos e definições de configuração básicas para aperfeiçoar a segurança da autenticação com senhas ocultas.

  2. Como usar superdaemons para ouvir conexões de rede de entrada.

  3. Verificação dos serviços de rede em busca de daemons desnecessários.

  4. 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 exemplo ssh.

{

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, use yes.

socket_type

Escolha stream para os sockets TCP ou dgram 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 diretiva bind, que é simplesmente um sinônimo para interface.

}

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 systemctl start ssh.socket não funcione com sua distribuição, experimente systemctl start sshd.socket.

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

  1. Como desbloquear a conta emma, anteriormente bloqueada?

  2. Anteriormente, a conta emma tinha uma data de expiração definida. Como definir a data de expiração como never (nunca)?

  3. 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?

  4. Você instalou o servidor web nginx. Como verificar se o nginx suporta TCP wrappers?

Exercícios Exploratórios

  1. Verifique se a existência do arquivo /etc/nologin impede o login do usuário root.

  2. A existência do arquivo /etc/nologin impede logins sem senha com chaves SSH?

  3. O que acontece no login quando o arquivo /etc/nologin contém somente esta linha de texto: login currently is not possible?

  4. A usuária comum emma seria capaz de obter informações sobre o usuário root contidas no arquivo /etc/passwd, por exemplo com o comando grep root /etc/passwd?

  5. 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 comando grep emma /etc/shadow?

  6. 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:

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

  2. A finalidade do superdaemon xinetd e como colocá-lo em execução e iniciar o serviço sshd sob demanda.

  3. Verificar quais serviços de rede estão em execução e desabilitar os serviços desnecessários.

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

  1. Como desbloquear a conta emma, anteriormente bloqueada?

    O superusuário pode executar passwd -u emma para desbloquear a conta.

  2. Anteriormente, a conta emma tinha uma data de expiração definida. Como definir a data de expiração como never (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 com chage -l emma.

  3. 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 "

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

  1. Verifique se a existência do arquivo /etc/nologin impede o login do usuário root.

    O usuário root ainda é capaz de fazer login.

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

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

  4. A usuária comum emma seria capaz de obter informações sobre o usuário root contidas no arquivo /etc/passwd, por exemplo com o comando grep root /etc/passwd?

    Sim, pois todos os usuários têm permissão de leitura para esse arquivo.

  5. 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 comando grep emma /etc/shadow?

    Não, pois os usuários comuns não têm permissão de leitura para esse arquivo.

  6. 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 diretiva disable = no. Depois, reinicie o serviço xinetd com systemctl restart xinetd.service (ou service xinetd restart nos sistemas com SyS-V-Init). Confira se funcionou com nc localhost daytime. Em vez de nc também é possível usar netcat.

Linux Professional Insitute Inc. Todos os direitos reservados. Visite o site dos Materiais Didáticos: https://learning.lpi.org
31/5000 Este trabalho está licenciado sob a Licença Creative Commons Atribuição-Uso Não-Comercial-NãoDerivativos 4.0 Internacional.