Instituto Superior de Engenharia de Lisboa

Instituto Superior de Engenharia de Lisboa Departamento de Engenharia Electrónica e Telecomunicações e de Computadores IRS Integração de Redes e Serviços (2011 2012) Docente: Pedro Ribeiro Grupo 1 Marco Jorge 33572 [MEIC]

Índice Remissivo 1 1ª Fase 6 3 3ª Fase 14 B Bibliografia 37 C Conclusão 36 D Diferentes fases do trabalho 5 E Estrutura da Rede 6 I Introdução 3 ISEL Índice Remissivo 2

Introdução Foi proposto o desafio de elaborar um trabalho na cadeira de IRS (integração redes e serviços), o qual consiste em criar um router, através da instalação do sistema operativo Gentoo(virtualizado). Este sistema operativo, serve de comunicação com a rede pública e interna do ISEL. Nas várias fases do trabalho, foi necessário configurar firewall s, protocolos e serviços de rede (OSPF, DNS, DHCP, RADIUS), tudo com a ajuda de um PC, a correr uma VM um router e um AP, descrição sumárias das várias fases: - Instalação de um software de virtualização (oracle virtual box) e configuração do sistema operativo (Gentoo) - Instalação da ferramenta BIND, e testes de DNS - Permitir o acesso á internet tanto na máquina Linux, como na Windows - Instalação de uma firewall(netfilter) e sua parametrização - Instalação de Radius e testes Linux / Windows - Configuração de um router para testes de Radius - Configuração de uma AP(access point) também com o objectivo de testar o acesso Radius. Software e Hardware utilizado Para o desenvolvimento deste trabalho, foram usadas várias ferramentas, tanto a nível de software como de hardware. O software utilizado foi o seguinte: Putty (acesso routers e VM) Oracle Virtual Box (virtualização de sistemas operativos) Dig (ferramenta de diagnóstico para DNS) Bind (ferramenta que permite a instalação e configuração de DNS) Quagga (ferramenta que permite efectuar configurações de routing em TCP/IP) IP Tables NetFilter (software que permite a criação de uma firewall em Linux) TCPDump (filtragem de pacotes TCP/IP, em Linux) ISEL Introdução 3

A nível de Hardware foram utilizados os seguintes equipamentos: ROUTER Cisco AP Cisco Portátil e PC Os equipamentos acima, permitiram criar uma rede, na qual todo o trabalho se processaria, implementando assim as várias fases propostas no enunciado da cadeira. ISEL Software e Hardware utilizado 4

Preparação do laboratório O trabalho é composto por várias fases, cada uma delas com vários objectivos, o enunciado do trabalho descreve todas essas fases bem como os objectivos a atingir. Para a criação da rede, foram distribuídos blocos de endereços pelos vários grupos, no meu caso foi-me atribuído o bloco 192.62.202.78/28, o que permite ficar com os seguintes endereços: IP Router: 10.62.202.78 (rede interna) IP Rede Externa: 10.62.75.131 Range de IP s a atríbuir aos Hosts 10.62.202.65-10.62.202.78 SubNet Mask 255.255.255.240 Subnet ID 10.62.202.64 Endereço de BroadCast 10.62.202.79 ISEL Preparação do laboratório 5

Desenho da Rede Basicamente o desenho simples da rede encontra-se na figura 1. Representa o equipamento a correr o Windows, e no mesmo uma VM a correr o sistema operativo Gentoo, que simula um router. Podemos observar, no desenho como as placas de rede criadas se encontram atribuídas, ou seja a eth1 é a nossa placa interna, e a eth0 será a placa externa, que fará a comunicação com os switches do ISEL. Figura 1 Desenho da rede Interface PC Laboratório ISEL Eth1 Eth0 Defaut Gateway PC Router Gentoo Switch ISEL 1ª Fase O trabalho começou pela instalação de um sistema operativo virtualizado (Gentoo), para a instalação desta VM(virtual machine), foi necessário o ficheiro de instalação, fornecido pelo docente da cadeira. Foi também usado um ficheiro já com algumas configurações base do Linux make.conf. Já terminada a instalação foi configurada uma placa de rede em modo NAT, para efectuar as primeiras configurações no Gentoo. Vários parâmetros de configuração tiveram que ser introduzidos, durante a instalação deste Sistema Operativo, (compatibilização com o CPU, estrutura de filesystem), optou-se pelo EXT4, devido a este ter uma maior performance, mais fiável e mais opções de configuração relativamente ao EXT3. Na imagem abaixo podemos ver a estrutura de filesystem da VM (Gentoo). A placa configurada na VM, está programada para obter IP a partir do DHCP da rede do ISEL. ISEL Desenho da Rede 6

Figura 2 - Estrutura de FileSystem do Gentoo Estrutura e tamanho das partições: Partição de Root: /dev/root [4,4 GB] Partição de Boot: /dev/sda1 [31 MB] Partição de SWAP: /dev/swap [500MB] Para a elaboração da 1ª fase, necessitamos apenas de um portátil a correr a VM com o Gentoo e uma ligação á rede do Isel, abaixo encontra-se o desenho da rede: Figura 3 Desenho da rede na 1ª fase ISEL 7

2ª Fase Nesta fase foi adicionada uma segunda placa na VM, em modo de host only e a primeira placa passou para o modo Bridged. Procedeu-se também á configuração do DHCP na VM, estas configurações foram efectuadas no Virtual Box, com as seguintes configurações: IP DHCP Server: 192.62.202.77 Range IP s atribuir ao DHCP: 192.62.202.66 69 Numa primeira configuração, foi colocada a placa ethernet do Windows configurada, para que parte do tráfego fosse redireccionado para o Gentoo, nomeadamente foi configurada na default gateway o IP do router e no DNS. Assim conseguimos testar os pedidos de DNS, acessos á internet, entre outros no Windows. Desta forma, configurouse a placa ethernet do Windows com o IP (192.62.202.76), respectiva netmask (255.255.255.240), a default gateway e DNS com o IP do Router Gentoo (10.62.202.78). Figura 4 Configuração ipv4 (placa em modo host only) ISEL 2ª Fase 8

Nesta fase foi também instalado o software BIND, este funciona como um servidor de DNS. O BIND (Berkeley Internet Name Domain )nasceu nos anos 80, desenvolvido na universidade da Califórnia, é uma implementação completa de um sistema DNS (Domain Name System), ou seja consegue efectuar resoluções de nome - IP, consegue também efectuar queries a serviços (mail, ns, entre outros). Devido a ser muito robusto e fiável, é o sistema de DNS mais usado em todo o mundo. O BIND encontra-se divido em 3 componentes Chave: Domain Name System Server: programa denominado de named, responde a pedidos DNS e fornece um serviço de DNS na internet, mas para tal, tem que ser configurados correctamente os domain names. O DNSS é o deamon que corre o servidor de DNS. Domain Name System Resolver: programa que resolve pedidos de domain names e respectivos hosts através de queries ao nameserver, e responde de acordo com o que se encontra configurado no nameserver. Este programa facilita o processo de resolver domain names e hosts em IP s, utiliza o o ficheiro resolv.conf para tal. Additional Software Tools: Ferramentas para efectuar testes ás configurações de DNS, entre elas encontra-se uma muito importante e usada nesta fase denominada de dig. Podemos verificar na figura 5, o processo de instalação do software BIND. Através do comando: emerge -av bind Figura 5 Instalação do software BIND ISEL 2ª Fase 9

Foram efectuadas várias configurações de DNS no bind, as quais passam por: - Criação de ACL s, para permitir queries de qualquer destino IP, mas bloqueia tudo o que sejam pedidos da placa loopback (127.0.0.0) ou locais - Configuração de IP s que ficarão á escuta de pedidos de DNS Tabela 1 Conteúdo do Ficheiro named.conf /* * Refer to the named.conf(5) and named(8) man pages, and the documentation * in /usr/share/doc/bind-9 for more details. * Online versions of the documentation can be found here: * http://www.isc.org/software/bind/documentation * * If you are going to set up an authoritative server, make sure you * understand the hairy details of how DNS works. Even with simple mistakes, * you can break connectivity for affected parties, or cause huge amounts of * useless Internet traffic. */ acl "xfer" { /* Deny transfers by default except for the listed hosts. * If we have other name servers, place them here. */ none; }; /* * You might put in here some ips which are allowed to use the cache or * recursive queries */ acl "bloqueia_local" { 127.0.0.0/8; }; acl "trusted" { //127.0.0.0/8; 10.0.0.0/8; 10.62.202.78/28; 193.137.220.0/24; ::1/128; }; options { directory "/var/bind"; pid-file "/var/run/named/named.pid"; /* https://www.isc.org/solutions/dlv >=bind-9.7.x only */ //bindkeys-file "/etc/bind/bind.keys"; listen-on-v6 { ::1; }; listen-on { 10.62.75.131; 127.0.0.1; 10.62.202.78;}; /*ALTERADO 127.0.0.1;*/ allow-query { /* * Accept queries from our "trusted" ACL. We will ISEL 2ª Fase 10

}; * allow anyone to query our master zones below. * This prevents us from becoming a free DNS server * to the masses. */ trusted; allow-query-cache { /* Use the cache for the "trusted" ACL. */ trusted; }; allow-recursion { /* Only trusted addresses are allowed to use recursion. */ trusted; none; //ALTERADO }; allow-transfer { /* Zone tranfers are denied by default. */ none; }; allow-update { /* Don't allow updates, e.g. via nsupdate. */ none; }; /* * If you've got a DNS server around at your upstream provider, enter its * IP address here, and enable the line below. This will make you benefit * from its cache, thus reduce overall DNS traffic in the Internet. * * Uncomment the following lines to turn on DNS forwarding, and change * and/or update the forwarding ip address(es): */ /* forward first; forwarders { // 123.123.123.123; // Your ISP NS // 124.124.124.124; // Your ISP NS // 4.2.2.1; // Level3 Public DNS // 4.2.2.2; // Level3 Public DNS //alterado // 8.8.8.8; // Google Open DNS //alterado // 8.8.4.4; // Google Open DNS }; */ //dnssec-enable yes; //dnssec-validation yes; /* * As of bind 9.8.0: * "If the root key provided has expired, * named will log the expiration and validation will not work." */ //dnssec-validation auto; }; /* if you have problems and are behind a firewall: */ //query-source address * port 53; ISEL 2ª Fase 11

/* logging { channel default_log { file "/var/log/named/named.log" versions 5 size 50M; print-time yes; print-severity yes; print-category yes; }; }; */ category default { default_log; }; category general { default_log; }; include "/etc/bind/rndc.key"; controls { inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys { "rndc-key"; }; }; zone "." in { type hint; file "/var/bind/root.cache"; //file "pri/named.root"; }; zone "localhost" IN { type master; file "pri/localhost.zone"; notify no; }; zone "127.in-addr.arpa" IN { type master; file "pri/127.zone"; notify no; }; zone "g1.lrcd.e.ipl.pt" IN { type master; file "pri/g1.lrcd.e.ipl.pt.zone"; allow-query { trusted; }; notify no; }; /* * Briefly, a zone which has been declared delegation-only will be effectively * limited to containing NS RRs for subdomains, but no actual data beyond its * own apex (for example, its SOA RR and apex NS RRset). This can be used to * filter out "wildcard" or "synthesized" data from NAT boxes or from * authoritative name servers whose undelegated (in-zone) data is of no * interest. * See http://www.isc.org/software/bind/delegation-only for more info */ //zone "COM" { type delegation-only; }; //zone "NET" { type delegation-only; }; //zone "YOUR-DOMAIN.TLD" { // type master; // file "/var/bind/pri/your-domain.tld.zone"; // allow-query { any; }; ISEL 2ª Fase 12

// allow-transfer { xfer; }; //}; //zone "YOUR-SLAVE.TLD" { // type slave; // file "/var/bind/sec/your-slave.tld.zone"; // masters { <MASTER>; }; /* Anybody is allowed to query but transfer should be controlled by the master. */ // allow-query { any; }; // allow-transfer { none; }; /* The master should be the only one who notifies the slaves, shouldn't it? */ // allow-notify { <MASTER>; }; // notify no; //}; Na tabela abaixo foram efectuadas algumas configurações: - O ficheiro de zona, foi criado de acordo com o nome do grupo (g1.lrcd.e.ipl.pt) - Foi configurado uma entrada para um NS(name server) a apontar para o IP da placa eth0 - Foi criada uma entrada para o serviço de mail, a apontar para o IP da placa eth0 - Foi criada uma entrada para efeitos de teste, para verificar da resolução NOME / IP. Tabela 2 Conteúdo do ficheiro de zona g1.lrcd.e.ipl.pt ; g1.lrcd.e.ipl.pt @ IN SOA ns hostmaster. ( 2011131001 ; serial 12h ; refresh 1h ; retry 2w ; expire 1h ; minimum ) IN NS ns IN MX 10 mail ns IN A 10.62.75.131 IN A testebind ; host records localhost IN A 127.0.0.1 mail IN A 10.62.75.131 testebind IN A 10.62.75.131 ISEL 2ª Fase 13

Para se efectuar testes de DNS, podemos usar uma ferramenta já aqui mencionada anteriormente, o dig. Nesta fase foi crucial a utilização desta ferramenta, para efectuar testes á configuração do BIND. Abaixo encontra-se um exemplo da sua utilização, a querie efectuada, pergunta ao IP do router se o nome ns.g1.lrcd.e.ipl.pt, tem alguma correspondência para o tipo Host. A resposta é dada na imagem abaixo, onde podemos verificar que existe uma correspondência. - dig @10.62.202.78 ns.g1.lrcd.e.ipl.pt A Figura 6 Resultado do comando dig 3ª Fase Nesta fase, iremos instalar o aplicativo quagga. Este aplicativo permite efectuar routing em TCP/IP e suporta diversos protocolos, entre eles (RIP, OSPF, BGP). Um sistema a correr o quagga, funciona como um router dedicado, ou seja permite roteamento de informação directamente com outros routers, utilizando os protocolos de routing mencionados anteriormente. O quagga utiliza esta informação, para actualizar a tabela de routing do Kernel, isto para que a informação certa vá para o sítio correcto. No quagga existem dois tipos de utilizador. - Normal User Mode (apenas permite visualizar o status do sistema) - Enable Mode (permite efectuar alterações ás configurações do sistema) ISEL 3ª Fase 14

Nesta fase iremos instalar o quagga e configurar o módulo de OSPF. Para instalação do quagga, usamos o seguinte comando: - emerge av quagga Figura 7 Instalação do quagga Após a instalação do quagga, ficarão a correr alguns processos (deamons), o zebra é um desses deamons, existem outros (bgpd, ripd, ospfd), cada um associado ao seu protocolo. Teremos que efectuar as configurações necessárias, isto pode ser conseguido através da execução do comando vtysh, o qual guarda automaticamente informação das placas de rede. Claro que mais informação terá que ser fornecida, pois apenas será gerada informação básica. Abaixo podemos ver, informação gerada automaticamente com o comando vtysh, a qual é armazenada no ficheiro, /etc/quagga/zebra.conf ISEL 3ª Fase 15

Tabela 3 - Conteúdo do ficheiro zebra.conf Zebra configuration saved from vty 2011/10/27 21:39:00 hostname gentoo password gentoo enable password gentoo log syslog interface eth0 multicast ipv6 nd suppress-ra interface eth1 ipv6 nd suppress-ra interface lo ip forwarding line vty Seguidamente iremos verificar o conteúdo do ficheiro, ospfd.conf, aqui se encontra toda a configuração do OSPF, para que funciona correctamente na rede ISEL. Além da informação gerada automaticamente com o comando vtysh, mais alguns parâmetros tiveram que ser introduzidos: - Configurar uma key para o OSPF na placa eth0 - Configurar o OSPF para a rede do ISEL, colocando informação dos IP s das redes 10.62.75.0/24 e 10.62.202.64/28, para permitir OSPF na área 75 - Colocação da placa eth1 em modo passivo, para prevenir o envio de OSPF hello Tabela 4 Conteúdo do ficheiro ospfd.conf Zebra configuration saved from vty 2011/10/27 21:39:00 hostname gentoo password gentoo enable password gentoo log syslog interface eth0 ip ospf message-digest-key 20 md5 mesmosimples interface eth1 interface lo router ospf ospf router-id 10.62.202.78 log-adjacency-changes ISEL 3ª Fase 16

Important: ensure reference bandwidth is consistent across all routers auto-cost reference-bandwidth 1000 passive-interface eth1 network 10.62.75.0/24 area 0.0.0.75 network 10.62.202.64/28 area 0.0.0.75 area 75 authentication message-digest line vty Para verificar uma correcta configuração do OSPF, podemos procurar quais os routers que se encontram como vizinhos (neighbours), através da utilização do seguinte comando. - show ip ospf neighour 4ª Fase Nesta fase iremos configurar o iptables, de acordo o enunciando fornecido pelo docente da cadeira. O iptables é um programa que permite a configuração de uma firewall, em sistemas Linux. Permite manter, inspeccionar, configurar, as tabelas de packet filtering no kernel do Linux. Podem ser definidas várias tabelas, e cada tabela contém um número de cadeias embutidas(input, OUTPUT, FOWARD, entre outras), também se podem criar novas cadeias. Cada cadeia contém uma lista de regras, que podem coincidir com um conjunto de pacotes. Cada regra ordena o que fazer com um pacote, caso este coincida com a mesma. Podemos instalar o iptables através de duas formas: 1. Seleccionar a opção na figura 8 (no Kernel), para que o iptables esteja disponível no sistema operativo. 2. Através da instalação do software pelo comando emerge av iptables ISEL 4ª Fase 17

Figura 8 Configuração de Kernel (módulo netfilter seleccionado) Na figura abaixo, podemos ver um fluxograma, com o funcionamento do netfilter. Foram colocados os IP s das placas interna e externa, para se verificar como o netfilter processa os pedidos. Figura 8 Fluxograma do netfilter Fluxograma Netfilter 10.62.75.131 Interface Entrada IP destino Local? NÃO FORWARD Interface Saída SIM INPUT TCP/IP OUTPUT 10.62.202.78 ISEL 4ª Fase 18

Na tabela abaixo, encontra-se todas as regras de netfilter configuradas, incluindo as de pré-routing. Tabela 5 Regras de netfilter GENTOO ~ iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:60022 state NEW,ESTABLISHED LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 Chain FORWARD (policy ACCEPT) target prot opt source destination ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmptype 8 REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt: 25 reject-with icmp-port-unreachable ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 Chain OUTPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state NEW ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 GENTOO ~ iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination REDIRECT tcp -- anywhere anywhere tcp dpt:60022 redir ports 22 Chain INPUT (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination DNAT tcp -- sapo.pt anywhere tcp dpt:http to:212.113.174.13:80 Chain POSTROUTING (policy ACCEPT) target prot opt source destination Para um correcto despiste das regras de netfilter implementadas, usou-se uma ferramenta (tcpump), a qual permite a captura na hora de pacotes, baseados em filtros. Na tabela abaixo, verificamos a captura de pacotes TCP, direccionados á placa eth0. ISEL 4ª Fase 19

Tabela 6 Captura de pacotes TCP, direccionados á placa eth0 GENTOO ~ tcpdump -pn -i eth0 tcp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 19:21:48.343053 IP 192.168.1.69.22 > 192.168.1.71.7072: P 2151880484:2151880600(116) ack 4192272885 win 4005 19:21:48.343534 IP 192.168.1.69.22 > 192.168.1.71.7072: P 116:232(116) ack 1 win 4005 19:21:48.344523 IP 192.168.1.69.22 > 192.168.1.71.7072: P 232:380(148) ack 1 win 4005 19:21:48.344865 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 116 win 253 19:21:48.345535 IP 192.168.1.69.22 > 192.168.1.71.7072: P 380:512(132) ack 1 win 4005 19:21:48.345923 IP 192.168.1.69.22 > 192.168.1.71.7072: P 512:644(132) ack 1 win 4005 19:21:48.346290 IP 192.168.1.69.22 > 192.168.1.71.7072: P 644:760(116) ack 1 win 4005 19:21:48.346706 IP 192.168.1.69.22 > 192.168.1.71.7072: P 760:892(132) ack 1 win 4005 19:21:48.348045 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 380 win 252 19:21:48.348208 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 644 win 251 19:21:48.348716 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 892 win 256 19:21:48.350311 IP 192.168.1.69.22 > 192.168.1.71.7072: P 892:1024(132) ack 1 win 4005 19:21:48.350753 IP 192.168.1.69.22 > 192.168.1.71.7072: P 1024:1156(132) ack 1 win 19:21:48.358639 IP 192.168.1.69.22 > 192.168.1.71.7072: P 3396:3528(132) ack 1 win 254 19:21:48.367845 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 4916 win 253 19:21:48.368077 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 5180 win 252 19:21:48.368982 IP 192.168.1.69.22 > 192.168.1.71.7072: P 5312:5668(356) ack 1 win 4005 19:21:48.369347 IP 192.168.1.69.22 > 192.168.1.71.7072: P 5668:5800(132) ack 1 win 4005 win 4005 19:21:48.397553 IP 192.168.1.69.22 > 192.168.1.71.7072: P 11292:11424(132) ack 137 win 4005 19:21:48.397895 IP 192.168.1.69.22 > 192.168.1.71.7072: P 11424:11556(132) ack 189 win 4005 19:21:48.398572 IP 192.168.1.71.7072 > 192.168.1.69.22:. ack 11176 win 253 ^C 103 packets captured 103 packets received by filter 0 packets dropped by kernel 5ª Fase Nesta fase irei descrever a instalação e configuração do RADIUS na rede do ISEL, como proposto pelo enunciado, fornecido pelo docente da cadeira. RADIUS (Remote Authentication Dial-In Service), permite autenticação e autorização, para ligações a determinados serviços de rede (os ISP usam muito o RADIUS, para autenticação de utilizadores, para aceder á Internet, Wi-Fi e serviços de email). O RADIUS é um protocolo cliente / servidor, que corre na camada application, e utiliza o protocolo UDP. O aplicativo freeradius, disponibiliza um serviço de RADIUS, no qual teremos que efectuar algumas configurações. ISEL 20

Figura 9 Instalação do freeradius no Gentoo Na tabela seguinte, verificamos as configurações efectuadas ao nível do router para permitir RADIUS para a VM Gentoo. Foram definidos os seguintes parâmetros de AAA: - aaa authentication login default group radius local (efectua a autenticação para RADIUS, mas no caso de o servidor não responder, consegue-se efectuar o login com um utilizador criado na BD do router, e desta forma não ficamos sem acesso ao router, mesmo sem um servidor de RADIUS. - aaa authentication login TELNET group radius (foi criada uma lista TELNET, para definir acessos via telnet, no caso do servidor RADIUS não responder, será pedida uma password para se entrar no router via Telnet na linha Vty 0. - aaa authorization exec default group radius local (foi definida autorização para execução de comandos via Shell, para todos os acessos RADIUS. - aaa accounting exec default start-stop group radius (foi definido o registo em log de todos os acessos que são feitos aquando do inicio/término de uma sessão de RADIUS. Abaixo encontramos as configurações do servidor de RADIUS IP e as portas onde se encontra á escuta, nomeadamente as portas de autenthication e accounting. Devido a problemas na comunicação com o RADIUS, as portas auth e acct tiveram que ser alteradas no router, porque o Router Cisco, cria automaticamente os acessos com ISEL 5ª Fase 21

portas diferentes das dos servidor RADIUS. Para isso, foi consultado o ficheiro /etc/services, onde se poderão observar as portas que o Gentoo usa para RADIUS. - radius-server host 10.62.75.131 auth-port 1812 acct-port 1813 Abaixo encontramos a key, que permite a troca de mensagens encriptadas entre o Router e o servidor de RADIUS, esta key tem que coincidir com a key definida no ficheiro clients.conf, para as redes configuradas nesse mesmo ficheiro. - radius-server key radius Tabela 7 Configuração do router C1700, com os parâmetros de Radius Router(config)do sh ru Building configuration... Current configuration : 1193 bytes version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname Router boot-start-marker boot-end-marker aaa new-model aaa authentication login default group radius local aaa authentication login TELNET group radius aaa authorization exec default group radius local aaa accounting exec default start-stop group radius aaa session-id common memory-size iomem 15 mmi polling-interval 60 no mmi auto-configure no mmi pvc mmi snmp-timeout 180 ip cef username router privilege 15 password 0 router ISEL 5ª Fase 22

interface Ethernet0 no ip address shutdown half-duplex interface FastEthernet0 ip address dhcp ip ospf message-digest-key 20 md5 mesmosimples speed auto router ospf 1 log-adjacency-changes auto-cost reference-bandwidth 1000 area 75 authentication message-digest network 10.62.75.0 0.0.0.255 area 75 network 10.62.202.64 0.0.0.15 area 75 ip forward-protocol nd no ip http server radius-server host 10.62.75.131 auth-port 1812 acct-port 1813 radius-server key radius control-plane line con 0 line aux 0 line vty 0 4 password router login authentication TELNET end Router(config) ISEL 5ª Fase 23

Na tabela 8, podemos verificar algumas configurações efectuadas, nomeadamente no acesso a clientes RADIUS. Foram configurados acessos, para as duas redes (etho e eth1) com o secret radius e atribuídos o short name de rede externa e rede interna. Tabela 8 Conteúdo do ficheiro de configuração clients.conf -*- text -*- clients.conf -- client configuration directives $Id: clients.conf,v 1.13 2008/04/17 12:22:23 aland Exp $ Definition of a RADIUS client (usually a NAS). The information given here over rides anything given in the 'clients' file, or in the 'naslist' file. The configuration here contains all of the information from those two files, and allows for more configuration items. The "shortname" is be used for logging. The "nastype", "login" and "password" fields are mainly used for checkrad and are optional. Defines a RADIUS client. '127.0.0.1' is another name for 'localhost'. It is enabled by default, to allow testing of the server after an initial installation. If you are not going to be permitting RADIUS queries from localhost, we suggest that you delete, or comment out, this entry. Each client has a "short name" that is used to distinguish it from other clients. In version 1.x, this field was the IP address of the client. In 2.0, the IP address is configured via the "ipaddr" or "ipv6addr" fields. For compatibility, the 1.x format is still accepted. client localhost { Allowed values are: dotted quad (1.2.3.4) hostname (radius.example.com) ipaddr = 127.0.0.1 OR, you can use an IPv6 address, but not both at the same time. ipv6addr = :: any. ::1 == localhost A note on DNS: We STRONGLY recommend using IP addresses rather than host names. Using host names means that the server will do DNS lookups when it starts, making it dependent on DNS. i.e. If anything goes wrong with DNS, the server won't start The server also looks up the IP address from DNS once, and only once, when it starts. If the DNS record is later updated, the server WILL NOT see that update. One client definition can be applied to an entire network. e.g. 127/8 should be defined with "ipaddr = 127.0.0.0" and "netmask = 8" If not specified, the default netmask is 32 (i.e. /32) We do NOT recommend using anything other than 32. There ISEL 5ª Fase 24

are usually other, better ways to acheive the same goal. Using netmasks of other than 32 can cause security issues. You can specify overlapping networks (127/8 and 127.0/16) In that case, the smallest possible network will be used as the "best match" for the client. netmask = 32 The shared secret use to "encrypt" and "sign" packets between the NAS and FreeRADIUS. You MUST change this secret from the default, otherwise it's not a secret any more The secret can be any string, up to 8k characters in length. Control codes can be entered vi octal encoding, e.g. "\101\102" == "AB" Quotation marks can be entered by escaping them, e.g. "foo\"bar" A note on security: The security of the RADIUS protocol depends COMPLETELY on this secret We recommend using a shared secret that is composed of: upper case letters lower case letters numbers And is at LEAST 8 characters long, preferably 16 characters in length. The secret MUST be random, and should not be words, phrase, or anything else that is recognizable. The default secret below is only for testing, and should not be used in any real environment. secret = testing123 Old-style clients do not send a Message-Authenticator in an Access-Request. RFC 5080 suggests that all clients SHOULD include it in an Access-Request. The configuration item below allows the server to require it. If a client is required to include a Message-Authenticator and it does not, then the packet will be silently discarded. allowed values: yes, no require_message_authenticator = no The short name is used as an alias for the fully qualified domain name, or the IP address. It is accepted for compatibility with 1.x, but it is no longer necessary in 2.0 shortname = localhost the following three fields are optional, but may be used by checkrad.pl for simultaneous use checks The nastype tells 'checkrad.pl' which NAS-specific method to use to query the NAS for simultaneous use. Permitted NAS types are: cisco computone livingston max40xx multitech netserver pathras patton ISEL 5ª Fase 25

portslave tc usrhiper other for all other types nastype = other localhost isn't usually a NAS... The following two configurations are for future use. The 'naspasswd' file is currently used to store the NAS login name and password, which is used by checkrad.pl when querying the NAS for simultaneous use. login = root password = someadminpas As of 2.0, clients can also be tied to a virtual server. This is done by setting the "virtual_server" configuration item, as in the example below. virtual_server = home1 } IPv6 Client client ::1 { secret = testing123 shortname = localhost } All IPv6 Site-local clients client fe80::/16 { secret = testing123 shortname = localhost } client some.host.org { secret = testing123 shortname = localhost } You can now specify one secret for a network of clients. When a client request comes in, the BEST match is chosen. i.e. The entry from the smallest possible network. client 10.62.202.64/28 { secret = radius shortname = rede interna } client 10.62.75.0/24 { secret shortname } = radius = rede externa client 10.10.10.10 { secret and password are mapped through the "secrets" file. secret = testing123 shortname = liv1 the following three fields are optional, but may be used by checkrad.pl for simultaneous usage checks nastype = livingston login = root password = someadminpas } Per-socket client lists. The configuration entries are exactly the same as above, but they are nested inside of a section. ISEL 5ª Fase 26