Tutorial Firewall

download Tutorial Firewall

of 32

Transcript of Tutorial Firewall

R e l a t r i o d o Tr a b a l h o Final de Integrao de Redes e Servios

A 1 LINHA DE DEFESA

por

ANDR ONOFRE LIMAN 28838 IRS 09/10 ISEL

HTTP://PWP.NET.IPL.PT/ALUNOS.ISEL/28838/

ndiceIntroduo Instalao do Gentoo Incio da instalao Congurando opes de compilao (kernel e outras aplicaes) O novo ambiente de execuo Instalando o Kernel DNS (bind) Ficheiros de Congurao Testes efectuados Quagga Arquitectura do Sistema Cenrio de Testes Congurao do sistema Teste nal Avaliao Final Firewall Iptables O percurso de um pacote atravs do Iptables Mquina de Estados - Connection Tracking Cenrio 1 - Firewall base Single Packet Authorization - SPA Proteco contra Port Scans Cenrio 2 - Controlo Parental Cenrio 3 - Balanceamento de Carga Cenrio 4 - Falta de conana Desempenho da Firewall Concluso Bibliograa Anexo A - DNS Anexo B - iptables 1 2 2 3 3 4 5 5 6 7 7 7 8 9 11 12 13 14 15 17 17 18 18 19 19 20 21 22 27

IntroduoEste trabalho tem como base comum a todos os grupos a instalao e congurao de um sistema Gentoo; a implementao de um servidor DNS utilizando o Bind9; e a implementao de um router que separe uma rede interna (10.62.74.176/28) da rede externa (10.62.75.0/24), comunicando a existncia da rede interna atravs de OSPF, utilizando o Quagga. O desenvolvimento destes sistemas desta forma, tem a vantagem de serem bastante ecientes devido reduzida quantidade de aplicaes, estritamente necessrias, para o cumprimento das funes do servidor/router, facto esse que traz tambm outras vantagens como maior segurana e menor complexidade. Em seguida, implementada a parte do trabalho especca a cada grupo, neste caso: implementao de uma rewall utilizando o Iptables. O objectivo o de realar algumas regras essenciais preveno de ataques muito conhecidos, e tambm o de demonstrar aplicaes prticas de vrios mdulos do prprio Iptables, em forma de cenrios comuns no dia a dia de administradores de redes e sistemas.

1/30

Command (m for help): p Disk /dev/sda: 30.0 GB, 30005821440 bytes 240 heads, 63 sectors/track, 3876 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes Device Boot /dev/sda1 Start 1 End 14 Blocks 105808+ Id 83 System Linux

Instalao do Gentoo

We need to make this partition bootable. Type a to toggle the bootable ag on a partition and select 1. If you press p again, you will notice Athat an * is placed in the "Boot" column. na mquina virtual, arrancando a mquina a partir da imagem do cheiro instalao do sistema foi feita

install-x86-minimal-20091020.iso. Este CD detecta o hardware contido na mquina, carrega os drivers necesCreating the Swap Partition srios, e fornece ao utilizador um ambiente Gentoo para que se proceda com a congurao da placa de rede Let's now create the swap partition. To do this, type n to create a new partition, then p to tell fdisk that you want a primary partition. Then com uma ligaosecond primarynecessria para fazer download do kernel,for the rstque se procedaWhen prompted for type 2 to create the internet, partition, /dev/sda2 in our case. When prompted e para cylinder, hit enter. com o particiothe last cylinder, type +512M to conguraes necessrias ao you've done this, sistema operativo. namento do disco e outrascreate a partition 512MB in size. After alojamento dotype t to set the partition type, 2 to select the A instalao do Gentoo divide-se em trs fases, conhecidas por stages. Na stage1 tem-se te fazer bootstrap ao sistema,Listing 3.8: Partition listing compilador swap partition Code ou seja, compilar o after creating a gcc, a biblioteca de C e mais alguns programas essenciais. Na stage2 o que se faz for help): p um emerge system para instalar os programas necessrios para se ter um sistema Command (m basicamente base funcional. No caso deste projecto, foi escolhido a instalao stage3, ou seja, os stages 1 e 2 j implemenDisk /dev/sda: 30.0 GB, 30005821440 bytes tados (no CD63 sectors/track, 3876 cylinders 240 heads, install-x86-minimal-20091020.iso) e o que se vai explicar em seguida consiste na stage3.Units = cylinders of 15120 * 512 = 7741440 bytes

partition you just created and then type in 82 to set the partition type to "Linux Swap". After completing these steps, typing p should display a partition table that looks similar to this:

Incio da instalao Device Boot Start

End

Blocks

Id

System

/dev/sda1 * 1 14 105808+ 83 Linux Aps constatar que a 15 rede j se encontrava congurada (#/sbin/ifcong eth0), procedeu-se partio do /dev/sda2 81 506520 82 Linux swap disco /dev/sda que alojar o sistema. Este block device constitui uma interface que abstrai o administrador e as aplicaes Rootespecicidades do disco, nomeadamente se so SCSI, IDE, ou outro tipo. Parties so diCreating the das Partition vises lgicas do disco e existem trs tipos: primrio, estendido e lgico. As parties primrias tm a sua Finally, let's create the root partition. To do this, type n to create a new partition, then p to tell fdisk that you want a primary partition. Then informao armazenada nopartition, /dev/sda3 in our case. When prompted for the rst cylinder, hit enter. When prompteds potype 3 to create the third primary Master Boot Record (MBR), e como este tem tamanho reduzido (512 bytes), for the last ser denidos quatro parties primrias. rest of the remaining space on your parties primrias especiais, na dem cylinder, hit enter to create a partition that takes up theAs parties estendidas so disk. After completing these steps, typing p should display a medida em que,partition a necessidade de se this: dada table that looks similar to terem mais do que quatro parties, estas permitem a criao de mais parties dentro delas, after creating the root partition sendo essas ltimas conhecidas por parties lgicas, cujos dados no so manCode Listing 3.9: Partition listing tidos no MBR. help): p Command (m for Disk /dev/sda: 30.0 GB, 30005821440 bytes Com base no que at ento foi explicado, criaram-se as seguintes parties (/sbin/fdisk /dev/sda): 240 heads, 63 sectors/track, 3876 cylinders Units = cylinders of 15120 * 512 = 7741440 bytes Device Boot /dev/sda1 * /dev/sda2 /dev/sda3 Start 1 15 82 End 14 81 3876 Blocks 105808+ 506520 28690200

Id 83 82 83

System Linux Linux swap Linux

A partio sda1 tem 32MB e a partio de boot, ou seja, onde se armazena o kernel utilizado pelo sistema To save the partition layout and exit das primeiras aplicaes a serem executadas no arranque do computador. operativo e o boot loader, quefdisk, type w. Neste caso, mais especicamente, o BIOS tenta encontrar o boot sector do primeiro dispositivo de arranque, Code Listing 3.10: Save and exit fdisk ou seja, o disco utilizado. Isto signica que o BIOS executar o boot loader que se situa no MBR, boot loader Command (m for help): w esse que d ao utilizador a opo do sistema operativo a arrancar. Para esta instalao optou-se, de entre os boot loaders LILO e GRUB, peloyou can continue withpara essa escolha remete-nos s vrias vantagens que o GRUB GRUB. A razo Creating Filesystems. Now that your partitions are created, tem sobre o LILO. A primeira, e provavelmente a de maior importncia, consiste no facto do GRUB permitir 4.d. Creating Filesystems que se aceda a uma linha de comandos e se carregue outro kernel que no apenas os especicados no seu cheiro de congurao. Isto particularmente til quando se altera a congurao do LILO para carregar um Introduction kernel novo e esquece-se de manter a velha congurao. Se o novo kernel rebentar, -se obrigado a reiniciar a Now do CD/DVD/disquete. Outra vantagem do GRUB you don't care about what lesystem to choose and nica partirthat your partitions are created, it is time to place a lesystem on them.aIf de esta apenas ter de ser instalada uma are happy with what we use as default in this handbook, continue with Applying a Filesystem to a Partition. Otherwise read on to learn about vez, available lesystems... em caso de necessidade apenas o respectivo cheiro de congurao. O LILO obrithe tendo-se que alterar ga a que a cada alterao na congurao, se tenha de voltar a instalar o boot loader no MBR visto ser l que Filesystems se armazena a informao relativa s suas conguraes. Alesystems on Linux systems. e a partio de swap que serve como memria virtual quando a RAM se esgota. partio sda2 tem 512MB Finalmente, a and true Linux lesystem but doesn't have metadataresto do disco means that atribudo lesystem checks at ext2 is the tried partio sda3, cujo tamanho ocupou o journaling, which de 8GB routine ext2 mquina virtual, startup time can be quite time-consuming. There is now quite a selection of newer-generation onde ser montado (mount) a raiz do sistema de cheiros utilizado (root). journaled lesystems that can be checked Em seguida, foram formatadas as parties sda1 (mke2fs /dev/sda2) e sda3 (mke2fs -j /dev/sda3) com os sistemas de cheiros ext2 e ext3 respectivamente. Apesar do ext3 j ser um sistema de cheiros bastante tes15 of 72 tado e consequentemente convel, visto que o sda1 tem apenas 32MB, optou-se por utilizar o ext2 para no 8:35 PM 10/19/09 desperdiar o espao necessrio ao armazenamento da metadata referente ao journaling.The Linux kernel supports various lesystems. We'll explain ext2, ext3, ReiserFS, XFS and JFS as these are the most commonly used

Saving the Partition Layout

2/30

A seguir, foram montadas as parties sda3 e sda1 para posteriormente se criar toda a estrutura do sistema de cheiros. Essa estrutura ser criada com a ajuda dos dois seguintes cheiros: stage3-i686.tar.bz2 e portage-latest.tar.bz2 obtidos no site http://www.gentoo.org/main/en/mirrors.xml com o comando links. O stage3 tarball contm a estrutura bsica do sistema de cheiros usado no Gentoo Linux. Essa estrutura a necessria para prosseguir com a instalao do sistema. Quanto ao portage, este consiste numa aplicao de gesto de software, tida para muitos como o melhor gestor de software para ambientes Linux, e tambm considerada uma das grandes vantagens da distribuio Gentoo. O portage permitir que sejam feitas actualizaes ao sistema, e que sejam adicionadas e removidas aplicaes de forma bastante simples. Congurando opes de compilao (kernel e outras aplicaes) Apesar de se poderem alterar essas opes utilizando as variveis de ambiente, o que tornaria essas alteraes temporrias mediante o reinicio do sistema, o mais adequado aqui torn-las permanentes no cheiro /etc/make.conf que um cheiro de congurao do portage. Dentro deste cheiro encontram-se as variveis CFLAGS e CXXFLAGS que denem as opes de optimizao do compilador gcc para C e C++ respectivamente. Outra varivel que se deve adicionar a este cheiro, com a ajuda do comando mirrorselect o GENTOO_MIRRORS que dene de onde o portage dever efectuar os downloads necessrios. Finalmente, com a ajuda do mesmo comando mas com parmetros diferentes, dever-se- adicionar a varivel SYNC que indica qual o servidor rsync a utilizar quanto se estiver a actualizar a chamada portage tree. Esta consiste na coleco de executveis e scripts necessrios ao download e instalao de software. Agora que j se conguraram as opes de compilao, o prximo passo consiste em mudar do ambiente de execuo do LiveCD para o do sistema instalado com o comando chroot. Este comando altera a raz do sistema / para a directoria que se lhe indicar. Contudo, antes de se fazer isso, h que garantir que a resoluo de nomes, no que diz respeito rede, continua a funcionar no novo ambiente. Para isso copiado o cheiro /etc/resolv.conf para /mnt/gentoo/etc/, sendo /mnt/gentoo a directoria que servir de raiz ao novo ambiente Documentation -- Gentoo Linux x86 Handbook no novo ambiente, se poder obter informao Gentoo Linux de execuo. Outro facto importante a garantir o de,http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?f... referente ao hardware em utilizao e aos dispositivos (devices) a que se tem acesso. Para isso so montados (mount) o /proc (mount -t proc none /mnt/gentoo/proc) e o /dev (mount -o bind /dev /mnt/gentoo/dev) respectivamente. O primeiro mount (relativo aos proc) faz com que seja montado um sistema de cheiros do PATH="/bin:/usr/bin:/usr/local/bin:/opt/bin:/usr/games/bin" tipo proc na directoria indicada. Esta pasta contm informao sobre que processos encontram-se em execuROOTPATH="/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin" LDPATH="/lib:/usr/lib:/usr/local/lib:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3" o e pormenores relativos a essas execues, e tambm contm informao sobre recursos que se encontram MANPATH="/usr/share/man:/usr/local/share/man" INFODIR="/usr/share/info:/usr/local/share/info" alocados naquele instante pelo kernel. Quanto ao segundo mount (relativo ao dev), este faz com que o mesmo PAGER="/usr/bin/less" contedo /dev seja acessvel em dois stios simultaneamente. Isso feito para que os dispositivos detectados EDITOR="/usr/bin/vim" KDEDIRS="/usr" pelo actual sistema (Live CD) possam ser acedidos pelo novo ambiente.CONFIG_PROTECT="/usr/X11R6/lib/X11/xkb /opt/tomcat/conf \ /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ \ O novo ambiente de execuo /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf"

Um ambiente de execuo basicamente denido pela raiz do sistema de cheiros desse ambiente (neste caso pretende-se que seja o /mnt/gentoo) e pelas variveis de ambiente. A alterao da raiz do sistema 5.b. Dening Variables Globally feito com o comando chroot, enquanto que a alterao das variveis de ambiente feita pelo comando envupdate e pelo source /etc/prole. O cheiro /etc/prole um cheiro que contm variveis de ambiente que The /etc/env.d Directory abrangem todo o sistema. Para que melhor se perceba o env-update, h que se conhecer a directoria /etc/env.d. Nesta pasta encontramFor instance, especcos a cada a le called que utilize variveis de ambiente na the execuo, ou que necessite se cheiros when you installed gcc,aplicao 05gcc was created by the ebuild which containssua denitions of the following variables: delas para ser encontrada. Um exemplo disto o gcc:Code Listing 2.1: /etc/env.d/05gcc PATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" ROOTPATH="/usr/i686-pc-linux-gnu/gcc-bin/3.2" MANPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/man" INFOPATH="/usr/share/gcc-data/i686-pc-linux-gnu/3.2/info" CC="gcc" CXX="g++" LDPATH="/usr/lib/gcc-lib/i686-pc-linux-gnu/3.2.3"

To centralise the denitions of these variables, Gentoo introduced the /etc/env.d directory. Inside this directory you will nd a number of les, such as 00basic, 05gcc, etc. which contain the variables needed by the application mentioned in their name.

Other distributions tell you to change or add such environment variable denitions in /etc/profile or other locations. Gentoo on the other hand makes it easy for you (and for Portage) to maintain and manage the environment variables without having to pay attention to the numerous les that can contain environment variables. For instance, when gcc is updated, the /etc/env.d/05gcc le is updated too without requesting any user-interaction. This not only benets Portage, but also you, as user. Occasionally3/30 might be asked to set a certain environment variable system-wide. you As an example we take the http_proxy variable. Instead of messing about with /etc/profile, you can now just create a le (/etc/env.d/99local) and enter your denition(s) in it:Code Listing 2.2: /etc/env.d/99local

Com esta arquitectura, nica do Gentoo, consegue-se organizar melhor as variveis de ambiente do sistema. Por exemplo se se quisessem acrescentar variveis, tudo o que se teria de fazer seria criar um cheiro /etc/env.d/99local com, por exemplo, a informao de proxy HTTP. Percebendo-se este esquema, o que o env-update faz concatenar as vrias variveis idnticas dos vrios cheiros. Esta concatenao na verdade apenas acontece para algumas variveis como o PATH, importante na localizao de cheiros nomeadamente executveis, e como MANPATH, importante para o comando man localizar os manpages especcos ao programa que se pretenda. O resultado dessas concatenaes, ou sobreposies, ser colocado ento no cheiro /etc/prole.env que , por sua vez utilizado por /etc/prole. O env-update tambm extrair a informao de LDPATH (contm lista de directorias onde se situam as bibliotecas utilizadas pelo dynamic linker) para criar /etc/ld.so.conf. Aps fazer isso, o env-update invocar internamente o comando ldcong para recriar /etc/ld.so.cache que utilizado pelo dynamic linker - parte do sistema operativo que carrega e liga as bibliotecas utilizadas pelas aplicaes em execuo. Para que se notem as diferenas provocadas pelo comando anterior imediatamente, necessrio a execuo do comando source /etc/prole. que basicamente faz um refresh s variveis de ambiente do sistema. Instalando o Kernel O primeiro passo foi o de actualizar o portage tree para a verso mais recente (emerge --sync --quiet). A seguir foi denido o perl do sistema (eselect prole list). Este perl muito importante na denio de valores por omisso nas principais variveis de ambiente do sistema, neste caso o USE, e tambm importante no bloqueio do sistema de forma a que este aceite apenas um determinado conjunto de aplicaes. Por exemplo, se o prole utilizado for o desktop, no USE constaro opes que pressupem que a mquina deseja instalar aplicaes como o kde ou o gnome, e mesmo aplicaes de suporte a multimdia (udio/video). Procedeu-se ento com o download do kernel (emerge gentoo-sources) e posteriormente foram feitas as seguintes conguraes no kernel tendo em ateno o facto de que todos os drivers, vitais ao arranque do kernel, fossem compilados dentro do kernel e no como mdulos, de forma a que o sistema arranque sem problemas, visto que os mdulos s so carregados no kernel aps este arrancar. Conguraes: escolha da famlia correcta de processadores; suporte aos sistemas de cheiros utilizados (ext2 e ext3, proc e virtual lesystem); suporte ao multi-processamento; e suporte a dispositivos USB. Em seguida foram compilados o kernel e os respectivos mdulos e, nalmente, colocado a imagem gerada na partio de boot. Aps a instalao do kernel foi congurado o cheiro /etc/fstab (contm informao relativa a que dispositivos de bloco - /dev - devem ser montados, onde e como), foi congurada a rede (/etc/conf.d/net) de forma a pedir endereo IP usando DHCP por omisso; foi congurada a placa de rede eth0 para se iniciar com o arranque do runlevel 3 (default); foi congurado o teclado para a lngua portuguesa (/etc/conf.d/keymaps); e foram instalados o syslog-ng (logs do sistema), vixie-cron (possibilidade de agendar tarefas nicas ou peridicas no sistema), slocate (indexao dos cheiros do sistema para rpida localizao dos mesmos), dhcpcd (pedidos dhcp como cliente), sudo (delegao de autorizao de execuo de comandos), e vim (editor de texto preferido do autor deste relatrio). Antes de terminar a instalao do Gentoo com o LiveCD, teve-se de instalar o GRUB, cuja escolha j se explicou na seco Incio da instalao. Finalmente fez-se reboot ao sistema, mas sem antes desmontar (umount) todos os devices montados: /mnt/gentoo/boot , /mnt/gentoo/dev , /mnt/gentoo/proc e /mnt/gentoo/. Com o reinicio do sistema, j a partir do disco, removeram-se os cheiros correspondentes ao stage3 e ao portage. Em seguida foi acrescentada uma password conta root, e foi criada uma conta ao utilizador alima, com password e respectiva pasta em /home/alima, sendo este utilizador pertencente aos grupos users, wheel. Este ltimo grupo particularmente til para a congurao do /etc/sudoers onde se especica que todos os utilizadores que pertencem ao grupo wheel tem permisso de acesso a pastas/cheiros/programas cujos acessos so normalmente vedados ao root.

4/30

DNS (bind)Existem trs tipos de servidores DNS: primrios, secundrios e de cache. Os primrios so considerados servidores DNS com autoridade sobre uma determinada zona (sub-domnio). sobre eles que so feitas as alteraes congurao das diferentes zonas contidas no domnio em causa. Os secundrios so servidores de backup ou de distribuio de carga relativamente aos primrios. Quando um cliente faz uma interrogao a um servidor secundrio, este responde com a mesma autoridade que o primrio, contudo correndo-se o risco da resposta no conter uma possvel actualizao recentemente feita sobre o primrio. Em relao ao sincronismo entre os servidores primrios e secundrios, o primrio pode noticar os servidores secundrios que estejam indicados no seu cheiro de congurao, ou os secundrios podem periodicamente requisitar actualizaes ao primrio (updates). Quanto aos servidores cache, possvel distinguir as suas respostas das dos primrios e secundrios, pois contm nessa resposta a indicao de que essa resposta no tem autoridade. O que estes servidores fazem , caso no encontrem a Fully Qualied Domain Name (FQDN) na cache, fazer o pedido recursivamente a um servidor primrio/secundrio. Caso encontre o FQDN pedido na interrogao, ento dada a resposta ao cliente. Ficheiros de Congurao Eis o cheiro de congurao principal /etc/bind/named.conf : - Anexo A tabela A.1 No /etc/bind/named.conf congura-se o bind para ser tanto um servidor de caching, para os domnios que este desconhea, reencaminhando-os para um dos root servers contidos no cheiro named.ca, e como servidor de primrio para o sub-domnio atribudo ao grupo 2: g2.lrcd.local. Outro cheiro importante na congurao, o indicado na congurao da zona responsvel pelo sub-domnio do grupo, o pri/ g2.lrcd.local.zone. A congurao contida nesse cheiro mostrado na seguinte tabela: - Anexo A tabela A.2 Neste cheiro d-se um TTL aos registos de uma semana, ou seja, este o tempo mximo que um servidor cache poder manter os registos retornados deste cheiro, a no ser que no prprio record seja indicado outro valor que se sobrepor ao TTL global. O serial number um nmero na forma AAAAMMDDxx onde AAAA corresponde ao ano, MM aos dois dgitos do ms, DD aos dois dgitos do dia, e xx ao nmero da actualizao deste cheiro. Este nmero importante porque, quando um servidor secundrio, que tenha este servidor como primrio, quiser actualizar a sua base de dados, com base neste nmero que o secundrio saber se necessria ou no uma actualizao. Mais especicamente, se o nmero de srie do servidor primrio for maior (indicando que houve uma nova actualizao) que o nmero de srie da ltima actualizao retirada desse mesmo primrio por parte do secundrio, ento necessrio actualizar-se. Quanto ao valor de Refresh, este indica com que periodicidade deve ser vericado o nmero de srie, para ver se necessria uma actualizao. O Retry indica, num cenrio onde o primrio no responde ao secundrio que pretende ver se h ou no a necessidade de se actualizar, com que periodicidade deve novamente tentar comunicar. O Expire indica aos servidores secundrios que faam cache aps quanto tempo, sem conseguir contactar com um servidor primrio, devem descartar o registo. O Minimum indica aos servidores de cache aps quanto tempo, caso no consigam contactar com um servidor primrio, devem invalidar os registos. Quanto ao resto da congurao, indica-se o ip do host server, e d-se o nome andre tambm a este host. No cheiro pri/g2.lrcd.local.rev indicado como proceder com os reverse lookups. Neste caso o nico registo o do host server.g2.lrcd.local que tem o ip 10.62.75.132. - Anexo A tabela A.3 Para pr em prtica estas conguraes, colocou-se o daemon named em execuo (/etc/init.d/named start). De salientar que que existe um cheiro de congurao chamado /etc/conf.d/named que contm uma varivel OPTIONS que indica os parmetros a serem passados na execuo do daemon named. Por omisso, esta

5/30

varivel encontra-se vazia. Isto signica que o daemon procurar o chiro de congurao principal named.conf na directoria /etc/bind e que, tambm por omisso, ser executado com as permisses do utilizador named, especialmente criado para este efeito. Caso, por exemplo, se quisesse executar o daemon com as permisses de root, e com o cheiro named.conf denido noutra directoria, apenas ter-se-ia de colocar na varivel OPTIONS o valor -u root -c /outra_dir. Testes efectuados Para testar toda esta implementao executaram-se, com a ajuda do comando dig, as seguintes instrues: - Anexo A tabela A.4 -

6/30

2

Quag

1.2 System Architecture

Traditional routing software is made as a one process program which provides all of t routing protocol functionalities. Quagga takes a dierent approach. It is made from collection of several daemons that work together to build the routing table. There may O Quagga consiste num pacote de software que disponibiliza servios de routing como RIP (RIPv1, RIPv2 e several protocol-specic routing daemons and zebra the kernel routing manager. RIPng), OSPF (OSPFv2 e OSPFv3) e BGP (BGP-4 e BGP-4+). Este software suporta tanto IPv4 como IPv6, e

Quagga

The tambm tem suporte para SNMP. ripd daemon handles the RIP protocol, while ospfd is a daemon which suppor

Arquitectura do Sistema table and for redistribution of routes between dierent routing protocols, there is a kern Com o Quagga instalado, routing table managercomo um router dedicado apossando-se das interfaces do daemons o sistema comporta-se zebra daemon. It is easy to add a new routing protocol prprio sistema. As actualizaes recebidas atravs dos protocolos de routingother software. You need to run only t the entire routing system without aecting any servem posteriormente para actualizar a tabela de routing do kernel. Essa actualizaowith routing protocolstabela de Thus, user may run a speci protocol daemon associated feita, directamente in use. routing do kernel, por um daemon chamado zebra. Indirectamente, a informao obtida pelo zebra -lhe fornecida por daemons daemon and send routing reports to a central routing console. especcos implementao de cada protocolo de routing, por exemplo, o OSPFv2 tem o daemon ospfd. Ou There is no need for these daemons to be running on the same machine. You can ev seja, o quagga utiliza a arquitectura demonstrada na gura seguinte, com a exibilidade digna dum software run several same protocol daemons on the same machine. This architecture creates ne open-source:

OSPF version 2. bgpd supports the BGP-4 protocol. For changing the kernel routi

possibilities for the routing system. +----+ |bgpd| +----+ +----+ |ripd| +----+ +-----+ |ospfd| +-----+

+-----+ |zebra| +-----+ | +---------------------------|--+ | v | | UNIX Kernel routing table | | | +------------------------------+Figura1 - Arquitectura deArchitecture Quagga System um Sistema Quagga(retirada do manual de referncia Quagga 0.99.4, 7/2006 - Kunihiro Ishiguro)

Multi-process architecture brings extensibility, modularity and maintainability. At t same time it also brings many conguration les and terminal interfaces. Each daemon h Com esta arquitectura tem-se:own conguration le and terminal interface. When you congure a static route, it mu its extensibilidade, dada facilidade de adicionar suporte a novos protocolos com a simples construo do daemon prprio; conguration le. When you congure BGP network item be done in zebra e modularidade, dado que o sistema encontra-se dividido must be done mdulos a facilidade de manuteno aumenta le. This podem-severy annoying thing. To resolve thembgpd conguration visto que can be a connar os problemas respectivos a problem, Quag dulo, apenas a esse mdulo. provides integrated user interface shell called vtysh. vtysh connects to each daemon wi UNIX domain socket and then works as a proxy for user input.

A comunicao entre os vrios daemons com o zebra, d-se atravs de um protocolo denominado por ZEBRA Quagga was planned to use multi-threaded o localhost when it runs PROTOCOL. Esta comunicao tipicamente feita utilizando sockets TCP sobremechanism(127.0.0.1), sendo with a kern that e, por exemplo, o ospfd escuta at the moment, the thread das grandes que o zebra escuta no porto 2601supports multi-threads. But sobre o 2604. Isto consiste numalibrary which comes wi gnu/Linux or a de se has some problems with running reliable services such as routi vantagens da utilizao deste sistema, que FreeBSDpoderem executar daemons em mquinas remotas, estansoftware, so we dont use threads at all. Instead we use the select(2) system call f do o zebra centralizado noutra.

multiplexing the events.

Cenrio de Testes

A mquina virtual que se tem vindo a desenvolver (a que se vai referir neste captulo como QUAGGA) ne1.3 Supported Platforms cessitar de duas interfaces. Contudo at agora s existe a interface eth0 no QUAGGA, devidamente conCurrently Quagga supports gnu/Linux, BSD and Solaris. Porting Quagga to other pla gurada em /etc/conf.d/net como cong_eth0 = ( dhcp ) , sendo o ip atribuido ao grupo 2 o 10.62.75.132. forms is not (cd /etc/init.d; ln -s net.lo net.eth1; rc-update add most be limited A segunda interface eth1 foi ento criadatoo dicult as platform dependent code should net.eth1 default) to the zeb daemon. com o ltimo endereo da rede que me foi atribuda Please let us know when y e congurada, em /etc/conf.d/net Protocol daemons are mostly platform independent. 10.62.74.176/28 nd out Quagga runs on a platform congurao necessria cong_eth1 = ( 10.62.74.190 netmask 255.255.255.240 ) . Outrawhich is not listed below. a activao da mquina para efectuar o re-encaminhamento de pacotes de uma interface para a outra. Isto normalmente feito da seguinte forma: #echo 1 > /proc/sys/net/ipv4/ip_forward ou #sysctl -w net.ipv4.ip_forward=1. Contudo, apesar disto funcionar, s o faz at que a mquina se reinicie. Caso se pretenda que a alterao seja permanente h que inserir manualmente no cheiro /etc/sysctl.conf a entrada net.ipv4.ip_forward=1, entrada essa que j dever constar no cheiro, mas com o valor por omisso zero.

7/30

Em relao s redes interna (10.62.74.176/28) e externa (10.62.75.132/24), colocou-se o eth0 ligado rede externa numa congurao bridge na porta ethernet do pc, e colocou-se o eth1 ligado rede interna numa congurao tambm bridge na placa de rede wireless do pc, onde se criou uma rede ad-hoc com WEP128 (apenas para impedir que qualquer um acedesse rede). Isto melhor explicado na seguinte gura:

Figura2 - Estrutura lgica do cenrio montado

Como se pode constatar pela gura anterior, ainda necessria uma estao interna (a que chamaremos de BT - backtrack) rede privada que me foi atribuda (10.62.74.176/28). Para esse efeito, foi utilizada uma imagem de um backtrack, apenas porque era uma imagem que j tinha no pc, e porque o objectivo o de testar a ligao da rede interna com o exterior, o que se faz com um simples ping. No BT foi necessrio congurar a sua nica interface eth0, ligada sicamente atravs da mquina virtual placa de rede wireless, com o ip esttico 10.62.74.177 (primeiro disponvel) visto que o QUAGGA no tem um servidor DHCP que fornea essa informao. Outra informao importante dada por servidores DHCP o default gateway, que neste caso ter tambm de ser congurada manualmente (route add default gateway 10.62.74.190). Para vericar se tudo cou bem congurado, para alm do comando #ifcong eth0, foi executado o comando #netstat -rn (imprime a tabela de routing do kernel sem tentar resolver os ips recorrendo a DNS) tendo sido vericado o seguinte output: Kernel IP routing table Destination Gateway 10.62.74.176 0.0.0.0

0.0.0.0

10.62.74.190

Genmask 255.255.255.240 0.0.0.0

Flags MSS Window irtt U 00 0 UG 00 0

Iface eth0 eth0

Congurao do sistema Para o cenrio que se est a desenvolver, o protocolo de routing utilizado ser o OSPFv2. Isto signica que ter-se- de congurar tanto o zebra (obrigatrio) como o ospfd. Em relao s conguraes relativas ao routing o zebra e os outros daemons (neste caso ospfd) permitem o acesso via telnet, onde ser apresentado um terminal que busca a total semelhana com o Cisco IOS. Esta outra grande vantagem do Quagga, que faz com que a transio de administradores habituados ao Cisco IOS, que o sistema mais utilizado no mercado, seja feita de forma transparente. Outra vantagem do Quagga o de fornecer um terminal especial, denominado por vtysh, que abstrai o administrador das inmeras transies de um terminal de um daemon para outro. Este vtysh recebe os comandos e conforme o contexto destes, assim os reencaminha para um daemon ou para outro. A gravao das conguraes feitas num terminal feita com o comando write, que guarda-as nos cheiros de congurao respectivos a cada daemon na directoria /etc/quagga/.

8/30

Quanto congurao do daemon propriamente dito, tem-se o cheiro /etc/conf.d/zebra onde temos a opo ZEBRA_OPTIONS onde se indicam os parmetros a passar ao daemon quando se lhe colocar em execuo. preciso indicar que a aplicao (zebra) se executar em modo daemon (-d) podendo-se assim execut-lo em background; preciso indicar qual o cheiro de congurao, com as conguraes iniciais, e onde dever armazenar as conguraes alteradas no acesso ao seu terminal (-f); preciso indicar exactamente onde car o cheiro com o seu process id (-i); tambm preciso indicar o endereo (-A), o porto (-P) onde dever esperar que venham acessos ao terminal, o utilizador e o grupo cujas permisses sero atribudas ao daemon zebra em execuo. A ordem de tarefas: 1 acede-se a todos os terminais (ou s a um - vtysh) e acrescentam-se as conguraes todas que se pretendem; 2 armazenam-se as conguraes feitas com o comando write. Eis o cheiro de congurao do ospfd (/etc/quagga/ospfd.conf): ! OSPFd sample conguration le ! ! hostname ospfd password zebra enable password xpto_123 ! interface eth0 ip ospf authentication message-digest ip ospf message-digest-key 20 md5 mesmosimples ! router ospf network 10.62.74.176/28 area 75 network 10.62.75.0/24 area 75 area 75 authentication message-digest area 75 default-cost 1000 passive-interface eth1 !

Teste nal O teste nal basicamente consiste em testar a ligao da rede interna externa, o que se vai fazer com um ping do BT a uma estao externa rede. Aps todas as conguraes previamente descritas no QUAGGA, foram colocados em execuo tanto o zebra (#/etc/init.d/zebra start #rc-update add zebra default) como o ospfd (#/usr/sbin/ospfd -d -u daemon -g daemon). Para se constatar que o ospf funciona bem entrou-se no terminal do ospf via telnet (normalmente #telnet 127.0.0.1 ospfd mas neste caso #vtysh) onde, aps se fazer #enable, executou-se o comando #show ip route pelo que se obteve o seguinte output:

9/30

server# sh ip route Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route O 0.0.0.0/0 [110/1010] via 10.62.75.253, eth0, 00:00:16 K>* 0.0.0.0/0 via 10.62.75.254, eth0 O>* 10.62.74.0/28 [110/20] via 10.62.75.57, eth0, 00:00:17 O>* 10.62.74.16/28 [110/20] via 10.62.75.57, eth0, 00:00:17 O>* 10.62.74.160/28 [110/110] via 10.62.75.131, eth0, 00:00:11 O 10.62.74.176/28 [110/10] is directly connected, eth1, 00:00:17 C>* 10.62.74.176/28 is directly connected, eth1 O 10.62.75.0/24 [110/10] is directly connected, eth0, 00:00:17 C>* 10.62.75.0/24 is directly connected, eth0 K * 127.0.0.0/8 is directly connected, lo C>* 127.0.0.0/8 is directly connected, lo

Para vericar quais os neighbors executou-se o comando #show ip ospf neighbor: server# sh ip ospf neighbor Neighbor ID 10.62.75.57 10.62.74.174 10.62.75.254 Pri State Dead Time 1 Full/Backup 00:00:32 1 Init/DROther 00:00:39 1 Full/DR 00:00:38 Address Interface RXmtL RqstL DBsmL 10.62.75.57 eth0:10.62.75.132 1 0 0 10.62.75.131 eth0:10.62.75.132 0 0 0 10.62.75.253 eth0:10.62.75.132 0 0 0

Finalmente, para verificar a ligao do BT com redes externas, foi executado no prprio BT o comando #ping -c 1 -R 193.137.220.1: PING 193.137.220.1 (193.137.220.1) 56(124) bytes of data. 64 bytes from 193.137.220.1: icmp_seq=1 ttl=61 time=4.86 ms RR: 10.62.74.177 10.62.75.132 193.137.221.3 193.137.220.125 193.137.220.1 193.137.220.1 193.137.221.10 10.62.75.253 10.62.74.190

--- 193.137.220.1 ping statistics --1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 4.869/4.869/4.869/0.000 ms

10/30

Avaliao Final O Quagga tem vrias vantagens trazidas pela sua arquitectura, que a tornam muito exvel - dado por exemplo se poderem executar daemons em mquinas diferentes - e tambm que a tornam modular e consequentemente menos exposta a erros globais que contaminem todo o sistema. O suporte ao IPv6 outra funcionalidade que demonstra a inteno deste sistema em ser uma opo no s agora como no futuro. Uma funcionalidade que desperta interesse o suporte a MPLS, o que demonstra empenho por parte da equipa que desenvolve o Quagga em traz-lo para o mesmo patamar de solues mais caras e h mais tempo no mercado. Contudo, o Quagga tambm tem, pelo menos ainda, algumas desvantagens. Um exemplo o facto do sistema no suportar alguns comandos bsicos do Cisco IOS como o caso do #enable secret xpto. Outro exemplo o facto do Quagga no suportar mltiplos processos, no caso vericado, de OSPF. Estas desvantagens obrigam a que se conclua que, apesar deste sistema ser uma muito boa soluo para ambientes menores, quando a complexidade aumenta, tanto a nvel de rede, como a nvel de segurana, torna-se necessria a passagem a solues dedicadas e proprietrias com maiores funcionalidades.

11/30

Firewall IptablesUm mnimo de segurana praticamente obrigatrio nos dias que correm. E, numa boa e slida implementao da chamada segurana em camadas, o rewall a primeira linha de defesa. deste facto que advm toda a importncia desta ferramenta.

A implementao iptables da Netlter uma stateful packet inspection (SPI) packet ltering rewall, ou seja, capaz de ltrar pacotes da rede enquanto mantm estado sobre o contexto destes mesmos pacotes. Isto importantssimo para a deteco de ataques tpicos a stateless packet lters (ataques explicados mais frente) que no mantm estado. No obstante o facto do iptables ser um SPI, este contm extenses que lhe permite restringir e/ou aceitar acessos com base em strings contidas no interior do datagrama (camada 7), e tambm com base nos endereos MAC (camada 2). No entanto, a anlise, nomeadamente aos dados da camada de aplicao degradam consideravelmente o desempenho da rewall, e nunca substituir um proxy que perceba de raiz o protocolo aplicacional que se pretenda analisar.

Um dos ataques que se fazem aos stateless packet lters, aproveitando o facto destes no manterem estado das ligaes, explorar as regras que se inserem na rewall para permitir que as respostas a pedidos internos passem pela rewall. Isto pode ser feito de duas formas. A primeira permitindo que passem, no sentido de fora para dentro, todos os pacotes com origem em portos inferiores a 1024 e com destino a portos superiores a esse mesmo valor. A segunda consiste em permitir passagem a todos os pacotes que tenham os bits ACK ou RST (cabealho TCP) activos. Qualquer um dos casos facilmente explorado. O primeiro exemplo no consegue negar acesso a atacantes que tenham conseguido instalar backdoors em computadores dentro do permetro de segurana que quem escuta de ligaes em portos acima do 1024. O segundo cenrio batido pela capacidade de se manipularem os cabealhos dos protocolos, nomeadamente activar o ACK do TCP. Ambos estes cenrios so fraquezas que j no se pem no caso de SPIs, dado que se, por exemplo, se receber um pacote com o ACK activo, mas no se tenha em memria a informao de que houve um pacote de dentro para fora que justicasse esse ACK, negado o acesso ao pacote.

Outro ataque especco aos stateless packet lters a explorao da diviso de pacotes IP, que excedam o MTU de um canal, em fragmentos. O problema da fragmentao advm do facto da informao relativa ao cabealho TCP/UDP (ou outro protocolo sobre IP), importante para a ltragem, s aparecer no primeiro fragmento - o fragmento 0. Consequentemente, as primeiras implementaes de rewalls (stateless packet lters) deixavam passar todos os fragmentos iguais ou superiores a 1, baseando-se no facto de que caso no tenha sido permitido o acesso ao fragmento 0, os seguintes no fariam sentido e seriam descartados pela mquina destino. Contudo esse no foi o caso, dado que vrias implementaes errneas do TCP/IP, em vrios sistemas operativos, ordenavam e reconstruam o pacote mesmo que faltasse o fragmento 0. Isto signica que um atacante apenas tem de enviar pacotes fragmentados com o cabealho TCP/UDP/ICMP no fragmento n, sendo n>0. Outras implementaes, ao no receber o fragmento 0, resultavam num crash do sistema. Estes problemas no se pem com SPIs, dado que aos pacotes fragmentados com o mesmo identicador de fragmentao -lhes aplicada a mesma deciso tomada para o fragmento 0 correspondente. No caso especco ao iptables, se se utilizar o connection tracking (mdulo que efectivamente o torna no SPI) ou NAT, tem-se a garantia de que o pacote juntado de novo antes de se atingir o cdigo de ltragem.

12/30

O percurso de um pacote atravs do Iptables Explicar-se-o trs casos na gura 3: recepo, emisso e re-encaminhamento de um pacote.

Figura 3 - Caminho efectuado por um pacote atravessando o Iptableshttp://www.frozentux.net/iptables-tutorial/iptables-tutorial.html

13/30

Chegando um pacote da rede, este pode ser acedido e/ou manipulado em diversos pontos (retratados na gura 3 pelas formas ovais). De salientar que no obrigatria nenhuma aco em qualquer um desses pontos. O primeiro ponto a tabela raw da cadeia PREROUTING. Este ponto utilizado para aceder a pacotes antes de se aplicar o connection tracking (ver seco Mquina de Estados a seguir), podendo-se inclusivamente indicar que no se quer que o pacote em causa passe pelo connection tracking. A seguir, entra em aco o connection tracking e s depois se chega ao segundo ponto, a tabela mangle tambm da cadeia PREROUTING. Nos pontos de mangling dada a opo de se alterar o pacote, neste caso por exemplo, alterar o TOS do cabealho IPv4. O terceiro ponto a tabela nat ainda da cadeia PREROUTING. Neste colocam-se, caso necessrio as regras de DNAT. Isto tem de ser feito antes do re-encaminhamento para que o pacote seja reencaminhado de acordo com o novo IP destino. E o passo seguinte, exactamente a deciso de re-encaminhamento, onde apenas se faz a distino entre se o pacote tem destino local ou remoto. Caso o pacote tenha destino local, o prximo ponto o da tabela mangle da cadeia INPUT. Neste ponto so efectuadas alteraes a cabealhos, depois do pacote ter sido encaminhado e antes de ser recebido pela aplicao. O ponto seguinte o da tabela lter e cadeia INPUT. Neste so aplicados os ltros necessrios. De notar que independentemente de qual a interface receptora, se o pacote tem destino local, passa obrigatoriamente por este ponto. Finalmente, caso o pacote seja aceite pelas regras de ltragem, chega ento aplicao. Caso o pacote tenha destino remoto, o prximo ponto o da tabela mangle da cadeia FORWARD. Neste pode ser alterado o pacote, de acordo com necessidades muito especcas, depois de ter passado pelo encaminhamento inicial mas antes da ltima deciso de encaminhamento (dado que neste ponto podem ser feitas alteraes ao pacote - ex TOS - que alterem a interface de sada). Em seguida tem-se o ponto da tabela lter ainda do cadeia FORWARD, por onde passam todos os pacotes que sejam re-encaminhados caso sejam aceites pelas regras aqui colocadas. A seguir tomada nova deciso de encaminhamento, devido a possveis alteraes inseridas pelo ponto da tabela mangle da cadeia FORWARD j referida. Finalmente, o pacote passa por dois pontos, o da tabela mangle da cadeia POSTROUTING, e o da tabela nat da mesma cadeia. Neste ltimo, onde normalmente se faz o SNAT, tipicamente usado para permitir acesso, aos servidores internos mapeados por DNAT, dos computadores tambm internos que tentem aceder aos IPs pblicos desses servidores (IP da interface pblica do router/rewall externo), ou para esconder IPs internos do exterior. O ltimo cenrio a ser considerado do envio de um pacote. Nestes casos, o pacote submetido a uma deciso de encaminhamento e, a seguir, passa pelas tabelas raw, mangle, nat, e lter da cadeia OUTPUT. Na tabela raw onde se pode aceder ao pacote antes deste passar pelo connection tracking que tem lugar logo em seguida, para atribuir estado ao pacote antes deste sair da mquina. A seguir o pacote passa pela tabela mangle, e nat que tm funes idnticas s j explicadas nas cadeias anteriores. Aps o nat, dado que o pacote pode ter sido alterado tanto pelo mangle como pelo prprio nat, h que passar novamente por outra deciso de re-encaminhamento. Finalmente o pacote passa pela ltragem e pela cadeia POSTROUTING explicada j no pargrafo anterior. Apenas de salientar que, na insero de regras utilizando Iptables, caso no se indique explicitamente que tabela se pretende utilizar, assume-se por omisso a tabela lter. Mquina de Estados - Connection Tracking O conntrack um mdulo do kernel (apesar de poder tambm poder ser compilado como parte interna deste) que permite ao kernel atribuir um estado a um pacote recebido, por enviar, ou em trnsito. Isto permite que o Iptables congure regras que ltrem pacotes com base nesses estado. Os estados acessveis no modo user space so: NEW, ESTABLISHED, RELATED, INVALID e UNTRACKED. Este mdulo, apesar de poder ser desactivado, hoje em dia j no se lhe desactiva devido s falhas inerentes aos stateless packet lters. Quando activo, o conntrack actua sempre nas cadeias PREROUTING (para pacotes recebidos ou em trnsito) e OUTPUT (para pacotes a enviar), e garante que haja sempre desfragmentao de fragmentos recebidos antes de proceder com a ltragem. Em seguida, para melhor se perceber todo o poder da exibilidade do Iptables, vai-se tirar partido de algumas das suas extenses, desenvolvendo-se cenrios que utilizem alguns dos vrios mdulos desta implementao.

14/30

Cenrio 1 - Firewall base Este cenrio tem como objectivo demonstrar e justicar a implementao de uma rewall com as regras mnimas para proteger a rede interna contra os ataques mais conhecidos. A listagem da rewall pode ser vista a seguir: - Anexo B Output 1 (e cdigo B.1 - script que originou a rewall) Em primeira anlise, a cadeia INPUT, ou seja, todos os pacotes que tenham como destino a prpria rewall. As regras 1 e 2 registam e negam respectivamente o acesso a pacotes no estado INVALID. Destes podem constar mensagens de erro ICMP que no estejam relacionadas com quaisquer ligaes, ou pacotes que no tenham sido identicados devido falta de recursos como memria na mquina onde se encontra o rewall. As regras 3 e 4 registam e negam acesso a pacotes IP que contenham opes no cabealho. Isto resulta de um tipo de ataque muito popular em casos onde a autenticao feita com base em endereos IP de origem (ex: TCP wrappers em sistemas UNIX; e ACLs da IIS em sistemas NT). Falsicar o seu IP (IP spoong) por si s no suciente na maior parte das vezes onde o atacante estar fora da rede do IP falsicado, ou seja, no retorno da comunicao os pacotes no passaro por ele. Contudo, se se utilizar o source routing, pode-se utilizar o loose routing para fazer com que os pacotes de resposta passem pelo prprio atacante. Da a importncia de negar estes pacotes em rewalls de fronteira, dado que normalmente o debug (para o qual estas opes foram concebidas) feito na rede interna, e no entre a rede interna e externa (cenrio tpico de um ataque). A regra 5 aceita pacotes cujas ligaes j tenham sido estabelecidas (ESTABLISHED), ou seja, comunicaes que tenham sido originadas pela prpria rewall, e tambm aceita pacotes que estejam relacionados (RELATED) com outras comunicaes j estabelecidas, como so os casos de FTP em modo activo, e mensagens de erro ICMP como host unreachable. A regra 6 aceita pacotes cuja origem seja a inteface de loopback. As regras 7 e 8 aceitam queries DNS (udp) ao porto 53. De salientar que isto apenas foi feito para facilitar a implementao do cenrio de testes com mquinas virtuais, pois a ltragem de pacotes deve ser o nico objectivo da mquina onde se implementa uma rewall. Isto porque no se quer deixar toda a rede interna vulnervel caso um atacante consiga penetrar dentro da rewall devido a uma vulnerabilidade de outra aplicao, neste caso o Bind9. Outro pormenor importante o de proteger a resoluo de nomes DNS de ataques de Negao de Servio (DoS). Isto no foi aqui feito porque o objectivo deste cenrio base o de demonstrar as vrias funcionalidade desta rewall, sendo que esta funcionalidade de limitao de trfego demonstrada na cadeia FORWARD, onde so protegidos os utilizadores da rede interna de ataques Syn Flood e de portscans. A regra 9 aceita trfego OSPF (protocol type 89) para que a implementao do Quagga se comunique com os vizinhos. Neste caso, no se aplica a preocupao de uma aplicao extra na mesma mquina que a rewall, pois esta normalmente se executa na mesma que o router, funo esta desempenhada com a ajuda do Quagga. A nica forma de se explorar neste caso o Quagga encontrando uma vulnerabilidade no protocolo OSPF o que, a ser possvel, ter-se-o problemas muito maiores do que somente a segurana da rede interna. Nesta regra 9 poder-se-ia utilizar o mdulo ttl para ltrar pacotes que, sendo vizinhos, tm de certeza TTL igual a 1 (... -m ttl --ttl-eq 1) e tambm poderia, apesar de perder alguma exibilidade, ltrar os IPs origem dos OSPF NEIGHBOURS. Porm, tanto o TTL como o IP origem podem ser facilmente falsicveis, e como o protocolo OSPF trata da sua prpria segurana (autenticidade e integridade com MD5) achou-se no ser necessrio um controlo muito apertado do trfego OSPF. A cadeia INPUT termina com a regra 10 que regista todos os pacotes que cheguem a este ponto, ou seja, aqueles cujo acesso ser negado, dado que a poltica de todas as cadeias (INPUT/OUTPUT/FORWARD) so de negao. Na cadeia OUTPUT por onde passam todos os pacotes que tenham sido gerados pela prpria mquina, as regras 1 e 2 tm as mesmas funes que as respectivas cadeia INPUT. As duas regras seguintes (3 e 4) permitem restringir trfego de sada a apenas aquele que tenha os IPs origem respectivos mquina, ou seja, de uma das interfaces. Isto apenas um pormenor (irrelevante se se assumir que a mquina gerida apenas por

15/30

administradores de conana) que impossibilita o spoong a partir da mquina rewall. A ltima regra 5 aceita o envio de trfego interface loopback. De notar que aqui tambm pode ser inserida uma 6 regra para registar os pacotes que atinjam o m da lista e sejam negados. Um ponto importante de salientar o do registo dos pacotes - logging. importante que o administrador perceba que podem ser feitos ataques DoS, neste caso ao disco rgido, inundando os cheiros de log com pacotes at que no mais haja espao em disco para registar mais nenhum pacote, podendo um atacante efectuar uma enorme quantidade de ataques sem sequer se preocupar com o IP spoong, o que tambm quer dizer que no se tem de preocupar com regras que neguem acesso a pacotes que utilizem loose routing. Existem mdulos, como o nth, que do a opo rewall de no registar todos os pacotes, mas apenas 1 em cada 10 por exemplo. Outra forma de combater este tipo de ataques o de automatizar, recorrendo a aplicaes de monitorizao (ex: Nagios), a compactao de cheiros que atinjam um determinado tamanho, ou mesmo mov-los para um dispositivo de armazenamento central (ex: NAS). A ltima cadeia a de FORWARD, por onde passam todos os pacotes que nem tm origem na prpria mquina, nem tm-na como destino. As regras 1 e 2 registam e negam acesso a pacotes no estado INVALID, a regra 3 impede a passagem de broadcasts, desta forma evitando ataques Smurf. Nestes ataques enviado por um atacante um ICMP echo request com destino broadcast e origem falsicada com o IP da vtima. Quando os computadores todos da rede interna responderem com o ICMP reply, a vtima ser inundada de pacotes (DoS). O impedimento do encaminhamento de pacotes com destino broadcast suportado a nvel do prprio kernel, contudo em verses mais antigas isso poder no ser verdade. As regras 4 e 5 impedem a passagem de pacotes com opes no cabealho IP, pelas mesmas razes anteriormente apresentadas, desta feita protegendo a rede interna. A regra 6 foi inicialmente concebida para proteger a prpria rewall, mais especicamente no porto 22 (administrao remota via SSH), de ataques Syn Flood. Neste o atacante explora uma fraqueza do protocolo TCP, no three-way-handshake, onde envia um syn, fazendo com que o servidor armazene estado (consumindo memria) com os dados da ligao. Contudo, aps o servidor responder com o syn+ack, o atacante j no mais responde. Isto tipicamente feito falsicando o IP origem para um IP que no esteja atribudo. Este era o nico servio a correr sobre TCP e consequentemente vulnervel a este tipo de ataques. De realar o facto do prprio sistema Linux ter formas de evitar este tipo de ataques (/etc/sysctl.cong - syn cookies, reduo de timeouts, etc) porm, sendo o objectivo do trabalho a demonstrao de como faz-lo com o Iptables, optou-se por fazer isso mesmo com a regra 6. Nesta, so encaminhados os pacotes TCP que tenham estado NEW, tipicamente as caractersticas de um pacote que pretenda iniciar uma sesso SSH. Esses pacotes so ento encaminhados para uma nova cadeia de regras chamada syn_ood_protect. Nesta cadeia utiliza-se o mdulo limit para limitar o uxo desses pacotes a 1 por segundo. Dado eu ser o nico administrador da mquina pareceu-me ser perfeitamente razovel esse valor. Apesar de tudo o que foi dito no pargrafo anterior, esta regra encontra-se no na cadeia INPUT mas sim na FORWARD. Isto para proteger os servidores internos com servios sobre TCP. Esta regra s no se encontra na cadeia INPUT porque no l necessria visto que no se permite acesso ao porto 22 antes de se autenticar o cliente (mtodo SPA explicado mais frente). A regra seguinte a 7 que permite a passagem de qualquer trfego interno para a rede externa. A regra 8 permite a passagem de pacotes relacionados com ligaes criadas a partir de dentro, e a regra 9 regista os pacotes que chegaram ao m da lista e sero descartados dada a poltica de negao comum a todas as cadeias principais. De salientar trs ataques aos quais nem a rewall nem a rede interna esto vulnerveis: Ping of Death - onde se envia um ICMP echo request com mais de 65536 bytes obrigando implementaes antigas de SOs a terem comportamentos estranhos como o bloqueio completo; Teardrop - onde se adulteravam os fragment offsets de forma a tambm explorar falhas em implementaes antigas do stack TCP/IP em SOs; e Land - onde se envia um pacote syn com o endereo e porto origens iguais aos do destino (isto provocava que o Win95 se bloqueasse). Estes ataques no tm efeito sobre o rewall, nem sobre a rede interna, porque o kernel utilizado considerado moderno no que diz respeito s falhas que estes ataques exploravam, e tambm porque, no caso do Ping of Death e Teardrop, utiliza-se o conntrack que garante a desfragmentao dos fragmentos antes16/30

destes serem re-encaminhados, local ou remotamente, e consequentemente a m formao do pacote ser logo detectada (sendo ento descartada). Caso o conntrack no fornecesse proteco, um simples iptables -A INPUT -p icmp --icmp-type echo-request -m length --length 86:0xffff -j DROP, no permitindo ICMP echo request maiores que 85 bytes seria mais do que suciente. Single Packet Authorization - SPA Esta tcnica consiste em deixar um daemon escuta de um pacote com dados que servem para autenticar um cliente. Quando esse pacote chega, o daemon insere uma regra na rewall permitindo acesso ao porto 22, por parte de um IP especco e por um determinado espao de tempo. A implementao utilizada foi a Forward Knock Operator (fwknop) por ser uma das melhores a nvel de implementao de autenticao considerada segura. Nomeadamente, protege de ataques de repetio, onde um atacante que obtenha uma cpia de um pacote j enviado, ao re-envi-lo o servidor aceita-o como vlido. O Fwknop protege-se deste ataque com a insero de 16 bits de dados aleatrios no pacote. Juntamente com mais alguns outros dados, calculado um hash desses dados com uma palavra-chave simtrica. Esse hash anexado ao pacote que ento enviado ao servidor. Com esta tcnica no mais foi necessrio proteger o porto 22 de syn oods. Uma das vantagens do SPA tambm tornar o sistema operativo, da mquina que contm a rewall, irreconhecvel, dado que apenas o porto 53 (que como j referido sequer l deveria estar) que apenas responde a queries DNS (udp). Isto foi testado com o NMap (http://nmap.org/ -> nmap -O -p 1-1024 10.62.75.132) que respondeu: Too many ngerprints match this host to give specic OS details. Outra vantagem o de no mais ser necessrio proteger o porto 22 (Secure Shell - SSH) de falhas/vulnerabilidades da implementao utilizada: o OpenSSH (www.google.com/search?q=OpenSSH+Vulnerability+site%3Acert.org) como o caso do SSL request oods que se resume no mesmo que syn oods mas a nvel de estabelecimento de ligao SSL (sobre o qual passa o SSH). O cliente executado sobre um MacBook Pro dever invocar: /Users/andreima/bin/fwknop -A tcp/22 -a 10.62.75.4 -D 10.62.75.132 Enquanto que no servidor j dever estar a se executar: /usr/bin/perl -w /usr/sbin/fwknopd -d -v # para poder ver a informao de debug O servidor foi congurado atravs dos cheiros /etc/fwknop/access.conf (informao relativa ao acesso do cliente como a palavra passe) e na mesma pasta fwknop.conf (com informao como o modo de escuta PCAP, ULOG, syslog; que comandos executar na recepo de um pacote vlido e aps o timeout; e tambm o timeout que por omisso de 30 segundos). Proteco contra Port Scans A preocupao contra portscans no se coloca no caso da cadeia INPUT pois os pacotes enviados pelo atacante sero todos descartados, com a excepo do porto 53 UDP. Aps um teste com: nmap -O -p 1-1024 10.62.75.132 e colocando a proteco contra syn oods na cadeia INPUT para efeitos de teste, notou-se que os pacotes , dada a sua rapidez de envio, foram maioritariamente (cerca de 2000/20XX) descartados no nal da cadeia syn_ood_protect. Consequentemente considerou-se que esta cadeia inicialmente criada para a proteco contra syn oods teve xito na intercepo de portscans, dada a sua caracterstica alta velocidade de envio facilmente confundvel com ataques DoS. A utilizao do mdulo hashlimit do Iptables foi considerada, contudo esse mdulo pode ser enganado com IP spoong onde o atacante utiliza todos os IPs da gama atribuda sua rede e utilizando um sniffer esperar pelas respostas, da que se tenha optado pela manuteno no uso do mdulo limit.

17/30

Cenrio 2 - Controlo Parental Neste cenrio pretende-se demonstrar alguns mdulos que podero ser utilizados para restringir acessos rede externa (Internet) aos mais pequenos. Isto ser feito limitando as horas de navegao, estabelecendo quantidades limites de downloads, e restringindo acesso a contedos com base em strings. A limitao do tempo de navegao feita utilizando o mdulo time:# iptables -A FORWARD -i eth1 -o eth0 -m time --timestart 12:00 --timestop 21:00 --days Mon,Tue,Wed,Thu,Fri -j ACCEPT # iptables -A FORWARD -i eth1 -o eth0 -m time --timestart 9:00 --timestop 23:00 --days Sat,Sun -j ACCEPT

Permite-se assim que se aceda rede exterior nos dias teis do meio-dia s 21h e nos ns de semana das 9h s 23h. Quanto limitao da quantidade de downloads, recorre-se ao mdulo quota:# iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 80 -m state --state ESTABLISHED -m quota --quota 52428800 -j ACCEPT # iptables -A FORWARD -i eth0 -o eth1 -p tcp --sport 80 -m state --state ESTABLISHED -j DROP

Permite-se assim que, no download de pginas web (http), se descarreguem at 50MB (1024 bytes x 1024 x 1024 = 52428800 bytes). Quanto restrio de contedo, recorre-se ao mdulo string:# iptables -A FORWARD -i eth1 -o eth0 -m string --string 'google.com' -j DROP

Restringe-se assim a passagem de quaisquer pacotes que contenham a string www.google.com, a no ser que se utilizem tcnicas de evaso de Network Intrusion Detection Systems (NIDS), mesmo as mais bsicas como a substituio de caracteres. Um exemplo disto , ao invs de se tentar aceder a www.google.com, pode aceder a %77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D. importante que se note que a proteco contra esta e vrias outras tcnicas de evaso de NIDS, neste caso tcnicas de substituio de caracteres, so impraticveis para um packet ltering rewall, dado que ter-se-iam de inserir inmeras regras na rewall para cada caso, o que em termos de ecincia inaceitvel. Se realmente se pretende fazer a deteco de worms, com base em assinaturas como o caso, h que utilizar um NIDS (ex: Snort/Cisco Secure IDS) que est muito mais bem preparado para negar acesso a pacotes mesmo que utilizem estas tcnicas que, para um NIDS, relativamente bsico. Outra vantagem dos NIDS, nestes casos, em relao s rewalls o desempenho. Muitos tambm tentam utilizar este mdulo string para impedir acesso a certos mtodos do HTTP, por exemplo, o POST. O autor deste mdulo, Emmanuel Roger, salienta que isto muito melhor feito por um proxy do protocolo em causa, neste caso dever-se-ia de utilizar por exemplo o Squid para o HTTP, e tambm reala o facto deste mdulo ter sido criado apenas com o intuito de colocar pacotes interessantes numa queue para posterior anlise por parte do administrador.

Cenrio 3 - Balanceamento de Carga Neste cenrio pretende-se balancear a carga entre dois servidores DNS internos. Isto pode ser feito da seguinte forma:# iptables -A PREROUTING -i eth0 -p udp --dport 53 -m nth --counter 0 --every 2 --packet 0 -j DNAT --to-destination 10.62.74.177:53 # iptables -A PREROUTING -i eth0 -p udp --dport 53 -m nth --counter 0 --every 2 --packet 1 -j DNAT --to-destination 10.62.74.178:53

Este mdulo nth contm 16 contadores e est a utilizar o primeiro (--counter 0). O contador incrementado at que atinja o valor 2, passando imediatamente a zero outra vez (--every 2). Cada regra executada se o seu valor xo (--packet x) corresponder ao mesmo do contador. importante notar que, caso haja comunicao cujos posteriores pacotes necessitem ser re-encaminhados da mesma forma, h que balancear apenas o primeiro pacote com NAT (-m state --state NEW) sendo que a tabela de NAT tratar de re-encaminhar os restantes pacotes para o mesmo servidor. Caso no se re-encaminhe apenas o primeiro pacote, corre-se um risco muito elevado de se terem pacotes a irem para um servidor e

18/30

outros a irem para servidores diferentes, o que no funcionaria por exemplo no caso de protocolos que usem o TCP ou mesmo de alguns UDP como o caso do NFS ou TFTP. Outra forma de fazer o balanceamento, para demonstrar a colocao de regras noutra tabela que no a por omisso, a tabela lter, a seguinte:# iptables -A PREROUTING -i eth0 -p udp --dport 53 -t mangle -m random --average 50 -j ROUTE --gw 10.62.74.177 # iptables -A PREROUTING -i eth0 -p udp --dport 53 -t mangle -j ROUTE --gw 10.62.74.178

Desta feita, na tabela mangle da cadeia PREROUTING, a primeira regra re-encaminha o DNS query para o servidor 10.62.74.177 com probabilidade 50% (--average 50) sendo que, as que no passem pela primeira, sejam re-encaminhados ao 10.62.74.178.

Cenrio 4 - Falta de conana Este cenrio reecte uma situao onde tem-se um administrador snior, e um jnior. Neste caso, o snior no cona ainda o suciente nas capacidades/habilidades do novo recruta, pelo que no tem inteno nenhuma de lhe dar permisso (ex: sudo) para executar o comando /sbin/iptables. Contudo em determinadas ocasies o administrador snior pode ter de sair e querer deixar a cargo do administrador jnior uma, ou mais, regras.# iptables -A FORWARD -i eth0 -p tcp -d 10.62.74.177 --dport http -m condition --condition webdown -j REJECT --reject-with tcp-reset # echo 1 > /proc/net/ipt_condition/webdown

Com estas regras o administrador snior pode dar permisso de escrita ao jnior do cheiro /proc/net/ ipt_condition/webdown de forma a que este controle nica e somente a regra que controla o acesso ao servidor HTTP interno 10.62.74.177. A pasta onde este cheiro se encontra a nica pasta onde se podem colocar estes cheiros. Neste caso, o snior pode deixar a cargo do jnior uma operao de manuteno do servidor HTTP, tendo com estas regras a possibilidade de rejeitar (echo 1 > ...) pedidos de clientes enquanto efectua a manuteno, podendo logo de seguida voltar a dar acesso ao servidor (echo 0 > ...).

Desempenho da Firewall Antes de terminar importantes se notar que o script (anexo B cdigo B.1) contm regras que podero ser reposicionadas caso os seus hit counts demonstrem ser maiores que as regras que se encontram sua frente com o mesmo jail (ex: ACCEPT). Alis, o posicionamento das regras foi feito de acordo com o que se acredita ser uma lgica coerente com a dos hit counts j referida. Outra forma de aumentar o desempenho do Iptables , medida que as regras aumentam, agrup-las de acordo com certas caractersticas em novas tabelas. Um exemplo disto , ao invs de se terem N regras ltrando com base em dados TCP, obrigando um pacote UDP a percorr-las todas, para s ento encontrar o conjunto de regras UDP, pode-se colocar uma nica regra que indique que, caso o pacote seja TCP que v ento percorrer uma cadeia tcp_lter por exemplo. Desta forma um pacote UDP no mais tem de percorrer as N regras TCP at chegar s suas, mas sim apenas percorrer uma regra. Outro aspecto importante no desempenho consiste no armazenamento das regras da rewall. Uma opo inicialmente lgica seria a de automatizar, na arranque do sistema, a execuo de um script (como o caso do cdigo B.1) de forma a activar a rewall nesse instante. Contudo, o problema reside no facto de, a cada chamada ao iptables, este extrair todo o conjunto de regras existentes no Netlter Kernel space, efectuar a alterao pretendida (insero,remoo, append), e nalmente voltar a transferir todo o conjunto da memria para o Netlter Kernel space outra vez. Todo este processo, para cada chamada ao iptables, faz perder mais tempo quanto maior for o nmero de regras da rewall, o que a certo ponto torna-se inconcebvel. por esse motivo que existem duas ferramentas, iptables-save e iptables-restore, que servem para armazenar e restaurar o conjunto de regras num nico pedido ao kernel.

19/30

ConclusoNa tentativa de se proteger uma rede, deve-se implementar a chamada defesa em camadas. Basicamente isto signica que um atacante ter de ultrapassar vrias camadas de segurana, at que atinja o seu objectivo. Esta estratgia d maior consistncia segurana implementada, na medida em que aquilo que se pretende defender no ca vulnervel no caso de uma camada ser atacada com sucesso. No mbito desta defesa em camadas, a rewall efectivamente a primeira barreira com a qual so confrontados os atacantes. importante deixar claro que a rewall, por si s, no uma soluo completa de segurana de redes. Da a importncia de mais camadas de segurana por detrs desta primeira. H uma enormidade de ataques, referidos nos pargrafos seguintes, que no so susceptveis deteco por parte de rewalls pois, apesar destas poderem suportar funcionalidades que analisem protocolos de camadas superiores, nomeadamente a camada de aplicao, estas funcionalidades atrasam consideravelmente o processo de encaminhamento dos pacotes, tornando-se funcionalidades impraticveis em redes com grandes quantidades de trfego. Normalmente, caso se pretenda examinar trfego da camada de aplicao, recorrem-se a proxies especializados num determinado protocolo (ex: Squid para HTTP). Como exemplo de um ataque que os packet ltering rewalls no detectam, temos a recepo, por parte de um utilizador da rede interna, de um e-mail com um From: conhecido por esse utilizador. Este simples facto retira todas as suspeitas deste utilizador. Contudo, o e-mail em causa pode ser forjado e, no campo Reply-To:, conter um endereo diferente do contido no From. Esta manipulao no pode ser detectada mesmo que se tenha um proxy rewall no meio. Isto porque perfeitamente legtimo, e acontece muitas vezes, querer-se enviar e-mails de vrias contas, mas ao mesmo tempo apenas se pretender receber numa nica conta. E h tambm que considerar o factor humano. Um utilizador da rede interna pode estar descontente com a QoS (ex: largura de banda disponvel a um determinado servio) fornecida pela rede em causa. J foram relatados casos onde utilizadores ligaram-se rede externa (internet) atravs de modems pessoais, no se apercebendo da criao de uma backdoor rede interna. Outros exemplos de ataques no detectveis por rewalls packet ltering so o SPAM, o XSS, o sql injection, anexos de email com vrus, exploits especcos aos protocolos das camadas superiores, entre muitos outros. Estes e outros ataques justicam fortemente a existncia das camadas seguintes de segurana. Nomeadamente: Network Intrusion Detection Systems (NIDS - ex:Snort); Host Intrusion Detection Systems (HIDS ex:Tripwire); VLANs; Cifra de canais de comunicao (ex: kerberos, VPNs); Monitoring Analysis and Response System (Cisco MARS); a construo de polticas de segurana onde devero ser sistematizados os passos que se devero tomar em casos de emergncia (Incident Handling); polticas de backup; segurana fsica dos servidores e dos dispositivos de redes(routers/switches); ACLs internas; treino dos utilizadores da rede para que tenham noes bsicas de segurana e nomeadamente no agirem de acordo com o pargrafo anterior, nem divulgarem as suas passwords a terceiros, nem criarem passwords facilmente quebradas por ferramentas especializadas (ex: John the Ripper); etc.

20/30

BibliograaS. Vermeulen, G. Goodyear. Gentoo Linux x86 Handbook, 19/10/2009 Internet Systems Consortium (ISC). Bind9 Administrator Reference Manual, 2005 Quagga, http://www.quagga.net/ Ramon Hontanon, Linux Security, Julho 2001 http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch14_:_Linux_Firewalls_Using_iptables http://www.netlter.org/documentation/HOWTO//packet-ltering-HOWTO.txt http://www.netlter.org/documentation/HOWTO//netlter-extensions-HOWTO.txt http://www.netlter.org/documentation/HOWTO//netlter-hacking-HOWTO.txt http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html http://www.portknocking.org/view/implementations http://www.netlter.org/projects/ulogd/index.html http://insecure.org/sploits/land.ip.DOS.html http://insecure.org/sploits/linux.fragmentation.teardrop.html http://insecure.org/sploits/ping-o-death.html

21/30

Anexo A - DNSNAMED.CONFlogging { }; options { channel default_syslog { le "/var/log/named/named.log" versions 3 size 5m; severity debug; print-time yes; print-severity yes; print-category yes; }; category default { default_syslog; }; directory "/var/bind"; listen-on-v6 { none; }; listen-on port 53 { 127.0.0.1; 10.62.75.132; }; pid-le "/var/run/named/named.pid";

EXPLICAOSuporte ao logging de interrogaes ao servidor.

Directoria base que contm os restantes cheiros de congurao. Servidor de cache para dominios que desconhece (query recursivo aos root servers).

}; zone "." IN { type hint; le "named.ca"; }; zone "localhost" IN { type master; le "pri/localhost.zone"; allow-update { none; }; notify no; }; zone "127.in-addr.arpa" IN { type master; le "pri/127.zone"; allow-update { none; }; notify no; }; zone "g2.lrcd.local" IN { type master; le "pri/g2.lrcd.local.zone"; allow-update { none; }; notify no; }; zone "2.31.172.in-addr.arpa" IN { type master; le "pri/g2.lrcd.local.rev"; };

Resoluo do domnio localhost.

Suporte ao reverse resolution dos ips do localhost.

Domnio atribuido ao grupo 2.

Suporte ao reverse resolution do ip atribuido ao grupo 2.

Tabela A.1 - named.conf PRI/G2.LRCD.LOCAL.ZONE $TTL 1D @ IN

SOA

g2.lrcd.local. alima.g2.lrcd.local. ( 2009110401 ; Serial 3H ; Refresh 15M ; Retry 1W ; Expire - 1 week 1D ) ; Minimum IN NS IN MX 10 IN A IN CNAME IN CNAME server.g2.lrcd.local. mail.g2.lrcd.local. 10.62.75.132 server server Tabela A.2 - g2.lrcd.local.zone

server andre mail

22/30

PRI/G2.LRCD.LOCAL.REV $TTL 1W @

1D IN SOA 2.31.172.in-addr.arpa. alima.g2.lrcd.local. ( 2008122601 ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum NS PTR server.g2.lrcd.local. server.g2.lrcd.local. Tabela A.3 - g2.lrcd.local.rev

132

dig @10.62.75.132 g2.lrcd.local

; DiG 9.4.3-P3 @10.62.75.132 g2.lrcd.local ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADERHEADERHEADERHEADERHEADERHEADERHEADER