Controle de Acesso A Rede Com PacketFenc PDF

FACULDADE DE TECNOLOGIA SENAI DE DESENVOLVIMENTO
GERENCIAL - FATESG
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE
COMPUTADORES
André Luiz Ramos de Souza

Diego de Souza Lopes
Controle de Acesso à Rede

com
PacketFence
GOIÂNIA
2011

com
PacketFence
Trabalho de conclusão de curso apresen-

tado à Faculdade de Tecnologia SENAI
de Desenvolvimento Gerencial - FATESG,
para obtenção do título de Graduado em
Tecnologia em Redes de Computadores.
Orientador:
Prof. MSc. Maurício Severich
GOIÂNIA
2011
i


com
PacketFence
Trabalho de conclusão de curso apresentado à Faculdade de Tecnologia SENAI de

Desenvolvimento Gerencial - FATESG, para obtenção do título de Graduado em
Tecnologia em Redes de Computadores.
Aprovada em de de 2011.
Banca Examinadora
Prof. MSc. Maurício Severich

Orientador
Prof. MSc. Rafael Leal Martins

Faculdade de Tecnologia SENAI - FATESG
Prof. MSc. Diogo Nunes de Oliveira

Faculdade de Tecnologia SENAI - FATESG
ii
DEDICATÓRIA
Aos nossos pais, esposas, filhos e à

todos aqueles que nos deram apoio
sempre que necessário.
iii
AGRADECIMENTOS
Agradecemos a Deus em primeiro lugar, que nos deu a oportunidade de ini-

ciar este curso e forças para concluí-lo. Aos nossos pais, sem os quais não podería-
mos estar onde estamos hoje.
Aos professores Maurício Severich e Maurício Lopes pela confiança dada a
nós, orientação e paciência. Também ao Wagner Kuramoto e Fernando Tsukahara
por nos ajudar com recursos necessários para a realização desse trabalho.
A todos aqueles que contribuíram de forma direta e indireta na conclusão
deste trabalho.
iv
Epígrafe
"As pessoas que são loucas o

suficiente para achar que podem
mudar o mundo são aquelas que o
mudam."
Comercial Pense Diferente da Apple,

1997
v
Resumo
Este trabalho tem como escopo demonstrar através de implementação a utilização

do software PacketFence para controlar o acesso de novos dispositivos (Notebook,
Desktop) à infraestrutura de rede de computadores utilizando conexões Ethernet ca-
beadas. Para fazer esse controle o PacketFence faz uso de tecnologias open source,
entre elas, o Nessus, ferramenta utilizada para fazer varreduras de computadores a
procura de vulnerabilidade de softwares que comprometa a segurança dos dados que
estão armazenados no dispositivo, o FreeRadius aplicativo que faz autenticação e au-
torização de usuário e dispositivo para acesso a rede de computadores, banco de
dados MySQL, utilizado para armazenar dados, o Snort, aplicativo que detecta ten-
tativas de intrusão a rede, Servidor web Apache HTTPD para fornecer páginas web
e Captive portal. Também serão abordados os protocolos 802.1x, 802.1q, Simple
Network Manager Protocol (SNMP) e Dynamic Host Configuration Protocol (DHCP).
Nesse documento o leitor irá encontrar breve descrição das aplicações e protocolos
citados e também o detalhamento da instalação, configuração e funcionalidades do
PacketFence em redes cabeadas.
vi
Abstract
This work aims to demonstrate by means of the use of the software implementa-
tion PacketFence. It is used to control the access of new devices (notebooks, desk-
tops) to the network infrastructure of computers using wired Ethernet connections. To
make this control PacketFence uses open source technologies, including the Nessus
scanning tool. It is used to make searches about computer software vulnerability that
compromise the security of data that is stored on the device. It include FreeRadius
application that makes authentication and authorization and user access device to the
computer network, MySQL database used to store data, Snort application that detects
intrusion attempts to the network, Apache HTTPD web server to provide web pages
and Captive portal. It also will be discussed 802.1x protocol, 802.1q, Simple Network
Manager Protocol (SNMP) and Dynamic Host Configuration Protocol (DHCP). In this
document the reader will find brief description of applications and protocols mentioned
early as well the details of the installation, configuration and functionality of Packet-
Fence in wired networks.
vii
Sumário
Lista de Figuras xi
Lista de Siglas xiv
1 INTRODUÇÃO 1
1.1 OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 FERRAMENTAS, PADRÕES, PROTOCOLOS E TECNOLOGIAS 5
2.1 O QUE É NETWORK ACCESS CONTROL ? . . . . . . . . . . . . . . . . . 5
2.1.1 Tipos de NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 NAC: Primeira Geração . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 NAC: Segunda Geração . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.4 O que é Network Access Protection ? . . . . . . . . . . . . . . . . . . . 8
2.1.5 O que é Network Admission Control ? . . . . . . . . . . . . . . . . . . 8
2.2 DYNAMIC HOST CONFIGURATION PROTOCOL . . . . . . . . . . . . . . 9
2.2.1 DHCP Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1.1 Como Funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 CAPTIVE PORTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.1 Extensible Authentication Protocol . . . . . . . . . . . . . . . . . . . . 17
2.6 SIMPLE NETWORK MANAGEMENT PROTOCOL . . . . . . . . . . . . . . 19

Sumário viii
2.6.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.2 Gerente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.6.3 Agente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.4 MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.6.5 Versões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.7 NETFLOW / IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 IEEE 802.1Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.9 INTRUSION DETECTION SYSTEM . . . . . . . . . . . . . . . . . . . . . . 24
2.9.1 Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.10 NESSUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 INTRODUÇÃO AO PACKETFENCE 28
3.1 O QUE É PACKETFENCE ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1.2 Modos PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.3 Integração Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.4 Registro de Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.1.5 Detecção de Atividade Anormal . . . . . . . . . . . . . . . . . . . . . . 31
3.1.6 Remediação de Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1.7 Gerenciamento Baseado em Linha de Comando e Web . . . . . . . . 31
3.1.8 Gerenciamento Flexível de VLAN . . . . . . . . . . . . . . . . . . . . . 32
3.1.9 Tipos de Violação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.10 Registro Automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.11 Expiração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.12 Acesso a Visitantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 IMPLEMENTAÇÃO E CONFIGURAÇÃO 35
Sumário ix
4.1 CONFIGURAÇÃO DE HARDWARE . . . . . . . . . . . . . . . . . . . . . . 35
4.2 MODELO DE TOPOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 CONFIGURAÇÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 Interface de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.4 PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.4.1 pf.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.4.2 networks.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3.4.3 switches.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.5 Configuração do Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3.5.1 Modo Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3.5.2 Modo 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3.6 Autenticação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.6.1 Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.6.2 RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.7 Acesso à Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.8 Habilitando o Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.9 Habilitando o Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5 RESULTADOS OBTIDOS 62
5.1 Tradução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6 CONSIDERAÇÕES FINAIS 72
Referências 74
Apêndice A -- Instalando o PacketFence 77

Sumário x
A.1 Procedimentos para Instalação . . . . . . . . . . . . . . . . . . . . . . . . . 77
Anexo A -- Tradução da Documentação do PacketFence 86

xi
Lista de Figuras
FIGURA 1 – Etapas envolvidas em uma comunicação entre o cliente e o

servidor DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
FIGURA 2 – Pacote do tipo DHCP Discover . . . . . . . . . . . . . . . . . . 12
FIGURA 3 – Lista de parâmetros de um DHCP Discover . . . . . . . . . . . 12
FIGURA 4 – EAPOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
FIGURA 5 – EAPOL Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
FIGURA 6 – EAPOL Termination . . . . . . . . . . . . . . . . . . . . . . . . 16
FIGURA 7 – EAP Supplicant . . . . . . . . . . . . . . . . . . . . . . . . . . 18
FIGURA 8 – VLAN Tag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
FIGURA 9 – Diagrama PacketFence . . . . . . . . . . . . . . . . . . . . . . 29
FIGURA 10 – Topologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
FIGURA 11 – Tela dos termos de uso do PacketFence . . . . . . . . . . . . 40
FIGURA 12 – Tela de configuração dos parâmetros do banco de dados . . . 41
FIGURA 13 – Tela de confirmação das configurações do banco de dados . . 41
FIGURA 14 – Tela compilação dos idiomas do PacketFence . . . . . . . . . 42
FIGURA 15 – Tela geração do certificado auto-assinado do PacketFence . . 42
FIGURA 16 – Tela criação de usuário para acessar a administração do Pac-

ketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
FIGURA 17 – Tela pergunta para baixar as regras do snort . . . . . . . . . . 43
FIGURA 18 – Tela pergunta para baixar as assinaturas fingerprint . . . . . . 43
FIGURA 19 – Tela pergunta para baixar o arquivo OUI . . . . . . . . . . . . 44
FIGURA 20 – Tela de execução do script configurator.pl . . . . . . . . . . . . 45
FIGURA 21 – Tela de escolha dos modos de configuração do PacketFence . 45

Lista de Figuras xii
FIGURA 22 – Tela o nome do host do PacketFence . . . . . . . . . . . . . . 46
FIGURA 23 – Tela o nome de domínio do PacketFence . . . . . . . . . . . . 46
FIGURA 24 – Tela servidores DHCP a serem utilizados . . . . . . . . . . . . 46
FIGURA 25 – Tela configuração da porta WebGUI do PacketFence . . . . . 46
FIGURA 26 – Tela configuração de envio de notificação do PacketFence . . 47
FIGURA 27 – Tela ativação de envio de notificação do PacketFence . . . . . 47
FIGURA 28 – Tela monitoramento de serviços do PacketFence . . . . . . . . 47
FIGURA 29 – Tela registro do dispositivo no log do PacketFence . . . . . . . 47
FIGURA 30 – Tela configuração de alta disponibilidade do PacketFence . . . 48
FIGURA 31 – Tela configuração da interface do Snort do PacketFence . . . 48
FIGURA 32 – Tela configuração do Nessus . . . . . . . . . . . . . . . . . . . 48
FIGURA 33 – Tela configuração para ativar SSL do Nessus . . . . . . . . . . 49
FIGURA 34 – Tela para ativar o escaneamento do Nessus . . . . . . . . . . 49
FIGURA 35 – Tela configuração banco de dados do PacketFence . . . . . . 49
FIGURA 36 – Tela finalizando a configuração do PacketFence . . . . . . . . 50
FIGURA 37 – Log com trap indicando novo MAC que é colocado na VLAN
de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
FIGURA 38 – Log demonstrando o DHCP Fingerprint . . . . . . . . . . . . . 63
FIGURA 39 – Log demonstrando o redirecionamento para o Captive Portal . 63
FIGURA 40 – Log demonstrando o registro do dispositivo . . . . . . . . . . . 64
FIGURA 41 – Log demonstrando a alteração da VLAN de registro para a

VLAN normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
FIGURA 42 – Log demonstrando recebimento de trap . . . . . . . . . . . . . 65
FIGURA 43 – Log demonstrando a comunicação do DHCP . . . . . . . . . . 65
FIGURA 44 – Log demonstrando uma violação sendo adicionada . . . . . . 66
FIGURA 45 – Log demonstrando o redirecinamento para o Captive Portal . . 66

Lista de Figuras xiii
FIGURA 46 – Log demonstrando o envio do escaneamento para segundo

plano . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
FIGURA 47 – Log demonstrando o escaneamento . . . . . . . . . . . . . . . 67
FIGURA 48 – Log demonstrando o fechamento da violação . . . . . . . . . . 68
FIGURA 49 – Log demonstrando a alteração de VLAN após o escaneamento

no registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
FIGURA 50 – Autenticação Captive Portal . . . . . . . . . . . . . . . . . . . . 69
FIGURA 51 – Scan do Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . 69
FIGURA 52 – Quarentena Estabelecida . . . . . . . . . . . . . . . . . . . . . 70
FIGURA 53 – Tela do e-mail enviado ao membro do projeto . . . . . . . . . . 70
FIGURA 54 – Tela do e-mail de resposta do membro do projeto . . . . . . . 71
FIGURA 55 – Tela retorno ao e-mail de resposta do membro do projeto . . . 71

xiv
Lista de Siglas
AAA Authentication Authorization Accounting
AP Access Points
ATM Asynchronous Transfer Mode
BOOTP BOOTstrap Protocol
CentOS Community ENTerprise Operating System
CHAP Challenge Handshake Authentication Protocol
Cisco ACS Secure Access Control Server
Cisco NAC Cisco Network Admission Control
DHCP Dynamic Host Configuration Protocol
DNS Domain Name System
EAP Extensible Authentication Protocol
EAPOL Extensible Authentication Protocol over LAN
EAPOR Extensible Authentication Protocol over RADIUS
FQDN Fully Qualified Domain Name
GB Gigabyte
GPLv2 General Public License versão 2
GTC Generic Token Card
HD Hard Disk
HTTPD Hyper Text Transfer Protocol Daemons
IDS Intrusion Detection System

Lista de Siglas xv
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
INC Incorporation
IP Internet Protocol
IPFIX Internet Protocol Flow Information Export
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
MAC Media Access Control
MD5 Message-Digest Algorithm 5
MIB Management Information Base
MTU Maximum Transmission Unit
NAC Network Access Control
NAK Negative Acknowledgement
NAP Network Access Protection
NAS Network Authentication Server
NASL Nessus Attack Scripting Language
NIDS Network Intrusion Detection System
NMS Network Management Stations
OSI Open Systems Interconnection
OTP One-Time Password
P2P Peer-to-Peer
PAP Password Authentication Protocol
PDA Personal Digital Assistants
PEAP Protected Extensible Authentication Protocol

Lista de Siglas xvi
PPP Point-to-Point Protocol
QoS Quality of Service
RADIUS Remote Authentication Dial In User Service
RAM Random Access Memory
RFC Requests For Comments
RHEL Red Hat Enterprise Linux
SCTP Stream Control Transmission Protocol
SELinux Security-Enhanced Linux
SGBD Sistema de Gerenciamento de Banco de Dados
SLIP Serial Line Internet Protocol
SMI Structure of Management Information
SMS Short Message Service
SNMP Simple Network Manager Protocol
SQL Structured Query Language
SSL Secure Sockets Layer
TCG Trusted Computing Group
TCP/IP Transmission Control Protocol/Internet Protocol
TI Tecnologia da Informação
TLS Transport Layer Security
TTLS Tunneled Transport Layer Security
UDP User Datagram Protocol
UTP Unshielded Twisted Pair
VLAN Virtual LAN
VoIP Voz over Internet Protocol

Lista de Siglas xvii
VPN Virtual Private Network
WAN Wide Area Network

1
1 INTRODUÇÃO
O aumento do uso de tecnologias no ambiente corporativo contribui para a expan-

são das redes de computadores, isso gera a necessidade de disponibilizar comuni-
cação com todas as partes da empresa. Geralmente essas expansões são feitas de
duas formas, através de cabos ou sem fio. Este último utiliza-se de ponto de acesso
(Access Point), porém, se a organização não possui políticas e ferramentas de segu-
rança para auxiliar no controle, é extremamente difícil lidar com quem pode ou não
usar a rede.
Um aspecto pouco observado pelo departamento de tecnologia da informação (T.I)

dessas organizações tanto públicas quanto privadas, é a falta de controle de uso dos
pontos de rede, principalmente quando aqueles que não são utilizados e são mantidos
ativos, assim permitindo o acesso à infraestrutura. Desta forma, permitem o acesso
de pessoas com intenções consideradas inapropriadas ou prejudiciais - do ponto de
vista da política de segurança e de uso da rede corporativa - cujo objetivo poderia ser
explorar esses acessos para obter, por exemplo, dados sigilosos ou realizar ataques
aos servidores das organizações.
Para exemplificar, imagine um aluno com interesse em ter acesso ao banco de

dados para alterar suas notas ou zerar os débitos com a instituição na qual estuda,
e ao passear pelos corredores da administração ele percebe que há um ponto de
rede (tomadas do tipo RJ-45 fêmea) livre para uso na parede. Imediatamente o aluno
conecta um notebook para ver o que acontece, e se o ponto estiver ativado, ou seja,
ligado a equipamentos de acesso à rede, somado a isso um servidor que fornece as
configurações de acesso automaticamente ao notebook, isso dará a esse aluno total
liberdade para executar aplicativos maliciosos que, consequentemente, poderão obter
informações como usuário e senha do banco de dados. Com esses dados em mãos,
o indivíduo poderá fazer as alterações que pretender na base de dados.
A fim de reduzir tais falhas, que estão em contínuo crescimento e que demanda a
1 INTRODUÇÃO 2
cada dia maior controle de acesso à infraestrutura de rede sujeita a novas ameaças e
vulnerabilidades, surgiu uma ferramenta de software livre, o PacketFence.
O PacketFence é classificado como Network Access Control (NAC). Essa cate-

goria de ferramentas tem como objetivo principal bloquear a conexão de dispositivos
e usuários desconhecidos ou sem permissão para acessar a rede de computadores
tanto cabeada quanto sem cabo (wireless), e pode ser utilizada em qualquer organi-
zação que queira implantar esses controles.
Para fazer esses bloqueios, o PacketFence utiliza um conjunto de tecnologias, tais

como: verificação de vulnerabilidade e detecção de atividade anormal na rede, ou
seja, verifica se no dispositivo há algum tipo de aplicação que comprometa a rede, por
exemplo: vírus, worms, entre outros tipos de pragas virtuais. Também são utilizadas
ferramentas e protocolos que fazem a autenticação de usuários. Esse conjunto de
tecnologias é configurado de acordo com as políticas de segurança estabelecidas pela
organização e definidas de acordo com as necessidades da organização.
O bloqueio leva em consideração a análise dos programas instalados - o hard-

ware e o usuário. Se algum desses pontos analisados estiver fora da política de segu-
rança, o acesso à rede principal da organização será bloqueado e desviado para outra
rede, na qual será possível corrigir os devidos problemas, por exemplo, atualização de
software. Somente após a correção do problema, o dispositivo terá permissão para
acessar a rede principal, ou seja, os recursos de uma forma geral.
É verificado se o dispositivo já está cadastrado, caso não esteja o mesmo será

redirecionado para uma área diferente, para que seja possível realizar o cadastro,
bem como sendo possível de se realizar uma verificação deste dispositivo, antes de
liberar o registro do mesmo.
O usuário também será verificado nesse inicio de comunicação, se ele não for
cadastrado, será necessário realizar esse cadastro para ingressar na rede e utilizar
os recursos como acesso à Internet e programas corporativos, consulta em banco de
dados, entre outros de acordo com as políticas estabelecidas.
Para reforçar; para se obter o acesso à rede principal é necessário que usuário
e dispositivos estejam de acordo com as políticas de segurança, se uma das partes
falhar o acesso será negado.
1.1 OBJETIVOS 3
1.1 OBJETIVOS
Este trabalho demonstrará como preencher a falha de segurança que os pontos

de redes sem utilização apresentam. Devido ao uso de um serviço de configuração
automática dos dispositivos na corporação, o atacante pode facilmente obter as con-
figurações referentes à infraestrutura da corporação, tais como: endereço Internet
Protocol (IP); máscara de rede; gateway e Domain Name System (DNS), deixando
facilmente acessível à infraestrutura de rede com a obtenção destas informações, o
que possibilita ataques originado de dispositivos não autorizados na rede.
Será realizado uma demonstração por meio de uma implementação do Packet-

Fence em ambiente isolado de interferências externas, pois se a implementação for
realizada em rede com várias máquinas, essas outras podem ser prejudicas com o
andamento da implementação.
É também parte do escopo deste trabalho apresentar uma tradução, dentro dos
limites permissivos, para a língua portuguesa da documentação dos manuais do soft-
ware PacketFence.
1.2 METODOLOGIA
A fim de atingir os objetivos propostos, foi realizada uma pesquisa exploratória em

material escrito, como, por exemplo, artigo publicado pelos próprios desenvolvedores
do sistema para coleta e seleção de conteúdo pertinente ao escopo deste trabalho.
Para a realização e desenvolvimento da parte prática, pode-se apontar a seguintes

ações:
- Configuração do servidor que faz as autenticações dos computadores e outros

ativos de redes para utilizar a rede, sendo que esse servidor é o ponto central
da rede, todas as conexões passam por esse equipamento. Foram habilitadas
as funcionalidades do software PacketFence de detecção de atividade anormal e
verificação de vulnerabilidade (IDS Snort, Nessus) e RADIUS para autenticação;
- O servidor trabalha juntamente com o switch para realizar o controle dos novos
dispositivos que serão conectados à rede;
1.2 METODOLOGIA 4
- Tais configurações foram realizadas com base na documentação original da fer-

ramenta PacketFence, que é um dos principais documentos de pesquisa.
5
2 FERRAMENTAS, PADRÕES, PROTOCOLOS E

TECNOLOGIAS
2.1 O QUE É NETWORK ACCESS CONTROL ?
Network Access Control (NAC) é uma abordagem unificada de tecnologias a fim

de prover ações de segurança em uma rede de computadores, tais como: antivírus,
detecção de intrusão e avaliação de vulnerabilidades, entre outras.
O conceito NAC é antigo, ou seja, surgiu desde os primórdios da telecomunicação.

O conceito foi idealizado através da patente de [Harris, Jackson e Petty 1987].
Inicialmente, o padrão definido pelo Institute of Electrical and Electronics Engineers

(IEEE) 802.1X também foi pensado como um NAC.
Existia uma disputa que gerava a falta de padronização quanto às soluções NAC,
pois cada fornecedor/empresa implementava recursos e desenvolvia suas próprias
soluções agregadas as suas próprias ferramentas, não estendendo para outros fa-
bricantes, pois não existia um padrão a ser seguido como modelo, a fim de garantir
compatibilidade entre soluções distintas.
Com o pensamento de acabar com a disputa das soluções NAC, o Internet En-
gineering Task Force (IETF) aprovou 2 padrões propostos pelo Trusted Computing
Group (TCG), a partir de então considerados como dois padrões NAC a serem im-
plementados pela indústria. Tais padrões estão definidos nas Requests For Com-
ments (RFC) de números 5792 [Sangster e Narayan 2010] e 5793 [Sahita et al. 2010].
NAC pode ser definido como um conjunto de tecnologias de redes de computado-

res cujo objetivo é fornecer segurança e controle de acesso à rede, permitindo ou não
o acesso de dispositivos. Esses dispositivos deverão estar em conformidade com as
políticas de segurança e de controle definidas pela organização, como, por exemplo,
para antivírus com um nível de proteção, para configuração e para a atualização do
sistema.
2.1 O QUE É NETWORK ACCESS CONTROL ? 6
De acordo com [INTEROP LABS 2006] NAC é definida como sendo um controle
genérico de acesso à rede que autentica e autoriza o tráfego. Tal controle de acesso
simplesmente poderia ser implementado com o uso de políticas de acesso ou defi-
nindo regras no firewall1 .
Como o NAC é um sistema de controle diferente, ele possui ferramentas disponí-

veis para fornecer o controle de acesso focado no usuário, ao contrário do firewall, cujo
controle é definido por regras aplicadas sobre o cabeçalho e/ou dados de um pacote.
Através do NAC é possível verificar a saúde dos dispositivos, ou seja, verificar se

possuem vírus ou outras pragas virtuais, tais como spyware e malware. Um benefício
importante ao se utilizar um NAC é a redução e a prevenção de ataques zero-day e
outros similares [Edwards 2008].
Ataques zero-day são ataques que tentam explorar as vulnerabilidades de aplica-

tivos que são desconhecidos pelos próprios desenvolvedores, ou seja, pelo próprio
criador do aplicativo.
Ataques zero-day podem destruir ou devastar uma rede, pois este é um ataque
que explora uma falha desconhecida ao qual não existe um patch para a correção do
problema. Ao explorar uma falha desta magnitude, os atacantes podem entrar em uma
rede para execução de código ou obter o controle total do computador da vítima.
2.1.1 Tipos de NAC
Segundo [Edwards 2008], pode-se apontar os seguintes tipos de NAC:
• Agent-based: Este tipo de NAC conta com um software que requer ser instalado
nos dispositivos dos usuários. Esta é uma abordagem simples, porém inflexível
requerendo software especial a ser instalado;
• Agentless: Este tipo de NAC não requer a instalação de agentes nos dispositi-
vos dos usuários.
• Inline: Neste tipo de NAC, todo o tráfego do cliente passa pela ferramenta NAC.
Esta abordagem pode gerar gargalos de throughput em redes maiores, além
1
Firewall é um dispositivo de rede que tem por objetivo aplicar políticas de segurança, verificando
informações da camada de enlace (camada 2 do modelo Open Systems Interconnection (OSI) e da
camada de rede (camada 3 do modelo OSI). Aplicando políticas de filtragem de pacotes Transmission
Control Protocol/Internet Protocol (TCP/IP) e portas.
de aumentar os custos já que mais dispositivos podem ser agregados, também

se agrega a função de firewall na qual se aplica as políticas de segurança na
camada de rede.
• Out-of-Band: Neste tipo de NAC é possível controlar uma infraestrutura em

escala geográfica, ou seja, em espaços físicos diferentes, desde que utilize a
tecnologia certa, como a porta de segurança e que haja comunicação entre as
redes.
2.1.2 NAC: Primeira Geração
As organizações estão a cada dia querendo controlar o acesso à rede com o uso
de tecnologias que melhor atenda e proteja as redes e dados delas.
A primeira versão NAC trouxe um modelo defeituoso, pois não atendeu aos di-
ferentes grupos que compõem as infraestruturas tecnológicas em uma organização,
pois crescia a demanda por proteger os dispositivos móveis2 , por grandes quantidades
de dispositivos, levando à falta de agilidade em termos de segurança.
As ameaças e vulnerabilidades cresciam constantemente e o modelo NAC 1.0

(primeira geração) não conseguiu se adaptar as regras de negócio, pois, com o sur-
gimento de novas ferramentas antivírus e anti-malwares, no geral, não foi possível
agregar melhores gerenciamentos do NAC com estas. Desta forma, tornou-se uma
ameaça e riscos aos dispositivos gerenciados. Devido aos riscos, poderia ocasionar
em perdas de dados devastadores nos dispositivos gerenciados.
De acordo com [Manlio 2009], a geração NAC 1.0 falhou devido ao foco em blo-
queio de clientes e a falta de agilidade, pois as ocorrências de ameaças novas e
constantes, além das vulnerabilidades que surgiam se somavam a um problema muito
maior em termos de segurança de uma organização.
Desta forma, os fornecedores (fabricantes) de softwares lançavam constantemente

atualizações para detectar e limpar as ameaças. Como resultado desta situação, te-
mos um problema de segurança, cujo modelo NAC de primeira geração não conseguiu
acompanhar.
2
São computadores de bolso. Os dispositivos móveis mais comuns são: Smartphone, Personal
Digital Assistants (PDA), Celular, Palmtop, Laptop (Notebook).
2.1.3 NAC: Segunda Geração
A segunda geração NAC ou NAC 2.0 surgiu devido à necessidade de uma abor-
dagem para o ambiente de novas ameaças e vulnerabilidades, já que este mudava
constantemente - surgimento de novas pragas virtuais. Desta forma, tornava-se ne-
cessário criar soluções com a capacidade de abranger as necessidades de segurança.
2.1.4 O que é Network Access Protection ?
Network Access Protection (NAP) é uma tecnologia da Microsoft

R
de controle de
acesso à rede introduzida pela primeira vez no Windows Server 2008. Através desta
tecnologia é possível reforçar a segurança na rede do usuário, criando diretivas per-
sonalizadas para verificar o computador antes de permitir o acesso, a fim de garantir
melhor conformidade, associando aqueles dispositivos que não estão em conformi-
dade a uma rede restrita.
A infraestrutura composta por um NAP inclui computadores com NAP client, pon-
tos de aplicação NAP, servidores de políticas NAP. Componentes opcionais podem
ser utilizados, por exemplo, servidores para remediação e servidores para verificar o
estado de saúde dos computadores, ou seja, se os computadores estão em perfeito
estado de saúde, longe de vírus, falhas de segurança e vulnerabilidades.
2.1.5 O que é Network Admission Control ?
Network Admission Control ou simplesmente NAC é a versão da Cisco referente

a Network Access Control. Cisco Network Admission Control trabalha restringindo
o acesso à rede e no estado de segurança, ou seja, é verificado a autenticação do
usuário ou do dispositivo antes do mesmo obter acesso à rede.
Cisco Network Admission Control (Cisco NAC) permite aos roteadores Cisco impor
privilégios de acesso quando determinado dispositivo tenta se conectar a uma rede,
ou seja, é verificado se o dispositivo está em conformidade, antivírus, definições de
vírus e mecanismos de verificação atualizados. Os dispositivos que estiverem fora de
conformidade são negados de acessarem os recursos da rede, sendo colocados em
uma área de quarentena, ou seja, ter acesso restrito aos recursos da rede, mantendo
os outros nós (dispositivos da rede) livres de infecção.
2.2 DYNAMIC HOST CONFIGURATION PROTOCOL 9
O principal componente do Cisco NAC é o Cisco Trusted Agent. Este reside nos
dispositivos, coletando informações referentes ao estado de segurança e enviando as
informações para os roteadores Cisco. Posteriormente, as informações são enviadas
para o Cisco Secure Access Control Server (Cisco ACS). Neste decide-se o que deve
ser feito em relação a determinado dispositivo, orientando o roteador Cisco a restringir
o acesso deste dispositivo.
2.2 DYNAMIC HOST CONFIGURATION PROTOCOL
Dynamic Host Configuration Protocol (DHCP) é um protocolo Dinâmico de Con-

figuração de Host [Droms 1997], ou seja, é um protocolo baseado no modelo cli-
ente/servidor que possibilita aos computadores em uma rede obterem configurações
Transmission Control Protocol/Internet Protocol (TCP/IP), tais como: endereço IP,
DNS, gateway, máscara de rede, entre outros de forma automática.
O protocolo DHCP é uma evolução do antigo protocolo BOOTstrap Protocol (BO-

OTP), este bastante utilizado em sistemas Unix. O BOOTP permitia a configuração
automática de dispositivos em uma rede, como impressoras e máquinas clientes.
No início da década de 90, a Internet Engineering Task Force (IETF) trabalhou

para desenvolver um protocolo que superasse as limitações do BOOTP com adições
de novos recursos, surgindo assim o DHCP. O protocolo DHCP está definido na RFC
2131 [Droms 1997].
O DHCP permite o envio de vários parâmetros por meio de um campo existente

no cabeçalho do protocolo, de nome "option". Entretanto, é possível além de enviar as
configurações, receber determinadas informações referente ao cliente, por exemplo,
sistema operacional e outros.
Para se obter as informações do cliente como, por exemplo: o sistema operacional,

é necessário que se ative o uso da "option code 61", as opções são definidas na RFC
2132 [Alexander e Droms 1997]. Atráves do uso deste parâmetro, é possível receber
a informação do cliente referente a qual sistema operacional o mesmo está utilizando,
essa técnica é conhecida como DHCP Fingerprint, sendo explanado a seguir.
2.2.1 DHCP Fingerprint
DHCP Fingerprint é um identificador quase único para um determinado sistema

operacional específico ou dispositivo [FingerBank 2011]. Através desse identificador é
possível saber o sistema operacional do cliente.
Esse identificador é a ordem em que o cliente solicita as opções referente às con-

figurações, como gateway, máscara de rede, DNS, entre outras. Atráves dessa ordem
de opções, é possível reconhecer o sistema operacional do cliente, pois cada sistema
operacional possui um identificador único.
Devido à difusão do protocolo DHCP, essa é a maneira mais simples de se obter

informação referente ao cliente. Como definido na RFC 2132, obter a identificação do
cliente é possível com o uso da opção "Option Code 61 - Client Identification".
Atualmente, existe um projeto [FingerBank 2011] que disponibiliza esses identifi-

cadores capturados pelo projeto. Estes identificadores estão disponíveis atráves de
um arquivo contendo vários identificadores, chamados de assinaturas fingerbank.
A maioria das ferrramentas de análise de rede, como sniffers de rede, analisadores

de protocolo, e soluções NAC fazem uso destas assinaturas.
2.2.1.1 Como Funciona
O protocolo DHCP possui alguns tipos de mensagem utilizadas para a realiza-

ção dos procedimentos de comunicação entre o cliente e o servidor para obtenção
das informações. Estas mensagens possuem um tipo específico na comunicação
entre o cliente e o servidor DHCP, os tipos de mensagem são: DHCPDISCOVER,
DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPNAK, DHCPDECLINE, DHCPRE-
LEASE e DHCPINFORM. Alguns dos tipos de mensagem não serão abordados no
teor de nosso trabalho.
O cliente envia uma mensagem em difusão, ou seja, em broadcast na rede, con-

tendo uma mensagem do tipo DHCPDISCOVER. O servidor ao receber essa men-
sagem, retorna com uma mensagem do tipo DHCPOFFER , ou seja, ofertando as
informações necessárias para a configuração do cliente, estas embutidas na mensa-
gem. Posteriormente, o cliente envia uma mensagem do tipo DHCPREQUEST, a fim
de iniciar a negociação, a partir de então, o cliente aguarda pela confirmação. Esta
confirmação é enviada pelo servidor contendo a mensagem do tipo DHCPACK, esta
para confirmar o recebimento, a partir deste momento, o cliente passa a ter endereço
IP e todas as configurações referentes à solicitação. Desta forma, finalizam-se as
etapas para a obtenção dos parâmetros de configuração, inicialmente solicitados pelo
cliente.
Conforme demonstrado na Figura 1:
F IGURA 1 Etapas envolvidas em uma comunicação entre o cliente e o servidor DHCP

Fonte: Autoria própria
A partir do momento que o cliente envia uma mensagem do tipo DHCPDISCOVER,

é possível obter algumas informações do cliente, tais como: Host Name; Vendor Class
(classe referente ao sistema operacional); Fully Qualified Domain Name (FQDN); Cli-
ent Identification; e outros. Através deste tipo de mensagem, o cliente solicita uma lista
de parâmetros de configurações, na qual existe uma ordem do pedido dos parâmetros,
a partir dessa ordem de parâmetros é possível saber qual o sistema operacional do
cliente. Essa técnica é conhecida como DHCP Fingerprint.
Na Figura 2, é apresentado uma mensagem do tipo DHCPDISCOVER na qual o

cliente envia e solicita informações, sendo que, através da opção "Option 12 - Host
Name", é possível saber o nome do host. Existe uma opção "Option 55 - Parameter
Request List" que é utilizada para solicitar os parâmetros de configuração, ou seja, a
lista dos parâmetros.
Com a lista dos parâmetros é identificada a assinatura do sistema operacional.

Essa identificação é realizada através da ordem dos parâmetros na lista, e através
desta é possível reconhecer qual sistema operacional o cliente está utilizando, por
exemplo: Microsoft Windows 7, Linux Ubuntu, entre outros, como mostra a Figura 3.
2.3 CAPTIVE PORTAL 12
F IGURA 2 Pacote do tipo DHCP Discover

F IGURA 3 Lista de parâmetros de um DHCP Discover

A Figura 3, representa os parâmetros capturados de um pedido de DHCPDIS-

COVER; a lista de parâmetros representa a identificação da assinatura do sistema
operacional Linux Ubuntu 10.10.
2.3 CAPTIVE PORTAL
Captive portal é o nome de um software responsável por gerenciar o acesso à

Internet em redes públicas, por exemplo, em locais como restaurantes, aeroportos,
provedores de Internet sem-fio, entre outros. Captive portal consiste de um aplicativo
de firewall que captura os pacotes do cliente e redireciona o tráfego para uma página
Web que solicita uma autenticação. Atráves do uso do Captive portal é permitido
limitar ou restringir o acesso à rede.
Quando um usuário tenta acessar qualquer página da Web com o uso de um na-
2.4 RADIUS 13
vegador, ele é automaticamente redirecionado para o Captive portal, pedindo uma

autenticação. Após fornecer as credênciais como usuário, senha ou certificado digital,
o Captive portal comunica com o servidor de autenticação enviando as credenciais
digitadas pelo usuário. Caso as credênciais sejam validadas pelo servidor de auten-
ticação, o mesmo retorna para o Captive portal a mensagem como sendo válidas as
credênciais, autorizando o acesso à rede pelo Captive portal.
Um Captive portal consiste de um roteador, ou seja, sendo o gateway padrão

da rede ou subrede que está a proteger. Captive portal é comumente utilizado para
proteger redes sem-fio, sendo também possível ser utilizado para prover a segurança
da rede cabeada.
A patente de [Zampiello et al. 2007], implementa um sistema e método escalável

de Captive Portal.
2.4 RADIUS
Remote Authentication Dial In User Service (RADIUS) é um protocolo Authentica-

tion Authorization Accounting (AAA), ou seja, é um protocolo que trata os procedimen-
tos de autenticação, autorização e auditoria (registro, contabilização, gerenciamento e
etc.) [UFRJ 2011]. A autenticação verifica a identidade de um usuário, enquanto que
a autorização garante que um usuário autenticado somente terá acesso aos recursos
autorizados, e a auditoria coleta as informações referentes ao uso dos recursos de
rede pelo usuário, por exemplo, gerenciamento, planejamento e cobrança.
RADIUS é baseado no modelo cliente/servidor, é definido na RFC 2865 [Rigney et

al. 2000] . Além de ser um sistema utilizado para prover autenticação centralizada, ele
é utilizado em redes dial-up, Virtual Private Network (VPN) e redes sem-fio. Existem
soluções RADIUS proprietárias, ou seja, soluções pagas, a exemplo do DIAMETER.
Também existem soluções gratuitas, como o FreeRADIUS.
O FreeRADIUS é um software desenvolvido sob a licença General Public License

versão 2 (GPLv2). Ele está em constante desenvolvimento e atualização, ao qual são
acrescentadas melhorias à medida que surge a necessidade.
Em uma rede de computadores, que utiliza RADIUS, existem funções especifica-

mente distintas de equipamentos, por exemplo, Cliente, Network Authentication Ser-
ver (NAS) e Servidor RADIUS, sendo que:
2.5 IEEE 802.1X 14
• Cliente - é um host que tenta utilizar um recurso da rede;
• NAS - é um host que recebe uma solicitação de autenticação de um cliente e

autentica esse pedido no Servidor RADIUS.
• Servidor RADIUS - é o host que validará o pedido NAS. A resposta referente ao

pedido poderá ser positiva ou negativa.
Os dados que são transmitidos entre o cliente (usuário) e o servidor RADIUS são
autenticados através do uso da shared secret (segredo compartilhado). Este nunca
é enviado pela rede, desta forma se faz necessário o conhecimento prévio do shared
secret tanto entre o NAS quanto no servidor RADIUS, para que seja possível haver a
autenticação entre eles.
As senhas do usuário são criptografadas, garantindo que nenhum usuário malici-

oso que esteja a escutar a rede, ou seja "sniffer", possa descobrir a senha do usuário.
RADIUS é um protocolo flexível, pois suporta vários métodos de autenticação do

usuário, tais como: Password Authentication Protocol (PAP); Challenge Handshake
Authentication Protocol (CHAP); login Unix; e outros mecanismos de autenticação.
RADIUS é extensível, pois permite adicionar novos atributos de tamanho variáveis

sem que haja a possibilidade de dificultar a implementação do protocolo, estendendo
aos novos mecanismos de autenticação.
2.5 IEEE 802.1X
O protocolo Institute of Electrical and Electronics Engineers (IEEE) 802.1X foi pro-
posto pelo IEEE 802 LAN/WAN, e é utilizado em redes Ethernet como um mecanismo
de controle de porta de acesso [H3C Technologies 2011].
Quando é conectado um dispositivo a um ativo de rede por exemplo, um switch,

e se esse switch estiver com 802.1x habilitado em sua porta física, o acesso dos
recursos da rede só poderá ser feito após a autenticação. Deste modo é possível
controlar quem pode acessar a rede cabeada.
De acordo com [H3C Technologies 2011], o funcionamento do protocolo é a arqui-

tetura cliente/servidor típica, nesse caso são definidas três entidades: Cliente, Dispo-
sitivo e o Servidor, como demonstrado na Figura 4, a seguir:
2.5 IEEE 802.1X 15
F IGURA 4 EAPOL
Fonte: http://www.h3c.com
Cliente é uma entidade que busca acesso à LAN, comumente é o dispositivo de

usuário final tal como um Notebook. A autenticação 802.1X é acionada quando o
cliente executa um aplicativo, também chamado suplicante, capaz de fazer tal auten-
ticação. Esse aplicativo deve suportar Extensible Authentication Protocol over LAN
(EAPOL).
O dispositivo geralmente é um equipamento de rede com suporte ao protocolo

802.1X e fornece portas de acesso físicas (redes cabeadas) e lógicas (redes sem fio
– wireless) para clientes que pretendem acessar a LAN, um exemplo de dispositivo e
o switch.
A última entidade, o servidor, fornece serviços de autenticação para os disposi-

tivos. Esse equipamento normalmente executa Remote Authentication Dial In User
Service (RADIUS). Esse serviço prove autenticação, autorização e contabilidade de
serviços para os usuários.
Esse sistema utiliza o Extensible Authentication Protocol (EAP) para trocar infor-
mações de autenticação entre o cliente e dispositivo e servidor de autenticação. Entre
o cliente e o dispositivo, os pacotes EAP são encapsulados utilizando o EAPOL (EAP
sobre LAN) para serem transferidos na rede.
Entre o dispositivo e o servidor RADIUS, os pacotes EAP podem ser trocados de

dois modos: EAP relay e EAP termination. No modo relay, os pacotes são encap-
sulados em EAP sobre RADIUS (EAPOR) no dispositivo, e então transmitidos pelo
dispositivo para o servidor RADIUS, conforme a Figura 5. Já no modo termination, os
pacotes são terminados no dispositivo, e convertidos em pacotes RADIUS que com o
Password Authentication Protocol (PAP) ou Challenge Handshake Authentication Pro-
tocol (CHAP) atribuido, são depois transferidos para o servidor RADIUS, conforme a
Figura 6.
2.5 IEEE 802.1X 16
F IGURA 5 EAPOL Relay

F IGURA 6 EAPOL Termination

2.5 IEEE 802.1X 17
Os conceitos básicos envolvidos no 802.1X são: porta controlada/porta não con-

trolada; estado autorizada/não autorizada; e direção de controle.
Porta controlada e não controlada é quando um dispositivo fornece porta para os

clientes acessarem a rede, cada porta física pode ser considerada como duas portas
lógicas, que seria uma porta controlada e uma porta não controlada. Todos os dados
que chegam à porta física são visíveis para ambas as portas lógicas.
Uma porta no modo não controlada está aberta em ambas as direções de entrada
e saída, isso permite a passagem de pacotes do protocolo EAPOL. Desse modo, o
cliente pode enviar e receber pacotes de autenticação.
Quando a porta está no modo aberta controlada, ela permite o tráfego de dados
somente quando ela está no estado autorizado, ou seja, após autenticação.
Estado autorizado e não autorizado é a porta controlada que pode estar em qual-
quer estado, autorizado ou não autorizado. O estado depende do resultado da auten-
ticação, com sucesso a porta fica no estado autorizado, senão, ela ficará no estado
não autorizado.
De acordo com [H3C Technologies 2011], o estado de autorização da porta pode

ser controlado de três formas: forçar autorização - permite o acesso de clientes não
autenticados -; Forçar a não autorizada - a porta fica no estado não autorizada e ne-
gando todos os pedidos de acesso dos clientes -; e, por último, o modo auto - nesse
modo a porta fica inicialmente no estado autorizada para permitir apenas pacotes EA-
POL para permitir a autenticação de clientes, após a autenticação, o estado da porta
passa o estado autorizada. Está escolha é mais comum, pois permite que qualquer
cliente utilize a porta para autenticação.
Controle de direção indica o estado da porta controlada e não autorizada que pode
ser configurada para negar o tráfego de e para o cliente ou apenas o tráfego do cliente.
2.5.1 Extensible Authentication Protocol
O Extensible Authentication Protocol (EAP) é um conjunto de padrões definidos

pelo IETF e descrito na RFC3478 [Leelanivas, Rekhter e Aggarwal 2003] e revisado
na RFC5247 [Aboba, Simon e Eronen 2008].
Esse protocolo é comumente utilizado em redes sem fio (WiFi) mas também pode
ser utilizado para autenticar clientes em redes cabeada. Ele padroniza a troca de men-
2.5 IEEE 802.1X 18
sagens para que o servidor autentique o cliente utilizando métodos de autenticação

suportado por ambas as partes.
No EAP são definidos quatro tipos de pacotes: request, response, success e fai-
lure [JANET 2011]. Ao conectar um dispositivo em uma porta com o 802.1x habilitado,
acontece o procedimento descrito na Figura 7.
F IGURA 7 EAP Supplicant

Fonte: http://www.ja.net
São especificados três tipos de autenticação: EAP (MD5-Challenge, Generic To-

ken Card (GTC) e One-Time Password (OTP) ) e três de não autenticação (Identity,
Negative Acknowledgement (NAK) e Notification). O tipo Identity é utilizado pelo au-
tenticador para solicitar ao suplicante o nome de usuário. O NAK é utilizado pelo par
(suplicante) para indicar que o protocolo proposto pelo autenticador não é suportado,
o autenticador pode tentar outro protocolo que seja suportado pelo suplicante. O tipo
Notification é usado para retornar mensagem que será apresentada ao usuário.
De acordo com [JANET 2011], o EAP faz uso do pass-through, ou seja, permite
que o autenticador repasse as respostas, usando o protocolo RADIUS para o servidor
EAP. A partir desse momento, o servidor assume o papel de autenticador para o res-
tante da sessão EAP, e tenta fazer a autenticação do suplicante, no caso da Figura 7,
é utilizando um banco de dados centralizado para autenticação.
Além dos três tipos de autenticação citados, também pode ser usado o Transport
Layer Security (TLS) , Tunneled Transport Layer Security (TTLS) e o Protected Ex-
tensible Authentication Protocol (PEAP). O EAP-TLS é baseado no TLS e usa um
certificado de usuário para autenticar o suplicante. O EAP-TTLS também utiliza o
TLS, mas diferente do primeiro o EAP-TLS não utiliza um certificado de usuário para
fazer a autenticação. O PEAP também utiliza TLS mas difere dos demais, pois só
pode proteger outros tipos de EAP.
2.6 SIMPLE NETWORK MANAGEMENT PROTOCOL 19
2.6 SIMPLE NETWORK MANAGEMENT PROTOCOL
Com o crescimento das redes de computadores, de pequenas redes domésticas

para grandes redes espalhadas geograficamente e somado a isso vários equipamen-
tos de fabricantes diferentes, a gerência dessas infraestruturas fica cada vez mais
complexa. O protocolo Simple Network Manager Protocol (SNMP) traz para os admi-
nistradores de redes a minimização dessas complexidades.
O SNMP começou a ser desenvolvido no início da década de 80 pelo IETF com

o objetivo de simplificar a gerência de redes. Com esse protrocolo é possível ge-
renciar switches, roteadores, softwares ou qualquer dispositivo que permita recuperar
informações de SNMP [Douglas e Kevin 2001].
2.6.1 Arquitetura
Software de gerência de redes não segue o modelo de cliente/servidor, modelo em

que somente o cliente faz requisição ao servidor, e sim o conceito de gerente e agente
[Douglas e Kevin 2001]. Nesse modelo, as requisições podem ser feitas pelo gerente
ao agente (operações GET e SET) ou pelo agente ao gerente (operação TRAP).
Por padrão, a comunicação entre as duas entidades é feita através do protocolo

User Datagram Protocol (UDP). São utilizadas as portas 161 para enviar e receber
solicitações e 162 para que os agentes envie traps ao gerente.
2.6.2 Gerente
A aplicação gerente é responsável pelo monitoramento e gerenciamento dos dis-

positivos gerenciados e também por fornecer a interface para o gerente humano. O
gerente também é conhecido como Network Management Stations (NMS), é respon-
sável pelas operações de pull (ou pulling) e receber traps [Douglas e Kevin 2001].
Pull é ação realizada pela NMS para ler dados na base de dados dos agentes
e trap é a ação realizada pelos agentes para enviar dados (eventos) dos dispositivos
gerenciados para o gerente ou NMS. Não é necessário que a NMS envie algum tipo de
solicitação para que o agente envie uma trap. Esse processo é assíncrono, ou seja,
o agente informa ao gerente automaticamente quando algo acontece no dispositivo
gerenciado.
2.6 SIMPLE NETWORK MANAGEMENT PROTOCOL 20
2.6.3 Agente
A aplicação que é armazenada nos dispositivos gerenciados é responsável em

coletar eventos e informar ao gerente o que acontece no dispositivo. Para coletar es-
sas informações, o agente faz a varredura do disposito monitorado, por exemplo, se
colocar um agente para monitorar um servidor de banco de dados, e se o uso do pro-
cessador desse servidor aumentar além do que foi configurado como quantidade limite
de operação, o agente imediatamente envia uma trap para o gerente NMS, sendo que
ela seria tratada, informando-o do evento que está acontecendo, e a NMS pode, se
estiver configurado, enviar um email avisando o responsável pelo servidor sobre o que
está acontecendo com aquele servidor.
2.6.4 MIB
A Management Information Base (MIB) é a base de informação do objeto gerenci-

ado. É na MIB que estão as informações coletadas pelos agentes [UFRJ 2011].
Quando uma NMS consulta informações de um dispositivo gerenciado, é na MIB

que são consultadas essas informações.
São definidas três tipos de MIBs padrão: MIB II, MIB Experimental e MIB Privada.
• MIB II: Evolução da MIB I, descrita pela RFC 1213 [McCloghrie e Rose 1991];
• MIB Experimental: É utilizada para desenvolvimento e testes de novas funcio-

nalidades de gerenciamento;
• MIB Privada: Fornece informações específicas dos dispositivos gerenciados.
Todos os agentes contêm a MIB II, pois essa MIB implementa os recursos neces-
sários para monitoramento do protocolo TCP/IP, porém o agente pode implementar os
vários tipos de MIBs.
Além dessas MIBs padrão, existem outras específicas para determinados tipos de
serviços, por exemplo, DNS Server MIB definida na RFC 1611 [Austein e Saperia 1994]
específica para servidores que executam serviços DNS.
A construção da estrutura das MIBs é baseada em regras descritas através da

Structure of Management Information (SMI) - Estrutura de Informações de Gerencia-
2.7 NETFLOW / IPFIX 21
mento. Segundo [Douglas e Kevin 2001], SMI define os objetos gerenciados e a MIB
é a junção desses objetos.
2.6.5 Versões
O protocolo SNMP contém três versões: SNMPv1; SNMPv2; e SNMPv3.
A versão 1 é definida pela RFC 1157 [Case et al. 1990]. É versão mais simples
do protocolo. Sua segurança é baseada em string de texto puro, ou seja, o nome da
comunidade implementada no agente. Esse método permite que qualquer software
que interprete dados SNMP consiga ter acesso às informaçãos de gerenciamento do
dispositivo.
A versão 2 é definida pela RFC 1905 [Case et al. 1996], 1906 [Case et al. 1996] e
1907 [Case et al. 1996]. Essa versão implementou melhorias de desempenho, gerên-
cia distribuída e bulk, mas continuou com o problema da segurança que foi resolvido
na versão 3.
Já a versão 3, a comunicação entre o gerente e agente (nessa versão são deno-

minados como entidades do SNMP) é criptografada. Também é necessário configurar
usuário e senha no agente e os mesmos no gerente. Essa versão é descrita pela RFC
1905, 1906, 1907, 2572, 2573, 2574 e 2575.
2.7 NETFLOW / IPFIX
Netflow é um protocolo de rede desenvolvido pela Cisco Systems para executar

no Cisco IOS, ou seja, para funcionar com o sistema operacional Cisco IOS nos equi-
pamentos de rede fabricados por esta como, por exemplo: switches, roteadores e
outros.
Netflow é um protocolo que captura o fluxo de rede nos equipamentos, este de-
finido na RFC 3954 [Claise 2004]. Através dessa coleta de informações é possível
gerar gráficos para demonstrar o nível de uso de um determinado equipamento, por
exemplo, consumo de banda; distribuição dos protocolos (porta, protocolo e endereço
IP); mapeamento de aplicativos, ou seja, saber quais aplicativos estão em uso na
rede. Desta forma é possível ajustar as políticas de Quality of Service (QoS), pois,
através destes mapeamentos é possível saber qual tráfego a ser priorizado de um
2.8 IEEE 802.1Q 22
determinado aplicativo na organização.
Fluxo de rede é uma sequência unidirecional de pacotes passando por um ponto

de observação na rede durante um determinado intervalo de tempo. Todos os pacotes
em um fluxo possuem propriedades comuns, tais como: endereço IP de origem e
destino; porta de origem e destino; e outros.
Os equipamentos da Cisco com o serviço NetFlow poderão exportar os paco-

tes coletados por meio do protocolo UDP ou Stream Control Transmission Proto-
col (SCTP), este último é definido na RFC 4960 [Stewart 2007].
NetFlow é um serviço flexível e extensível, a versão 9 em específico está sendo

utilizada como base para a criação de um novo padrão. Este padrão está sendo
padronizado pelo IETF, sendo chamado de Internet Protocol Flow Information Export
(IPFIX) [Claise 2004].
O padrão IPFIX, está definido nas seguintes RFC’s: 3917, 5101, 5102, 5103, 5153,
5470, 5472, 5473, 5474, 5610, 5655, 5815, 5982, 6183, 6235, 6313.
O IPFIX é um protocolo para exportar informação de fluxo do tráfego observado

de um dispositivo, tais como, roteador, switch e outros. Com base na versão 9 do
protocolo Cisco NetFlow, o IPFIX está prestes a se tornar o padrão da indústria
[Leinen 2004]. Desta forma, todos os fabricantes poderão utilizar o IPFIX como o
protocolo para a gravação e coleta de informações de fluxo, para análise posterior.
Através destas informações, é possível utilizar para geração de gráficos.
2.8 IEEE 802.1Q
Em alguns ambientes corporativos pode haver a necessidade de criar segmentos

distintos em uma rede local, isso pode ser feito através de redes físicas distintas ou
Virtual LAN (VLAN).
De acordo com [Prado 1998], para controle de pacotes em VLANs são utilizados
três modelos básicos: VLAN baseada em portas; em endereço MAC; e em protocolos,
sendo:
- VLAN baseada em porta: cada porta Ethernet do dispositivo pode ser associado
a uma VLAN, exemplo de dispositivo switch;
2.8 IEEE 802.1Q 23
- VLAN baseada em MAC: Nesse modelo a VLAN é associada ao endereço MAC

do dispositivo cliente;
- VLAN baseada em protocolo: Nesse caso a VLAN é definida por protocolos (IP,
IPX, ...) e endereços da camada 3 do modelo OSI.
Como as abordagens iniciais eram baseadas em portas e endereços MAC, as

VLANs estavam restritas a um único switch ou um empilhamento com switch contro-
lador.
Para estabelecer VLANs que atravessam o limite físico de um switch foi criado o
padrão IEEE 802.1Q.
A especificação IEEE 802.1Q define os padrões, operação, administração da topo-

logia de VLAN dentro da infraestrutura LAN. A norma descreve como quebrar grandes
redes em partes menores para tráfego broadcast e multicast, também ajuda a fornecer
um maior nível de segurança para a estrutura de VLAN.
As funções descritas anteriores são possíveis graças às tags do 802.1Q, conforme

a Figura 8. Portas compatíveis com 802.1Q são configuradas para transmitir quadros
identificados ou não. O campo tag contém a identificação da VLAN, pois cada VLAN
tem uma identificação (ID). Ao conectar um equipamento (switch) em uma porta, am-
bos compatíveis com 802.1Q, os quadros transmitidos entre os equipamentos con-
têm informações da VLAN que os originou. Isso faz com que a VLAN abranja vários
segmentos de redes. É possível configurar para que não sejam transmitidas essas
informações, isso é necessário por que há alguns equipamentos, por exemplo impres-
soras, que não têm suporte ao 802.1Q, estes equipamentos devem estar conectados
a portas sem tag, ou seja, untagged.
F IGURA 8 VLAN Tag

2.9 INTRUSION DETECTION SYSTEM 24
2.9 INTRUSION DETECTION SYSTEM
Intrusion Detection System (IDS) - Sistema de Detecção de Intrusão abrange

ferramentas utilizadas para identificar ataques (tentativas de acesso sem autorização)
aos sistemas. Esses ataques podem ser originados de usuários que não fazem parte
da organização ou por usuários legítimos da organização.
As ferramentas de IDS identificam essas tentativas de acesso e informam ao ad-

ministrador sobre o ocorrido. Essas identificações podem ser feitas através de assina-
turas ou aprendendo o comportamento da rede ou sistemas e, através dessa aprendi-
zagem, identificar ações fora do padrão.
Os sistemas de IDS são compostos de sensores que são responsáveis por monito-
rar o comportamento da rede e de sistemas. Os sensores estáticos são configurados
inicialmente de acordo com a política de segurança da empresa, essa contém as as-
sinaturas de ataques já conhecidas. Os sensores inteligentes são responsáveis por
identificar mutação de ataques existentes de acordo com as assinaturas conhecidas.
Também conseguem aprender (analisar) como uma determinada rede ou sistema se
comporta em um determinado período de tempo. Essa análise fica armazenada para
comparações futuras, pois, se for identificada alguma ação fora do comportamento
analisado, o IDS qualifica essa ação como sendo um ataque.
A console de monitoramento apresenta ao administrador de redes os eventos e

alertas do IDS. É através dessa que o administrador controla todos os sensores, po-
dendo aplicar novas assinaturas, instalar novos sensores e configurar os já existentes.
Como ferramenta de IDS o PacketFence utiliza o Snort, esta será descrita a se-
guir.
2.9.1 Snort
O Snort é um Sistema de Detecção de Intrusão de Rede (Network Intrusion De-

tection System (NIDS)), open source desenvolvido inicialmente por Martin Roesch,
e mantida por colaboradores espalhados pelo mundo. A comunidade do software é
composta de vários tipos de contribuintes, desde usuários comuns até desenvolvedo-
res que mantém o software sempre atualizado [Roesch 1999].
Entre outras características da ferramenta estão: vasta quantidade de assinaturas;

2.9 INTRUSION DETECTION SYSTEM 25
código fonte pequeno e atualizações freqüentes tanto no código fonte como as assina-
turas que, consequentemente, fazem o Snort aceito entre os administradores de redes
e utilizado em conjunto com outras aplicações como, por exemplo, o PacketFence.
O Snort é utilizado para realizar varreduras em redes de computadores, coletando

e analisando pacotes TCP/IP. Ao ser executada, a ferramenta coloca a placa de rede
do computador em modo promiscuo, ou seja, captura todos os dados que por ela pas-
sar. Há três formas de executar a ferramenta: Sniffer : esse modo faz a captura de
pacotes TCP/IP e mostra o resultado na tela do computador, já no modo Packet Log-
ger o resultado não aparece na tela e sim são gravados em forma de log no disco. O
terceiro modo, Network Intrusion Detection System, é a junção dos dois últimos modos
e mais, pois a ferramenta analisa os pacotes TCP/IP capturados a procura de carac-
terísticas que sinalizam ataque. Os dados do cabeçalho do pacote são comparados
com as assinaturas, caso seja encontrado indício de ataque, ou seja, a assinatura é
igual aos dados do cabeçalho, o Snort é capaz de executar ações configuradas pelo
administrador da rede nas regras da aplicação.
Para realizar essas tarefas, o Snort tem em sua arquitetura três subsistemas: De-
codificador de pacote; Engenharia de Detecção; e Subsistema de login e alerta.
O decodificador de pacote trabalha nas camadas dois, três e quatro da pilha do

protocolo TCP/IP, fazendo a classificação dos dados coletados, colocando marcação
nos pacotes que posteriormente serão utilizados pelo subsistema Engenharia de
Detecção. O decodificador trabalha com dados do tipo Ethernet, Serial Line Internet
Protocol (SLIP), Point-to-Point Protocol (PPP) e Asynchronous Transfer Mode (ATM).
O subsistema Engenharia de Detecção armazena as regras do Snort. Essas re-

gras são mantidas em duas listas: Chain Headers (Cadeia de Cabeçalhos) e Chain
Options (Cadeia de Opções). Na Chain Headers estão armazenados os atributos co-
muns de uma regra, por exemplo, endereço de IP de origem e destino, porta. O Chain
Options armazena padrões de ataques, esses padrões serão pesquisados nos paco-
tes capturados, e se o ataque for detectado essa Chain contém as ações que serão
tomadas.
O Subsistema de login/alerta grava o que está ocorrendo na rede e gera os alertas

para o administrador em tempo real.
A opção de login grava os dados em arquivos de texto que pode ser utilizado por
multi-plataformas (Windows, Mac, etc.) ou envia essas informações para o syslog
2.10 NESSUS 26
(programa responsável por gerar e armazenar logs nos sistemas Linux/Unix). A opção
de login também pode ser configurada para armazenar pacotes decodificados, em
formato legível para ser humano.
De acordo com [Roesch 1999], a criação do arquivo texto de alerta pode ser feito
de três maneiras. A primeira é a criação desse arquivo com informações completas
do alerta, essas informações registradas são passadas pelo protocolo do nível de
transporte. A segunda registra um subconjunto condensado de informações, fazendo
com que o desempenho seja maior do que a primeira e a terceira é utilizada para
desconsiderar alertas, essa é utilizada quando a rede está passando por testes de
segurança.
2.10 NESSUS
O Nessus é um scanner robusto de vulnerabilidade. O projeto da ferramenta Nes-

sus teve início em 1998, com Renaud Deraison. No início do projeto a ferramenta
era open source. Com o lançamento do Nessus 3, em Dezembro de 2005, a Tenable
Network Security Inc., empresa por trás do Nessus, passou a cobrar por atualizações,
ou seja, o software em si permanece livre, mas as atualizações sobre vulnerabilidades
têm um custo [Deraison 2004].
O Sistema modular, ideal para grandes redes de computadores, pois o administra-

dor de redes tem a liberdade de escolher qual modo quer usar. Esses módulos estão
na forma de plugins que são adicionados ao Nessus.
As atualizações da ferramenta são mantidas pela comunidade, isso traz ao Nessus

atualizações frequentes de vulnerabilidades.
A arquitetura do software é composta pelo servidor (nessusd), cliente, os plugins

e a base de conhecimento. A base de conhecimento ajuda o Nessus a “aprender”
com os scanners já realizados, ou seja, ela guarda informações de vulnerabilidades
já detectadas pelo Nessus. Os plugins são scripts escritos na linguagem própria do
Nessus, a Nessus Attack Scripting Language (NASL) e são programados para execu-
tar determinada tarefa, como por exemplo, varrer a rede a procura de computadores
que estejam com vírus.
A arquitetura Cliente/Servidor está presente no Nessus, isso traz à ferramenta a

flexibilidade de ser executada em quase todos os Sistemas Operacionais, basta que
2.10 NESSUS 27
este tenha o cliente para conectar ao servidor.

28
3 INTRODUÇÃO AO PACKETFENCE
3.1 O QUE É PACKETFENCE ?
PacketFence é um software gratuito e uma solução open source para Controle de

Acesso à Rede [INVERSE INC. 2011]. PacketFence é desenvolvido sob tecnologias e
padrões abertos, ou seja, nenhuma empresa fechará estes padrões utilizados, garan-
tindo assim maior confiabilidade no desenvolvimento da ferramenta. PacketFence é
desenvolvida e mantida pela INVERSE INC, cujos desenvolvedores estão localizados
na América do Norte. Por ser um software gratuito, a comunidade poderá, caso tenha
interesse, contribuir com o projeto da ferramenta.
PacketFence tem a responsabilidade de garantir que qualquer dispositivo ou usuá-

rio somente terá acesso à rede após ser registrado. Desta forma, garante-se uma
maior segurança à rede e dados de uma organização. Através do PacketFence é pos-
sível centralizar o gerenciamento das redes tanto com fio quanto sem-fio, sendo este
utilizado para garantir a segurança desde uma rede pequena à uma rede muito grande
e heterogênea.
3.1.1 Visão Geral
O PacketFence conta com:
- Captive portal: este sendo bastante utilizado para o registro e remediação dos
dispositivos, ele possui: suporte ao padrão IEEE 802.1X, suporte a Voz over In-
ternet Protocol (VoIP), isolamento de dispositivos problemáticos na camada 2
do modelo Open Systems Interconnection (OSI), ou seja, dispositivos que pos-
suem vírus em geral, falhas de segurança e vulnerabilidades, possui integração
com o Snort;
- Snort: este é utilizado para detectar diferentes tipos de ataques ou atividades

3.1 O QUE É PACKETFENCE ? 29
anormais na rede;
- Nessus: este último sendo utilizado para scanner de vulnerabilidades, ou seja,

verifica se o dispositivo possui falhas de segurança ou vulnerabilidades.
Conforme a Figura 9 a seguir, é um fluxograma demonstrando a integração das

tecnologias, equipamentos e softwares ao PacketFence.
F IGURA 9 Diagrama PacketFence

Fonte: PacketFence Administration Guide
3.1.2 Modos PacketFence
Out-of-Band: PacketFence é uma solução totalmente Out-of-Band (fora de li-

nha), ou seja, permite uma solução de escala geográfica e mais resistente às
falhas, quando usado de forma correta com a tecnologia porta de segurança
(port-security ). Através deste modo, um único servidor PacketFence pode ser
usado para gerenciar switches e muitos nós (dispositivos) conectados a ele.
Inline: O modo Inline (em linha) é suportado pelo PacketFence para agregar
equipamentos de rede com fio e sem-fio que não são gerenciáveis, ou seja, o
PacketFence não consegue gerenciar estes dispositivos, tal como: mudar de
VLAN; aplicar o recurso de porta de segurança (port-security ); entre outros.
Neste modo, todo o tráfego é direcionado ao PacketFence. O modo Inline pode
muito bem coexistir com o modo Out-of-Band.
3.1.3 Integração Wireless
PacketFence integra perfeitamente com redes sem-fio através do modulo FreeRa-

dius. Este permite segurança em redes com fio e sem-fio, além de fazer uso de uma
mesma base de dados para fornecer autenticação tanto em redes com fio quanto em
redes sem-fio através do Captive portal, deixando, desta forma, a autenticação cen-
tralizada. A integração suporta vários Access Points (AP) e controladores sem-fio de
diferentes fabricantes, tornando o ambiente heterogêneo.
3.1.4 Registro de Dispositivos
PacketFence utiliza uma solução similar ao Captive portal para realizar o registro
dos dispositivos. Diferentemente de soluções comuns de Captive portal, a solução
do PacketFence recorda os usuários previamente registrados, pois este verifica se o
usuário está devidamente registrado juntamente com o dispositivo na base de dados
do PacketFence. Caso exista o registro do dispositivo, o mesmo não será interceptado
pelo Captive portal e consequentemente não será pedido para se registrar novamente.
Desta forma, o usuário consegue acesso sem outra autenticação. Contudo, os usuá-
rios não poderão ter acesso à rede sem primeiramente aceitar a Política de Uso.
3.1.5 Detecção de Atividade Anormal
O PacketFence é capaz de identificar e bloquear atividades maliciosas na rede,

tais como: computador com vírus; worms; spyware e outras pragas virtuais. Isso é
possível devido a integração com o Snort. Estas atividades maliciosas podem ser
detectadas com a execução local do Snort, ou seja, no mesmo servidor do Packet-
Fence ou remotamente, este último sendo executado em outro servidor diferente do
PacketFence.
A base de assinaturas do Snort, este possui vários tipos de assinaturas de ata-

ques e outros, tais como: ataques ao Shell; ataques Web; ataques de vírus; entre
outros tipos de ataques. Tornando assim uma ferramenta de extrema necessidade
para manter a segurança da rede.
3.1.6 Remediação de Dispositivos
PacketFence realiza a remediação dos dispositivos através do Captive portal. Ini-

cialmente, todo o tráfego do dispositivo é interceptado e finalizado e, redirecionado
para o Captive portal. A remediação é realizada com base no status do dispositivo, ou
seja, não registrado, violação, etc.
Se o dispositivo está com o status de não registrado, o usuário será redirecio-

nado para o Captive portal e, através deste, o usuário poderá registrar o dispositivo.
Entretanto, se o dispositivo está com o status de violação, o mesmo também será redi-
recionado para o Captive portal, porém não sendo demonstrada a opção para registro
e sim, informações para a correção da situação do dispositivo em particular e, através
destes, reduzindo os custos e intervenções da parte de Help Desk.
3.1.7 Gerenciamento Baseado em Linha de Comando e Web
O PacketFence oferece dois modos de gerenciamento da ferramenta, gerencia-

mento baseado em linha de comando e baseado na Web.
Independentemente do modo de gerenciamento, todas as tarefas do PacketFence

podem ser realizadas em linha de comando quanto no ambiente Web. A administração
Web suporta diferentes níveis de permissão para autenticação de usuários, sendo
possível usar autenticação Lightweight Directory Access Protocol (LDAP) ou Microsoft
Active Directory.
3.1.8 Gerenciamento Flexível de VLAN
O PacketFence faz uso da técnica de VLAN definido no padrão IEEE 802.1Q. Esta
técnica é bastante utilizada para segmentação de uma rede de maneira mais eficaz,
pois, com o uso desta técnica, é possível segmentar uma rede em várias VLAN’s,
podendo segmentar um switch em VLAN’s diferentes, ou seja, várias redes distintas
em um mesmo equipamento.
PacketFence possui um gerenciamento flexível de VLAN, pois sua topologia de

VLAN poderá ser mantida da forma que está e apenas duas novas VLAN’s terão de
ser adicionadas em toda a sua rede. As VLAN’s que terão de serem adicionadas são:
VLAN de Registro e VLAN de Isolamento.
A VLAN de Registro será utilizada para o registro de dispositivos e usuários. Essa

VLAN está separada das demais, não possuindo acesso à rede principal e à Internet.
A VLAN de Isolamento é utilizada para isolar dispositivos que estejam com problemas,
sejam estes problemas de segurança, vírus ou até um software Peer-to-Peer (P2P)
que está em execução no dispositivo. Desta forma, atribui-se a VLAN de Isolamento
para a correção dos problemas, além de isolar estes dispositivos problemáticos da
rede principal.
3.1.9 Tipos de Violação
O PacketFence poderá usar o Snort e Nessus como fonte de informações para

bloquear dispositivos em sua rede de computadores. Para realizar estes bloqueios,
o PacketFence poderá usar uma combinação dos mecanismos de detecção, ou seja,
dos tipos de violação, tais como: DHCP Fingerprint, User-Agent e MAC Address.
Com o uso do DHCP Fingerprint é possível saber qual o sistema operacional do

dispositivo. Essa assinatura é única, ou seja, cada dispositivo possui a sua identifi-
cação; este mecanismo será explanado posteriormente. Então, o PacketFence po-
derá bloquear os dispositivos baseando-se em sua assinatura. Através do mecanismo
User-Agent, o PacketFence bloqueia o dispositivo com base no navegador de Internet,
por exemplo: Safari, Internet Explorer, Mozilla Firefox, entre outros. Já o bloqueio pelo
mecanismo de MAC Address, o PacketFence bloqueia os dispositivos com base no
fabricante do dispositivo de rede.
3.1.10 Registro Automático
O PacketFence tem várias formas para registrar um cliente ou dispositivo de forma

automática. Estas formas ou mecanismos para registrar um cliente ou dispositivo são:
DHCP Fingerprint, User-Agent e MAC Address. O DHCP Fingerprint baseia-se na
assinatura do dispositivo, User-Agent baseia-se no tipo de navegador de Internet e o
MAC Address baseia-se no endereço de hardware do dispositivo.
3.1.11 Expiração
O tempo de acesso à rede poderá ser controlado com o PacketFence, com os

parâmetros de configuração. A duração do tempo de acesso poderá ser uma data
absoluta (por exemplo, Ter 15 Nov 2011), um período de tempo (por exemplo, 4 sema-
nas a contar a partir do primeiro acesso) ou assim que o dispositivo se tornar inativo
na rede. Após a expiração os dispositivos que estiverem registrados estes passaram
para status de dispositivos não registrados.
Será apresentado o seguinte exemplo:
Um Consultor está a visitar a sua empresa, ele precisar utilizar os recursos da sua
rede de computadores para acessar a Internet e este ficará em sua empresa somente
por um período máximo de 8 horas, ou seja, uma jornada de trabalho. Ao se passar o
período de 8 horas, o cadastro do Consultor expirará e da, próxima vez que este estiver
em sua empresa, não conseguirá acessar os recursos da sua rede de computadores,
pois o status após a expiração passa a ser de não registrado. Desta forma, sua rede
se torna mais segura, sendo que o Consultor precisará de autorização, ou seja, de
registro para acessar os recursos da sua rede de computadores.
3.1.12 Acesso a Visitantes
Atualmente, as empresas precisam fornecer aos seus Consultores acesso à Inter-

net, pois estes requerem o acesso para a realização de seus trabalhos. Além disso, di-
ficilmente é necessária a eles terem acesso a infraestrutura corporativa interna. Desta
forma, evita-se encargos administrativos como, por exemplo, auditoria, pois ao regis-
trar um usuário na infraestrutura corporativa interna, este passa por auditoria, uma vez
que cada recurso alocado gera despesas, tendo então, que justificar este registro em
uma auditoria interna.
O PacketFence suporta acesso a visitante ou convidado, sendo este gerenciado

em uma VLAN especial para convidado, a qual somente terá acesso à Internet. O
convidado ou visitante somente irá para Internet depois que este estiver registrado.
Para isso, o PacketFence utiliza uma VLAN de Registro e um Captive Portal, sendo
este último utilizado para explicar aos clientes, ou seja, convidados ou vistantes, como
se registrar para o acesso à Internet e como funciona o seu acesso.
Para registrar um convidado, existem várias possibilidades, tais como: registro ma-
nual, auto-registro, acesso ao visitante com ativação por email e ativação por telefone
celular via Short Message Service (SMS).
35
4 IMPLEMENTAÇÃO E CONFIGURAÇÃO
Este capítulo descreve os passos necessários para implementar a ferramenta Pac-

ketFence para o controle de acesso à rede cabeada. O ambiente proposto deverá
migrar dispositivos para diferentes VLANs de acordo com as políticas adotadas, que
serão descritas no tópico 4.2.
4.1 CONFIGURAÇÃO DE HARDWARE
A implementação e configuração da ferramenta foi realizada utilizando-se de tec-

nologia para virtualização1 , ou seja, fazendo uso de máquina virtual para a realização
de todos os procedimentos, a fim de obter os resultados esperados pela proposta da
ferramenta. A seguir, a configuração utilizada pela máquina virtual:
- Processador: Intel;
- Memória: 1,5 GB de RAM;
- Hard Disk: 20GB;
- Rede: 2 interfaces, sendo uma para gerenciamento e outra para monitoramento.
4.2 MODELO DE TOPOLOGIA
Na Tabela 1, é demonstrado as informações propostas, referentes à topologia a

ser implementada.
1
É uma técnica que separa a Aplicação e Sistema Operacional dos componentes físicos, ou seja,
do hardware. Em uma definição livre, virtualização é capacidade de executar diferentes sistemas ope-
racionais em um único hardware.
4.2 MODELO DE TOPOLOGIA 36
VLAN Descrição PacketFence Rede Interface

1 Gerenciamento 10.0.10.1 10.0.10.0/24 eth0
2 Registro 192.168.2.10 192.168.2.0/24 eth0.2
3 Isolação 192.168.3.10 192.168.3.0/24 eth0.3
10 Normal 192.168.1.10 192.168.1.0/24 eth0.10
TABELA 1 Dados da Topologia
A Figura 10 é uma representação gráfica da topologia apresentada na Tabela 1,

e a seguir, uma breve descrição dos tipos de VLAN adotadas para a implementação
desta topologia:
F IGURA 10 Topologia
Fonte: Autoria Própria
4.3 CONFIGURAÇÕES 37
- VLAN 1 - Gerenciamento: é a VLAN utilizada para o gerenciamento do Pac-

ketFence aos switches, ou seja, é nesta que estão todos os dispositivos que o
PacketFence gerencia;
- VLAN 2 - Registro: é a VLAN utilizada para o registro dos dispositivos que não
estão registrados na base de dados do PacketFence, através desta VLAN os
clientes somente terão acesso ao Captive Portal para a realização do registro;
- VLAN 3 - Isolação: é a VLAN utilizada para isolar dispositivos que estejam com
problemas, ou seja, vulnerabilidades, vírus, execução de software P2P. A fim de
re-mediar estes dispositivos, ou seja, corrigir estes problemas, sendo utilizado
o Captive Portal para apresentar informações aos clientes de como resolver os
problemas, em particular para cada dispositivo;
- VLAN 10 - Normal: é a VLAN na qual está toda a rede corporativa, ou seja, a

rede na qual estão os servidores e estações dos funcionários, sendo possível
acessar todos os serviços fornecidos pela empresa.
4.3 CONFIGURAÇÕES
O sistema operacional utilizado para a implementação e configuração da ferra-

menta PacketFence foi o Community ENTerprise Operating System (CentOS) 6. Este
foi escolhido por ser open source, ou seja, de uso gratuito, não sendo necessário
realizar algum tipo de pagamento para utilizar o sistema operacional.
A ferramenta PacketFence é suportada pelos seguintes sistemas operacionais:

Red Hat Enterprise Linux (RHEL) e CentOS nas versões 5.x/6.x, respectivamente,
nas arquiteturas i386 e x86_64, ou seja, 32bits e 64bits [Inverse 2011].
A instalação do PacketFence não será abordada nesta parte do trabalho, porém

consulte a seção Apêndice A para saber como instalar a ferramenta.
4.3.1 Interface de Rede
Os arquivos de configuração das interfaces de rede, estão localizados dentro de

/etc/sysconfig/network-scripts/, este local poderá mudar dependendo do sistema ope-
racional a ser utilizado. A seguir, a descrição dos parâmetros a serem utilizados nas
configurações das interfaces de rede:
- DEVICE: Identifica o dispositivo de rede, ou seja, a interface de rede;
- BOOTPROTO: Informa o tipo de configuração a ser utilizada, sendo static, essas

configurações são manual ou estática, sendo dhcp, significa que as configura-
ções serão automáticas via servidor DHCP e none, sem nenhuma configuração,
ou seja, a interface ficará em bridge;
- ONBOOT: Ativa o dispositivo ao ligar o computador, ou seja, no momento do

boot a placa de rede será carregada para uso;
- IPADDR: Identifica o endereço IP do computador;
- NETMASK: Identifica a máscara da rede;
- MTU: é a abreviação para Maximum Transmission Unit, indica o tamanho do

maior datagrama que uma camada de um protocolo de comunicação pode trans-
mitir.
Será configurado a interface eth0, para isso será necessário editar o arquivo ifcfg-
eth0, deixando-o, de acordo com o conteúdo a seguir:
DEVICE="eth0"
BOOTPROTO="static"
ONBOOT="yes"
IPADDR="10.0.10.1"
NETMASK="255.255.255.0"
A VLAN 2 será adicionada à interface eth0, para isso, deverá ser criado o arquivo
ifcfg-eth0.2, sendo adicionado o conteúdo a seguir:
DEVICE="eth0.2"
VLAN="yes"
BOOTPROTO="static"
ONBOOT="yes"
IPADDR="192.168.2.10"
NETMASK="255.255.255.0"
MTU="1442"
A VLAN 3 será adicionada à interface eth0, para isso, deverá ser criado o arquivo
ifcfg-eth0.3 e sendo adicionado o conteúdo a seguir:
DEVICE="eth0.3"
VLAN="yes"
BOOTPROTO="static"
ONBOOT="yes"
IPADDR="192.168.3.10"
NETMASK="255.255.255.0"
MTU="1442"
A VLAN 10 também deverá ser adicionada à interface eth0, para isso, será criado
o arquivo ifcfg-eth0.10, sendo adicionado o conteúdo a seguir:
DEVICE="eth0.10"
VLAN="yes"
BOOTPROTO="static"
ONBOOT="yes"
IPADDR="192.168.1.10"
NETMASK="255.255.255.0"
MTU="1442"
4.3.2 SELinux
Security-Enhanced Linux (SELinux) é uma implementação de uma fle-
xível e refinada arquitetura Mandatory Access Control (MAC). SELinux
provê uma política de segurança sobre todos os processos e objetos
do sistema baseando suas decisões em etiquetas contendo uma vari-
edade de informações relevantes à segurança. A lógica da política de
tomada de decisões é encapsulada dentro de um simples componente
conhecido como servidor de segurança (security server ) com uma in-
terface geral de segurança [Wikipédia 2005].
O SELinux é uma característica que poderá ser requerida por algumas organiza-
ções, porém o PacketFence não será executado corretamente se o SELinux estiver
definido para enforced [Inverse 2011].
Para desativar o SELinux, deverá ser editado o arquivo /etc/selinux/config, dei-

xando a diretiva SELINUX, conforme a seguir:
SELINUX=disabled
4.3.3 MySQL
O MySQL é um Sistema de Gerenciamento de Banco de Dados (SGBD), que

utiliza a linguagem Structured Query Language (SQL) como interface, este não sendo
abordado no escopo deste trabalho.
Após iniciar o banco de dados, será necessário executar a ferramenta de admi-

nistração do MySQL (mysqladmin) para alterar a senha do usuário root, conforme o
comando a seguir:
mysqladmin -u root password ’suasenha’
4.3.4 PacketFence
Para iniciar a configuração do PacketFence, deve-se executar o instalador /usr/lo-

cal/pf/installer.pl. Ao executar o instalador, são realizadas algumas perguntas, tais
como: usuário e senha do bando de dados, dados da empresa para gerar o certificado
Secure Sockets Layer (SSL), entre outras perguntas. De acordo com as respostas, é
que o instalador, prepará a estrutura da base de dados do PacketFence, os certificados
a serem utilizados a fim de garantir uma maior segurança aos acesso Web, a criação
do usuário administrador do gerenciamento Web, e outros.
O conteúdo apresentado na Figura 11, se refere à aceitação aos termos propostos

pelos desenvolvedores da ferramenta.
F IGURA 11 Tela dos termos de uso do PacketFence

Fonte: Script da Ferramenta PacketFence
O conteúdo apresentado na Figura 12, se refere à verificação das configurações,

tais como: endereço IP, porta e nome do banco de dados, para o acesso e criação de
um usuário para o PacketFence, bem como a criação do schema, ou seja, a estrutura
do banco de dados.
F IGURA 12 Tela de configuração dos parâmetros do banco de dados

As informações apresentadas na Figura 13, são referentes às informações digitas

para o acesso do banco de dados e criação de um usuário e schema para o Packet-
Fence.
F IGURA 13 Tela de confirmação das configurações do banco de dados

O script de configuração compilará as linguagens, ou seja, as traduções do Pac-

ketFence, para a possível utilização posterior. Conforme demonstrado na Figura 14.
F IGURA 14 Tela compilação dos idiomas do PacketFence

Algumas perguntas demonstradas na Figura 15, referem-se aos dados necessá-

rios para a geração de um certificado auto-assinado, sendo também possível utilizar
um certificado comercial, para fornecer segurança ao acesso do Captive Portal.
F IGURA 15 Tela geração do certificado auto-assinado do PacketFence

A pergunta demonstrada na Figura 16, se refere à criação de um usuário adminis-

trativo, afim de acessar a interface de administração web do PacketFence.
F IGURA 16 Tela criação de usuário para acessar a administração do PacketFence

Na Figura 17, é demonstrada uma pergunta que se refere à baixar os arquivos de

regras do Snort, ou seja, baixar as últimas atualizações de regras disponíveis.
F IGURA 17 Tela pergunta para baixar as regras do snort

Conforme demonstrado na Figura 18, a pergunta desta figura se refere à baixar

o arquivo contendo as assinaturas DHCP fingerprints mais recente, ou seja, a última
atualização.
F IGURA 18 Tela pergunta para baixar as assinaturas fingerprint

Para finalizar a execução do script, é perguntado se deseja obter a última versão

dos prefixos OUI, estes são usados para identificar os fabricantes das interfaces de
rede. E por último, altera a permissão do diretório /usr/local/pf e do aplicativo de ge-
renciamento do PacketFence em linha de comando /usr/local/pf/bin/pfcmd, conforme
mostra a Figura 19.
F IGURA 19 Tela pergunta para baixar o arquivo OUI

O script /usr/local/pf/configurator.pl é utilizado para configurar o PacketFence. Por-

tanto, a fim de realizar as configurações iniciais, será executado o comando a seguir:
/usr/local/pf/configurator.pl
Ao executar o script de configuração, é fornecido as opções de configuração do

PacketFence, ou seja, os modos que deseja ativar, devendo escolher uma opção para
prosseguir. Estas opções podem ser observadas na Figura 20.
Ao escolher uma das opções apresentadas na Figura 20, por exemplo a opção 4,
posteriormente é apresentada as opções que se referem aos modos VLAN ou Inline,
conforme demonstrado na Figura 21, ou seja, com a opção de VLAN é para ser usado
com equipamentos gerenciáveis e a opção Inline para equipamentos não gerenciáveis.
F IGURA 20 Tela de execução do script configurator.pl

F IGURA 21 Tela de escolha dos modos de configuração do PacketFence

Na Figura 22, é perguntado o nome do host, sem o domínio.
F IGURA 22 Tela o nome do host do PacketFence

A Figura 23, apresenta a pergunta referente ao nome de domínio do PacketFence,

ou seja, qual o nome de domínio a ser utilizado.
F IGURA 23 Tela o nome de domínio do PacketFence

Na Figura 24, é perguntado os endereços IP dos servidores DHCP a serem utili-

zados, estes são os endereços IP do PacketFence em cada VLAN.
F IGURA 24 Tela servidores DHCP a serem utilizados

A Figura 25, apresenta a pergunta referente a qual porta a ser utilizada para a
administração web do PacketFence, sendo a 1443 a padrão a ser configurada.
F IGURA 25 Tela configuração da porta WebGUI do PacketFence

Na Figura 26, é perguntado qual o endereço de e-mail, para que seja enviado as
notificações de violações.
F IGURA 26 Tela configuração de envio de notificação do PacketFence

Neste momento, conforme apresentado na Figura 27, é perguntado se deseja ati-

var a notificação por e-mail, caso os serviços do PacketFence não estejam em execu-
ção.
F IGURA 27 Tela ativação de envio de notificação do PacketFence

Na Figura 28, é perguntado se deseja ativar o recurso de reiniciar os serviços do

PacketFence, caso estes fiquem desativados.
F IGURA 28 Tela monitoramento de serviços do PacketFence

Na Figura 29, é apresentado a pergunta que se refere ao registro de dispositivos,

ou seja, se deseja forçar o registro dos dispositivos.
F IGURA 29 Tela registro do dispositivo no log do PacketFence

A Figura 30, apresenta a pergunta para configurar o serviço de alta disponibili-

dade, para ativar esta opção, deve ter uma placa de rede adicional para realizar a
configuração deste serviço.
F IGURA 30 Tela configuração de alta disponibilidade do PacketFence

Na Figura 31, apresenta a pergunta referente ao Snort, ou seja, qual interface

gostaria de ativar o monitoramento do Snort.
F IGURA 31 Tela configuração da interface do Snort do PacketFence

Na Figura 32, é perguntado o endereço IP, porta, usuário e senha para o Nessus,
ou seja, informações para a comunicação com o Nessus, a fim de enviar tarefas para
o escaneamento dos dispositivos.
F IGURA 32 Tela configuração do Nessus

É perguntado na Figura 33, se deseja ativar criptografia SSL para a comunicação

com o servidor, ou seja, garantir uma maior segurança na comunicação.
F IGURA 33 Tela configuração para ativar SSL do Nessus

É apresentado na Figura 34, se deseja ativar o escaneamento para novos disposi-

tivos, ou seja, ao registrar novos dispositivos, estes serão escaneados.
F IGURA 34 Tela para ativar o escaneamento do Nessus

Na Figura 35, são realizadas perguntas referentes à configuração do banco de

dados, ou seja, é perguntado o endereço IP, a porta, o usuário, banco de dados, e a
senha para a conexão do PacketFence.
F IGURA 35 Tela configuração banco de dados do PacketFence

A seguir, na Figura 36, as configurações iniciais realizadas pelo script foram en-
cerradas com a finalização da execução do script, devendo configurar os arquivos
networks.conf e switches.conf, estes sendo explorados mais adiante.
F IGURA 36 Tela finalizando a configuração do PacketFence

4.3.4.1 pf.conf
As configurações dos parâmetros do PacketFence devem ser configuradas no ar-

quivo pf.conf que se encontra dentro de /usr/local/pf/conf. Neste arquivo é possível
habilitar/desabilitar o monitoramento do Snort, escaneamento do Nessus, configurar
as interfaces de rede, entre outros parâmetros. Para saber mais sobre os parâmetros
de configuração, acesse a documentação que está em /usr/local/pf/conf/, o nome do
arquivo é documentation.conf.
Após a execução do aplicativo configurador do PacketFence o /usr/local/pf/configu-

rator.pl, este gera as configurações com as quais foram respondidas nas perguntas
durante a execução do configurador. As configurações geradas pelo configurador são
apresentadas a seguir:
[general]
domain=redes.local
hostname=pf
dhcpservers=192.168.2.10,192.168.3.10,192.168.1.10
[trapping]
range=192.168.2.0/24,192.168.3.0/24,192.168.1.0/24
detection=enabled
[scan]
pass=admin
[database]
pass=pfdb123
[interface eth1]
type=monitor
É necessário configurar as interfaces no arquivo pf.conf. Porém nas configurações

das interfaces do PacketFence, existem algumas possibilidades de tipos de interface,
a serem declaradas como valor do parâmetro type. A seguir, algumas opções a serem
utilizadas:
[interface]
type= ?
- management: Gerenciamento do PacketFence
- internal: Rede interna para uso com parâmetro enforcement (vlan, inline)
- monitor: Utilizado para monitoramento do Snort
- dhcp-listener: Recebe todo tráfego dhcp
Afim de realizar as configurações, deve-se adicionar as seguintes linhas ao final

do arquivo:
[interface eth0]
ip=10.0.10.1
mask=255.255.255.0
type=management
gateway=10.0.10.1
[interface eth0.2]
ip=192.168.2.10
mask=255.255.255.0
type=internal
enforcement=vlan
gateway=192.168.2.1
[interface eth0.3]
ip=192.168.3.10
mask=255.255.255.0
type=internal
enforcement=vlan
gateway=192.168.3.1
[interface eth0.10]
ip=192.168.1.10
mask=255.255.255.0
type=internal
enforcement=vlan
gateway=192.168.1.1
4.3.4.2 networks.conf
Através do arquivo networks.conf são configurados os parâmetros dos serviços

de DNS e DHCP oferecidos pelo PacketFence. Este arquivo está localizado dentro do
diretório /usr/local/pf/conf/. O arquivo por padrão está vazio, ou seja, sem nenhuma
informação configurada no mesmo.
Afim de realizar as devidas configurações, será adicionado as seguintes informa-

ções, a seguir:
[192.168.2.0]
type=vlan-registration
netmask=255.255.255.0
gateway=192.168.2.10
next_hop=
named=enabled
domain-name=registration.redes.local
dns=192.168.2.10
dhcpd=enabled
dhcp_start=192.168.2.11
dhcp_end=192.168.2.254
dhcp_default_lease_time=300
dhcp_max_lease_time=300
[192.168.3.0]
type=vlan-isolation
netmask=255.255.255.0
gateway=192.168.3.10
next_hop=
named=enabled
domain-name=isolation.redes.local
dns=192.168.3.10
dhcpd=enabled
dhcp_start=192.168.3.11
dhcp_end=192.168.3.254
[192.168.1.0]
type=Normal
netmask=255.255.255.0
gateway=192.168.1.10
pf_gateway=
named=disabled
domain-name=production.redes.local
dns=8.8.8.8,8.8.4.4
dhcpd=enabled
dhcp_start=192.168.1.11
dhcp_end=192.168.1.254
4.3.4.3 switches.conf
As configurações dos switches gerenciados são colocados no arquivo switches.conf,

este sendo localizado em /usr/local/pf/conf/. Deverá ser alterado na declaração default,
os seguintes parâmetros, a seguir:
[default]
vlans = 2,3,4,10
normalVlan = 10
registrationVlan = 2
isolationVlan = 3
macDetectionVlan = 4
O switch deverá possuir o serviço de telnet habilitado, pois o PacketFence se co-

necta ao switch por meio deste para realizar configurações no mesmo. Portanto, ao
final do arquivo switches.conf, será adicionado as seguintes configurações referentes
ao switch:
[10.0.10.4]
type = ThreeCom::Switch_4200G
mode=production
uplink = 25
cliTransport = Telnet
cliUser = admin
cliPwd =
4.3.5 Configuração do Switch
As configurações do switch podem ser realizadas de duas formas: porta console

ou via acesso remoto usando telnet. Este último deve-se saber o endereço IP do
equipamento. Através da porta console, é conectado um cabo serial na porta console
do equipamento e a outra ponta do cabo deve ser conectada na porta serial do com-
putador. Para acessar o switch será necessário um software, por exemplo, o Hyper
Terminal.
Será demonstrado a seguir dois modos de configuração do switch com o Packet-

Fence, o modo access e modo com autenticação 802.1x.
4.3.5.1 Modo Access
As portas do switch ao serem configuradas em modo access, permitem ao Pac-

ketFence utilizar qualquer método de autenticação para o registro do usuário, dife-
rentemente do modo 802.1X (port-security ), sendo obrigatório o uso de autenticação
RADIUS. A seguir, será apresentando os comandos para a configuração do switch em
modo access.
Criando as VLAN’s:
A VLAN 1 não precisará ser configurada, pois esta já vem configurada por padrão
no switch, sendo que a VLAN 1 por padrão vem em modo access.
system-view
vlan 2
vlan 3
vlan 4
vlan 10
quit
system-view - entra no modo de configuração do switch;
vlan x - adiciona a VLAN, sendo x um número que pode variar de 1 à 4096.
Habilitando o SNMP:
O SNMP deverá ser habilitado no switch para que este envie traps ao PacketFence
ao detectar a mudança do status da porta, ou seja, linkup e linkdown.
snmp-agent
snmp-agent target-host trap address udp-domain 10.0.10.1 params
securityname public
snmp-agent trap enable standard linkup linkdown
quit
- snmp-agent - configura o agent snmp do switch;
- target-host - configura o IP que o switch enviará as traps;
- trap - configura o tipo de trap a ser ativada.

Configurando as portas em modo access, elas devem ser configuradas em cada

interface. A seguir, os comandos a serem executado no switch para realizar as confi-
gurações, sendo x substituído por um número inteiro, ou seja, o número da porta do
switch na qual se deseja configurar.
interface ethernet 1/0/X

port link-type access
port access vlan 4
quit
Configurando a porta do roteador da rede principal, este deverá ficar na VLAN

10, pois é nessa VLAN que ficará a rede principal, ou seja, a rede que terá acesso à
Internet.
interface ethernet 1/0/1

port link-type access
port access vlan 10
quit
Configurando a porta do PacketFence, este deverá ficar em uma porta como trunk,
pois deve permitir que o tráfego das outras VLAN’s cheguem ao PacketFence.
interface ethernet 1/0/12

port link-type trunk
port trunk permit vlan 2
quit
4.3.5.2 Modo 802.1x
No modo de autenticação 802.1x, se deve utilizar o método de autenticação RA-

DIUS.
As configurações que devem ser realizadas no switch para habilitar este modo:
configurar um schema radius, sendo que neste é informado o endereço IP do servidor
RADIUS e a porta; configurar a shared secret a ser utilizada para a comunicação
do switch e o RADIUS; informar que os logins serão sem o prefixo do domíno, por
exemplo, usuario@redes.local; informar o domínio; ativar o schema para este domínio,
no caso o redes.local; atribuir VLAN por string, ou seja, por texto; habilitar o domínio
redes.local como sendo o domínio padrão a ser utilizado; e especificar o método de
autenticação, além de ativar a port-security, ou seja, segurança por porta.
Configuração Global:
A seguir, os comandos necessários para realizar as configurações descritas ante-

riormente, a fim de habilitar o modo 802.1x no switch:
system-view
radius scheme Redes
server-type standard
primary authentication 10.0.10.1 1812
primary accounting 10.0.10.1 1812
accounting optional
key authentication pfsecret123
user-name-format without-domain
quit
domain redes.local
radius-scheme Redes
vlan-assignment-mode string
quit
domain default enable redes.local
dot1x authentication-method eap
port-security enable
quit
Para finalizar a configuração do modo 802.1x, deverá ativar a port-security nas

interfaces que se deseja habilitar essa segurança, configurando a autenticação por
MAC Address ou usuário e senha e desabilitando os trap de linkUp e linkDown. A
seguir, os comandos necessários para realização desta configuração:
system-view
interface etthernet 1/0/x
port-security port-mode mac-else-userlogin-secure-ext
undo enable snmp trap updown

quit
quit
4.3.6 Autenticação
A fim de registrar os dispositivos, primeiramente, devem-se criar os usuários, so-

mente posterior a este procedimento, realizar o registro do dispositivo. Para criar o
arquivo de usuários e senhas, será utilizado o utilitário htpasswd, este serve para rea-
lizar a criação de usuários com a senha em hash.
4.3.6.1 Local
O PacketFence por padrão utiliza o método de registro local, ou seja, armazena os

registros em arquivo de texto puro, sendo este o arquivo user.conf, localizado dentro
do diretório conf do PacketFence. No entanto, este arquivo não existe, devendo ser
criado. Para criar o arquivo e adicionar um novo usuário, será executado o seguinte
comando, a seguir:
htpasswd -c /usr/local/pf/conf/user.conf diego
Após a criação do arquivo user.conf, para todos os outros usuários que se deseja
cadastrar, deve-se executar o comando acima sem o parâmetro -c (create). Esse
parâmetro é utilizado para criar o arquivo, adicionando a este um novo usuário. Para
inserir novos usuários ao arquivo, o comando ficará da seguinte forma, a seguir:
htpasswd /usr/local/pf/conf/user.conf andre
A fim de ativar a autenticação, ou seja, registrar os equipamentos ao usuário, deve-

se adicionar um parâmetro no arquivo pf.conf. A seguir, o parâmetro a ser adicionado
dentro da declaração [trapping]:
[trapping]
registration=enabled
Ao realizar qualquer alteração nos arquivos de configuração do PacketFence para

que a alteração seja válidada, será necessário reiniciar o serviço novamente:
service packetfence restart
4.3.6.2 RADIUS
Para habilitar a autenticação RADIUS, primeiramente, será adicionado a seguinte

declaração ao arquivo pf.conf :
[registration]
auth=radius
Agora, será criado um usuário administrativo para o RADIUS, executando o se-

guinte comando:
htpasswd /usr/local/pf/conf/admin.conf webservice
Neste momento é necessário adicionar o usuário e senha recém-criados dentro

do arquivo /etc/raddb/packetfence.pm, a seguinte configuração deve ser realizada:
WS_USER => ’webservice’,

WS_PASS => ’pfweb’,
Deve-se criar um usuário que será utilizado para registrar um dispositivo, para isso
será adicionado a seguinte linha a seguir, ao final do arquivo /etc/raddb/users:
"andre" Cleartext-Password := "123456"
Será alterado as informações referente ao banco de dados do PacketFence, no

arquivo /etc/raddb/sql.conf, a seguir:
server = "localhost"
port = 3306
login = "pf"
password = "pfdb123"
radius_db = "pf"
Deve-se adicionar na configuração do switch em switches.conf o seguinte parâme-

tro e seu valor:
[10.0.10.4]
radiusSecret = pfsecret123
A fim de validar a configuração realizada, será reiniciado o serviço do PacketFence

novamente.
service packetfence restart
4.3.7 Acesso à Internet
Com base na topologia a qual foi seguida para montar a infraestrutura do Pac-
ketFence e demais dispositivos, para o cliente na rede principal conseguir acessar a
Internet, deverá ser realizado as seguintes configurações no PacketFence:
1. Ativar o roteamento do sistema operacional;
echo "1" > /proc/sys/net/ipv4/ip_forward
2. Adicionar a rota padrão de saída para o roteador, este deve ser o IP do roteador
da rede da organização que tem uma conexão direta com a internet;
route add default gw 192.168.1.1
3. Adicionar uma regra ao iptables, para permitir o redirecionamento.
iptables -t filter -A FORWARD -s 192.168.1.0/24 -j ACCEPT
4.3.8 Habilitando o Snort
Para habilitar o Snort, é necessário adicionar à declaração [trapping] que está

localizada no arquivo pf.conf, o seguinte parâmetro e seu valor:
[trapping]
detection=enabled
Com a diretiva acima habilitada, o Snort notifica o PacketFence sobre a violação,

com base em suas assinaturas. Para habilitar o bloqueio de uma violação, ou seja,
enviar o cliente para a VLAN de Isolamento (VLAN 3), deve-se habilitar as regras do
tipo de detecção no arquivo violation.conf que está localizado no diretório conf do
PacketFence. A fim de habilitar qualquer regra contida neste arquivo, proceda da
seguinte forma:
enabled=Y
Sendo: Y para habilitado e N para desabilitado.
A seguir, um exemplo:
[1100004]
desc=Browser isolation example
url=/remediation.php?template=banned_devices
trigger=USERAGENT::101,USERAGENT::102
actions=trap,email,log
enabled=N
4.3.9 Habilitando o Nessus
Para habilitar o escaneamento do Nessus ao dispositivo do cliente, é necessário

adicionar alguns parâmetros ao arquivo pf.conf. A seguir, a declaração [scan] e seus
parâmetros:
[scan]
user=admin
pass=admin
port=1241
ssl=enabled
A fim de habilitar o escaneamento do Nessus aos dispositivos logo após o seu

registro, deve-se adicionar o seguinte parâmetro à declaração [scan]:
[scan]
registration=enabled
62
5 RESULTADOS OBTIDOS
As figuras apresentadas nesta parte do documento, foram retiradas do log de

acesso do PacketFence. Este arquivo de log do PacketFence poderá ser localizado
dentro do diretório /usr/local/pf/log, com o nome packetfence.log.
Inicialmente as portas de conexões do switch aos dispositivos dos clientes estão

na VLAN de detecção de MAC, ou seja, a VLAN 4.
Ao conectar um dispositivo em uma porta do switch, este envia um trap ao Packet-

Fence com o endereço MAC conectado na porta. O PacketFence recebe esse trap,
verifica se o dispositivo existe em sua base de dados, não existindo ele altera a VLAN
do dispositivo, para a VLAN de registro (VLAN 2). Esse procedimento poderá ser
observado na Figura 37, a seguir:
F IGURA 37 Log com trap indicando novo MAC que é colocado na VLAN de registro
Após a alteração do dispositivo para a VLAN de registro, este solicita configura-

ções ao servidor de DHCP, a fim de se obter de forma automática as configurações.
No momento em que esta solicitação chega ao PacketFence, este por sua vez, verifica
a lista de parâmetros enviados pelo dispositivo em uma mensagem de DHCPDISCO-
VER, compara com a base de assinaturas de DHCP Fingerprint que o mesmo possui,
identificando assim, o sistema operacional do dispositivo. Depois, segue as demais
etapas, conforme demonstrado na Figura 1, até o dispositivo receber a confirmação

do servidor de DHCP, com uma mensagem DHCPACK. Ao receber essa confirmação,
finaliza-se a obtenção das configurações requeridas pelo dispositivo.
Para uma melhor visualização este processo é apresentado na Figura 38, a seguir:
F IGURA 38 Log demonstrando o DHCP Fingerprint

O cliente ao abrir o navegador de Internet e este tentando abrir qualquer site, o

PacketFence redireciona-o para o Captive portal, identifica qual o navegador utilizado
e sua versão, depois redireciona-o para a página de autenticação, como mostra a
Figura 39:
F IGURA 39 Log demonstrando o redirecionamento para o Captive Portal

O cliente deve possuir um cadastro para que este seja utilizado para o registro do
dispositivo. Digitando as informações de usuário e senha no Captive portal e estes
sendo válidos, então, o dispositivo será registrado.
Para uma melhor visualização, a Figura 40 demonstra essa ação:
F IGURA 40 Log demonstrando o registro do dispositivo

A partir do momento em que o dispositivo já estiver registrado, o PacketFence

preparará um pedido de alteração de VLAN, como mostra a Figura 41:
F IGURA 41 Log demonstrando a alteração da VLAN de registro para a VLAN normal

A partir de então, o PacketFence envia uma solicitação com o pedido de alteração

de VLAN na porta, na qual o dispositivo esteja conectado. O switch ao receber essa
solicitação, por sua vez, se preparará para atender a solicitação, de modo que este
iniciará a alteração da VLAN de registro para a VLAN normal (VLAN 10), ou seja, para
a VLAN da rede principal. A Figura 42, demonstra esse processo.
Após a alteração de VLAN, o dispositivo solicitará as configurações ao servidor

de DHCP, para saber o funcionamento, observe a Figura 1, somente depois que o
dispositivo receber a mensagem de DHCPACK, este já estará pronto com as devidas
configurações referentes a VLAN normal, ou seja, a partir deste momento o cliente
poderá acessar a Internet bem como utilizar os outros recursos da rede principal,
como mostra a Figura 43.
F IGURA 42 Log demonstrando recebimento de trap

F IGURA 43 Log demonstrando a comunicação do DHCP

Caso os parâmetros de escaneamento do Nessus estejam configurados e habili-

tados, após o registro do dispositivo, este será verificado pelo Nessus. Neste caso,
somente após a verificação do Nessus é que o PacketFence alterará o dispositivo da
VLAN de registro para a VLAN normal.
Adicionando a violação após o registro, para isto, será apresentado a seguir, a

Figura 44:
F IGURA 44 Log demonstrando uma violação sendo adicionada

A Figura 45, demonstra a alteração da página do Captive Portal para apresentar

as informações ao usuário de que ele está em quarentena e o mesmo será verificado.
F IGURA 45 Log demonstrando o redirecinamento para o Captive Portal

O PacketFence enviará a tarefa para segundo plano, para ser executada pelo Nes-
sus, ou seja, a partir deste momento foi solicitado o escaneamento do dispositivo. Esta
tarefa poderá ser observada na Figura 46.
F IGURA 46 Log demonstrando o envio do escaneamento para segundo plano

A Figura 47, demonstra informações do escaneamento e redirecionamento do cli-

ente para o Captive Portal.
F IGURA 47 Log demonstrando o escaneamento

Finalizando o processo de escaneamento do Nessus. A fim de mostrar esse pro-

cesso, é apresentado a Figura 48.
Após finalizar o escaneamento, a violação é fechada, ou seja, foi verificado se

o dispositivo estava com alguma vulnerabilidade. Posteriormente, é preparado um
pedido de solicitação ao switch para realizar a alteração da VLAN, como mostra a
Figura 49.
Após a alteração da VLAN do dispositivo, o cliente solicita configurações ao servi-

dor de DHCP, a fim de se obter as configurações de forma automática. Este procedi-
mento é o mesmo apresentado na Figura 43.
F IGURA 48 Log demonstrando o fechamento da violação

F IGURA 49 Log demonstrando a alteração de VLAN após o escaneamento no registro

Se ocorrer qualquer violação o PacketFence altera a VLAN do dispositivo para a

VLAN de Isolação (VLAN 3), ou seja, este somente sairá após a correção do problema,
voltando assim para a VLAN normal.
Depois que o dispositivo do cliente não se encontra mais conectado ao switch, o

PacketFence altera a VLAN daquela porta onde o dispositivo do cliente estava conec-
tado, retornando-a para a VLAN 4.
Os dados apresentados na seção 5 até aqui demonstraram os logs de acesso do

servidor PacketFence, a fim de demonstrar o que ocorre ao cliente no momento da
autenticação, é apresentado a Figura 50, esta demonstra o Captive Portal do Packet-
Fence, nesse momento é solicitado usuário e senha, e para completar, será necessá-
rio aceitar o termo de uso, ou seja, as políticas da empresa.
F IGURA 50 Autenticação Captive Portal

A Figura 51, demonstra o escaneamento do Nessus após o registro do dispositivo.
F IGURA 51 Scan do Nessus

A Figura 52, demonstra o Snort em ação, após encontrar uma violação no cliente.
5.1 Tradução 70
F IGURA 52 Quarentena Estabelecida

5.1 Tradução
Como escopo deste trabalho, foi realizado a tradução da documentação da ferra-

menta PacketFence [Inverse 2011], nas versões: 2.2.1, 3.0.2 e 3.0.3. Sendo que a
tradução anexada ao trabalho é a versão 3.0.2.
A fim de contribuir com o projeto PacketFence, foi enviado um e-mail a equipe de

desenvolvimento do projeto, como mostra a Figura 53.
F IGURA 53 Tela do e-mail enviado ao membro do projeto

Um membro da equipe de desenvolvimento do projeto retornou ao e-mail enviado,

como mostra a Figura 54.
5.1 Tradução 71
F IGURA 54 Tela do e-mail de resposta do membro do projeto

A tradução foi aceita e adicionada ao repositório do projeto e também publicada no

site do projeto, ou seja, a tradução faz parte da documentação oficial, como mostra a
Figura 55. Com a publicação da tradução, esta é uma enorme contribuição em idioma
português do Brasil com o projeto e com a comunidade brasileira.
F IGURA 55 Tela retorno ao e-mail de resposta do membro do projeto

72
6 CONSIDERAÇÕES FINAIS
O controle de pontos de redes é algo extremamente importante, pois uma tomada

RJ-45 fêmea ligada a um equipamento de rede (switch) somado com um serviço de
DHCP pode trazer para dentro da rede da organização pessoas com o objetivo de
roubar dados sensíveis ao negócio da empresa. Porém, para fazer esse controle
são necessárias ferramentas que consigam de forma automatizada controlar quem
pode ou não utilizar esse ponto de rede, pois, dependendo da quantidade de pontos
existentes, fica humanamente difícil fazer esse controle.
Para fazer esse controle de forma automatizada, foi pesquisado o funcionamento

da ferramenta PacketFence, os pontos relevantes foram: como a ferramenta atua no
caso de adição de novo dispositivo na rede; como são feitas as varreduras nesse
dispositivo a procura de algum software que possas trazer risco à infraestrutura; e
qual seria a ação caso fosse encontrado algum problema nesse dispositivo. Para que
os objetivos fossem alcançados, foi necessária a construção de um ambiente real,
mas parcialmente virtual para os testes.
Foi aplicado nesse ambiente o conhecimento adquirido com a pesquisa explorató-

ria da documentação do PacketFence e também de outros pesquisados na Internet.
A documentação da ferramenta não explica de forma clara algumas configurações,

porém, como a ferramenta é open source, foi feita uma verificação no código fonte da
mesma para averiguar como seria o funcionamento correto, por exemplo, o modelo
do switch que foi utilizado não está na relação de equipamentos suportados pelo Pac-
ketFence, foi necessário fazer configurações no código fonte para que o mesmo fosse
suportado.
Após as configurações da ferramenta, como demonstrado na seção 4, foi possível

utilizá-la de forma a coibir pessoas não autorizadas ou equipamentos com falhas de
segurança a utilizar a rede.
Esse bloqueio foi alcançado graças a integração das ferramentas Nessus e Snort,
6 CONSIDERAÇÕES FINAIS 73
somado com os protocolos 802.1Q e 802.1X juntamente com o PacketFence. Esse

conjunto de ferramentas integradas foi o necessário para bloquear acessos às portas
do switch utilizado na topologia.
O PacketFence oferece suporte às redes sem fio (Wireless), infelizmente não foi
possível testar as funcionalidades da ferramenta nesse tipo de ambiente. Outro ponto
é o controle de visitante que não foi abordado. Foi explicado que há uma configuração
específica, o que não foi realizado, para que fosse possível realizar esse tipo de con-
trole, pois esse controle é interessante para empresas ou locais onde a rotatividade
de pessoas é constante - este controle requer apenas um simples e rápido cadastro
do usuário que utilizará a rede por um curto período, por exemplo, um vendedor que
queira apenas acessar a Internet para enviar um pedido a empresa na qual trabalha,
esse usuário teria de fazer um pequeno cadastro como visitante, pois, ao tentar aces-
sar qualquer site, ele será redirecionado ao Captive Portal do PacketFence, neste é
possível realizar o cadastro, a partir desse cadastro é gerado um código que poderá
ser enviado, em forma de mensagem, para o celular do usuário e esse código terá
uma validade, o tempo necessário para o vendendor enviar o e-mail com o pedido.
O PacketFence é poderoso recurso open source, ou seja, sem custo de licencia-

mento. O único custo seria a mão de obra para implementação e suporte do mesmo.
Com o conteúdo deste trabalho é possível fazer a instalação e usar a ferramenta

sem dificuldades, pois além de conter o detalhamento da implementação real também
há documentação da ferramenta em anexo e totalmente em português.
Sendo sugerido para futuros trabalhos quanto à ferramenta a uma maior explora-
ção da ferramenta PacketFence e seu uso em no controle de acesso à rede sem-fio,
segurança no controle de acesso à rede, exploração dele para uma integração total
de controle à rede e integração do PacketFence no controle de acesso aos visitantes.
74
Referências
[Aboba, Simon e Eronen 2008]ABOBA, B.; SIMON, D.; ERONEN, P. Extensible

Authentication Protocol (EAP) Key Management Framework. IETF, ago. 2008.
RFC 5247 (Proposed Standard). (Request for Comments, 5247). Disponível em:
<http://www.ietf.org/rfc/rfc5247.txt>.
[Alexander e Droms 1997]ALEXANDER, S.; DROMS, R. DHCP Options and BOOTP

Vendor Extensions. IETF, mar. 1997. RFC 2132 (Draft Standard). (Request for Com-
ments, 2132). Updated by RFCs 3442, 3942, 4361, 4833, 5494. Disponível em:
[Austein e Saperia 1994]AUSTEIN, R.; SAPERIA, J. DNS Server MIB Extensions.

IETF, maio 1994. RFC 1611 (Historic). (Request for Comments, 1611). Disponível
em: <http://www.ietf.org/rfc/rfc1611.txt>.
[Case et al. 1990]CASE, J. et al. Simple Network Management Protocol (SNMP). IETF,
maio 1990. RFC 1157 (Historic). (Request for Comments, 1157). Disponível em:
[Case et al. 1996]CASE, J. et al. Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2). IETF, jan. 1996. RFC 1907 (Draft
Standard). (Request for Comments, 1907). Obsoleted by RFC 3418. Disponível em:
[Case et al. 1996]CASE, J. et al. Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2). IETF, jan. 1996. RFC 1905 (Draft Stan-
dard). (Request for Comments, 1905). Obsoleted by RFC 3416. Disponível em:
[Case et al. 1996]CASE, J. et al. Transport Mappings for Version 2 of the Simple
Network Management Protocol (SNMPv2). IETF, jan. 1996. RFC 1906 (Draft Stan-
dard). (Request for Comments, 1906). Obsoleted by RFC 3417. Disponível em:
[Claise 2004]CLAISE, B. Cisco Systems NetFlow Services Export Version 9. IETF,

out. 2004. RFC 3954 (Informational). (Request for Comments, 3954). Disponível em:
[Deraison 2004]DERAISON, R. Nessus Network Auditing. 2. ed. Rockland-MA: Syn-

gress, 2004.
[Douglas e Kevin 2001]DOUGLAS, M. R.; KEVIN, S. J. SNMP Essencial. 1. ed. Rio de

Janeiro-RJ: Campus, 2001.
Referências 75
[Droms 1997]DROMS, R. Dynamic Host Configuration Protocol. IETF, mar. 1997. RFC
2131 (Draft Standard). (Request for Comments, 2131). Updated by RFCs 3396, 4361,
5494. Disponível em: <http://www.ietf.org/rfc/rfc2131.txt>.
[Edwards 2008]EDWARDS, J. The essential guide to nac. IT Security,
Jun 2008. Disponível em: <http://www.itsecurity.com/features/
essential-guide-nac-062308/>. Acesso em: 10 Out. 2011.
[FingerBank 2011]FINGERBANK. DHCP fingerprints. Mar 2011. Disponível em:
<http://www.fingerbank.org>. Acesso em: 27 Set. 2011.
[H3C Technologies 2011]H3C TECHNOLOGIES. 20-802.1X Configuration. 2011.
Disponível em: <http://www.h3c.com/portal/Technical_Support___Documents/
Technical_Documents/Switches/H3C_S5120_Series_Switches/Configuration/
Operation_Manual/H3C_S5120-SI_CG-Release_1101-6W105/201108/723588_1285_
0.htm>. Acesso em: 30 Out. 2011.
[Harris, Jackson e Petty 1987]TELELOGIC, INC. William J. Harris, Joseph M. Jackson
e David C. Petty. Automatic dialer for telephone network access control. 1987. US
4447676, 08 Mai. 1984.
[INTEROP LABS 2006]INTEROP LABS. What is NAC. May 2006. Disponível em:
<http://www.interop.com/archive/pdfs/NAC.pdf>. Acesso em: 19 Set. 2011.
[Inverse 2011]INVERSE. PacketFence Administration Guide. Out. 2011. Disponível
em: <http://www.packetfence.org/downloads/PacketFence/doc/PacketFence_
Administration_Guide-3.0.2.pdf>.
[INVERSE INC. 2011]INVERSE INC. Site PacketFence. Jul 2011. Disponível em:
<http://www.packetfence.org>. Acesso em: 23 Jul. 2011.
[JANET 2011]JANET. Extesible Authentication Protocol (EAP). 2011. Disponível
em: <http://www.ja.net/documents/publications/factsheets/065-eap.pdf>.
Acesso em: 28 Out. 2011.
[Leelanivas, Rekhter e Aggarwal 2003]LEELANIVAS, M.; REKHTER, Y.; AGGARWAL,
R. Graceful Restart Mechanism for Label Distribution Protocol. IETF, fev. 2003.
[Leinen 2004]LEINEN, S. Evaluation of Candidate Protocols for IP Flow Information
Export (IPFIX). IETF, out. 2004. RFC 3955 (Informational). (Request for Comments,
3955). Disponível em: <http://www.ietf.org/rfc/rfc3955.txt>.
[Manlio 2009]MANLIO, F. NAC 2.0: A new model for a more secure future.
Dec 2009. Disponível em: <http://www.articlesbase.com/security-articles/
nac-20-a-new-model-for-a-more-secure-future-1579991.html>. Acesso em: 20
Set. 2011.
[McCloghrie e Rose 1991]MCCLOGHRIE, K.; ROSE, M. Management Information
Base for Network Management of TCP/IP-based internets:MIB-II. IETF, mar. 1991.
RFC 1213 (Standard). (Request for Comments, 1213). Updated by RFCs 2011, 2012,
2013. Disponível em: <http://www.ietf.org/rfc/rfc1213.txt>.
Referências 76
[Prado 1998]PRADO, F. F. d. Trabalho sobre a norma técnica IEEE - 802.1q – Vir-

tual LANs. 1998. Disponível em: <http://www.gta.ufrj.br/grad/98_2/fernando/
fernando.html>. Acesso em: 18 Nov. 2011.
[Rigney et al. 2000]RIGNEY, C. et al. Remote Authentication Dial In User Ser-

vice (RADIUS). IETF, jun. 2000. RFC 2865 (Draft Standard). (Request for
Comments, 2865). Updated by RFCs 2868, 3575, 5080. Disponível em:
[Roesch 1999]ROESCH, M. Lightweight Intrusion Detection For Networks. 1999.

Disponível em: <http://www.usenix.org/event/lisa99/full_papers/roesch/
roesch.pdf>. Acesso em: 15 Nov. 2011.
[Sahita et al. 2010]SAHITA, R. et al. PB-TNC: A Posture Broker (PB) Proto-

col Compatible with Trusted Network Connect (TNC). IETF, mar. 2010. RFC
5793 (Proposed Standard). (Request for Comments, 5793). Disponível em:
[Sangster e Narayan 2010]SANGSTER, P.; NARAYAN, K. PA-TNC: A Posture Attribute

(PA) Protocol Compatible with Trusted Network Connect (TNC). IETF, mar. 2010.
[Stewart 2007]STEWART, R. Stream Control Transmission Protocol. IETF, set. 2007.

RFC 4960 (Proposed Standard). (Request for Comments, 4960). Updated by RFCs
6096, 6335. Disponível em: <http://www.ietf.org/rfc/rfc4960.txt>.
[UFRJ 2011]UFRJ, G. Management Information Base (MIB). 2011. Disponível em:

<http://www.gta.ufrj.br/grad/04_1/snmp/mib.htm>. Acesso em: 10 Out. 2011.
[UFRJ 2011]UFRJ, G. RADIUS. 2011. Disponível em: <http://www.gta.ufrj.br/

grad/08_1/radius/Introduo.html>. Acesso em: 15 Out. 2011.
[Wikipédia 2005]WIKIPéDIA. SELinux. Nov. 2005. Disponível em: <http://pt.

wikipedia.org/wiki/SELinux>. Acesso em: 20 Nov. 2011.
[Zampiello et al. 2007]SBC KNOWLEGDE VENTURES LP. Geoffrey Zampiello, Jimmy

Forsyth, Andy Prince e Taso Devetzis. Scalable Captive Portal Redirect. 2007. US
0214265, 13 Set. 2007.
77
APÊNDICE A -- Instalando o PacketFence
A fim de realizar a instalação do PacketFence, deve-se inicialmente possuir uma

instalação de algum sistema operacional suportado pelo PacketFence. São suporta-
dos os seguintes sistemas operacionais nas arquiteturas i386 ou x86_64:
- Red Hat Enterprise Linux (RHEL) 5.x/6.x Server;
- Community ENTerprise Operating System (CentOS) 5.x/6.x
O sistema operacional escolhido para a realização da instalação do PacketFence

foi o CentOS 6 x86_64. Partindo do pressuposto que foi realizado uma instalação
limpa com a opção "minimal", ou seja, somente o básico deste sistema operacional.
A seguir será descrito os procedimentos para obter a instalação do PacketFence com
todos os softwares necessários para o seu funcionamento.
A.1 Procedimentos para Instalação
1. Deve-se baixar o pacote rpmforge do repositório REPOFORGE, este pacote

contém configurações para adicionar ao YUM o repositório repoforge.
wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-
2.el6.rf.x86_64.rpm
2. Instalar o pacote baixado anteriormente.
rpm -ivh rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
3. Desabilite o repositório padrão repoforge para isso edite o arquivo /etc/yum.rep-

os.d/rpmforge.repo, deixando a diretiva enabled = 0.
A.1 Procedimentos para Instalação 78
[rpmforge]
name=RHEL $releasever - RPMforge.net - dag
baseurl=http://apt.sw.be/redhat/el6/en/$basearch/rpmforge
mirrorlist=http://apt.sw/be/redhat/el6/en/mirrors-rpmforge
enabled=0
protect=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmforge-dag
gpgcheck=1
4. Baixe o pacote EPEL do repositório fedoraproject.
wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-
5.noarch.rpm
5. Instalar o pacote EPEL baixado anteriormente.
rpm -ivh epel-release-6-5.noarch.rpm
6. Crie um arquivo de repositório do PacketFence, em /etc/yum.repos.d/packet-

fence.repo com as informações a seguir:
[PacketFence]
name=PacketFence Repository
baseurl=http://inverse.ca/downloads/PacketFence/RHEL$releasever/$basearch
enabled=0
gpgcheck=0
7. Atualize a lista de repositório.
yum --enablerepo=PacketFence,rpmforge update
8. Instalação do PacketFence completo. A instalação completa, contará com os

seguintes softwares: Banco de Dados Mysql, DNS, DHCP, RADIUS e Snort.
yum --enablerepo=PacketFence,rpmforge groupinstall Packetfence-complete

9. Lista de Pacotes e dependências:

Pacote Arquitetura Versão Repositório Tamanho
Instalação:
bind x86_64 32:9.7.0-5.P2.el6_0.1 updates 3.5 M
dhcp x86_64 12:4.1.1-12.P1.el6_0.4 updates 887 K
freeradius x86_64 2.1.11-1.el6 PacKetFence 2.4 M
freeradius-perl x86_64 2.1.11-1.el6 PacKetFence 82 K
freeradius-utils x86_64 2.1.11-1.el6 PacKetFence 150 K
mysql-server x86_64 5.1.52-1.el6_0.1 updates 8.1 M
pacKetfence noarch 3.0.2-1.el6 PacKetFence 6.3 M
pacKetfence-freeradius2 noarch 3.0.2-1.el6 PacKetFence 23 K
snort x86_64 1:2.9.1.2-1.el6 PacKetFence 2.2 M
Dependências:
apr x86_64 1.3.9-3.el6_0.1 updates 124 K
apr-util x86_64 1.3.9-3.el6_0.1 updates 87 K
apr-util-ldap x86_64 1.3.9-3.el6_0.1 updates 15 K
bind-libs x86_64 32:9.7.0-5.P2.el6_0.1 updates 829 K
cairo x86_64 1.8.8-3.1.el6 base 309 K
cvs x86_64 1.11.23-11.el6_0.1 updates 713 K
daq x86_64 0.6.2-1.el6 PacKetFence 135 K
dejavu-fonts-common noarch 2.30-2.el6 base 59 K
dejavu-lgc-sans-mono-fonts noarch 2.30-2.el6 base 393 K
dejavu-sans-mono-fonts noarch 2.30-2.el6 base 450 K
fontconfig x86_64 2.8.0-3.el6 base 186 K
fontpacKages-filesystem noarch 1.41-1.1.el6 base 8.8 K
freeradius-mysql x86_64 2.1.11-1.el6 PacKetFence 64 K
freetype x86_64 2.3.11-6.el6_0.2 updates 359 K
gettext x86_64 0.17-16.el6 base 1.8 M
httpd x86_64 2.2.15-5.el6.centos base 811 K
httpd-tools x86_64 2.2.15-5.el6.centos base 68 K
libX11 x86_64 1.3-2.el6 base 582 K
libX11-common noarch 1.3-2.el6 base 188 K
libXau x86_64 1.0.5-1.el6 base 22 K
libXft x86_64 2.1.13-4.1.el6 base 49 K
libXpm x86_64 3.5.8-2.el6 base 59 K
libXrender x86_64 0.9.5-1.el6 base 27 K
libdnet x86_64 1.12-6.el6 epel 28 K
Continuação:
libedit x86_64 2.11-4.20080712cvs.1.el6 base 74 K
libgomp x86_64 4.4.4-13.el6 base 108 K
libjpeg x86_64 6b-46.el6 base 134 K
libpcap x86_64 14:1.0.0-6.el6 base 126 K
libpng x86_64 2:1.2.44-1.el6 base 180 K
libthai x86_64 0.1.12-3.el6 base 183 K
libtool-ltdl x86_64 2.2.6-15.5.el6 base 44 K
libxcb x86_64 1.5-1.el6 base 100 K
lm_sensors-libs x86_64 3.1.1-10.el6 base 37 K
mailcap noarch 2.1.31-1.1.el6 base 27 K
mod_perl x86_64 2.0.4-10.el6 base 3.2 M
mod_ssl x86_64 1:2.2.15-5.el6.centos base 85 K
mysql x86_64 5.1.52-1.el6_0.1 updates 889 K
net-snmp x86_64 1:5.5-27.el6_0.1 updates 297 K
net-snmp-libs x86_64 1:5.5-27.el6_0.1 updates 1.5 M
pango x86_64 1.28.1-3.el6_0.5 updates 351 K
perl x86_64 4:5.10.1-115.el6 base 10 M
perl-Apache-Htpasswd noarch 1.8-3.el6 epel 16 K
perl-AppConfig noarch 1.66-6.el6 base 87 K
perl-Authen-Krb5-Simple x86_64 0.42-1.el6.rf rpmforge 34 K
perl-Authen-SASL noarch 2.13-2.el6 base 51 K
perl-BSD-Resource x86_64 1.29.03-3.el6 base 35 K
perl-Bit-Vector x86_64 7.1-2.el6 base 169 K
perl-CGI x86_64 3.49-115.el6 base 191 K
perl-CGI-Session noarch 4.35-5.el6 base 120 K
perl-Cache-Cache noarch 1.06-2.el6 epel 89 K
perl-Carp-Clan noarch 6.03-2.el6 base 25 K
perl-Class-Accessor noarch 0.31-6.1.el6 base 26 K
perl-Class-Accessor-Fast-Contained noarch 1.01-1.el6.rf rpmforge 9.9 K
perl-Class-Data-Inheritable noarch 0.08-3.1.el6 base 10 K
perl-Class-Gomor noarch 1.02-1.el6.rf rpmforge 23 K
perl-Compress-Raw-Zlib x86_64 2.023-115.el6 base 66 K
perl-Compress-Zlib x86_64 2.020-115.el6 base 42 K
perl-Config-IniFiles noarch 2.68-1.el6 epel 46 K
perl-Convert-ASN1 noarch 0.22-1.el6 base 43 K
Continuação:
perl-Crypt-DES x86_64 2.05-9.el6 epel 19 K
perl-Crypt-GeneratePassword noarch 0.03-16.el6 epel 213 K
perl-Crypt-Rijndael x86_64 1.09-2.el6 epel 31 K
perl-DBD-MySQL x86_64 4.013-3.el6 base 134 K
perl-DBD-Pg x86_64 2.15.1-3.el6 base 197 K
perl-DBI x86_64 1.609-4.el6 base 705 K
perl-Data-HexDump noarch 0.02-1.2.el6.rf rpmforge 8.8 K
perl-Data-PhrasebooK noarch 0.29-1.el6.rf rpmforge 60 K
perl-Data-PhrasebooK-Loader-YAML noarch 0.09-1.el6.rf rpmforge 24 K
perl-Date-Manip noarch 5.54-4.el6 base 177 K
perl-Devel-StacKTrace noarch 1:1.22-4.el6 base 26 K
perl-Digest-HMAC noarch 1.01-22.el6 base 22 K
perl-Digest-SHA1 x86_64 2.12-2.el6 base 49 K
perl-Email-Date-Format noarch 1.002-5.el6 base 16 K
perl-Error noarch 1:0.17015-4.el6 base 29 K
perl-Exception-Class noarch 1.29-1.1.el6 base 37 K
perl-ExtUtils-MaKeMaKer x86_64 6.55-115.el6 base 289 K
perl-ExtUtils-ParseXS x86_64 1:2.2003.0-115.el6 base 41 K
perl-File-Tail noarch 0.99.3-8.el6 epel 23 K
perl-FreezeThaw noarch 0.45-5.el6 base 19 K
perl-GSSAPI x86_64 0.26-5.el6 base 64 K
perl-HTML-Parser x86_64 3.64-2.el6 base 109 K
perl-HTML-Tagset noarch 3.20-4.el6 base 17 K
perl-IO-Compress-Base x86_64 2.020-115.el6 base 65 K
perl-IO-Compress-Zlib x86_64 2.020-115.el6 base 132 K
perl-IO-SocKet-SSL noarch 1.31-2.el6 base 69 K
perl-IO-Tty x86_64 1.08-3.el6 epel 39 K
perl-IPC-Cmd x86_64 1:0.56-115.el6 base 42 K
perl-IPC-ShareLite x86_64 0.17-1.el6.rf rpmforge 63 K
perl-IPTables-ChainMgr noarch 0.9-1 PacKetFence 17 K
perl-IPTables-Parse noarch 0.7-4.el6 epel 16 K
perl-IPTables-libiptc x86_64 0.51-2.el6.rf rpmforge 86 K
perl-JSON noarch 2.15-5.el6 base 97 K
perl-LDAP noarch 1:0.40-1.el6 base 354 K
perl-List-MoreUtils x86_64 0.22-10.el6 base 53 K
Continuação:
perl-Locale-MaKetext-Simple x86_64 1:0.18-115.el6 base 27 K
perl-Log-Dispatch noarch 2.27-1.el6 epel 71 K
perl-Log-Dispatch-FileRotate noarch 1.19-4.el6 epel 24 K
perl-Log-Log4perl noarch 1.30-1.el6 epel 392 K
perl-MIME-Lite noarch 3.027-2.el6 base 82 K
perl-MIME-Lite-TT noarch 0.02-1.el6.rf rpmforge 7.7 K
perl-MIME-Types noarch 1.28-2.el6 base 32 K
perl-Mail-Sender noarch 0.8.16-3.el6 epel 54 K
perl-Mail-Sendmail noarch 0.79-12.el6 epel 28 K
perl-MailTools noarch 2.04-4.el6 base 101 K
perl-Math-Base85 noarch 0.2-6.el6 epel 13 K
perl-Module-Load x86_64 1:0.16-115.el6 base 24 K
perl-Module-Load-Conditional x86_64 0.30-115.el6 base 30 K
perl-Module-Pluggable x86_64 1:3.90-115.el6 base 36 K
perl-Net-Appliance-PhrasebooK noarch 1.8-1.el6.rf rpmforge 17 K
perl-Net-Appliance-Session noarch 1.36-1.el6.rf rpmforge 121 K
perl-Net-Frame noarch 1.07-1 PacKetFence 36 K
perl-Net-Frame-Simple noarch 1.04-1 PacKetFence 14 K
perl-Net-IPv4Addr noarch 0.10-6.el6 epel 16 K
perl-Net-IPv6Addr noarch 0.2-6.el6 epel 13 K
perl-Net-Interface x86_64 1.011-1.el6.rf rpmforge 132 K
perl-Net-LibIDN x86_64 0.12-3.el6 base 35 K
perl-Net-MAC noarch 1.5-1.el6.rf rpmforge 21 K
perl-Net-MAC-Vendor noarch 1.18-1.el6.rf rpmforge 14 K
perl-Net-NetmasK noarch 1.9015-8.el6 epel 25 K
perl-Net-Pcap x86_64 0.16-2.el6 epel 80 K
perl-Net-SNMP noarch 5.2.0-4.el6 epel 100 K
perl-Net-SSLeay x86_64 1.35-9.el6 base 173 K
perl-Net-Telnet noarch 3.03-11.el6 base 56 K
perl-Net-Write noarch 1.05-1 PacKetFence 16 K
perl-Params-ChecK x86_64 1:0.26-115.el6 base 32 K
perl-Params-Validate x86_64 0.92-3.el6 base 75 K
perl-Parse-Nessus-NBE noarch 1.1-1 PacKetFence 10 K
perl-Parse-RecDescent noarch 1.965-1.el6 epel 189 K
perl-Pod-Escapes x86_64 1:1.04-115.el6 base 29 K
Continuação:
perl-Pod-POM noarch 0.25-2.el6 base 75 K
perl-Pod-Simple x86_64 1:3.13-115.el6 base 208 K
perl-RadiusPerl noarch 0.15-1.el6.rf rpmforge 19 K
perl-Readonly noarch 1.03-11.el6 base 22 K
perl-Readonly-XS x86_64 1.05-3.el6 base 14 K
perl-Regexp-Common noarch 2010010201-2.el6.rf rpmforge 168 K
perl-SOAP-Lite noarch 0.710.10-2.el6 base 328 K
perl-SocKet6 x86_64 0.23-3.el6 base 23 K
perl-Template-ToolKit x86_64 2.22-5.el6 base 1.3 M
perl-TermReadKey x86_64 2.30-10.el6 base 31 K
perl-Test-Harness x86_64 3.17-115.el6 base 228 K
perl-Test-Simple x86_64 0.92-115.el6 base 109 K
perl-Text-CSV noarch 1.21-1.el6.rf rpmforge 50 K
perl-Text-CSV_XS x86_64 0.85-1.el6 epel 71 K
perl-Text-Iconv x86_64 1.7-6.el6 base 22 K
perl-Thread-Conveyor noarch 0.17-1.el6.rf rpmforge 28 K
perl-Thread-Conveyor-Monitored noarch 0.12-1.el6.rf rpmforge 20 K
perl-Thread-Pool noarch 0.32-1.el6.rf rpmforge 39 K
perl-Thread-Serialize noarch 0.11-1.el6.rf rpmforge 11 K
perl-Thread-Tie noarch 0.12-1.el6.rf rpmforge 34 K
perl-Time-HiRes x86_64 4:1.9721-115.el6 base 45 K
perl-TimeDate noarch 1:1.16-11.1.el6 base 34 K
perl-Try-Tiny noarch 0.09-1.el6.rf rpmforge 18 K
perl-UNIVERSAL-require noarch 0.13-1.el6.rf rpmforge 11 K
perl-URI noarch 1.40-2.el6 base 117 K
perl-XML-DOM noarch 1.44-7.el6 base 136 K
perl-XML-Filter-BufferText noarch 1.01-8.el6 base 9.6 K
perl-XML-LibXML x86_64 1:1.70-5.el6 base 364 K
perl-XML-NamespaceSupport noarch 1.10-3.el6 base 17 K
perl-XML-Parser x86_64 2.36-7.el6 base 224 K
perl-XML-RegExp noarch 0.03-7.el6 base 9.8 K
perl-XML-SAX noarch 0.96-7.el6 base 78 K
perl-XML-SAX-Writer noarch 0.50-8.el6 base 24 K
perl-YAML noarch 0.70-4.el6 base 81 K
perl-devel x86_64 4:5.10.1-115.el6 base 419 K
Continuação:
perl-gettext x86_64 1.05-16.el6 epel 21 K
perl-libs x86_64 4:5.10.1-115.el6 base 576 K
perl-libwww-perl noarch 5.833-2.el6 base 387 K
perl-load noarch 0.19-1.el6.rf rpmforge 26 K
perl-suidperl x86_64 4:5.10.1-115.el6 base 46 K
perl-version x86_64 3:0.77-115.el6 base 48 K
php x86_64 5.3.2-6.el6_0.1 updates 1.1 M
php-cli x86_64 5.3.2-6.el6_0.1 updates 2.2 M
php-common x86_64 5.3.2-6.el6_0.1 updates 516 K
php-gd x86_64 5.3.2-6.el6_0.1 updates 103 K
php-ldap x86_64 5.3.2-6.el6_0.1 updates 35 K
php-pear noarch 1:1.9.0-2.el6 base 391 K
php-pear-Auth-SASL noarch 1.0.4-1.el6 epel 12 K
php-pear-Log noarch 1.12.7-1.el6 epel 58 K
php-pear-MDB2 noarch 2.5.0-0.3.b3.el6 epel 125 K
php-pear-Mail noarch 1.2.0-1.el6 epel 29 K
php-pear-Net-SMTP noarch 1.6.1-1.el6 epel 22 K
php-pear-Net-SocKet noarch 1.0.10-1.el6 epel 12 K
php-pear-db noarch 1.7.13-2.el6.rf rpmforge 101 K
pixman x86_64 0.18.4-1.el6_0.1 updates 146 K
pKgconfig x86_64 1:0.23-9.1.el6 base 70 K
postgresql-libs x86_64 8.4.7-1.el6_0.1 updates 193 K
rrdtool x86_64 1.3.8-6.el6 base 293 K
rrdtool-perl x86_64 1.3.8-6.el6 base 36 K
zlib-devel x86_64 1.2.3-25.el6 base 43 K
10. Baixe o nessus em http://www.tenable.com/products/nessus/nessus-down-

load-agreement e depois instale-o.
rpm -ivh Nessus-4.4.1-es6.x86_64.rpm
11. Obtenha um serial registrando o produto em http://www.tenable.com/prod-

ucts/nessus/nessus-homefeed, posteriormente ative o serial com o comando, a se-
guir:
/opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX-XXXX

Após a execução do comando demonstrado anteriormente, o nessus vai baixar os

plugins mais recentes, a fim de deixar o software atualizado.
O comando a seguir, é utilizado para adicionar usuários com privilégios de admi-

nistrador ou não ao Nessus.
/opt/nessus/sbin/nessus-adduser
86
ANEXO A -- Tradução da Documentação do

PacketFence

Controle de Acesso A Rede Com PacketFenc PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Controle de Acesso A Rede Com PacketFenc PDF

Enviado por

Direitos autorais:

Formatos disponíveis

FACULDADE DE TECNOLOGIA SENAI DE DESENVOLVIMENTO

André Luiz Ramos de Souza

Controle de Acesso à Rede

Controle de Acesso à Rede

Trabalho de conclusão de curso apresen-

André Luiz Ramos de Souza

Controle de Acesso à Rede

Trabalho de conclusão de curso apresentado à Faculdade de Tecnologia SENAI de

Prof. MSc. Maurício Severich

Prof. MSc. Rafael Leal Martins

Prof. MSc. Diogo Nunes de Oliveira

Aos nossos pais, esposas, filhos e à

Agradecemos a Deus em primeiro lugar, que nos deu a oportunidade de ini-

"As pessoas que são loucas o

Comercial Pense Diferente da Apple,

Este trabalho tem como escopo demonstrar através de implementação a utilização

Lista de Siglas xiv

2 FERRAMENTAS, PADRÕES, PROTOCOLOS E TECNOLOGIAS 5

2.1 O QUE É NETWORK ACCESS CONTROL ? . . . . . . . . . . . . . . . . . 5

2.1.1 Tipos de NAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.2 NAC: Primeira Geração . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.3 NAC: Segunda Geração . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.4 O que é Network Access Protection ? . . . . . . . . . . . . . . . . . . . 8

2.1.5 O que é Network Admission Control ? . . . . . . . . . . . . . . . . . . 8

2.2 DYNAMIC HOST CONFIGURATION PROTOCOL . . . . . . . . . . . . . . 9

2.2.1 DHCP Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1.1 Como Funciona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 CAPTIVE PORTAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.5 IEEE 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.5.1 Extensible Authentication Protocol . . . . . . . . . . . . . . . . . . . . 17

2.6 SIMPLE NETWORK MANAGEMENT PROTOCOL . . . . . . . . . . . . . . 19

2.7 NETFLOW / IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.8 IEEE 802.1Q . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.9 INTRUSION DETECTION SYSTEM . . . . . . . . . . . . . . . . . . . . . . 24

3.1 O QUE É PACKETFENCE ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.1 Visão Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1.2 Modos PacketFence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.3 Integração Wireless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.4 Registro de Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1.5 Detecção de Atividade Anormal . . . . . . . . . . . . . . . . . . . . . . 31

3.1.6 Remediação de Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.7 Gerenciamento Baseado em Linha de Comando e Web . . . . . . . . 31

3.1.8 Gerenciamento Flexível de VLAN . . . . . . . . . . . . . . . . . . . . . 32

3.1.9 Tipos de Violação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.1.10 Registro Automático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.1.12 Acesso a Visitantes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 CONFIGURAÇÃO DE HARDWARE . . . . . . . . . . . . . . . . . . . . . . 35

4.2 MODELO DE TOPOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3.1 Interface de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3.5 Configuração do Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.5.1 Modo Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.3.5.2 Modo 802.1x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.3.7 Acesso à Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.8 Habilitando o Snort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3.9 Habilitando o Nessus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Apêndice A -- Instalando o PacketFence 77

A.1 Procedimentos para Instalação . . . . . . . . . . . . . . . . . . . . . . . . . 77

Anexo A -- Tradução da Documentação do PacketFence 86

FIGURA 1 – Etapas envolvidas em uma comunicação entre o cliente e o

FIGURA 2 – Pacote do tipo DHCP Discover . . . . . . . . . . . . . . . . . . 12

FIGURA 3 – Lista de parâmetros de um DHCP Discover . . . . . . . . . . . 12

FIGURA 5 – EAPOL Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

FIGURA 6 – EAPOL Termination . . . . . . . . . . . . . . . . . . . . . . . . 16