Integração de Redes e Serviços

(1)

Instituto Superior de Engenharia de Lisboa

Área Departamental de Engenharia de Electrónica e

Telecomunicações e de Computadores

(ADEETC)

Mestrado em Engenharia de Redes de Comunicação e

Multimédia

(MERCM)

Integração de Redes e Serviços

Relatório do Trabalho Prático

Docente: Eng.º Pedro Ribeiro Discentes: João Palma n.º 31726 Miguel Batista n.º 32035 2011/2012 Semestre de Inverno 18 de Fevereiro de 2012

(2)

(3)

Índice

Índice de figuras ... 5 Siglas ... 6 Introdução ... 7 1. VM Gentoo ... 8 1.1 Abordagem ... 8 1.2 Configuração ... 8 2. DHCP ... 9 2.1 Abordagem ... 9 2.2 Configuração ... 9 2.3 Testes e Resultados ... 10 3. BIND ... 11 3.1 Abordagem ... 11 3.2 Configuração ... 12 3.3 Testes e Resultados ... 14 4. QUAGGA ... 15 4.1 Abordagem ... 15 4.2 Configuração ... 16 4.3 Testes e Resultados ... 17 5. IPTABLES ... 19 5.1 Abordagem ... 19 5.2 Configuração ... 20 5.3 Testes e Resultados ... 23 6. FreeRadius ... 25

(4)

4 6.1 Abordagem ... 25 6.2 Configuração ... 25 6.3 Testes e Resultados ... 27 Conclusão ... 31 Bibliografia ... 33 Anexos ... 34

(5)

5

Índice de figuras

Figura 1 – IPTables Chains (1) – Linux IPTables Pocket Reference ... 19

Figura 2 – IP Tables Chains (2) – Linux IPTables Pocket Reference ... 20

Figura 3 - IPTables: Teste à norma Nº2 ... 23

Figura 4 - IPTables: Teste à norma Nº6 ... 24

Figura 5 – IPTables: Teste à norma Nº9 ... 25

Figura 6 - Login com sucesso no router, via telnet ... 28

Figura 7 - Accounting - Registo de entrada ... 30

(6)

6

Siglas

AAA Accounting, Authorization and Authentication ACL Access Control List

DHCP Dynamic Host Configuration Protocol DNS Domain Name Server

NAT Network Address Translation OSPF Open Shortest Path First

RADIUS Remote Authentication Dial In User Service

SO Sistema Operativo

SSH Secure Shell

TCP Transport Control Protocol

(7)

7

Introdução

Este trabalho tem por objectivo a integração de vários serviços numa rede de computadores. Estes serviços vão desde um servidor de DHCP até a um servidor de DNS, passando pela configuração de um Firewall e de um Router. Todos estes serviços correm em cima de uma máquina Linux Gentoo.

A configuração de rede será a seguinte:

A porta eth0 está ligada à rede do laboratório e a porta eth1 está ligada à rede interna.

Assim, para a resolução deste trabalho, foi necessário criar e configurar uma máquina virtual com o sistema operativo Gentoo. A lista dos serviços que foram instalados e configurados na VM é a seguinte:

 DHCP

 BIND

 QUAGGA

 IPTABLES

(8)

8

1. VM Gentoo

1.1 Abordagem

Como suporte aos serviços de rede que se pretende disponibilizar, será configurada uma Máquina Virtual (VM – Virtual Machine) Linux, cuja distribuição será o Gentoo.

A configuração e instalação do S.O. terá por base o site web

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1, onde se descrevem passo a passo as várias fases da configuração do sistema, nomeadamente a configuração do sistema de ficheiros, configuração da rede, boot, instalação de software necessário para a realização deste trabalho e a compilação do Kernel.

A distribuição Gentoo é configurada via linha de comandos, sendo altamente modular neste aspecto (um dos passos da sua configuração a compilação do próprio Kernel). É também possível adaptar o S.O. para a máquina onde este irá operar, optimizando bastante o seu desempenho. Possui um mecanismo de instalação/manutenção de software denomidado de Portage, com as funções de

download, configuração, compilação e instalação.

1.2 Configuração

A configuração da máquina virtual Gentoo consistiu essencialmente em 3 passos. Segue-se uma descrição resumida dos mesmos:

1. Criação e formatação de partições:

a. Utilização do fdisk para criar 3 partições – swap, boot e root b. Utilização do mkfs para formatar as partições e criar o sistema

de ficheiros – utilizou-se ext4 para as partições de boot e root. c. Activação da partição de swap com os comandos mkswap e

swapon

2. Configuração e compilação do Kernel:

(9)

9 b. Utilização do links para fazer download do Kernel do Gentoo c. Configuração do ficheiro make.conf do Gentoo para definir as

CFLAGS

d. Instalação das sources do Gentoo

e. Configuração dos módulos a incluir no Kernel f. Compilação do Kernel

3. Instalação e configuração do bootloader:

a. Criação e configuração do ficheiro /etc/fstab para definir os pontos de montagem

b. Instalação do GRUB e configuração do ficheiro /boot/grub/grub.conf

2. DHCP

2.1 Abordagem

O servidor de DHCP servirá para dar as configurações iniciais para qualquer máquina que se ligue à rede interna.

O servidor de DHCP servirá para dar as configurações iniciais para qualquer máquina que se ligue à rede interna. Para tal, e como pretendemos que a rede interna tenha o endereço base 10.62.202.128/28, configurou-se o ficheiro dhcpd.conf com a seguinte subnet.

(10)

10 subnet 10.62.202.128 netmask 255.255.255.240 {

range 10.62.202.129 10.62.202.141; option routers 10.62.202.142; }

Desta forma, qualquer computador que se ligue à rede interna irá obter um dos IPs entre 10.62.202.129 e 10.62.202.141, sendo o IP 10.62.202.142 o endereço do PC que configurámos e será visto como o gateway da rede interna para o computadores que estiverem ligados à mesma.

2.3 Testes e Resultados

Após a configuração do DHCP, verificou-se que o mesmo estava em funcionamento pois ao ligar uma máquina na rede interna, o seu DHCP Request foi respondido pelo nosso servidor.

Oct 27 21:47:50 localhost dhcpd:

DHCPREQUEST for 10.62.202.129 from 00:50:56:c0:00:01 (Miguel-PC) via eth1

Oct 27 21:47:50 localhost dhcpd:

DHCPACK on 10.62.202.129 to 00:50:56:c0:00:01 (Miguel-PC) via eth1

Como é possível ver pelas mensagens de DHCP trocadas, o pedido de configuração do PC da rede interna é respondido e é-lhe atribuído o IP 10.62.202.129, como pode ser comprovado pela configuração de rede do mesmo, usando o comando

ipconfig.

(11)

11 Connection-specific DNS Suffix . : IPv4 Address. . . : 10.62.202.129 Subnet Mask . . . : 255.255.255.240 Default Gateway . . . : 10.62.202.142

3. BIND

3.1 Abordagem

BIND é um software open-source para UNIX que permite instanciar um servidor de DNS Local.

A configuração do serviço de DNS, para além da configuração do próprio BIND, prende-se também com outra questão: Zonas. A configuração de zonas permite ao servidor de DNS saber quais os domínios da rede a que está afecto, bem como as suas configurações (nome e IP do servidor autoritário, servidor Web, servidor de Mail, IPs aos quais responde, entre outros). Também é possível criar ACLs, de modo a permitir ao Administrador do serviço de DNS configurar e atribuir um nome a um conjunto de IPs para serem utilizados pelas zonas configuradas.

No ponto seguinte será demonstrada a configuração efectuada para este serviço e no ponto 3.3 encontram-se os resultados obtidos com a utilização do mesmo.

(12)

12 3.2 Configuração

Configuração da zona do domínio

Na configuração da zona é indicado à autoridade SOA (Start of Authority) o nome do servidor autoritário do domínio e um email pertence ao Administrador do domínio. Definem-se também valores para a verificação do número de série por parte dos servidores secundários, tentativas de actualização dos registos primários e tempos de cache dos registos nos servidores secundários. Por fim, é definida a máquina responsável pelo domínio, ou seja, o servidor autoritário e os nomes que serão possíveis de serem acedidos pela resolução deste domínio, bem como os respectivos endereços IP. $TTL 1W @ IN SOA ns1 admin.ns ( 2008122645 ; Serial 28800 ; Refresh 14400 ; Retry 604800 ; Expire - 1 week 86400 ; Minimum ) @ IN NS ns1 ns1 IN A 10.62.75.135 ns2 IN A 10.62.75.133 www A 192.68.221.49 xpto IN A 111.111.111.111

(13)

13 Configuração do serviço ACL acl "trusted" { 127.0.0.0/8; ::1/128; 10.62.202.128/28; }; allow-query { trusted; }; allow-query-cache { trusted; }; zone "." in { type hint; file "/var/bind/root.cache"; }; zone "localhost" IN { type master; file "pri/localhost.zone"; notify no; }; zone "g5.lrcd.e.ipl.pt" IN { type master; file "pri/g5.zone"; notify no; allow-update { none; }; allow-transfer { 10.62.75.133; }; allow-query { any; }; };

(14)

14 A configuração do BIND é efectuada através da edição do ficheiro named.conf. Neste ficheiro é possível adicionar as várias zonas possíveis de resolução pelo serviço, ACLs, bem como propriedades afectas á resolução de endereços, como por exemplo a propriedade Allow-Query, que permite identificar quais os endereços a que o BIND irá responder (negando os pedidos dos restantes).

Veja-se a definição da zona "g5.lrcd.e.ipl.pt" mencionada anteriormente, onde se especifica a localização do ficheiro de configuração da zona e algumas opções de resolução, tais como allow-query e allow-transfer que indicam, respectivamente, quais os endereços que tem autorização para receber respostas DNS relativas a este domínio e quais os endereços com permissão para copiarem a informação do domínio (neste caso está-se a dar permição ao IP 10.62.75.133, pertencente ao grupo Nº3 da disciplina).

Para efectuar testes ao serviço BIND foi utilizado o comando DIG. Este comando, que faz parte do pacote de instalação do BIND (Bind-Tools) permite efectuar

queries a servidores DNS (tal como o nslookup do MS Windows).

Assim, efectuou-se um pedido DNS para saber informações sobre o nome xpto.g5.lrcd.e.ipl.pt. Inicialmente, o pedido foi encaminhado para o servidor DNS responsável pelo domínio lrcd.e.ipl.pt (193.137.220.20), que por sua vez o encaminhou para o servidor responsável pelo dominio g5.lrcd.e.ipl.pt (10.62.75.135). Obteve-se assim, como se pode verificar pela figura seguinte, que o endereço IP para o nome questionado é 111.111.111.111.

(15)

15

4. QUAGGA

4.1 Abordagem

A configuração do Quagga foi feita através da linha de comando vtysh. Na interface eth0 foi configurado o OSPF pois será esta a interface que irá anunciar o router à rede do laboratório e estabelecer as adjacências com os outros routers.

<<>> DiG 9.7.3 <<>> xpto.g5.lrcd.e.ipl.pt ;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61752 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION: ;xpto.g5.lrcd.e.ipl.pt. IN A ;; ANSWER SECTION: xpto.g5.lrcd.e.ipl.pt. 604739 IN A 111.111.111.111 ;; AUTHORITY SECTION: g5.lrcd.e.ipl.pt. 172800 IN NS srv-g5-lrcd.e.ipl.pt. ;; ADDITIONAL SECTION: srv-g5-lrcd.e.ipl.pt. 172800 IN A 10.62.75.135

;; Query time: 3 msec

;; SERVER: 193.137.220.20#53(193.137.220.20) ;; WHEN: Thu Oct 20 20:55:58 2011

(16)

16 4.2 Configuração

A configuração do Quagga foi feita através da linha de comando vtysh. Na interface eth0 foi configurado o OSPF pois será esta a interface que irá anunciar o router à rede do laboratório e estabelecer as adjacências com os outros routers. Em ambas as interfaces foi desactivado o IPv6.

interface eth0

ip ospf message-digest-key 20 md5 mesmosimples ipv6 nd suppress-ra

interface eth1

ipv6 nd suppress-ra

Para o router anunciar-se a si próprio e à rede interna, adicionou-se a seguinte configuração. Foi ainda definido qual o tipo de autenticação a usar nas mensagens de OSPF.

router ospf

auto-cost reference-bandwidth 1000 network 10.62.75.0/24 area 0.0.0.75 network 10.62.202.128/28 area 0.0.0.75 area 75 authentication message-digest

Por último, como o router não fazia o forwarding de pacotes da rede interna para a rede do laboratório e vice-versa, foi necessário executar o comando ip forwarding para permitir o forwarding de pacotes.

(17)

17 4.3 Testes e Resultados

Após a configuração do Quagga, procedeu-se a alguns testes para verificar a validade da sua configuração.

Em primeiro lugar, fez-se um ping da rede interna para a rede externa. Sendo o IP 10.62.75.133, o endereço da interface de fora (eth0) do router (máquina Gentoo).

C:\Users\Miguel>ping 10.62.75.133

Pinging 10.62.75.133 with 32 bytes of data:

Reply from 10.62.75.133: bytes=32 time=4ms TTL=63 Reply from 10.62.75.133: bytes=32 time=1ms TTL=63 Reply from 10.62.75.133: bytes=32 time=1ms TTL=63 Reply from 10.62.75.133: bytes=32 time=1ms TTL=63

Ping statistics for 10.62.75.133:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 4ms, Average = 1ms

Em seguida, fez-se outro ping para outra máquina da rede do laboratório, neste caso, o router da rede do laboratório.

C:\Users\Miguel>ping 10.62.75.252

Pinging 10.62.75.252 with 32 bytes of data:

Reply from 10.62.75.252: bytes=32 time=4ms TTL=254 Reply from 10.62.75.252: bytes=32 time=1ms TTL=254

(18)

18 Reply from 10.62.75.252: bytes=32 time=1ms TTL=254

Reply from 10.62.75.252: bytes=32 time=1ms TTL=254

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 1ms, Maximum = 4ms, Average = 1ms

Mais uma vez, é necessário relembrar que estes pings da rede interna para a rede do laboratório apenas são possíveis devido à execução do comando ip forwarding executado durante a configuração do Quagga.

Após a configuração manual, na máquina da rede interna, dos IPs dos servidores de DNS, passou-se a conseguir fazer o seguinte tipo de pings:

C:\Users\Miguel>ping google.com

Pinging google.com [209.85.169.99] with 32 bytes of data: Reply from 209.85.169.99: bytes=32 time=35ms TTL=50 Reply from 209.85.169.99: bytes=32 time=35ms TTL=50 Reply from 209.85.169.99: bytes=32 time=34ms TTL=50 Reply from 209.85.169.99: bytes=32 time=34ms TTL=50

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:

(19)

19

5. IPTABLES

5.1 Abordagem

De modo a integrar as funcionalidades de um firewall na rede, recorreu-se ao módulo IPTables disponibilizado pelo pacote Netfilter.

O módulo IPTables permite a implementação regras de filtragem de pacotes, tanto a nível da saída da rede como a nível da entrada. Este módulo está organizado em 5 pontos de intercepção (chains), onde o pacote que dá entrada na rede apenas é filtrado por uma delas. Estes pontos são:

 INPUT

 OUTPUT

 FORWARDING

 PREROUTING

 POSTROUTING

O esquema para as três primeiras regras (INPUT, OUTPUT e FORWARDING) pode ser visto na figura seguinte.

Figura 1 – IPTables Chains (1) – Linux IPTables Pocket Reference

Os pacotes com destino ao Router são encaminhados para a chain de INPUT. Os pacotes gerados pelo Router são encaminhados para a chain de OUTPUT. Para a cadeia de FORWARD são encaminhados os pacotes que atravessam o Router com destino à

(20)

20 Rede Local, ou seja, pacotes cuja interface de destino seja diferente da de origem (Interface Origem = eth0 e Interface Destino = eth1, ou vice-versa).

As restantes cadeias - PREROUTING e POSTROUTING - são destinadas para regras que necessitem de ser aplicadas assim que o pacote entra/sai das interfaces, nomeadamente para aplicação da técnica de NAT aos pacotes.

Figura 2 – IP Tables Chains (2) – Linux IPTables Pocket Reference

Um dos atractivos do IPTables é a possibilidade de efectuar SPI (Statefull Packet Inspection) aos pacotes. Através do uso do módulo Conntrack consegue-se controlar os vários estados das ligações activas que passam na rede. É bastante útil para os protocolos que mantém estado, tal como o TCP, FTP, ICMP e SSH.

No ponto 5.2 estão descritas as regras a ter em conta para a protecção da rede do trabalho e no ponto 5.3 demonstram-se os resultados obtidos.

Para a entrada de pacotes na rede devem ser considerados os seguintes objectivos:

1. É aceite todo o tráfego pertencente a comunicações originadas no router ou que atravessa o router vindo da rede interna (eth1) (validação baseada em estado conntrack);

2. São aceites ligações SSH para a rede interna e router;

(21)

21 4. Os acessos SSH exteriores para o router têm de se fazer para o port

60022 (mantendo o SSH a escutar apenas no porto 22); 5. Todo o restante tráfego exterior é negado.

Na saída de tráfego para o exterior deve-se considerar que:

6. São negadas todas as comunicações para servidores SMTP;

7. São aceites comunicações originadas no router ou na rede interna (eth1);

8. Os pedidos DNS provenientes da rede interna e destinados aos endereços 193.137.220.18 e 193.137.220.19 devem após "forwarding" ir sempre destinados ao 193.137.220.20;

9. Os pedidos HTTP da rede interna destinados ao IP 213.13.146.140 devem ser alterados para o IP destino 212.113.174.13;

10. As comunicações entre a rede interna (ligada à eth1) e o router não têm quaisquer limitações;

11. Todo o restante tráfego é negado;

Os pontos enunciados acima encontram-se totalmente implementados no módulo IPTables do trabalho e encontram-se descritos, na íntegra, no Anexo X deste relatório. Em baixo, descrevem-se apenas algumas das regras mais importantes, cujos resultados práticos se evidenciam no ponto 3.5.

Objectivo Nº2:

Regra 9:

O porto onde o serviço de SSH está à escuta é o 22 e o protocolo usado é o TCP.

-A INPUT -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -i eth0 -p tcp -m tcp --dport 22 -m conntrack --ctstate DNAT -j ACCEPT -A OUTPUT -o eth1 -p tcp -m tcp --dport 22 -j ACCEPT

(22)

22 Para construir esta norma é necessário aplicar regras em mais que uma chain, de modo a contemplar os pacotes com destino ao Router e também os pacotes vindos da rede exterior com destino à local.

Assim, têm-se duas regras na chain de INPUT de modo a contemplar os pacotes destinados ao Router, quer seja via eth1 (rede local), quer seja para contemplar as ligações processadas por NAT via PREROUTING (Objectivo Nº4), vindas da eth0. Tem-se também uma regra para contemplar os pacotes originados pelo Router (cadeia de OUTPUT) e uma 4ª regra para processar os pacotes com destino á rede local via eth0 (exteriores à rede), cujo seu estado seja “DNAT”, isto é, o pacote tenha sido alterado via NAT (Objectivo Nº4).

Objectivo Nº6:

Regra 9:

O serviço de SMTP está à escuta no porto 25 e o protocolo usado é o TCP. Para que sejam totalmente negadas as comunicações SMTP, necessita-se de implementar regras em mais que de uma chain. Assim, tem-se uma primeira regra para filtrar os pacotes que atravessam a rede local (FORWARDING) e com destino à rede exterior, e uma segunda regra para negar a saída aos pacotes com origem no Router e destinados à rede exterior.

Objectivo Nº9:

Regra 9:

Através da chain de PREROUTING é possível aplicar a técnica de NAT aos pacotes. Por exemplo, na regra acima, sempre que chegue um pacote pela interface eth1, com endereço de destino 213.13.146.140/32, porto 80 de destino e TCP como

-A FORWARD -o eth0 -p tcp -m tcp --dport 25 -j DROP -A OUTPUT -o eth0 -p tcp -m tcp --dport 25 -j DROP

-A PREROUTING -d 213.13.146.140/32 -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 212.113.174.13

(23)

23 protocolo de transporte, o seu endereço de destino passa a ser sempre 212.113.174.13.

Objectivo Nº2

Efectuando ligações SSH a partir da rede interna obtém-se, com sucesso, uma mensagem de login, tal como se demonstra na imagem seguinte.

Figura 3 - IPTables: Teste à norma Nº2

Objectivo Nº6

Veja-se o seguinte excerto do ficheiro de Logs do sistema, onde se verifica que o pedido SMTP da máquina 10.62.202.129 (na rede interna) para o servidor SMTP do IPL foi negado pelo IPTables.

(24)

24 23:25:56.713059 IP 10.62.202.129.55575 > 192.104.48.10.25: S 1462369535:1462369535(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

23:25:59.712786 IP 10.62.202.129.55575 > 192.104.48.10.25: S 1462369535:1462369535(0) win 8192 <mss 1460,nop,wscale 8,nop,nop,sackOK>

23:26:05.713189 IP 10.62.202.129.55575 > 192.104.48.10.25: S 1462369535:1462369535(0) win 8192 <mss 1460,nop,nop,sackOK>

Desligando o serviço IPTables, tem-se uma ligação com sucesso, tal como se apresenta na imagem abaixo.

Figura 4 - IPTables: Teste à norma Nº6

Objectivo Nº9

Veja-se o seguinte teste, em que a introdução no browser do endereço http://www.sapo.pt (cujo IP é 213.13.146.140) leva a um redireccionamento para http://www.zon.pt (que corresponde ao IP 212.113.174.13).

(25)

25

Figura 5 – IPTables: Teste à norma Nº9

6. FreeRadius

6.1 Abordagem

Nesta parte do trabalho pretendeu-se configurar um servidor RADIUS para fornecer AAA (Accounting, Authorization and Authentication) na ligação via telnet a um router Cisco ligado à rede do laboratório.

A configuração do servidor de RADIUS envolveu vários passos. Em primeiro lugar foi necessário verificar o ficheiro principal de configuração radiusd.conf, cuja configuração por omissão estava de acordo com o pretendido.

De seguida adicionou-se uma entrada no ficheiro de users, em que é configurada a password, o username, o IP do cliente, entre outros parâmetros. O

(26)

26 parâmetro Cisco-avpair = “shell:priv-lvl=15” define o nível de permissões do utilizador no router Cisco.

testing Cleartext-Password := "password" Reply-Message = "Hello, Testing", Service-Type = Framed-User, Framed-IP-Address = 10.62.202.129, Framed-IP-Netmask = 255.255.255.240, Framed-Routing = Broadcast-Listen, Fall-Through = YES, Cisco-avpair = "shell:priv-lvl=15"

Para além do ficheiro de users, foi necessário adicionar duas novas entras no ficheiro clients.conf:

A primeira entrada refere-se ao router que está na rede do laboratório e define qual o segredo usado para as comunicações com o servidor de RADIUS.

client 10.62.75.30/24 {

secret = testing123 }

A segunda entrada é relativa a um computador presente na rede interna, que assim se pode autenticar no servidor de RADIUS, esta entrada define o segredo e a password. client 10.62.202.129 { secret = testing123 shortname = testing-network password = password }

(27)

27 Por último, falta a configuração no router propriamente dito para fazer a comunicação com o servidor de RADIUS.

aaa new-model

aaa authentication login default group radius aaa authorization exec default group radius

aaa accounting exec default start-stop group radius aaa accounting network default start-stop group radius

aaa session-id common

Configuraram-se as três funcionalidades do RADIUS, o Accounting, Authentication e o Authorization. Nos resultados iremos ver estas funcionalidades em funcionamento.

Para testar o FreeRadius, efectuou-se um login no router, via telnet. Ao estabelecer a ligação foi-nos solicitado a informação de login.

(28)

28

Figura 6 - Login com sucesso no router, via telnet

O login foi efectuado com sucesso, utilizando as credenciais configuradas no servidor de RADIUS. Logo após a entrada, executou-se o comando “show ip int brief” cuja execução foi possível devido ao parâmetro de configuração Cisco-avpair = "shell:priv-lvl=15", que permite a execução de comandos no router.

No momento do login, obtemos a seguinte mensagem no log do servidor de RADIUS indicando que tinha sido efectuado o login.

Sending Access-Request of id 238 to 10.62.202.142 port 1812 User-Name = "testing"

Password = "password"

rad_recv: Access-Accept packet from host 10.62.202.142 port 1812, id=238, length=65 Reply-Message = "Hello, %(User-Name)"

Service-Type = Framed-User

Framed-IP-Address = 10.62.202.129 Framed-IP-Netmask = 255.255.255.240 Framed-Routing = Broadcast-Listen

(29)

29 Total approved auths: 1

Total denied auths: 0 Total lost auths: 0 Total time(secs): 0

É possível ver pela mensagem anterior que o login foi efectuado com sucesso uma vez que a mensagem é do tipo Access-Accept.

No router, também é possível verificar que o RADIUS estava bem configurado pois conseguimos saber os servidores e sessões RADIUS.

Router#sh aaa servers

RADIUS: id 2, priority 1, host 10.62.75.135, auth-port 1812, acct-port 1646 State: current UP, duration 698s, previous duration 0s

Dead: total time 0s, count 2 Authen: request 29, timeouts 24

Response: unexpected 0, server error 0, incorrect 0, time 2ms Transaction: success 5, failure 6

Author: request 0, timeouts 0

Account: request 0, timeouts 0

(30)

30 Router#sh aaa sessions

Total sessions since last reload: 10 Session Id: 10

Unique Id: 12 User Name: testing IP Address: 10.62.75.95 Idle Time: 0

CT Call Handle: 0 Router#

E assim, se verificou que o Authorization e Authentication estavam a funcionar correctamente. Falta assim o Accounting, que se verificou vendo os logs durante o login e posterior logout do utilizador.

(31)

31

Figura 8 - Accounting - Registo de saída

Nas duas mensagens anteriores de Start e Stop é possível saber várias informações sobre a sessão como por exemplo, IP do cliente, causa da terminação da ligação (neste caso foi “User-Request”), duração da sessão ou tráfego da sessão. Estas informações podem servir para realizar estatísticas de utilização, para taxar os clientes consoante a utilização dos recursos, etc.

É importante notar que foi necessário criar regras no IPTables para abrir os portos UDP 1812 e 1813 que são usados pelo RADIUS, estas regras foram colocadas na chain de INPUT pois as mensagens RADIUS são destinadas ao router em si e não a um servidor na rede interna (caso contrário, teria de ser colocada na chain de FORWARD).

Conclusão

Com a realização deste trabalho ficou-se com um maior entendimento acerca da integração de serviços numa rede de computadores. A parte inicial do trabalho também foi muito importante, pois permitiu perceber como se configura uma

(32)

32 máquina Linux de raiz, desde a criação de partições e compilação do Kernel até à instalação e configuração das ferramentas que foram usadas durante a realização deste trabalho.

Foi ainda possível verificar a importância e o poder da ferramenta IPTables, em que durante a realização do trabalho surgiram situações em que estava tudo bem configurado mas nada funcionava até se colocarem regras no IPTables para permitir a passagem do tráfego desejado – um exemplo desta situação foi a configuração do Accounting no servidor de RADIUS em que o servidor não estava a receber as mensagens de Accounting do router externo.

Por fim, a configuração das restantes ferramentas permitiu ter uma percepção mais generalizada dum sistema com vários serviços integrados numa rede de computadores.

(33)

33

Bibliografia

Gentoo Handbook - http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1

Wikipedia – http://www.wikipedia.org/

FreeRADIUS – http://freeradius.org/

Quagga – http://www.quagga.net/

(34)

34

Anexos

Devido à dimensão dos ficheiros de configuração, optou-se por colocar os mesmos à parte do relatório para não tornar este demasiado extenso. (Ver ficheiro Anexos.rar)