quarta-feira, 28 de julho de 2010

RADIUS no pfSense

Seria mesmo agradável que o pacote FreeRADIUS para o pfSense 1.2.3 permitisse editar todas as opções de configuração directamente a partir da interface Web, mas infelizmente não é assim. É mesmo preciso editar o ficheiro de configuração com o vi e perceber o funcionamento do EAP, LEAP, PEAP, PAP, MSCHAP, GTC... é muita sigla.
Instalação e configuração inicial
A instalação do FreeRADIUS é bastante simples, é só ir a System » Packages e instalar o pacote.
A configuração inicial também não é complicada.
Em Services » FreeRADIUS temos acesso a 3 separadoes.
No separador users definimos os utilizadores que vão utilizar a rede, incluindo o IP que vão receber e a VLAN a que vão estar associados. É possível definir utilizadores "gerais" que recebem um IP por DHCP dentro de uma gama, permitindo várias ligações em simultâneo do mesmo utilizador.
O separador clientes permite definir os clientes que vão usar o servidor RADIUS. Neste tipo de autenticação os clientes são os switch e access points, não são os PCs (estes chamam-se os suplicantes) nem os utilizadores humanos (os users). Cada cliente, além de um IP fixo e um nome descritivo, tem de ter definida uma chave secreta, que terá de ser definida também no dispositivo cliente para assegurar protecção e autenticação das comunicações. Os Settings são as definições gerais do servidor (interface, número do porto e logs).
Depois desta configuração o RADIUS não vai funcionar, pois é preciso configurar o método de autenticação e para isso é preciso editar um ficheiro de configuração.
A autenticação por 802.1x permite que um suplicante se identifique usando um par username/password e/ou um certificado digital. Para o fim que pretendo o certificado digital não é prático, por isso vou usar a autenticação baseada apenas em username/password.
Processo de autenticação
Início
Quando o cliente detecta um novo suplicante ou um suplicante faz um pedido de autenticação estabelece-se uma ligação em estado "não autorizado" entre cliente e suplicante. Neste estado apenas tráfego 802.1x é permitido. Qualquer outro tipo de tráfego é bloqueado pelo cliente (switch/AP). O cliente envia uma mensagem de EAP-Request ao suplicante, que responde com uma mensagem de EAP-Response. Esta mensagem é encapsulada numa mensagem RADIUS e enviada pelo cliente ao servidor de autenticação, que a processa.
Negociação EAP
O servidor envia uma mensagem EAP-Request (encapsulada numa mensagem RADIUS) a indicar o método de autenticação que prefere. O suplicante pode aceitar esse método de autenticação e iniciar logo a fase de autenticação. Se não aceitar o método envia uma resposta em que indica o método que prefere.
A fase de negociação continua até que ambas as partes (suplicante e servidor) conseguem chegar a acordo sobre o método a usar ou cancela a autenticação se não chegarem a acordo.
Autenticação
Quando chegam a acordo inicia-se uma conversa entre o suplicante e o servidor, traduzida pelo cliente.
A comunicação entre o cliente e o servidor faz-se com mensagens RADIUS, a comunicação entre o suplicante e o cliente faz-se com mensagens EAPOL. É o cliente que faz a tradução.
Se a autenticação for bem sucedida o cliente passa a ligação (port) para o estado autorizado.
Problemas
Em teoria é tudo muito bonito e bem pensado, mas existem alguns problemas. Mesmo sem entrar pelos problemas de segurança do protocolo 802.1x, que são vários e graves, o principal problema é a implementação nos sistemas operativos.
Os utilizadores da rede irão utilizar quase exclusivamente sistemas operativos Windows (XP, Vista ou 7), que têm problemas com a autenticação 802.1x, cada um à sua maneira.
Em todos os sistemas Windows, após uma autenticação falhada o sistema operativo não permite nova tentativa durante 20 minutos, no XP e Vista é preciso editar uma chave de registo para poder alterar o valor.
O Windows XP tem dificuldades em lidar com a alteração súbita de IP resultante da autenticação de um novo utilizador. Também pode haver problemas com o PEAP-MSCHAPv2 se não for usado com roaming profiles (há um hotfix).
O Windows 7 deixa de responder a pedidos 802.1x se uma autenticação falhar (há um hotfix).
EAP
O Extensible Authenciation Protocol é uma framework que fornece os métodos básicos de comunicação entre dispositivos para realizar autenticação. Por si só não consegue realizar a autenticação, têm de ser usadas "extensões" ao EAP básico para permitir a autenticação. Existem cerca de 40 métodos diferentes de autenticação EAP.
Há métodos definidos pela IETF (e que portanto são padrões oficiais) e métodos proprietários de determinados fabricantes. Fornecem autenticação dos pares e/ou confidencialidade total/parcial da mensagems e/ou integridade da mensagem usando vários métodos. Cada um com as suas vulnerabilidades.
Para a comunicação ser bem sucedida, obviamente, ambos os extremos têm de suportar EXACTAMENTE o mesmo método de autenticação. Cada método tem os seus próprio parâmetros de configuração que também devem ser idênticos nos dois dispositivos que pretendem comunicar.
É uma grande complicação, ou seja, SNAFU.
Regra geral, a combinação mais compatível (sem ser universal) é o PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol - Microsoft Challenge-handshake Authentication Protocol version 2)
Então o que eu quero mesmo é configurar o FreeRADIUS para usar PEAP-MSCHAPv2.
Configurar o PEAP-MSCHAPv2
A configuração é feita editando os ficheiros de configuração do FreeRADIUS, que se encontram em /usr/local/etc/raddb/.
Os ficheiros importantes editar são:

  • /usr/local/etc/raddb/radiusd.conf
  • /usr/local/etc/raddb/clients.conf
  • /usr/local/etc/raddb/eap.conf
  • /usr/local/etc/raddb/users
Apenas é preciso editar "à mão" dois deles (radiusd.conf e eap.conf), os outros dois podem ser configurados através da interface web.
A edição pode ser feita por consola, usando o vi, mas o pfSense permite-nos editar os ficheiros de configuração directamente dentro da interface web (que é bastante mais amigável que o vi). Basta ir a Diagnostics » Edit file e introduzir o caminho completo do ficheiro e carregar em Load (e no fim carregar em Save).
É aconselhável ler (e perceber) os comentários em cada ficheiro, apesar de eu aqui ter eliminado os comentários, por uma questão de simplicidade.
O radiusd.conf deve conter:

   mschap {
        authtype = MS-CHAP
        use_mppe = yes
        require_encryption = yes
        require_strong = yes
   }



   authorize {
        preprocess
        mschap
suffix
eap
files
   }
  
   authenticate {
        Auth-Type MS-CHAP {
               mschap
        }
        eap
    }
O clients.conf deve conter a identificação dos clientes, mas é preenchido pela interface web. Não é preciso editar "manualmente".
O eap.conf deve conter, pelo menos:
default_eap_type = peap



tls { 
        private_key_password = whatever
        private_key_file = ${raddbdir}/certs/cert-srv.pem
        certificate_file = ${raddbdir}/certs/cert-srv.pem
        CA_file = ${raddbdir}/certs/demoCA/cacert.pem
        dh_file = ${raddbdir}/certs/dh
        random_file = /dev/urandom
}

peap {
        default_eap_type = mschapv2
}
A private_key_password por defeito é whatever. Para usar outra private key é preciso gerar novos certificados, mas por enquanto KISS e usamos estes.
O ficheiro users contém, em plain text, os usernames e passwords dos utilizadores. Provavelmente seria melhor manter esta informação de uma forma mais complexa e segura (MySQL, LDAP, AD, etc), mas primeiro vamos KISS (e já é bastante complicado). Não é preciso editar manualemente o users, os utilizadores podem ser adicionados pela interface web.
Ligação
Em clientes linux indicar PEAP com MSCHAPv2 (a entidade de certificação não é necessária), colocar username e password e já está.
Em clientes XP (falta experimentar)
Em cliente Vista (falta experimentar)
Em clientes Windows 7 é preciso definir manualmente uma ligação, retirar o "validar certificado" e tirar o "usar nome de inicia de sessão no windows", depois introduzir username e password (tendo em conta que tanto o protocolo PEAP como o MSCHAPv2 são da Microsoft talvez fosse de esperar uma ligação mais simples...).
Webgrafia
http://tldp.org/HOWTO/8021X-HOWTO/freeradius.html
http://www.linuxquestions.org/questions/linux-wireless-networking-41/freeradius-peap-wpa_supplicant-653620/
http://blog.vannuil.com/2008/10/wpa2-enterprise.html

terça-feira, 27 de julho de 2010

Snort no pfSense

Instalar e configurar o Snort no pfSense
pfSense é uma excelente firewall opensource baseada em BSD.
Snort é uma a aplicação de detecção e prevenção de intrusos (IDS/IPS)
Estando o pfSense 1.2.3 já instalado a instalação do Snort é bastante simples, pois só é preciso ir aos pacotes e instalar...
Convém registar-se em http://www.snort.org para obter um Oinkcode, que é um código para poder fazer o download de uma versão mais recente das regras de IDS/IPS (para obter as regras ainda mais recentes é preciso pagar - acho justo).
A configuração faz-se em Services » Snort.
Interface WAN
Primeiro é preciso adicionar uma interface (por defeito é a externa - WAN).
A configuração individual da interface permite, primeiro, definir um nome (obrigatório) e o algoritmo de gestão de memória. O algoritmo seleccionado é o AC-BNFA e li algures num blog, que é (era) o único que funcionava.
De seguida, a Home net e External net definem a rede interna e externa, respectivamente. Se estamos a configurar as regras para a interface WAN podem deixar-se em default. Para definir regras para a LAN é preciso editar o ficheiro de configuração (iremos a isso mais tarde).
O block offenders adiciona uma regra à firewall para bloquear o IP que gerou um aviso no Snort.
Para cada interface podem definir-se as categoria ou regras individuais que se pretendem usar.
As regras de IDS/IPS consomem muita RAM e muitos ciclos de CPU, por isso convém activar apenas as que se pretendem MESMO usar.
Podem ainda ser definidos manualmente o endereço de alguns servidores (DNS, mail, http, etc). Estes endereços serão depois usados em algumas regras para ajudar a fazer uma filtragem mais exacta.
Os Preprocessors são operações aplicadas aos pacotes de dados antes de serem analisados pelas regras.
Liguei o Portscan detection e DNS detection. Algumas regras (nomeadamente as de exploit e de bad traffic) apenas funcionam se o preprocessador de http estiver ligado.
Configurações globais
Depois de configurar pelo menos uma interface podemos aceder às configurações globais, onde configuramos o comportamento do Snort que é comum a todas as interfaces. É aqui que se indica o Oinkcode para poder aceder a actualizações. O snort.org apenas permite actualizações com um intervalo mínimo de 15 minutos. Os developers aconselham 12 horas. Eu coloquei a 24.
Temos ains acesso aos logs dos alertas e dos bloqueios, bem como a uma lista branca de IPs. O Supress não faço ideia o que seja.
Interface LAN
A configuração da interface LAN é mais complicada.
É preciso "trocar" as redes LAN e WAN para poder analisar o tráfego que chega à firewall pela interface "inside" como possível fonte de ataque.
É preciso aceder à consola do pfSense e editar o ficheiro snort.conf, que se encontra em /usr/local/etc/snort/snort_12345_fxp1/.
A parte "snort_12345_fxp1" deve ser alterada para coincidir com o nome usado pelo snort (aparece na página de configuração da interface).
Edita-se o ficheiro trocando a definição da HOME_NET com a EXTERNAL_NET.
Assim, a EXTERNAL_NET fica com os IPs das máquinas que pertencem à rede e a HOME_NET fica com tudo o que não pertence à EXTERNAL_NET.
De volta à interface web, definir as categorias, regras, servidores, e pré-processadores para esta interface.
Gravar as alterações e aplicar.
Por via das dúvidas é melhor parar o Snort e depois voltar a iniciar. Se houver algum problema com as configurações o Snort não arranca. Caso algo não funcione, verificar os logs do sistema Status » System logs
No meu caso foi preciso esperar algum tempo até o Snort começar a detectar ataques.