Porteiro competente - Linux Magazine

linux.magazine.com.br
  • No tags were found...

Porteiro competente - Linux Magazine

Controle de acesso em redes com fio com o IEEE 802.1X

SEGURANÇA

Porteiro competente

Você achava que o padrão IEEE 802.1X era apenas para

redes sem fio Veja como configurar um sistema de controle

de acesso de rede com ele e um servidor FreeRADIUS.

por Sven Übelacker e Nils Magnus

Supreet Vaid – www.sxc.hu

Usuários de redes sem fio estão

acostumados com o ritual

de entrada de dados de login

antes da conexão à rede local. O

padrão IEEE 802.1X [1] define uma

técnica para o controle de acesso a

redes baseado em portas usado na

maioria dos pontos de acesso sem fio.

Muitos administradores não percebem

que é possível oferecer controle

de acesso para redes convencionais

(com fio) com o IEEE 802.1X, que

possui um esquema de autenticação

com várias vantagens sobre as alternativas

como a baseada em porta e

MAC, fácil de bisbilhotar e difícil

de gerenciar.

Na era dos notebooks, um laptop

sem autorização pode se conectar a

uma rede a partir de qualquer lugar.

Entretanto, administradores que

procuram uma proteção eficiente

podem usar o IEEE 802.1X para impedir

acessos não autorizados antes

que o intruso chegue até uma janela

de navegador ou uma tela de login.

Desbloqueio de porta

O ambiente de autenticação do IEEE

802.1X inclui três componentes:

suplicante: o cliente que solicita

acesso à rede;

autenticador: um switch Ethernet

ou ponto de acesso por meio do

qual o suplicante pede acesso;

servidor de autenticação: servidor

na rede que mantém um banco

de dados de autenticação e

se comunica com o banco de

dados para aprovar ou rejeitar

a solicitação de acesso.

No caso de pontos de acesso sem

fio domésticos, o autenticador e o

servidor de autenticação geralmente

62 http://www.linuxmagazine.com.br


IEEE 802.1X | SEGURANÇA

se encontram no mesmo dispositivo.

Em uma LAN com fio, a situação é

um pouco mais complicada. Muitos

switches gerenciáveis oferecem

suporte a IEEE 802.1X. Um switch

bem configurado, portanto, é um

bom autenticador, recebendo solicitações

de acesso de clientes e

comunicando-se com o servidor de

back-end – normalmente utilizando

o popular protocolo de autenticação

RADIUS.

Antes que o switch (que no contexto

do RADIUS é chamado de Network

Access Server – NAS) permita

qualquer tipo de tráfego em uma de

suas portas, chamadas pelo padrão

de Port Access Entities (PAE), o dispositivo

solicitante – normalmente

um computador desktop ou laptop

– precisa passar por um processo

de autenticação. Essa autenticação

ocorre na camada de enlace

de dados e se baseia no Extensible

Authentication Protocol (EAP). O

dispositivo que faz a solicitação precisa

rodar um programa cliente (o

chamado suplicante, ou supplicant),

que apresenta suas credenciais na

forma de um quadro Ethernet especial

chamado EAPoL.

O EAP suporta várias credenciais,

mas os certificados de clientes

X.509v3 são o tipo mais comum.

Os certificados usam um padrão

criptográfico estrito e podem ser

gerenciados individualmente ou,

caso necessário, por meio de uma

infraestrutura de chave pública (PKI)

com a extensão de protocolo EAP-

TLS [2]. Outras opções incluem

One Time Passwords (OTP), Projected

EAP (PEAP) e TLS tunelado

(TTLS).

Quando um switch recebe uma

solicitação do tipo EAP-Response/

Identity, ele a encaminha a um

Servidor de Acesso Remoto (RAS,

na sigla em inglês) que atua como

servidor de autenticação. O sistema

RAS conhece todas as permissões e

informa o resultado da autenticação

Figura 1 O switch gerenciado Netgear FSM726 tem 24 portas que podem

ser configuradas individualmente para suportar operações

IEEE802.1X Auto.

ao switch. Se for positiva, o switch

abre o PAE e permite ao cliente

acessar a rede e desempenhar uma

ação – por exemplo, obter um IP

por DHCP.

Autenticação

Muitos switches gerenciados suportam

IEEE 802.1X. Por exemplo, um

Netgear FSM726, que custa cerca de

200 dólares nos EUA e tem 2 portas

gigabit, o 3Com 2924-SFP Plus, com

custo de mais ou menos 270 dólares

nos EUA, e o Level One GSW-2494,

de 340 dólares. Todos estes dispositivos

têm 24 portas e diferem entre

si em alguns recursos.

Quase todos esses switches incluem

uma interface web (figura 1)

e alguns usam interface de linha

Quadro 1: Cisco IOS

de comando para a configuração,

como o IOS da Cisco. O artigo 5.1

do padrão 802.1X define as exigências

para os switches. Alguns deles,

como os que utilizam o IOS, apresentam

mais recursos, tais como uma

VLAN para convidados que recebe

os suplicantes que não receberem

permissão de acesso (essa opção de

VLAN para convidados é útil para

visitantes e conferências).

Para disponibilizar um controle

de acesso a redes no switch, o administrador

precisa alternar as portas

(PAEs) do modo Authorized para o

modo Auto e dar ao dispositivo de

rede a senha e o IP do Servidor de

Acesso Remoto. É uma boa ideia

adicionar uma VLAN separada para

uma sub-rede administrativa isolada

No Cisco IOS, o comando dot1x system-auth-control ativa o 802.1X em

todo o switch (listagem 1). O comando radius-server host Radius IP adiciona

o servidor RADIUS e key define a chave do RADIUS. O comando aaa

authentication atribui o grupo radius. Os comandos dot1x pae authenticator

e dot1x port-control auto convertem a interface selecionada em interface

802.1X. A VLAN para convidados, que remete o cliente a uma rede

não crítica caso a autenticação falhe, é configurada com o comando dot1x

guest-vlan vlan-id. Para mais detalhes, confira o Guia de Configuração do

IOS [3] ou a wiki do FreeRADIUS [4].

Linux Magazine #61 | Dezembro de 2009

63


SEGURANÇA | IEEE 802.1X

e configurar a porta para Authorized

a fim de evitar problemas do tipo

“ovo e galinha”.

RADIUS e usuários

O switch utiliza o protocolo RA-

DIUS (definido na RFC 2865) para

conversar com o servidor RAS. A

comunicação é protegida por uma

chave compartilhada que pode ser

gerada pelo administrador com o

comando pwgen -s -1 e depois armazenada

no switch.

Listagem 1: Configuração do Cisco IOS.

Com este passo, o administrador

termina os preparativos para o dispositivo

de rede. Todas as outras configurações

do servidor são feitas no

servidor RAS. Esse servidor também

gerencia o certificado, a menos que

seja preferível mantê-los em uma

máquina separada por motivos de

segurança.

O FreeRADIUS [5] é uma boa

escolha como servidor de acesso

remoto. Bastam poucas modificações

nas configurações padrão em

01 Switch# configure terminal

02 Switch(config)# dot1x system‐auth‐control

03 Switch(config)# aaa new‐model

04 Switch(config)# aaa authentication dot1x default radius

05 Switch(config)# radius‐server host 192.168.123.23 auth‐port 1812

key hEoLw6DC

06 Switch(config)# interface fa1/10

07 Switch(config‐if)# switchport mode access

08 Switch(config‐if)# dot1x pae authenticator

09 Switch(config‐if)# dot1x port‐control auto

10 Switch(config‐if)# end

11 Switch# show dot1x interface fa1/10 details

Listagem 2: Trecho do arquivo ca.cnf.

01 [certificate_authority]

02 countryName = BR

03 stateOrProvinceName = SP

04 localityName = SaoPaulo

05 organizationName = UebelHacker

06 emailAddress = ca@uebelhacker.br

07 commonName = “UebelHacker CA”

Listagem 3: Trecho do arquivo server.cnf.

01 [server]

02 countryName = BR

03 stateOrProvinceName = SP

04 localityName = SaoPaulo

05 organizationName = UebelHacker

06 emailAddress = radius@uebelhacker.br

07 commonName = “UebelHacker Radius Server”

Listagem 4: Modificando o makefile do CA.

01 client.crt: client.csr ca.pem ca.key index.txt serial

02 openssl ca -batch -keyfile ca.key -cert ca.pem -in client.csr

-key $(CAPWD) -out client.crt -extensions xpclient_ext -extfile

xpextensions -config ./client.cnf

/etc/raddb/ (no openSUSE) ou em

/etc/freeradius/ (no Ubuntu) para

o administrador ativar o EAP-TLS.

As configurações básicas do FreeRA-

DIUS são estendidas com a inclusão

de vários arquivos personalizados. Por

exemplo, o software pode recuperar

uma lista de usuários de um banco

de dados ou de um serviço de diretório,

ou impor restrições de tempo

aos usuários.

As configurações gerais encontramse

no arquivo radius.conf. Como

o servidor só é necessário para a

autenticação, a seção listen com

type = auth é a configuração mais

relevante. Para impedir que o software

escute solicitações na porta

UDP 1812 em todas as interfaces, é

necessário configurar o endereço IP

na chave ipaddr. Além disso, pode

haver a necessidade de modificar

suas regras de firewall. Para melhor

acompanhamento das solicitações,

você pode adicionar uma entrada

auth = yes na seção log do arquivo

radius.conf.

O arquivo clients.conf especifica

o segmento administrativo entre o

switch e o servidor RAS. A entrada

secret contém o segredo compartilhado

por eles dois:

client 192.168.123.0/24 {

secret = hEoLw6DC

shortname = uebelhackers

}

Quando o arquivo radius.conf

se vincula ao eap.conf, a chave default_eap_type

é definida como tls.

A senha que ativa o certificado do

servidor, que ainda precisa ser criado,

é definida na mesma seção que

private_key_password.

Novos certificados

Algumas distribuições incluem um

makefile no diretório /etc/raddb/

certs. É possível usar esse makefile

junto com o OpenSSL para gerar

três tipos de certificados: um certi-

64 http://www.linuxmagazine.com.br


IEEE 802.1X | SEGURANÇA

ficado (primeiro) para um pequeno

CA, que mais tarde assinará os

certificados do servidor (segundo)

e do cliente (terceiro). No entanto,

se esse diretório estiver vazio, como

no caso do Ubuntu 9.04, obtenha

os arquivos do GitHub do Free-

RADIUS GitHub em raddb/certs

[6]. O pacote inclui um arquivo de

configuração para cada certificado

e um makefile compartilhado. Para

criar um novo certificado de CA, é

preciso modificar o arquivo ca.cnf.

Altere a seção [certificate_authority],

como mostra a listagem 2. Os valores

de input_password e output_password

precisam ser idênticos.

Para editar a seção [server] em

server.cnf, siga os mesmos passos,

mas escolha um commonName

diferente para distinguir os certificados

(listagem 3). Depois, insira a

private_key_password especificada

no arquivo eap.conf como senha.

Por fim, o comando make all criará

os certificados da CA e do servidor,

o arquivo Diffie-Hellman (dh) e o

arquivo random, ambos importantes

componentes no handshake

SSL/TLS.

Certificados

de usuários

No EAP-TLS, cada dispositivo precisa

de seu próprio certificado de cliente,

que pode ser criado no client.

cnf. O makefile do FreeRADIUS

por padrão assina essas credenciais

com o certificado do servidor. Para

o CA assiná-los, mude as linhas da

listagem 4 e muita atenção à tabulação

no início da linha 2. Depois,

é possível entregar os certificados

da CA diretamente aos suplicantes.

O commonName na seção [client]

especifica o nome do usuário para

permissões e outras configurações no

RADIUS. Mais uma vez, o certificado

é protegido por senha usando

aquela definida em input_password

e output_password.

[client]

countryName = BR

stateOrProvinceName = SP

localityName = SaoPaulo

organizationName = UebelHacker

emailAddress = s@uebelhacker.br

commonName = uebelacker

Diferentemente dos certificados da

CA e do servidor, será preciso criar

múltiplos certificados aqui – um para

cada usuário. Como o comando make

client gera apenas um certificado,

faz sentido gerar um script para essa

tarefa. Em seguida, é possível entregar

os certificados aos usuários de uma

forma segura, preferivelmente em

um pen drive ou smartcard.

Configuração

de usuários

A próxima informação de que o

RAS precisará são os detalhes dos

usuários autorizados. Para simplificar,

é possível fornecer a cada

Listagem 5: Banco de dados de usuários.

usuário um certificado de cliente

assinado pela CA. Se você não

mudar o arquivo de configuração

users no servidor RADIUS, ele dará

acesso a qualquer um que possua

um certificado válido. Com isso,

o switch atribuirá um suplicante

à VLAN especificada.

No entanto, se for preferível fornecer

mais detalhes sobre os usuários

ao servidor RAS, há várias opções

para isso: o mais rápido seria

adicionar os usuários autorizados e

os não autorizados ao arquivo users.

Veja a listagem 5 com um exemplo

desse método.

A linha 3 da listagem 5 define o

padrão para qualquer suplicante

que forneça um certificado válido

via EAP. Os detalhes de Tunnel-Type

e Tunnel-Medium são pedidos pelo padrão,

caso você deseje que o switch

atribua uma VLAN – por exemplo,

23 como o segmento do usuário. A

RFC 2869 define mais extensões

para o RADIUS, como a restrição do

01 dau Auth‐Type := Reject

02

03 DEFAULT Auth‐Type := EAP, Login‐Time := “Wk0800‐2000”

04 Tunnel‐Type = 13,

05 Tunnel‐Medium = 6,

06 Tunnel‐Private‐Group‐Id = 23,

07 Fall‐Through = Yes

08

09 uebelacker Auth‐Type := EAP, Login‐Time = “Any”

10 Tunnel‐Private‐Group‐Id = 42

Listagem 6: Arquivo xsupplicant.conf.

01 default_netname = intranet

02 intranet {

03 type = wired

04 allow_types = eap_tls

05 identity = uebelacker

06 eap_tls {

07 user_cert = “/caminho/para/s@uebelhacker.br.pem”

08 user_key = “/caminho/para/s@uebelhacker.br.pem”

09 user_key_pass = “Senha-Usercert”

10 root_cert = “/path/to/ca.pem”

11 chunk_size = 1398

12 random_file = /dev/urandom

13 }

14 }

Linux Magazine #61 | Dezembro de 2009

65


SEGURANÇA | IEEE 802.1X

Figura 2 O Network Manager conhece

o serviço EAP-TLS e oferece

uma interface gráfica de

configuração.

login a dias de semana entre 8:00 e

20:00 para evitar invasões noturnas.

A primeira linha bloqueia o usuário

dau, que acabou de sair da empresa,

mas ainda possui um certificado válido.

Como alternativa, seria possível

implementar essa lógica com as

Listagem 7: Arquivo wired.conf.

Listas de Revogação de Certificados

(CRLs, na sigla em inglês), porém esse

passo é um pouco mais complicado.

A primeira regra de combinação se

aplica a esse arquivo, a menos que

você tenha configurado o atributo

Fall-Through como mostrado na linha

7. Os outros atributos sobrescrevem

as configurações do administrador,

uebelacker, que não está sujeito a restrições

de tempo e segue direto para

o segmento administrativo.

O comando radiuss -X executa

o RAS em modo de depuração para

identificar alguma configuração

incorreta. Se o servidor iniciar sem

problemas, o RADIUS mostrará que

está respondendo às solicitações:

Listening on authentication

address 192.168.123.23 port 1812

Ready to process requests.

Faz sentido executar o daemon no

modo de depuração até a porta da

rede ser desbloqueada; assim, todas

as atividades serão extensamente

registradas na saída padrão.

01 eapol_version=2

02 ap_scan=0

03 fast_reauth=1

04 network={

05 key_mgmt=IEEE8021X

06 eap=TLS

07 identity=”uebelacker”

08 ca_cert=”/caminho/para/ca.pem”

09 client_cert=”/caminho/para/s@uebelhacker.br.pem”

10 private_key=”/caminho/para/s@uebelhacker.br.pem”

11 private_key_passwd=”Senha-Usercert”

12 eapol_flags=0

13 }

Listagem 8: DHCP no arquivo interfaces.

01 auto eth0

02 iface eth0 inet dhcp

03 wpa-iface eth0

04 wpa-driver wired

05 wpa-conf /etc/wpa_supplicant/wired.conf

Monitoramento

É possível monitorar as atividades

no modo de produção com tail -f

/var/log/radius/radius.log:

Info: Ready to process requests.

Auth: Login OK: [uebelacker]

(from client uebelhackers port 13

cli 00:19:e0:18:38:5c)

Esta saída indica que o dono do

certificado emitido para uebelacker

fez login na porta 13 do switch.

O Xsuplicant do projeto Open1X

da OpenSEA Alliance [7][8] e o

wpa_supplicant [9] suportam esse

tipo de login. No entanto, algumas

distribuições não incluem nenhum

desses dois suplicantes. No Ubuntu

9.04 e posteriores, assim como em

várias outras distribuições, o Network

Manager atua como interface gráfica

para o wpa_supplicant (figuras 2 e 3).

No cliente

O usuário precisa configurar um

perfil 802.1X em /etc/xsupplicant/

xsupplicant.conf (listagem 6), que

pode ser testado chamando o suplicante

da seguinte maneira:

xsupplicant -D wired -i eth0 \

-d 5 -f -c \

/etc/xsupplicant/xsupplicant.conf

Após a autenticação 802.1X e

a liberação da porta de rede, que

será indicada pelo anúncio Changing

from AUTHENTICATING

to AUTHENTICATED, o script

inicial atribui um IP estático ou

usa o DHCP normalmente. Caso o

Xsupplicant tenha sido iniciado em

segundo plano por meio do /etc/

init.d/xsupplicant start e sobreviva a

uma reinicialização graças a chkconfig

xsupplicant on, a autenticação

802.1X ocorrerá automaticamente.

Teste

O pacote wpa_supplicant fornece

meios de testar a configuração:

66 http://www.linuxmagazine.com.br


IEEE 802.1X | SEGURANÇA

wpa_supplicant \

-i eth0 -D wired

-c /etc/wpa_supplicant/wired.conf

Em seguida, é necessário criar o

arquivo de configuração wired.conf

como especificado na listagem 7.

Como a autenticação 802.1X é baseada

em redes com fio, é possível usar

a versão 2 do eapol_version e desabilitar

a busca de pontos de acesso.

O suplicante anuncia o evento

CTRL-EVENT-EAP-SUCCESS no caso de

uma autenticação bem sucedida.

Para executar o cliente permanentemente

em segundo plano e

autenticá-lo automaticamente no

caso de portas 802.1X, os usuários

precisam modificar o arquivo /etc/

network/interfaces, como mostrado

na listagem 8 para o Debian – supondo

que se use DHCP. Caso

contrário, deve-se mudar o item

dhcp para static e definir um endereço

IP estático. O comando /etc/

init.d/networking restart ativa essas

configurações. Se o cliente alcançar

o estado authorized em uma porta

sem IEEE 802.1X, a tentativa de login

será redundante, mas o cliente

funcionará normalmente.

Produção

O último passo para o administrador

é configurar o servidor RADIUS no

modo de produção: habilitar o script

init usando service freeradius start

e digitando chkconfig freeradius on

para fazer com que o servidor inicie

o FreeRADIUS toda vez que o sistema

iniciar.

Conclusão

Os componentes para autenticação

de dispositivos existem em muitos ambientes.

A combinação desses componentes

fica a cargo do administrador.

Para algumas pessoas, o Controle

de Acesso à Rede (NAC) ainda

inclui outros aspectos, tais como

validação técnica de status de versão

ou assinaturas de vírus atualizadas,

alinhadas à política de segurança.

O NAC oferece várias opções de

customização: além de LDAP ou

integração com bancos de dados

SQL, ambientes mais complexos

podem necessitar do emprego de

um PKI com o uso do Tiny CA [10],

por exemplo. Smartcards, como o

Aladdin E-Token, protegem os certificados

dos usuários.

O FreeRADIUS suporta IPv6 a

partir da versão 2; no entanto, alguns

switches 802.1X podem não seguir os

padrões. Se você estiver testando o

IKEv2, por exemplo, confira o arquivo

experimental.conf do projeto. Há um

Mais informações

[1] IEEE 802.1x-2004:

http://www.ieee802.org/1/pages/802.1x-2004.html

[2] RFC 5216, “EAP-TLS Authentication Protocol”:

http://tools.ietf.org/rfc/rfc5216.txt

Gostou do artigo

Queremos ouvir sua opinião. Fale conosco em

cartas@linuxmagazine.com.br

Este artigo no nosso site:

http://lnm.com.br/article/3163

projeto no SourceForge com nome

idêntico para pesquisar o IKE2 [11].

Graças ao projeto Hostapd [12], os

administradores podem esperar para

breve uma nova implementação do

EAP no FreeRADIUS, conhecida

por EAP2. n

[3] Guia Cisco 802.1x: http://www.cisco.com/en/US/docs/switches/

lan/catalyst4500/12.2/31sg/configuration/guide/dot1x.html

[4] FreeRADIUS Wiki com comandos Cisco IOS:

http://wiki.freeradius.org/Cisco

[5] Projeto FreeRADIUS: http://freeradius.org

[6] FreeRADIUS em GitHub:

http://github.com/Antti/freeradius-server/tree/master

[7] OpenSEA: http://openseaalliance.org

[8] Projeto Open1X: http://open1x.sf.net

[9] WPA supplicant: http://hostap.epitest.fi/wpa_supplicant/

[10] Tiny CA: http://tinyca.sm-zone.net

[11] Projeto EAP-IKEv2 em Sourceforge: http://eap-ikev2.sf.net

[12] Modos EAP suportados pelo FreeRADIUS:

http://freeradius.org/features/eap.html

Figura 3 Com a configuração

completa, o logon no

switch é transparente

para os usuários.

Linux Magazine #61 | Dezembro de 2009

67

More magazines by this user
Similar magazines