quarta-feira, 25 de maio de 2011

CA e Apache com SSL

Configuração de um servidor como CA e web SSL
Pretende-se com este trabalho configurar um servidor como Autoridade de Certificação (CA) e como servidor web com SSL.
O servidor usado é o ubuntu 10.04 (Lucid Lynx) server. O cliente pode ser qualquer um que permita a utlização de um browser com suporte para SSL. Neste trabalho foi usado o Mozilla Firefox a correr em ubuntu 11.04 (Natty Narwhal).
O servidor precisa que estejam instalados os pacotes openssl e apache2.
Vamos assumir que o servidor funciona no endereço www.redes.pt.
Para este trabalho foi criada uma entrada no ficheiro hosts tanto do servidor como do cliente, para que o endereço www.redes.pt apontasse para o ip do servidor.
Depois de cumpridos estes requisitos é necessário:

  1. Gerar autoridade de certificação
  2. Instalar a autoridade de certificação
    1. no cliente
    2. no servidor
  3. Criar um certificado para o servidor
  4. Configurar o site seguro usando o certificado gerado.

1. Gerar autoridade de certificação
Primeiro é necessário criar um par de chaves de encriptação. Vamos usar o algoritmo 3DES com 4096 bits.
openssl genrsa -des3 -out ca.key 4096
As chaves ficam armazenadas no ficheiro ca.key.
De seguida vamos usar essa chave para criar um certificado autoassinado, isto é, a própria entidade que requere o certificada é a entidade que o assina. O certificadao é do tipo X.509 com uma validade de 365 dias.
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
O certificado fica em ca.crt.
2. Instalar a autoridade de certificação
2.1. Cliente
É necessário enviar o ficheiro ca.crt (através de pen, e-mail, etc) para o cliente.
No Firefox ir a Editar » Preferências » Avançado » Ver certificados » Importar, e importar o certificado.
2.2. Servidor
Copiar o ficheiro ca.crt para /etc/ssl/certs e ca.key para /etc/ssl/private
3. Criar um certificado para o servidor
Primeiro é preciso criar um par de chaves para o servidor web. Vamos criar chaves 3DES com 2048 bits.
openssl genrsa -des3 -out www.redes.pt.key 2048
O nome do servidor foi usado como nome do ficheiro, mas tal não é obrigatório.
Vamos agora fazer um pedido para que a CA assine digitalmente a chave de encriptação.
openssl req -new -key www.redes.pt.key -out www.redes.pt.csr
O requerimento fica em www.redes.pt.csr
Agora a CA vai assinar o pedido, criando o certificado:
openssl x509 -req -days 365 -in www.redes.pt.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out www.redes.pt.crt
O certificado fica em www.redes.pt.crt.
O Common Name (CN) do certificado do servidor TEM de ser www.redes.pt.
Copiamos agora o ficheiro www.redes.pt.crt para /etc/ssl/certs e o ficheiro www.redes.pt.key para /etc/ssl/private
4. Configurar o site seguro usando o certificado
É preciso activar o módulo SSL no Apache, copiando os ficheiros ssl.conf e ssl.load de /etc/apache2/mods-available para /etc/apache2/mods-enabled.
Editamos o ficheiro /etc/apache2/mods-enabled/ssl.conf e criamos um virtualhost, dentro da secção IfModule.../IfModule.
Vamos criar o site www.redes.pt, alojado em /var/www/seguro.
O virtualhost deve conter pelo menos, as seguintes directivas:
VirtualHost exemplo.dominio.topo:443

DocumentRoot “/var/www/seguro”
ServerName www.redes.pt:443
ServerAdmin root@redes.pt
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
SSLEngine on
SSLCipherSuite
ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/certs/www.redes.pt.crt
SSLCertificateKeyFile /etc/ssl/private/www.redes.pt.key
/VirtualHost
Nota: faltam os sinais "maior" e "menor" nas tags VirtualHost, porque o Blogspot as retira automaticamente.
Outros comandos de interesse

openssl rsa -noout -text -in server.key
Mostra o conteúdo da chave server.key


openssl req -noout -text -in server.csr
Mostra o conteúdo do pedido de certificado server.csr


openssl x509 -noout -text -in ca.crt
Mostra o conteúdo do certificado ca.crt


openssl rsa -in server.key -out server-nopass.key
Retira a password da chave.

sábado, 21 de maio de 2011

Mail do Moodle através do GMail

Para evitar SPAM, muito serviços de e-mail não aceitam mensagens de servidores "desconhecidos".
Portanto, se temos um servidor com Moodle, quando tenta enviar as mensagens (fóruns, mensagens de registo, etc) estas mensagens são rejeitadas pelos servidores de mail do GMail, HotMail, etc.
Para ultrapassar isto, basta definir uma conta de GMail no Moodle, para poder enviar os e-mails através do GMail e não diretamente a partir do servidor.
As instruções seguintes servem para Moodle 1.9.x, versão 1.9.2 ou superior. É possível fazer o mesmo para versões anteriores ou posteriores, mas os passos são diferentes.

Passo 1

É conveniente actualizar o Moodle para a última versão estável do ramo 1.9.

Passo 2

Editar o ficheiro /lib/phpmailer/class.smtp.php e procurar a linha 83, ou como as linhas podem mudar ligeiramente, logo a seguir à linha

function Connect($host,$port=0,$tval=30) {

acrescentar:

$host = 'ssl://' . $host;

Gravar o ficheiro.

Passo 3

Convém agora criar uma conta de GMail para usar especificamente para enviar o e-mail do Moodle.
Na página de configuração do e-mail, em Administração » Servidor » Correio electrónico (http://endereço_do_servidor/admin/settings.php?section=mail) acrescentar os seguintes dados:
  • Servidores de SMTP: smtp.gmail.com:465
  • Nome de utilizador de SMTP: endereço da conta gmail, incluindo a parte @gmail.com
  • Senha de SMTP: a password da conta gmail usada.

Passo 4

Testar para verificar se o e-mail é enviado corretamente.
Notar que as mensagens dos fóruns são enviadas após um tempo de espera (tipicamente 30 minutos) e que normalmente os resumos dos fóruns só são enviados uma vez por dia (tipicamente às 17:00), por isso pode ser necessário esperar algum tempo (~ 24 h) para verificar se as mensagens são realmente enviadas.

Pagina de administração do Moodle não aparece

No Moodle 1.8 e 1.9 acontece um irritante bug, não sei porquê, mas a página de admin fica completamente em branco, sem nenhum conteúdo.
Não consegui descobrir o que causa isto, mas descobri como resolver.
Editar o ficheiro /enrol/internal/enrol.php e comentar as linhas da classe enrolment_plugin (a linha com a definição da classe e a linha com o } ).
E pronto, subitamente já aparece tudo.

terça-feira, 10 de maio de 2011

Windows XP como terminal server

Como usar um modesto Windows XP (SP3) e transformá-lo num servidor de terminais.
O Windows XP tem já instalado um Remote Desktop Server que está artificialmente limitado a servir apenas um utilizador de cada vez. Este patch permite retirar essa limitação e deixa o XP servir vários clientes em simultâneo.
Após instalar o patch é preciso verificar se:
  1. O Fast User Switch está ligado
  2. Os utilizadores pertencem ao grupo Remote Desktop Users
  3. Os utilizadores têm password definida
Para adicionar os utilizadores ao grupo Remote Desktop Users ir a Painel de Controle » Administration Tools » Computer management » Local users and groups » Users

domingo, 13 de março de 2011

Painel de controlo para webserver

Acabo de experimentar alguns painéis de controlo para servidores web, OpenPanel, ispCP Omega, EHCP.
Para os experimentar instalei-os em máquinas virtuais do VirtualBox. Todos tiveram como base o Ubuntu 10.04 (Lucid Lynx) Server.
Já há alguns anos que uso o (excelente) ISPConfig 2 e recentemente passei a usar o ISPConfig 3, mas queria dar uma vista de olhos em outras ofertas open source para webpanels.
ISPConfig 2
Já é antigo, mas continua bastante bom. Aproveitando a licença open source, as instalações que uso do ISPConfig 2 estão "personalizadas" e vão exactamente de encontro ao que precisava na altura em que os instalei. A navegação não é das mais fáceis, mas é bastante eficaz. A interface de administração vem com https de instalação.
ISPConfig 3
Mais moderno e melhor interface, mas o painel de administração não usa https, embora seja possível acrescentar.
OpenPanel
Muito bom aspecto, baseado na interface do MacOS e fácil de instalar e configurar. Foi o que se instalou mais rapidamente e ocupou menos espaço em disco, o que é sinal que não tem todas as funcionalidades dos outros...
É fácil e rápido para criar coisas como por exemplo redirects, mas faltam-lhe algumas características dos outros painéis.
ispCP Omega
Muito completo. É um fork do VHCS (do qual dizem muito bem, mas nunca experimentei). O desenvolvimento do VHCS tem estado parado.
A instalação foi demorada e (aparentemente) bastante completa.
A interface é agradável e fácil de utilizar (usável). Faz distinção entre administradores, revendedores e utilizadores (como o ISPConfig) e tem suporte para emissão de facturas e criação de templates de alojamento.
EHCP
A instalação foi demorada. A interface ainda não está completa... Tem muita potencialidade, mas ainda não está pronto para ser usado num ambiente mais exigente.
Conclusão
Quando se está com pressa e não se precisa de muita complexidade: OpenPanel
Para um serviço com aspecto mais profissional: ispCP Omega
Daqui por uns tempos voltar a visitar o EHCP
ISPConfig 3 continua a ser uma boa opção.

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.