Transporte Seguro com o Easy-RSA
Originalmente, o protocolo LDAP trafega na rede em texto claro. Isso inclui as senhas de usuário que, mesmo criptografadas, podem ser extraídas da rede (sob alvo de sniffers) e sofrerem ataques de dicionário, por exemplo. Esse problema pode ser evitado adicionando uma camada extra de criptografia.
Um algorítimo de criptografia extensamente utilizado é o RSA, que em neste caso será utilizado sob o conceito de criptografia de chave pública. Em um mecanismo de criptografia de chave pública, é utilizado um par de chaves criptográficas, uma pública e outra privada, associadas de tal maneira que, uma mensagem criptografada com a chave pública só pode ser descriptografada de posse de sua correspondente privada (isso garante a confidencialidade da mensagem). Por outro lado, uma mensagem criptografada com a chave privada pode ser lida por quem possuir a chave pública. Isso permite autenticar a origem de uma mensagem, pois apenas alguém de posse da chave privada poderia gerá-la.
O estabelecimento de criptografia implica o uso de certificados em uma conexão cliente-servidor, o que também garante identidade mútua. A segurança no transporte dos dados é fornecida pela criptografia enquanto que a confiança é garantida por um ou mais certificados que atestam a identidade do servidor.
Via de regra, esses certificados são emitidos por uma entidade pública independente e de confiança reconhecida, conhecida como Autoridade Certificadora - AC (ou CA, do inglês "Certificate Authority"), em troca do pagamento (geralmente anual) de uma taxa de serviço. Como exemplos de Autoridade Certificadoras nacionais, temos a Caixa Econômica Federal, Serasa Experian, Casa da Moeda do Brasil, entre outras.
Geralmente, por questões de custo ou mesmo de implementação, é comum a utilização de certificados digitais auto-assinados, onde o próprio provedor de um determinado serviço atesta sua identidade. Neste cenário, os clientes que se conectam a um determinado serviço que utiliza um certificado auto-assinado, utiliza uma cópia do próprio certificado do servidor, o que significa que para cada serviço disponibilizado deve haver, em cada cliente que o utilize, uma cópia do certificado emitido pelo servidor.
A grande questão da auto-assinatura é que qualquer um pode emitir um certificado e se passar pela uma entidade na rede. Pode-se imaginar um atacante com acesso a rede, que se vale de certificados auto-assinados, suprimindo a identidade de um servidor legítimo e desviando as requisições dos clientes para todo e qualquer fim.
Como Autoridades Certificadoras públicas cobram pela emissão de certificados válidos, uma opção viável é criar um certificado a partir de uma autoridade privada para uso na rede local. O
Easy-RSA é um utilitário criado para prover e gerenciar uma infraestrutura de certificação X.509 e que pode ser utilizado para criar uma Infraestrutura de Chave Pública (ICP) voltada para o ambiente de rede local de uma empresa, por exemplo.
Neste artigo, será utilizado o Easy-RSA para criar uma Autoridade Certificadora (AC) local, que será responsável por gerar os certificados necessários, tanto para o servidor quanto para os clientes.
Instalação
Na máquina da AC será instalado o Easy-RSA, inicializada uma nova PKI e gerado um par de chaves (pública e privada) para o servidor LDAP. Por questões de segurança, é recomendável que a máquina da AC seja independente do servidor LDAP.
Instalando dependências, a única dependência do EasyRSA é o pacote do OpenSSL:
sudo apt-get update
sudo apt-get install openssl
Verificado o diretório para onde se deseja baixar o pacote do EasyRSA, o pacote deve ser baixado e extraído (o EasyRSA também está disponível através do gerenciador de pacotes):
wget https://github.com/OpenVPN/easy-rsa/archive/3.0.1.tar.gz
tar xzvf 3.0.1.tar.gz
rm 3.0.1.tar.gz
Dever existir um diretório de nome "easy-rsa-3.0.1" no diretório atual.
Configurando o servidor
Deve-se criar um arquivo "vars" a partir de uma cópia do arquivo existente "vars.example" presente no subdiretório "easyrsa3".
Ao iniciar o processo de criação da AC, será editado o arquivo "vars". Por padrão, de forma comentada, tem-se algo do tipo:
set_var EASYRSA_REQ_COUNTRY "US"
set_var EASYRSA_REQ_PROVINCE "CA"
set_var EASYRSA_REQ_CITY "SanFrancisco"
set_var EASYRSA_REQ_ORG "Copyleft Certificate Co"
set_var EASYRSA_REQ_EMAIL "me@example.net"
set_var EASYRSA_OU "My Organizational Unit"
Os comentários no arquivo explicam o significado de cada uma das variáveis.
O valores da configuração padrão, devem ser alterados de acordo com a organização em questão:
sudo vi vars
Executando o seguinte comando, o processo é iniciado. Será requisitada a palavra-chave e as informações relativas à organização:
sudo ./easyrsa build-ca
Gerando o certificado da Autoridade Certificadora - AC:
Basta confirmar (com
Enter) os valores informados anteriormente no arquivo "vars". No campo "Common name" insira o nome totalmente qualificado (FQDN) relativo ao domínio.
Finalizada a criação da Autoridade Certificadora, o programa de configuração relata a criação do certificado público em
/etc/certs/easy-rsa-3.0.1/easyrsa3/pki/ca.crt. Também foi gerada uma chave privada correspondente em
/etc/certs/easy-rsa-3.0.1/easyrsa3/pki/private/ca.key.
É preciso garantir que o arquivo privado possa ser lido pelo servidor LDAP, que roda sob o usuário "openldap":
# adduser openldap ssl-cert
# cp ca.key /etc/ssl/private/ca.segredes.local.key
# chown root:ssl-cert /etc/ssl/private/ca.segredes.local.key
# chmod 0640 /etc/ssl/private/ca.segredes.local.key
# mv segredes.local.pem /etc/ssl/certs/
Informando ao daemon 'slapd' para que utilize as chaves para criptografia, alterando os parâmetros do 'ssl.dif' com o 'ldapmodify':
# cat >ssl.ldif <<END
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/segredes.local.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ca.segredes.local.key
-
END
# ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
Para finalizar este procedimento e habilitar a criptografia, o arquivo
/etc/default/slapd deve ser editado alterando-se a variável "SLAPD_SERVICES" para os valores "ldaps:/// ldapi:///", conforme abaixo:
sudo vi /etc/default/slapd
# Default location of the slapd.conf file or slapd.d cn=config directory. If
# empty, use the compiled-in default (/etc/ldap/slapd.d with a fallback to
# /etc/ldap/slapd.conf).
SLAPD_CONF=
# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER="openldap"
# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP="openldap"
# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf by
# default)
SLAPD_PIDFILE=
# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
# SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
SLAPD_SERVICES="ldaps:/// ldapi:///"
# If SLAPD_NO_START is set, the init script will not start or restart
# slapd (but stop will still work). Uncomment this if you are
# starting slapd via some other means or if you don't want slapd normally
# started at boot.
#SLAPD_NO_START=1
# If SLAPD_SENTINEL_FILE is set to path to a file and that file exists,
# the init script will not start or restart slapd (but stop will still
# work). Use this for temporarily disabling startup of slapd (when doing
# maintenance, for example, or through a configuration management system)
# when you don't want to edit a configuration file.
SLAPD_SENTINEL_FILE=/etc/ldap/noslapd
# For Kerberos authentication (via SASL), slapd by default uses the system
# keytab file (/etc/krb5.keytab). To use a different keytab file,
# uncomment this line and change the path.
#export KRB5_KTNAME=/etc/krb5.keytab
# Additional options to pass to slapd
SLAPD_OPTIONS=""
Configurando o cliente
No cliente, a configuração relacionada aos módulos (previamente instalados) "libpam-ldap" e "libnss-ldap" deve ser alterada para usar a URl "ldaps://". Como agora o ambiente de rede local dispõe de uma ICP X.509, onde os certificados públicos são assinados pela chave da Autoridade Certificadora - AC, é preciso configurar os clientes para confiar nas assinaturas da AC local.
Com os arquivos em mãos, os certificado da AC devem ser copiados para
/usr/local/share/ca-certificates:
# cp ca.crt /usr/local/share/ca-certificates/segredes.crt
# update-ca-certificates
Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d....
Adding debian:falcot.pem
done.
done.
Alterando os parâmetros de URl padrão e DN BASE padrão no arquivo
/etc/ldap/ldap.conf. Neste caso, os valores são:
#
# LDAP Defaults
#
# See ldap.conf(5) for details
# This file should be world readable but not world writable.
BASE dc=segredes,dc=local
URI ldaps://ldap.segredes.local
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
# TLS certificates (needed for GnuTLS)
TLS_CACERT /etc/ssl/certs/ca-certificates.crt
Na próxima página, será instalado o ambiente gráfico.