CÓDIGO DA DISCIPLINA: DEE345

SEGURANÇA DIGITAL - Aula 10

Prof. Jéfer Benedett Dörr

Departamento de Engenharias e Exatas - UFPR/Palotina

Docente de Segurança da Informação

Aula 10: Autenticação, Autorização e Controle de Acesso Avançado

Objetivos de Aprendizagem

Compreender a infraestrutura AAA (Autenticação, Autorização, Auditoria).
Detelhar estratégias de autenticação (SYK, SYH, SYA) e MFA.
Explorar armazenamento seguro de senhas e ataques de dicionário.
Conhecer protocolos de SSO e IAM: Kerberos, SAML, OAuth2, OIDC, FIDO2.
Implementar ACLs e RBAC em sistemas UNIX.

1. Infraestrutura AAA

AAA (Autenticação, Autorização, Auditoria) é fundamental para segurança, conforme LGPD e PNSI.

Autenticação: confirma identidade de usuários e sistemas.
Autorização: verifica permissões após autenticação.
Auditoria: coleta/análise de logs para detectar e investigar incidentes.

FreeIPA: ipa user-add aluno --first=Aluno --last=Sobrenome. freeipa.org
Wazuh: wazuh-control start. wazuh.com

Prática: Configure FreeIPA para gerenciar usuários. Monitore logins SSH com Wazuh em uma VM.

Configuração FreeIPA + Wazuh para Gerenciamento e Monitoramento

Objetivo: Criar um domínio FreeIPA para gerenciamento centralizado de usuários e monitorar acessos SSH via Wazuh.

1. Configurar FreeIPA Server

Instale em uma VM CentOS/RHEL: sudo yum install freeipa-server
Execute a configuração: sudo ipa-server-install
Crie um usuário admin: sudo kinit admin
sudo ipa user-add --first=Nome --last=Sobrenome usuario

2. Configurar Cliente FreeIPA

Nos hosts clientes (Ubuntu/Debian): sudo apt install freeipa-client
Junte-se ao domínio: sudo ipa-client-install --domain=seu.dominio --server=ip.do.servidor

3. Instalar Wazuh Agent

Adicione o repositório: curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | sudo apt-key add -
echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | sudo tee /etc/apt/sources.list.d/wazuh.list
Instale o agente: sudo apt update && sudo apt install wazuh-agent
Registre no servidor Wazuh: sudo /var/ossec/bin/agent-auth -m IP_DO_SERVIDOR_WAZUH

4. Monitorar Logins SSH

No servidor Wazuh, verifique os alertas em:
Security Events → Filtrar por "sshd"
Para alertas específicos de FreeIPA: grep "ipa" /var/ossec/logs/alerts/alerts.json

Resultado: Usuários gerenciados centralmente via FreeIPA com todos os logins SSH monitorados e alertados pelo Wazuh.

2. Autenticação UNIX

2.1 Credenciais e Sessões - Entendendo Credenciais e Sessões no Linux

Conceito: Entenda como o Linux gerencia identidades de usuário e permissões durante a execução de processos.

Identificadores de Usuário

UID (User ID): Identificador real do usuário
EUID (Effective User ID): Identificador usado para verificação de permissões
SUID (Saved User ID): Permite recuperar privilégios anteriores

Comandos para Verificação


# Verificar IDs do usuário atual
id

# Verificar IDs em processos em execução
ps -o ruid,euid,suid,cmd -p [PID]

Arquivos Críticos de Usuários

/etc/passwd: Informações básicas de usuários
/etc/group: Definições de grupos
/etc/shadow: Senhas criptografadas (acesso restrito)

Proteção dos Arquivos


# Verificar permissões
ls -l /etc/passwd /etc/group /etc/shadow

# Configurar permissões seguras:
chmod 644 /etc/passwd   # -rw-r--r--
chmod 644 /etc/group    # -rw-r--r--
chmod 640 /etc/shadow   # -rw-r-----

Boas Práticas:

O /etc/shadow deve ser acessível apenas por root
Verifique regularmente se as permissões não foram alteradas
Use sudo para operações privilegiadas

UID, EUID, SUID — id, ps -o ruid,euid,ruid,cmd
/etc/passwd, /etc/group, /etc/shadow — proteção via permissões:


ls -l /etc/{passwd,group,shadow}
chmod 640 /etc/shadow

2.2 Fatores de Autenticação

SYK: senha, PIN, padrão.
SYH: tokens TOTP, smartcards, chaves YubiKey.
SYA: biometria (fingerprint, facial).

🔑 SYK (Something You Know) - O que você sabe

Senhas alfanuméricas
PINs numéricos
Padrões de desbloqueio
Perguntas de segurança

Exemplo de uso: login: usuario + senha: ********

📱 SYH (Something You Have) - O que você possui

Tokens TOTP (Google Authenticator, Authy)
Smartcards (CAC, PIV)
Chaves de hardware (YubiKey, Titan)
Aplicativos de autenticação
Tokens SMS (menos seguro)

Exemplo: ssh -i ~/.ssh/id_ed25519_sk user@host (requer toque na YubiKey)

👤 SYA (Something You Are) - O que você é

Impressão digital (fingerprint)
Reconhecimento facial
Reconhecimento de íris
Reconhecimento de voz
Comportamento (digitação, padrões de uso)

Exemplo: Desbloqueio de smartphone com Face ID

💡 Melhor prática: Use MFA (Multi-Factor Authentication) combinando pelo menos 2 fatores diferentes (ex: SYK + SYH) para segurança máxima.

2.3 MFA Prático para SSH com Google Authenticator

Contexto: A configuração abaixo implementa autenticação em dois fatores (2FA) para SSH, combinando:

🔑 Chaves SSH (algo que você tem)
🔢 Códigos TOTP do Google Authenticator (algo que você sabe)

Isso protege contra ataques mesmo se uma chave SSH for comprometida.

1. Instalação do Google Authenticator PAM

sudo apt update
sudo apt install libpam-google-authenticator

O módulo PAM (Pluggable Authentication Modules) permite integrar o 2FA ao sistema de autenticação do Linux.

2. Configuração por Usuário

google-authenticator

Este comando interativo irá:

Gerar um segredo único para o usuário
Mostrar um QR code para configurar no app móvel
Fornecer códigos de recuperação
Fazer perguntas de configuração (recomenda-se responder "Y" para todas)

3. Configuração do PAM para SSH

# Editar /etc/pam.d/sshd
auth required pam_google_authenticator.so

Esta linha adiciona a verificação do código TOTP como requisito para autenticação via SSH.

4. Configuração do SSH Server

# Editar /etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive

Estas diretivas:

ChallengeResponseAuthentication: Ativa o desafio/resposta para 2FA
AuthenticationMethods: Exige ambos:
- Chave SSH (publickey)
- Código TOTP (keyboard-interactive)

Fluxo de Autenticação Resultante:

Cliente conecta via SSH com sua chave privada
Servidor pede o código TOTP do Google Authenticator
Usuário digita o código atual do app móvel
Acesso é concedido somente após ambas as verificações

5. Reinicie o serviço SSH

sudo systemctl restart sshd

Importante: Mantenha uma sessão SSH aberta durante os testes para evitar bloqueio acidental.

Dicas de Segurança:

Guarde os códigos de recuperação em local seguro
Para administradores, configure primeiro em conta secundária
Considere usar AllowUsers no sshd_config para restringir acesso

Outras alternativas:

Duo Security: sudo apt install duo-unix
YubiKey OTP: Configuração similar com pam_yubico
FreeOTP: Alternativa open-source ao Google Authenticator

3. Senhas e Hashes

3.1 Armazenamento Seguro de Senhas

Somente hashes em /etc/shadow
Use bcrypt ou SHA-512:


# Em /etc/login.defs
ENCRYPT_METHOD SHA512

Princípio Básico: Sistemas Linux nunca armazenam senhas em texto puro.
Exemplo ruim: Se /etc/passwd contivesse "senha123" diretamente
Mecanismo Atual: O arquivo /etc/shadow guarda apenas:
- Hashes criptográficos das senhas
- Salts (valores aleatórios para evitar rainbow tables)
- Metadados de expiração
Exemplo de linha: usuario:$6$salt$hash:18000:0:99999:7:::
Algoritmos Recomendados:
- bcrypt - Resistente a GPU/ASIC (melhor para novas instalações)
- SHA-512 - Padrão atual na maioria das distros Linux
- Obsoleto: MD5 e SHA-256 devem ser evitados


# Configuração global (distros baseadas em Linux-PAM)
# Arquivo: /etc/login.defs

# Algoritmo de hashing (SHA512 é o padrão atual)
ENCRYPT_METHOD SHA512

# Número de rounds (iterações) para o hash
# Valor maior = mais seguro porém mais lento
SHA_CRYPT_MIN_ROUNDS 5000
SHA_CRYPT_MAX_ROUNDS 5000

Verificação Prática:

Crie um usuário de teste: sudo useradd teste_pwd
Defina uma senha: sudo passwd teste_pwd
Verifique o hash gerado: sudo grep teste_pwd /etc/shadow
Observe o prefixo $6$ indicando SHA-512

3.2 Técnicas de Quebra de Senhas

Objetivo: Demonstrar como atacantes podem explorar senhas fracas
Uso legítimo: Testes de penetração autorizados e auditorias de segurança
Ferramentas Comuns:
- John the Ripper - Quebra hashes offline
- Hydra - Ataques de força bruta em serviços online
- Hashcat - Uso intensivo de GPU para quebra rápida

1. Quebra de Hashes com John the Ripper


# Comando básico para quebra com wordlist:
john --format=raw-sha512 --wordlist=/usr/share/wordlists/rockyou.txt hashes.txt

# Opções importantes:
# --format: Especifica o tipo de hash (ex: raw-sha512, nt, md5crypt)
# --wordlist: Dicionário de senhas comuns
# hashes.txt: Arquivo contendo os hashes capturados

2. Ataque de Força Bruta no SSH com Hydra


# Teste de credenciais contra serviço SSH:
hydra -L usuarios.txt -P senhas.txt -t 4 ssh://192.168.0.100

# Parâmetros chave:
# -L: Arquivo com lista de usuários
# -P: Arquivo com lista de senhas
# -t: Número de threads paralelas
# ssh://: Alvo do ataque (pode ser substituído por http-post-form, ftp, etc)

Hashcat:


# Hashcat
hashcat -m 1800 -a 0 hashes.txt /usr/share/wordlists/rockyou.txt
# Pwgen
pwgen -s -c -n 16 1
# Cracklib
echo "senha123" | cracklib-check

Proteções Efetivas:

Senhas Complexas: Mínimo de 12 caracteres com mistura de tipos
Limitadores de Tentativas: fail2ban ou pam_tally2 para bloquear IPs
Autenticação Multi-Fator: Impede uso de senhas mesmo que descobertas
Salting Adequado: Garante que cada hash seja único mesmo para senhas iguais

Exemplo de Boas Práticas:


# Instalação do fail2ban para proteção do SSH
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

# Configuração básica (em /etc/fail2ban/jail.local):
[sshd]
enabled = true
maxretry = 3
bantime = 1h

3.3 Políticas de Senha

Objetivo: Estabelecer controles para fortalecimento de credenciais
Problema comum: Senhas permanentes sem rotatividade ou critérios de complexidade

1. Comando `chage` (Change Age)


# Configurações básicas para usuário 'aluno':
sudo chage -d 0 aluno          # Força troca no próximo login
sudo chage -E 2025-12-31 aluno # Data de expiração da conta
sudo chage -m 7 aluno          # Mínimo 7 dias entre trocas
sudo chage -M 90 aluno         # Máximo 90 dias com mesma senha
sudo chage -W 5 aluno          # Aviso 5 dias antes da expiração
sudo chage -I 2 aluno          # Inativação após 2 dias expirado

2. Configuração Global (/etc/login.defs)


# Políticas padrão para todos usuários:
PASS_MAX_DAYS   90
PASS_MIN_DAYS   7
PASS_WARN_AGE   14
PASS_MIN_LEN    12

3. Complexidade com pam_pwquality


# Editar /etc/security/pwquality.conf:
minlen = 12
minclass = 3  # Mínimo 3 categorias (maiúscula, minúscula, número, símbolo)
maxrepeat = 2
usercheck = 1  # Não permite senhas contendo nome do usuário

4. Verificação de Políticas


# Visualizar configurações de um usuário:
sudo chage -l aluno

# Verificar senhas fracas (requer pam_cracklib):
sudo pam_tally2 --user=aluno

# Testar complexidade:
echo "senha_teste" | pwscore

5. Exemplo Completo de Implementação


#!/bin/bash
# Script de aplicação de políticas:
for user in $(ls /home); do
  sudo chage -M 90 -m 7 -W 7 $user
  sudo chage -d 0 $user  # Força troca inicial
done

# Aplicar política de complexidade:
sudo sed -i 's/^minlen.*/minlen = 12/' /etc/security/pwquality.conf
sudo systemctl restart sshd

Boas Práticas Recomendadas:

Rotatividade: Troca obrigatória a cada 90 dias (não menos que 7 dias)
Histórico: Bloquear reuso das últimas 5 senhas (remember=5 no pam_unix)
Bloqueio: Contas inativas devem ser desabilitadas após 30 dias
Auditoria: Monitorar falhas de login com faillock ou pam_tally2

4. Autenticação com Kerberos

Arquitetura Básica

KDC (Key Distribution Center) - Servidor central que emite tickets:
- Serviço: krb5-kdc
- Porta padrão: 88 (TCP/UDP)
kadmin - Ferramenta administrativa:
- kadmin.local (modo direto no KDC)
- kadmin (acesso remoto autenticado)

Fluxo de Autenticação

Cliente solicita TGT (Ticket Granting Ticket) ao KDC
KDC verifica credenciais e emite TGT criptografado
Cliente usa TGT para obter tickets de serviço

Comandos Práticos

1. Administração de Principals


# Acessar console administrativo (como root no KDC)
sudo kadmin.local

# Criar novo principal (usuário/serviço)
addprinc aluno@DOMINIO.LOCAL

# Listar principals existentes
listprincs

# Remover principal
delprinc aluno@DOMINIO.LOCAL

2. Operações com Tickets


# Obter ticket inicial (como usuário)
kinit aluno@DOMINIO.LOCAL
# Senha será solicitada

# Verificar tickets ativos
klist

# Destruir tickets
kdestroy

3. Configuração do Cliente


# Arquivo de configuração (/etc/krb5.conf)
[libdefaults]
    default_realm = DOMINIO.LOCAL
    ticket_lifetime = 24h
    renew_lifetime = 7d

[realms]
    DOMINIO.LOCAL = {
        kdc = kdc.dominio.local
        admin_server = kdc.dominio.local
    }

Exemplo Completo


# Instalação no Ubuntu Server (KDC)
sudo apt install krb5-kdc krb5-admin-server

# Configuração inicial
sudo krb5_newrealm

# Criar usuário e testar
sudo kadmin.local -q "addprinc aluno"
kinit aluno
klist -e  # Mostra algoritmos de criptografia

Boas Práticas

Use nomes de realm em MAIÚSCULAS (padrão Kerberos)
Defina tempos de vida curtos para tickets (24h para TGT)
Monitore o KDC com kadmind para tentativas de brute-force
Integre com LDAP para gerenciamento centralizado de usuários

Ferramentas

FreeIPA: freeipa.org
Heimdal: h5l.org

5. SSO & IAM

Single Sign-On (SSO): Login único para múltiplas aplicações.
Identity and Access Management (IAM): Gerenciamento de identidades e controle de acesso.

5.1 SAML

Security Assertion Markup Language - Troca de asserções XML entre IdP e SP.

Componentes:

Identity Provider (IdP): Quem autentica (ex.: ADFS, Shibboleth)
Service Provider (SP): Aplicação que o usuário acessa
Asserção: Documento XML com dados de autenticação

Uso típico: Ambientes corporativos, sistemas legados, intranet.

5.2 OAuth 2.0 / OIDC

OAuth 2.0: Protocolo de autorização para APIs.
OpenID Connect (OIDC): Camada de autenticação sobre OAuth 2.0.

Fluxo básico:

App redireciona usuário para IdP
Usuário se autentica
IdP retorna código de autorização
App troca código por tokens

# Teste com oauth2-cli:
oauth2 --client-id X --client-secret Y \
  --authorize-url https://idp/auth \
  --token-url https://idp/token \
  --scope "openid profile"

Tokens:

Access Token: Acesso a APIs
Refresh Token: Renovação de tokens
ID Token (OIDC): Informações de identidade

Uso típico: APIs modernas, SPAs, apps móveis, "Login com Google".

5.3 FIDO2 / WebAuthn

Autenticação sem senha via criptografia de chave pública no navegador.

Funcionamento:

Registro do autenticador (biometria, token físico)
Sistema envia desafio criptográfico
Autenticador assina com chave privada
Sistema valida com chave pública

Autenticadores:

Biométricos: Touch ID, Face ID, impressão digital
Hardware: YubiKey, Google Titan
Plataforma: TPM, Secure Enclave

// Exemplo WebAuthn - Registro
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32),
    rp: { name: "Minha App" },
    user: { id: userId, name: "user@email.com" }
  }
});

Vantagens: Resistente a phishing, sem senhas, experiência superior.

5.4 Comparação Rápida

Método	Melhor para	Formato	Complexidade
SAML	Corporativo, B2B	XML	Alta
OAuth/OIDC	APIs, apps modernas	JSON	Média
FIDO2/WebAuthn	Autenticação forte	Binário	Baixa (usuário)

Recomendação: Use OIDC para novos projetos, SAML para sistemas legados, FIDO2 para máxima segurança.

Ferramentas

Keycloak: keycloak.org
Okta: okta.com

6. Controle de Acesso

Controle de Acesso: Mecanismos para determinar quem pode acessar recursos e quais operações podem realizar.

6.1 ACL Unix (Access Control Lists)

Extensão das permissões Unix tradicionais (rwx), permitindo controle granular por usuário/grupo específico.

Instalação e uso básico:

# Instalar suporte ACL
sudo apt install acl

# Definir permissões específicas
setfacl -m u:alice:rw /dados/secreto        # usuário alice: read+write
setfacl -m g:developers:r /dados/projeto    # grupo developers: read only
setfacl -m o::--- /dados/privado            # outros: sem acesso

# Verificar ACLs
getfacl /dados/secreto

# Remover ACL específica
setfacl -x u:alice /dados/secreto

# Limpar todas as ACLs
setfacl -b /dados/secreto

Permissões ACL:

r (read): Leitura de arquivos, listagem de diretórios
w (write): Escrita em arquivos, criação/remoção em diretórios
x (execute): Execução de arquivos, travessia de diretórios

Vantagens: Controle fino, múltiplos usuários/grupos por arquivo.
Limitações: Nem todos os sistemas de arquivos suportam, complexidade aumentada.

6.2 RBAC com SUDO

Role-Based Access Control usando sudo para elevar privilégios baseados em papéis de usuário.

Configuração de papéis:

# /etc/sudoers.d/papeis-sistema

# Papel: Administradores de Banco
%dbadmins ALL=(ALL) /usr/bin/mysql, /usr/bin/psql, /bin/systemctl restart mysql

# Papel: Operadores Web
%webops ALL=(www-data) /usr/sbin/nginx, /bin/systemctl * nginx, /bin/systemctl * apache2

# Papel: Backup Operators
%backup ALL=(root) NOPASSWD: /usr/bin/rsync, /bin/tar, /usr/bin/duplicity

# Papel: Desenvolvedores
%developers ALL=(deploy) /usr/bin/git, /bin/systemctl restart app-*

# Usuário específico com comando restrito
alice ALL=(root) /usr/local/bin/deploy-script.sh

Sintaxe sudo:

%grupo: Aplica regra a todo o grupo
ALL=(usuário): Pode executar como usuário específico
NOPASSWD: Não solicita senha
Comandos separados por vírgula: Lista de executáveis permitidos

Comandos úteis:

# Verificar privilégios do usuário atual
sudo -l

# Executar como usuário específico
sudo -u www-data /usr/sbin/nginx -t

# Log de atividades sudo
sudo tail -f /var/log/auth.log | grep sudo

6.3 Modelos de Controle de Acesso

6.3.1 DAC (Discretionary Access Control)

Princípio: O proprietário do recurso controla quem tem acesso.

Exemplos: Permissões Unix (chmod), ACLs, compartilhamentos Windows
Características: Flexível, descentralizado, fácil de usar
Limitações: Proprietário pode dar acesso inadequado, difícil auditoria

# Exemplo DAC
chmod 755 arquivo.txt          # proprietário define permissões
chown alice:developers file    # transfere propriedade

6.3.2 MAC (Mandatory Access Control)

Princípio: Sistema operacional controla acesso baseado em políticas centralizadas.

Implementações: SELinux, AppArmor, grsecurity
Características: Segurança alta, resistente a privilege escalation
Aplicação: Ambientes críticos, sistemas governamentais

# Exemplo SELinux
# Verificar contexto de segurança
ls -Z /var/www/html/

# Definir contexto para arquivos web
chcon -R -t httpd_exec_t /var/www/html/
restorecon -R /var/www/html/

# Verificar status SELinux
getenforce
sestatus

6.3.3 RBAC (Role-Based Access Control)

Princípio: Permissões atribuídas a papéis, usuários recebem papéis.

Hierarquia: Usuários ← Papéis ← Permissões

Vantagens: Escalável, auditável, segue princípio do menor privilégio
Implementações: Active Directory, LDAP, Kubernetes RBAC, AWS IAM

# Exemplo conceitual RBAC
Usuário: joão
Papéis: [developer, backup-operator]
Permissões: 
  - developer: {read_code, write_code, deploy_staging}
  - backup-operator: {read_backups, create_backups}

6.4 Comparação dos Modelos

Modelo	Controle	Flexibilidade	Segurança	Uso Típico
DAC	Proprietário	Alta	Média	Sistemas pessoais, compartilhamentos
MAC	Sistema	Baixa	Muito Alta	Ambientes críticos, militares
RBAC	Administrador	Média	Alta	Empresas, sistemas corporativos

6.5 Boas Práticas

Princípio do Menor Privilégio: Conceder apenas acesso mínimo necessário
Separação de Responsabilidades: Dividir tarefas críticas entre múltiplos usuários
Revisão Regular: Auditar e remover acessos desnecessários
Logging: Registrar todas as operações de acesso
Automação: Use ferramentas como Ansible para gerenciar permissões em escala

# Exemplo de auditoria de acesso
# Verificar logins recentes
last -n 20

# Verificar tentativas de sudo
grep sudo /var/log/auth.log | tail -20

# Listar usuários com privilégios sudo
grep -E '^sudo|^admin' /etc/group

Recomendação: Combine modelos conforme necessidade - RBAC para organização geral, MAC para proteção crítica, DAC para flexibilidade do usuário final.

Ferramentas

OpenLDAP: ldapadd -x -D "cn=admin,dc=exemplo,dc=com" -W -f user.ldif. openldap.org
Ansible: ansible-playbook configure_sudoers.yml. ansible.com

7. Extensões Práticas: LDAP, PAM & Auditoria

7.1 Configuração do OpenLDAP

O OpenLDAP é um servidor de diretórios que implementa o protocolo LDAP para gerenciar autenticação e autorização centralizadas, essencial para conformidade com LGPD e PNSI. Esta seção configura um servidor LDAP básico em Ubuntu, cria uma estrutura inicial e protege credenciais.

Configuração Básica do OpenLDAP

Os passos a seguir instalam o OpenLDAP, configuram o domínio base, criam uma unidade organizacional e uma conta administrativa, e importam a estrutura inicial.

Passo 1: Instalação


# Instala o servidor OpenLDAP (slapd) e ferramentas de cliente (ldap-utils)
sudo apt update
sudo apt install slapd ldap-utils

Motivo: O slapd é o daemon do servidor LDAP, e o ldap-utils fornece comandos como ldapadd e ldapsearch para gerenciar o diretório.

Objetivo: Disponibilizar os componentes necessários para operar o LDAP.

Segurança: Usa repositórios oficiais do Ubuntu para evitar pacotes maliciosos.

Passo 2: Reconfiguração do Domínio


# Reconfigura o domínio base (ex.: dc=exemplo,dc=local) e a senha do administrador
sudo dpkg-reconfigure slapd

Motivo: Define o DN base (ex.: dc=exemplo,dc=local) e cria a conta cn=admin,dc=exemplo,dc=local com senha hasheada.

Objetivo: Personalizar a estrutura do diretório e habilitar administração segura.

Segurança: A senha é armazenada como hash SSHA, resistente a ataques de força bruta.

Passo 3: Criação da Estrutura (db.ldif)


# Arquivo db.ldif
dn: ou=People,dc=exemplo,dc=local
objectClass: organizationalUnit
ou: People

dn: cn=admin,dc=exemplo,dc=local
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
userPassword: {SSHA}hash_da_senha
description: LDAP Administrator

# Gerar hash SSHA para a senha
slappasswd -s MinhaSenha123 > hash.txt

Motivo: Define uma unidade organizacional (ou=People) para usuários e uma conta administrativa (cn=admin) com senha criptografada.

Objetivo: Criar a estrutura hierárquica inicial do diretório LDAP.

Segurança: O hash {SSHA} protege a senha, e a hierarquia facilita ACLs.

Passo 4: Importação da Estrutura


# Importa o arquivo db.ldif para o diretório LDAP
sudo ldapadd -x -D "cn=admin,dc=exemplo,dc=local" -W -f db.ldif

Motivo: Adiciona os objetos definidos no LDIF ao servidor LDAP.

Objetivo: Popular o diretório com a estrutura inicial.

Segurança: Usa autenticação administrativa para evitar modificações não autorizadas.

Passo 5: Verificação


# Lista objetos no diretório
ldapsearch -x -b "dc=exemplo,dc=local" -H ldap://localhost

Motivo: Confirma que os objetos foram importados corretamente.

Objetivo: Validar a configuração inicial do servidor.

Segurança: Usa conexão local para evitar exposição de dados.

Ferramentas Complementares

phpLDAPadmin: Interface web para gerenciar LDAP. sudo apt install phpldapadmin. phpldapadmin.sourceforge.net
JExplorer: Cliente GUI para explorar DIT. jxplorer.org
FreeIPA: LDAP integrado com Kerberos. ipa-server-install. freeipa.org

Nota:

Prática:

Configure um servidor OpenLDAP em uma VM Ubuntu, importe um LDIF com uma OU e um usuário, e verifique com ldapsearch.
Instale phpLDAPadmin e adicione um usuário via interface web.
Configure TLS no OpenLDAP editando cn=config e teste com ldapsearch -Z.

Conformidade Legal:

LGPD: Centralização de identidades facilita auditoria de acessos (Art. 46).
PNSI: Autenticação centralizada é exigida para sistemas críticos.

7.2 Bloqueio de Contas com PAM

O PAM (Pluggable Authentication Modules) gerencia autenticação no Linux, e os módulos pam_tally2 e pam_faillock bloqueiam contas após tentativas de login malsucedidas, protegendo contra força bruta. Esta seção configura bloqueios, monitora falhas e garante conformidade com LGPD e PNSI.

Bloqueio de Contas com PAM

Os passos a seguir configuram pam_tally2 e pam_faillock para bloquear contas após 5 falhas, com desbloqueio após 600 segundos, e mostram como auditar tentativas.

pam_tally2

Passo 1: Configuração


# Adiciona ao /etc/pam.d/common-auth
auth required pam_tally2.so onerr=fail deny=5 unlock_time=600 even_deny_root

Motivo: Configura o módulo pam_tally2 para bloquear contas após 5 falhas de login, com desbloqueio automático após 10 minutos, incluindo o usuário root.

Objetivo: Proteger serviços (ex.: SSH, login local) contra ataques de força bruta.

Segurança: Limita tentativas de acesso não autorizado, armazenando contadores em /var/log/tallylog.

Passo 2: Verificação de Tentativas


# Exibe falhas de login para o usuário aluno
pam_tally2 --user aluno

Motivo: Consulta o número de tentativas malsucedidas e o status de bloqueio.

Objetivo: Auditar possíveis ataques ou erros de usuário.

Segurança: Facilita a detecção de força bruta e suporta auditorias.

Passo 3: Resetar Contador


# Zera o contador de falhas para aluno
pam_tally2 --user aluno --reset

Motivo: Desbloqueia a conta manualmente, zerando falhas.

Objetivo: Restaurar acesso legítimo após bloqueio.

Segurança: Requer privilégios administrativos, evitando abusos.

pam_faillock

Passo 1: Configuração


# Adiciona ao /etc/pam.d/common-auth
auth required pam_faillock.so preauth silent deny=5 fail_interval=900 unlock_time=600
auth [default=die] pam_faillock.so authfail

Motivo: Configura pam_faillock para bloquear contas após 5 falhas em 15 minutos, com desbloqueio após 10 minutos, sem vazar informações.

Objetivo: Implementar bloqueio robusto e moderno, compatível com auditorias.

Segurança: O parâmetro silent evita exposição de detalhes, e fail_interval protege contra ataques distribuídos.

Passo 2: Verificação de Status


# Exibe falhas e status de bloqueio para aluno
faillock --user aluno

Motivo: Relata tentativas malsucedidas e estado da conta.

Objetivo: Permitir auditoria e gerenciamento de bloqueios.

Segurança: Suporta conformidade com LGPD e PNSI via rastreamento.

Configurações Complementares


# Integra Fail2ban para bloquear IPs
sudo apt install fail2ban
# /etc/fail2ban/jail.local
[sshd]
enabled = true
port = ssh
maxretry = 5
bantime = 3600
sudo systemctl restart fail2ban

# Monitora logs PAM com Wazuh
tail -f /var/ossec/logs/alerts/alerts.log | grep pam

# Adiciona MFA com Google Authenticator
auth required pam_google_authenticator.so

Motivo: Combina bloqueio de contas com bloqueio de IPs e MFA para proteção em camadas.

Objetivo: Aumentar a resiliência contra ataques de força bruta.

Segurança: Fail2ban bloqueia IPs maliciosos, Wazuh audita em tempo real, e MFA adiciona autenticação forte.

Ferramentas Complementares

Fail2ban: Bloqueia IPs após falhas. fail2ban-client status sshd. fail2ban.org
Wazuh: Monitora logs PAM. wazuh-control start. wazuh.com
PAM-MFA: Integra Google Authenticator. github.com/google-authenticator

Prática:

Configure pam_tally2 e pam_faillock em uma VM Ubuntu, simule falhas de login SSH e verifique bloqueios com pam_tally2 e faillock.
Integre Fail2ban para bloquear IPs e monitore logs com Wazuh.
Adicione MFA com Google Authenticator e teste bloqueio com pam_faillock.

Conformidade Legal:

LGPD: Bloqueio de contas protege contra acessos indevidos (Art. 46).
PNSI: Controles de autenticação são obrigatórios para sistemas críticos.
Lei Carolina Dieckmann: Mitiga invasões por força bruta.

7.3 Auditoria com auditd

O auditd é o sistema de auditoria do Linux que registra eventos como acessos a arquivos, chamadas de sistema e autenticações, essencial para detecção de incidentes e conformidade com LGPD e PNSI. Esta seção configura auditoria de eventos de autenticação, analisa logs e gera relatórios.

Auditoria com auditd

Os passos a seguir instalam o auditd, configuram monitoramento de logs de autenticação, e mostram como buscar e resumir eventos para auditoria.

Passo 1: Instalação e Inicialização


# Instala auditd e ativa o serviço
sudo apt update
sudo apt install auditd
sudo systemctl enable --now auditd

Motivo: Instala o daemon de auditoria e garante sua execução contínua.

Objetivo: Disponibilizar o sistema de auditoria para monitoramento de eventos.

Segurança: Usa repositórios oficiais e ativação imediata para proteção ininterrupta.

Passo 2: Configuração de Regras


# Monitora /var/log/auth.log para eventos de autenticação
sudo auditctl -w /var/log/auth.log -p wa -k auth_events
# Monitora alterações em /etc/passwd
sudo auditctl -w /etc/passwd -p wa -k passwd_changes

Motivo: Define regras para rastrear acessos e alterações em logs de autenticação e arquivos críticos.

Objetivo: Detectar tentativas de login, uso de sudo ou modificações não autorizadas.

Segurança: Identifica força bruta, escalação de privilégios ou manipulação de credenciais.

Passo 3: Busca de Eventos


# Pesquisa eventos associados à chave auth_events
sudo ausearch -k auth_events --interpret
# Pesquisa eventos de alterações em /etc/passwd
sudo ausearch -k passwd_changes --interpret

Motivo: Extrai logs detalhados de eventos auditados em formato legível.

Objetivo: Investigar incidentes como falhas de login ou acessos indevidos.

Segurança: Facilita a identificação de atividades suspeitas com detalhes de usuário e hora.

Passo 4: Relatório Resumido


# Gera relatório de eventos auditados
sudo aureport -k --summary

Motivo: Sumariza eventos por chave para auditorias ou relatórios de conformidade.

Objetivo: Fornecer uma visão geral de atividades suspeitas.

Segurança: Suporta LGPD e PNSI com evidências de monitoramento.

Configurações Complementares


# Monitora execuções de comandos
sudo auditctl -a always,exit -F arch=b64 -S execve -k command_exec
# Integra com Wazuh
tail -f /var/ossec/logs/alerts/alerts.log | grep audit
# Relatório diário com Logwatch
logwatch --service audit --range yesterday --detail High

Motivo: Amplia auditoria para comandos e integra com ferramentas de análise.

Objetivo: Aumentar visibilidade e resposta a incidentes.

Segurança: Wazuh e Logwatch fornecem alertas e relatórios automatizados.

Ferramentas Complementares

Wazuh: SIEM para alertas em tempo real. wazuh-control start. wazuh.com
Logwatch: Relatórios diários de logs. logwatch --service audit. sourceforge.net/logwatch
Splunk: Análise avançada de logs. splunk add monitor /var/log/audit/audit.log. splunk.com

Prática:

Configure auditd em uma VM Ubuntu, monitore /var/log/auth.log e /etc/passwd, e analise com ausearch.
Integre auditd com Wazuh para alertas e gere relatórios com Logwatch.
Simule um ataque de força bruta no SSH e verifique logs com aureport.

Conformidade Legal:

LGPD: Auditoria de acessos é obrigatória (Art. 46).
PNSI: Monitoramento é exigido para sistemas críticos.
Lei Carolina Dieckmann: Rastreamento mitiga invasões.

7.4 Mini-Laboratório: AAA Unificado (FreeRADIUS + OpenLDAP + Kerberos)

Este laboratório integra FreeRADIUS, OpenLDAP e Kerberos para criar uma infraestrutura AAA (Autenticação, Autorização, Auditoria) centralizada, ideal para redes corporativas. A solução garante autenticação segura, autorização baseada em papéis e auditoria, conforme LGPD e PNSI.

Mini-Laboratório: AAA Unificado

Os passos a seguir instalam os componentes, configuram integrações e testam autenticação RADIUS, criando um servidor AAA funcional.

Passo 1: Instalação


# Instala FreeRADIUS, OpenLDAP e Kerberos
sudo apt update
sudo apt install freeradius freeradius-ldap slapd ldap-utils krb5-kdc krb5-admin-server

Motivo: Disponibiliza os pacotes para FreeRADIUS (autenticação RADIUS), OpenLDAP (diretório de identidades) e Kerberos (autenticação por tickets).

Objetivo: Preparar o servidor AAA com os componentes necessários.

Segurança: Usa repositórios oficiais para evitar pacotes maliciosos.

Passo 2: Configurar FreeRADIUS para OpenLDAP


# Editar /etc/freeradius/3.0/mods-available/ldap
server = 'localhost'
identity = 'cn=admin,dc=exemplo,dc=local'
password = 'senha_admin'
base_dn = 'ou=People,dc=exemplo,dc=local'
# Habilitar módulo
sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/
sudo systemctl restart freeradius

Motivo: Integra o FreeRADIUS com o OpenLDAP para consultar credenciais e atributos de usuários.

Objetivo: Usar o LDAP como backend de autenticação para RADIUS.

Segurança: A senha do bind deve ser forte; em produção, use TLS (ldaps://).

Passo 3: Configurar Kerberos e Integrar com LDAP


# Editar /etc/krb5.conf
[libdefaults]
    default_realm = EXEMPLO.LOCAL
[realms]
    EXEMPLO.LOCAL = {
        kdc = localhost
        admin_server = localhost
    }
# Criar principal mapeado ao LDAP
sudo kadmin.local -q "addprinc -x dn=uid=aluno,ou=People,dc=exemplo,dc=local aluno@EXEMPLO.LOCAL"
sudo systemctl restart krb5-kdc
# Verificar ticket
kinit aluno
klist

Motivo: Configura o Kerberos para autenticação por tickets e sincroniza contas LDAP como principals.

Objetivo: Habilitar SSO com Kerberos, usando o LDAP como fonte de identidades.

Segurança: O mapeamento evita duplicação, e o KDC deve ser protegido contra replay.

Passo 4: Testar Autenticação RADIUS


# Configurar cliente RADIUS em /etc/freeradius/3.0/clients.conf
client localhost {
    ipaddr = 127.0.0.1
    secret = secreta
}
# Testar autenticação
radtest aluno MinhaSenha123 localhost 0 secreta

Motivo: Simula uma solicitação RADIUS para verificar a integração com OpenLDAP.

Objetivo: Confirmar que o servidor AAA autentica usuários corretamente.

Segurança: A senha compartilhada (secreta) deve ser forte e protegida.

Configurações Complementares


# Habilitar TLS no LDAP
tls_cacertfile=/etc/ssl/certs/ca-cert.pem
# Auditar logs RADIUS
tail -f /var/log/freeradius/radius.log
# Capturar pacotes com Wireshark
wireshark -i lo -f "port 1812 or port 88"

Motivo: Adiciona TLS, auditoria e análise de pacotes para maior segurança e depuração.

Objetivo: Proteger comunicações e facilitar diagnóstico.

Segurança: TLS evita interceptação, e logs/Wireshark ajudam a detectar anomalias.

Ferramentas Complementares

FreeIPA: AAA integrado. ipa-server-install. freeipa.org
Wireshark: Analisa pacotes. wireshark -f "port 1812". wireshark.org
Daloradius: Interface web para RADIUS. sudo apt install daloradius. github.com/daloradius

Prática:

Configure FreeRADIUS, OpenLDAP e Kerberos em uma VM Ubuntu e autentique com radtest.
Instale FreeIPA como alternativa e compare com a configuração manual.
Use Wireshark para capturar pacotes RADIUS e Kerberos durante autenticação.

Conformidade Legal:

LGPD: AAA centralizado suporta auditoria (Art. 46).
PNSI: Autenticação robusta para sistemas críticos.
Lei Carolina Dieckmann: Mitiga invasões por credenciais.

7.5 Rede Simulada e Cenários de Controle de Acesso

Este laboratório simula uma rede corporativa com autenticação centralizada (Kerberos), diretório de identidades (OpenLDAP), e controle de acesso (ACLs/RBAC). Dois hosts são configurados: um controlador AAA e um cliente web com SSO, garantindo conformidade com LGPD e PNSI.

Rede Simulada e Cenários de Controle de Acesso

Os passos a seguir montam dois hosts, definem grupos LDAP, configuram diretórios com ACLs/RBAC, e testam acessos para validar a segurança.

Passo 1: Montar Dois Hosts Linux

Controlador AAA


# Instalar FreeRADIUS, OpenLDAP e Kerberos
sudo apt update
sudo apt install freeradius freeradius-ldap slapd ldap-utils krb5-kdc krb5-admin-server
# Configurar OpenLDAP
sudo dpkg-reconfigure slapd
# Configurar Kerberos
sudo krb5_newrealm

Cliente Web


# Instalar Apache e mod_auth_kerb
sudo apt install apache2 libapache2-mod-auth-kerb krb5-user
sudo a2enmod auth_kerb
sudo systemctl restart apache2

Motivo: O controlador AAA centraliza autenticação e autorização; o cliente web simula aplicações com SSO Kerberos e LDAP.

Objetivo: Criar um ambiente realista para testar AAA.

Segurança: Use firewall (ufw allow 1812,88,389) no controlador e HTTPS no cliente.

Passo 2: Definir Grupos no LDAP


# Criar groups.ldif
dn: ou=Groups,dc=exemplo,dc=local
objectClass: organizationalUnit
ou: Groups

dn: cn=financeiro,ou=Groups,dc=exemplo,dc=local
objectClass: posixGroup
cn: financeiro
gidNumber: 1001
memberUid: aluno

dn: cn=ti,ou=Groups,dc=exemplo,dc=local
objectClass: posixGroup
cn: ti
gidNumber: 1002
# Importar
sudo ldapadd -x -D "cn=admin,dc=exemplo,dc=local" -W -f groups.ldif
# Verificar
ldapsearch -x -b "dc=exemplo,dc=local" "(memberUid=aluno)"

Motivo: Cria grupos POSIX para segregar acesso por departamento.

Objetivo: Implementar RBAC com base em grupos LDAP.

Segurança: O bind administrativo protege contra modificações não autorizadas.

Passo 3: Criar Diretórios e Atribuir ACL/RBAC


# Configurar diretórios
sudo mkdir -p /dados/{financeiro,ti}
sudo chown root:financeiro /dados/financeiro
sudo chown root:ti /dados/ti
sudo chmod 770 /dados/{financeiro,ti}
sudo setfacl -m g:financeiro:rwx /dados/financeiro
sudo setfacl -m g:ti:rwx /dados/ti
# Verificar
getfacl /dados/financeiro
getfacl /dados/ti
# Auditar acessos
sudo auditctl -w /dados/financeiro -p wa -k financeiro_access

Motivo: Configura diretórios com permissões baseadas em grupos, usando ACLs para controle granular.

Objetivo: Garantir segregação de acesso entre departamentos.

Segurança: ACLs e propriedade root evitam acessos indevidos.

Passo 4: Testar Acesso


# Configurar Apache SSO (/etc/apache2/sites-available/000-default.conf)
<Directory /var/www/html>
    AuthType Kerberos
    AuthName "Kerberos SSO"
    KrbAuthRealms EXEMPLO.LOCAL
    KrbServiceName HTTP/cliente.exemplo.local
    Krb5KeyTab /etc/apache2/http.keytab
    Require ldap-group cn=financeiro,ou=Groups,dc=exemplo,dc=local
</Directory>
sudo a2ensite 000-default
sudo systemctl restart apache2
# Testar acesso local
su - aluno -c "touch /dados/financeiro/teste.txt"
su - aluno -c "touch /dados/ti/teste.txt" # Deve falhar
# Testar SSO
kinit aluno
firefox http://cliente.exemplo.local

Motivo: Valida autenticação Kerberos, autorização LDAP e ACLs/RBAC.

Objetivo: Confirmar que apenas usuários autorizados acessam recursos.

Segurança: Kerberos protege credenciais, e LDAP+ACLs garantem segregação.

Ferramentas Complementares

FreeIPA: AAA integrado. ipa-server-install. freeipa.org
Wazuh: Monitora logs. tail -f /var/ossec/logs/alerts.log. wazuh.com
phpLDAPadmin: Gerencia LDAP. sudo apt install phpldapadmin. phpldapadmin.sourceforge.net

Nota: O vazamento da Serasa (2024) ocorreu por permissões excessivas, mitigável com ACLs e RBAC.

Prática:

Configure controlador AAA e cliente web em VMs Ubuntu, implemente SSO e teste acesso a diretórios.
Use FreeIPA como alternativa e compare com a configuração manual.
Monitore acessos com Wazuh e auditd, e gerencie grupos com phpLDAPadmin.

Conformidade Legal:

LGPD: RBAC protege dados pessoais (Art. 46).
PNSI: Controles de acesso para sistemas críticos.
Lei Carolina Dieckmann: Mitiga invasões.

Quiz de Avaliação – Aula 10

1. Na infraestrutura AAA, qual componente é responsável por confirmar identidade e credenciais?

Autenticação

Autorização

Auditoria

Access Control

CORRETO! A Autenticação confirma identidade e credenciais.

INCORRETO. É a Autenticação que verifica quem você é, antes de autorizar ou auditar.

2. Em UNIX, qual UID é usado pelo kernel para decisões de acesso?

UID real

EUID (Effective UID)

SUID (Saved UID)

GID primário

CORRETO! O EUID é usado para avaliar permissões em UNIX.

INCORRETO. As decisões de acesso usam o EUID, não o UID real ou SUID.

3. Qual combinação representa autenticação multi-fator (MFA)?

Senha + endereço de e-mail

Senha (SYK) + Token de hardware (SYH)

Impressão digital + foto de perfil

CORRETO! MFA combina ao menos dois fatores, como SYK e SYH.

INCORRETO. Um segundo fator deve ser independente da senha, como um token.

4. Qual protocolo é usado para autenticação única (SSO) em SAML?

OAuth 2.0

SAML (Security Assertion Markup Language)

Kerberos

SSH

CORRETO! SAML é o padrão XML para SSO entre IdP e SP.

INCORRETO. SAML, não OAuth nem Kerberos, é usado para SSO baseado em asserções XML.

5. Qual modelo de controle de acesso associa permissões a papéis em vez de usuários individuais?

ACL

RBAC (Role-Based Access Control)

MAC (Mandatory Access Control)

DAC (Discretionary Access Control)

CORRETO! No RBAC, atribuímos permissões a papéis, não diretamente a usuários.

INCORRETO. A ACL associa permissões a objetos/usuários, enquanto o RBAC usa papéis.

6. Em UNIX, qual comando exibe o conteúdo de /etc/shadow (hashes de senha)?

sudo cat /etc/shadow

cat /etc/passwd

grep shadow /etc/group

sudo less /etc/group

CORRETO! /etc/shadow contém hashes de senha e precisa de sudo para leitura.

INCORRETO. /etc/passwd não armazena hashes — estes estão em /etc/shadow.

7. Qual ferramenta implementa autenticação de rede baseada em tickets?

LDAP

Kerberos

OAuth 2.0

SAML

CORRETO! Kerberos usa tickets para autenticação segura de serviços.

INCORRETO. Kerberos é o protocolo de tickets, não OAuth nem LDAP.

8. Qual comando Linux ajusta a expiração de senha para um usuário (por exemplo, usuário 'aluno')?

passwd -e aluno

sudo chage -E 2025-12-31 aluno

usermod -e aluno 2025-12-31

expiredate aluno 2025-12-31

CORRETO! O comando chage -E define data de expiração da conta.

INCORRETO. Use chage -E para expirar contas; passwd -e apenas força troca no próximo login.

SEGURANÇA DIGITAL - Aula 10

Prof. Jéfer Benedett Dörr

Aula 10: Autenticação, Autorização e Controle de Acesso Avançado

Objetivos de Aprendizagem

1. Infraestrutura AAA

Configuração FreeIPA + Wazuh para Gerenciamento e Monitoramento

1. Configurar FreeIPA Server

2. Configurar Cliente FreeIPA

3. Instalar Wazuh Agent

4. Monitorar Logins SSH

2. Autenticação UNIX

2.1 Credenciais e Sessões - Entendendo Credenciais e Sessões no Linux

Identificadores de Usuário

Comandos para Verificação

Arquivos Críticos de Usuários

Proteção dos Arquivos

2.2 Fatores de Autenticação

2.3 MFA Prático para SSH com Google Authenticator

3. Senhas e Hashes

3.1 Armazenamento Seguro de Senhas

Verificação Prática:

3.2 Técnicas de Quebra de Senhas

1. Quebra de Hashes com John the Ripper

2. Ataque de Força Bruta no SSH com Hydra

Hashcat:

Proteções Efetivas:

Exemplo de Boas Práticas:

3.3 Políticas de Senha

1. Comando chage (Change Age)

2. Configuração Global (/etc/login.defs)

3. Complexidade com pam_pwquality

4. Verificação de Políticas

5. Exemplo Completo de Implementação

Boas Práticas Recomendadas:

4. Autenticação com Kerberos

Arquitetura Básica

Fluxo de Autenticação

Comandos Práticos

1. Administração de Principals

2. Operações com Tickets

3. Configuração do Cliente

Exemplo Completo

Boas Práticas

Ferramentas

5. SSO & IAM

5.1 SAML

5.2 OAuth 2.0 / OIDC

5.3 FIDO2 / WebAuthn

5.4 Comparação Rápida

Ferramentas

6. Controle de Acesso

6.1 ACL Unix (Access Control Lists)

6.2 RBAC com SUDO

6.3 Modelos de Controle de Acesso

6.3.1 DAC (Discretionary Access Control)

6.3.2 MAC (Mandatory Access Control)

6.3.3 RBAC (Role-Based Access Control)

6.4 Comparação dos Modelos

6.5 Boas Práticas

Ferramentas

7. Extensões Práticas: LDAP, PAM & Auditoria

7.1 Configuração do OpenLDAP

Configuração Básica do OpenLDAP

Passo 1: Instalação

Passo 2: Reconfiguração do Domínio

Passo 3: Criação da Estrutura (db.ldif)

Passo 4: Importação da Estrutura

Passo 5: Verificação

Ferramentas Complementares

7.2 Bloqueio de Contas com PAM

Bloqueio de Contas com PAM

pam_tally2

Passo 1: Configuração

Passo 2: Verificação de Tentativas

Passo 3: Resetar Contador

pam_faillock

Passo 1: Configuração

Passo 2: Verificação de Status

Configurações Complementares

Ferramentas Complementares

1. Comando `chage` (Change Age)