Embed Size (px)
Citation preview
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
MAURICIO KUNITAKI
IPTABLES: UMA OPÇÃO PARA GERENCIAMENTO DE SEGURANÇA, TRÁFEGO DE REDE E QUALIDADE DE SERVIÇO
LINS – SP
2º SEMESTRE/2013
2
CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA
PAULA SOUZA
FACULDADE DE TECNOLOGIA DE LINS PROF. ANTONIO SEABRA
CURSO SUPERIOR DE TECNOLOGIA EM REDES DE COMPUTADORES
MAURICIO KUNITAKI
IPTABLES: UMA OPÇÃO PARA GERENCIAMENTO DE SEGURANÇA, TRÁFEGO DE REDE E QUALIDADE DE SERVIÇO
Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins para obtenção do Título de Tecnólogo em Redes de Computadores.
Orientador: Prof. Me. Alexandre Ponce de Oliveira
LINS – SP
2º SEMESTRE/2013
3
MAURICIO KUNITAKI
IPTABLES: UMA OPÇÃO PARA GERENCIAMENTO DE SEGURANÇA,
TRÁFEGO DE REDE E QUALIDADE DE SERVIÇO
Trabalho de Conclusão de Curso apresentado à Faculdade de Tecnologia de Lins, como parte dos requisitos necessários para a obtenção do título de Tecnólogo em Redes de Computadores sob orientação do Prof. Me. Alexandre Ponce de Oliveira.
Data de aprovação:____/____/____
___________________________________ Orientador (Prof. Me. Alexandre Ponce de Oliveira)
___________________________________
Examinador 1
___________________________________
Examinador 2
4
A minha família que sempre me apoiou. A minha namorada Elisangela, que acreditou em mim mesmo quando nem eu acreditava e com seu amor me deu forças para continuar. A minha avó Rosa in memorian.
5
AGRADECIMENTOS
A Deus, que me deu o dom da vida, me capacitou e permitiu a realização
desse sonho.
Agradeço especialmente ao meu orientador professor Alexandre Ponce de
Oliveira pelos ensinamentos, incentivos, esclarecimentos e principalmente por
despertar em mim o gosto pela área de redes de computadores. Agradeço também
ao professor Julio Lieira que além de contribuir com este trabalho e enriquecimento
no aprendizado durante esses três anos, foi muito importante no meu crescimento
pessoal.
Aos amigos Cesar e Jairo pelo companheirismo e apoio nos bons e maus
momentos.
Agradeço a todos os professores e colegas de classe que de alguma maneira
contribuíram para a conclusão desse ciclo da minha vida.
Tenho certeza que vou levar os valores, aprendizados e amizades adquiridas
comigo para sempre.
6
RESUMO
O objetivo deste trabalho foi avaliar a ferramenta iptables na área de segurança, gerenciamento de tráfego e qualidade de serviço em redes de computadores. O gerenciamento dos recursos e a necessidade de preservar a qualidade dos serviços de rede se tornam mais importantes à medida que são essenciais para a realização de tarefas, que hoje, agilizam processos e diminuem custos, principalmente em ambientes empresariais. Desta forma procurou-se apresentar uma opção de ferramenta livre que pode ser utilizada em diferentes aspectos da gerência de rede de computadores. O iptables é uma ferramenta nativa do Kernel do Linux, desenvolvida para manipulação das tabelas do módulo Netfilter e não requer grande poder computacional. Foram aplicadas técnicas de marcação de pacotes com o iptables, que em conjunto a outras ferramentas livres ofereçam um resultado satisfatório nos aspectos avaliados. Neste trabalho foram abordados conceitos de redes de computadores, qualidade de serviço e segurança e, apresentada pesquisa sobre as ferramentas iptables, Traffic Control e a disciplina de fila Hierarquical Token Bucket. O ambiente de testes foi estruturado através do uso de máquinas virtuais, para simular as máquinas: Servidor, Cliente e Atacante. Para o desenvolvimento dos testes faz-se necessário um Sistema Operacional Linux com Kernel na versão 4.2 ou superior.
Palavras–Chave: iptables, QoS, gerenciamento de rede, tráfego de rede, segurança.
7
ABSTRACT
The objective of this work was to evaluate the tool iptables in the area of security, traffic management and quality of service. The management of resources and the need to preserve the quality of the network services are becoming more important the extent that they are essential for the achievement of tasks, which today, streamline processes and reduce costs, especially in corporate environments. In this way we sought to introduce an option for low-cost tool that can be used in different aspects of the management of network computers. The iptables is a native tool from the Linux Kernel, developed for manipulation of tables of Netfilter module and it doesn’t require large computational power. Techniques for packet marking with the iptables, which in conjunction with other free tools offer a satisfactory result to the aspects assessed were applied. In this work were discussed concepts of computer networks, quality of service and safety and, presented research on the tools iptables, Traffic Control and discipline of queue Hierarquical Token Bucket. The test environment were structured through the use of virtual machines to simulate the machines: Server, Client, and Attacker. For the development of tests it is necessary a Linux Operating System with Kernel version 4.2 or higher.
Keywords: iptables, free software, network management, Linux.
8
LISTA DE ILUSTRAÇÕES
Figura 1.1 – Camadas do modelo OSI
Figura 1.2 – Camadas do modelo TCP/IP
Figura 1.3 – Campos do datagrama IP.
Figura 2.1 – Filas no roteador
Figura 2.2 – Funcionamento do protocolo RSVP
Figura 3.1 – Tipos de incidentes reportados á CERT.br em 2012
Figura 3.2 – Posicionamento do firewall na rede de computadores
Figura 4.1 – Localização do Kernel
Figura 4.2 – Esquema da tabela Filter
Figura 4.3 – Esquema da Tabela NAT
Figura 5.1 – Organização da rede de testes
Figura 5.2 – Cenário de testes de segurança
Figura 5.3 – Handshake de três vias
Figura 5.4 – Varredura de portas com êxito
Figura 5.5 – Listagem das regras ativas do iptables no firewall
Figura 5.6 – Varredura de portas sem êxito
Figura 5.7 – Log do sistema operacional
Figura 5.8 – Lista de portas alteradas
Figura 5.9 – Log de Ping Flood
Figura 5.10 – Hierarquia de classes no HTB
Figura 5.11 – Teste de velocidade Host A
Figura 5.12 - Teste de velocidade Host B
Figura 5.13 - Teste de QoS no serviço de FTP
9
LISTA DE TABELAS
Tabela 5.1 - Configuração das máquinas virtuais utilizadas
Tabela 5.2 – Definições de parâmetros do TC
10
LISTA DE ABREVIATURAS E SIGLAS
ANSI - American National Standards Institute
CERT - Centro de estudos, reposta e tratamento de incidentes de segurança no
Brasil
CBQ - Class Based Queueing
DNS - Domain Name System
DOS - Denial of Service
FCC - Federal Communications Commission
FTP - File Transfer Protocol
HTB - Hierarquical Token Bucket
ICANN - Internet Corporation for Assigned Names and Numbers
ISO - International Organization for Standardization
IPV4 – Internet Protocol Version 4
IPV6 – Internet Protocol Version 6
IEEE - Institute of Electrical and Electronics Engineers
IETF - Internet Engineering Task Force
IP - Internet Protocol
ISP - Internet Service Provider
LAN - Local Area Network
MAN - Metropolitan Area Network
NAT - Network Address Translation
PFIFO - Packet First in First Out
QoS – Quality of Service
OSI - Open System Interconnection
RSVP - Resource Reservation Protocol
SLA - Service Level Agreement
SFQ - Classless Queuing Disciplines
11
SMTP - Simple Message Transfer Protocol
SSH – Security Shell
TC - Traffic Control
TCP - Transfer Control Protocol
TOS - Type of Service
ITU – International Telecommunication Union
VoIP - Voice over Internet Protocol
WAN - Wide Area Network
12
LISTA DE SIMBOLOS
@ - Arroba
# - Sustenido
13
SUMÁRIO
INTRODUÇÃO .......................................................................................................... 14
1 SOFTWARE DE REDES ........................................................................................ 16
1.1 ARQUITETURA DE REDE .............................................................................. 16
1.2 CAMADAS ....................................................................................................... 17
1.2.1 Interface da camada ..................................................................................... 17
1.2.2 Serviços das camadas .................................................................................. 17
1.2.3 Serviço com conexão e sem conexão .......................................................... 18
1.2.4 Vantagens e desvantagens das camadas .................................................... 19
1.3 PROTOCOLOS ............................................................................................... 19
1.3.1 Padronização de protocolos ......................................................................... 20
1.4 Modelos de referência ..................................................................................... 21
1.4.1 Modelo de referência OSI ............................................................................. 21
1.4.2 Modelo TCP/IP ............................................................................................. 23
1.4.3 Comparações entre modelo OSI e TCP/IP ................................................... 24
1.5 PROTOCOLO IP ............................................................................................. 25
1.5.1 ENDEREÇO IP ............................................................................................. 26
2 QOS ....................................................................................................................... 30
2.1 SURGIMENTO DA QoS .................................................................................. 30
2.2 DEFINIÇÃO DE QOS ...................................................................................... 31
2.3 PARÂMETROS DE QOS ................................................................................. 32
2.4 TÉCNICAS DE QOS ........................................................................................ 33
2.4.1 Técnicas de controle de congestionamento .................................................. 33
2.4.2 Serviços integrados e serviços diferenciados ............................................... 34
3 SERVIÇOS DE REDE ............................................................................................ 37
3.1 CONTROLE DE TRÁFEGO ............................................................................. 37
3.2 FIREWALL ....................................................................................................... 38
3.2.1 Firewall filtro de pacotes ............................................................................... 39
4 IPTABLES .............................................................................................................. 41
4.1 KERNEL .......................................................................................................... 41
4.2 MÓDULO NETFILTER ..................................................................................... 42
14
4.3 TABELAS ......................................................................................................... 42
4.3.1 Tabela Filter .................................................................................................. 42
4.3.2 Tabela NAT ................................................................................................... 43
4.3.3 Tabela Mangle .............................................................................................. 44
4.4 REGRAS .......................................................................................................... 44
4.5 CHAIN .............................................................................................................. 44
4.6 FERRAMENTA IPTABLES .............................................................................. 45
4.6.1 Comandos .................................................................................................... 45
4.6.2 Alvo ............................................................................................................... 48
4.6.3 Ação .............................................................................................................. 49
5 IMPLEMENTAÇÃO ................................................................................................ 49
5.1 CENÁRIO ........................................................................................................ 50
5.2 SEGURANÇA .................................................................................................. 51
5.2.1 Ataque de varredura de portas ..................................................................... 51
5.2.2 Teste de segurança contra ataque de varredura de portas .......................... 52
5.2.3 DoS: Ping Flood ............................................................................................ 55
5.2.4 Testes de segurança contra ataque de Ping Flood ...................................... 56
5.3 CONTROLE DE TRÁFEGO ............................................................................. 57
5.3.1 Cenário ......................................................................................................... 57
5.3.2 Ferramentas para controle de tráfego ........................................................... 58
5.3.3 Testes de controle de tráfego ....................................................................... 58
5.4 QoS.................................................................................................................. 63
5.4.1 Teste de qualidade de serviço ...................................................................... 63
CONCLUSÃO ............................................................................................................ 66
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 67
ANEXOS ................................................................................................................... 69
14
INTRODUÇÃO
A importância de se garantir qualidade e segurança em uma rede de
computadores é inquestionável, hoje ela é um dos principais meios de comunicação
e interliga milhões de pessoas ao redor do mundo por diversos dispositivos e através
de diferentes meios. Segundo a International Telecommunication Union União (ITU,
2012), em 2011 haviam 2,3 bilhões de pessoas online na Internet.
Serviços oferecidos pelas redes como o compartilhamento de arquivo,
Internet e e-mail são constantemente utilizados por empresas e são essenciais para
o seu funcionamento e competitividade no mercado. A grande demanda na
utilização desses serviços gera um intenso tráfego nas transmissões de dados em
redes de computadores, esses dados por sua vez precisam ser transportados de
forma rápida, segura e de maneira que não cause lentidão para os usuários
interligados na rede, assim evita-se o congestionamento. (TANENBAUM;
WETHERALL, 2011)
Segundo Bernardes (2011), na busca de um melhor desempenho na rede e
nos serviços que são disponibilizados, bem como a segurança das informações, os
profissionais responsáveis pelo gerenciamento de redes de computadores buscam
ferramentas automatizadas que os auxiliem neste gerenciamento para identificar os
gargalos e evitar o congestionamento em redes de computadores, uma vez que
realizar esse trabalho de forma manual é demorado, pouco efetivo e custoso para a
empresa.
O objetivo principal deste trabalho é demonstrar o funcionamento da
ferramenta livre iptables, nativa no Kernel do Linux a partir da versão 2.4, em
diferentes áreas da administração de redes, como por exemplo a área de segurança,
gerenciamento de tráfego e Quality of Service (QoS) ou qualidade de serviço.
Para atingir o objetivo principal foram realizados estudos sobre redes de
computadores e sobre as áreas mencionados a fim de compreender seus
funcionamentos, a partir disso, implementar regras que atinjam um nível aceitável de
qualidade e segurança nas respectivas áreas.
Este trabalho está organizado da seguinte forma: o primeiro capítulo descreve
os conceitos relacionados a redes de computadores, o segundo capítulo aborda a
15
definição e as ferramentas existentes de QoS, o terceiro capítulo descreverá o que é
e como atuam o serviço o Firewall e controle de tráfego. O quarto capítulo descreve
a ferramenta iptables e suas características.
O estudo de caso é descrito no quinto capítulo, onde é apresentado o cenário
onde os testes foram aplicados, as técnicas utilizadas e os resultados obtidos, por
fim tem-se as considerações finais do trabalho.
16
1 SOFTWARE DE REDES
Inicialmente, quando a principal função dos computadores era o
processamento de cálculos matemáticos, todo o investimento em tecnologia se
destinava aos hardwares, visto que o tipo de informação processado não carecia de
muito cuidado. Com o advento de novos serviços aos computadores e a interligação
deles por meio de redes de computadores, informações mais complexas começaram
a ser processadas e compartilhadas, desse modo tornou-se inviável todo o processo
de comunicação depender somente de hardwares, assim surgiu a necessidade dos
softwares nas redes de computadores. (FOROUZAN, 2008)
Assim sendo, as redes de computadores são formadas por um conjunto de
hardwares e softwares. Hardwares de rede é toda infraestrutura física usada no
transporte de sinais de um local para o outro e softwares são programas escritos em
linguagem de alto nível que viabilizam essa comunicação, são os protocolos.
(FOROUZAN, 2008)
Este capítulo tem como objetivo mostrar os conceitos da arquitetura dos
softwares de rede e a finalidade de suas camadas, a importância dos protocolos e
dos modelos de arquitetura.
1.1 ARQUITETURA DE REDE
Nos anos 60, muitos fabricantes de computadores tinham mais de uma linha
de produto que eram totalmente incompatíveis entre si. Para os fabricantes acabava
sendo muito custoso o desenvolvimento e a manutenção dessas duas linhas
completamente diferentes e entre os usuários havia o problema de incompatibilidade
de softwares. Para resolver isso, a IBM criou o System/360, máquina que era
compatível por software, pois tinham a mesma arquitetura e se diferenciavam
somente no preço e desempenho, assim os programas executariam em qualquer
máquina, solucionando os dois problemas. (TANENBAUM; WOODHULL, 2002)
Em suma, a arquitetura de rede tem o mesmo propósito. Ela é o conjunto de
camadas e protocolos que contem informações suficientes para que o
desenvolvedor construa um hardware ou software para cada camada de forma que
ele funcione corretamente de acordo com o protocolo utilizado, garantindo, dessa
maneira, interoperabilidade entre todas as entidades.
17
1.2 CAMADAS
As camadas são estruturadas hierarquicamente, ou seja, uma camada sobre
a outra formando uma pilha. Cada uma possui seus próprios protocolos.
Características como número de camadas, nome e função se diferem de uma
arquitetura para outra.
Segundo Kurose e Ross (2010), uma camada de protocolo pode ser
implementada em software, em hardware ou em uma combinação dos dois. Como
cada camada oferece um serviço, ela pode atuar em lugares diferentes uma das
outras, comumente as camadas inferiores de uma hierarquia atuam nos hardwares e
as camadas mais altas nos softwares de aplicação.
A comunicação entre as camadas se dá entre os níveis, a camada 2 da
máquina emissora, por exemplo, se comunica com a camada 2 da máquina
receptora. Apesar das camadas só se comunicarem com o seu par, esta
comunicação não acontece diretamente, os dados são transferidos pelas camadas
até a camada mais baixa onde se encontra o meio físico e por ela ocorre a
comunicação de fato. (TANENBAUM; WETHERALL, 2011)
No lado emissor cada camada utiliza o serviço da camada imediatamente
inferior a ela, de cima para baixo, já no lado receptor a ordem inverte, cada camada
faz uso do serviço da camada superior, de baixo para cima. (FOROUZAN, 2008)
1.2.1 Interface da camada
Entre cada nível de camada uma interface define quais serviços a camada
inferior deve prestar a superior, essa definição precisa ser bem clara, pois faz com
que o volume de informações diminua entre as camadas e facilite a substituição de
implementação de uma camada por uma implementação completamente diferente.
(TANENBAUM; WETHERALL, 2011)
1.2.2 Serviços das camadas
Segundo Tanenbaum e Wetherall (2011), um serviço é um conjunto de
operações que a camada oferece à camada localizada acima dela. O serviço
18
determina quais operações a camada está apta para executar em nome de seus
usuários.
Tanenbaum e Wetherall (2011), acrescentam algumas questões importantes
relacionadas aos serviços das camadas, primeiramente todas as camadas
necessitam identificar os transmissores e receptores. Constantemente as redes são
constituídas por vários computadores, assim sendo, é necessário um modo em que
um processo de uma máquina possa identificar com quem ele deseja estabelecer
comunicação.
Por conseguinte, se faz necessário as camadas e aos protocolos que nelas
atuam estabelecer como ocorrerá a transferência de dados. Os dados podem ser
transmitidos em ambos os sentidos ou em apenas uma direção.
Tanenbaum e Wetherall (2011), citam também a questão de controle de erros,
os circuitos de comunicação são passiveis a interferência, assim, comprometendo a
integridade dos dados. O receptor deve ter a capacidade de notificar o transmissor
quais mensagens foram recebidas com erros e quais não.
Por fim, Tanenbaum e Wetherall (2011), consideram, além dos citados, mais
dois problemas que precisam ser resolvidos em diversos níveis de camadas, a
velocidade que um transmissor envia mensagens e o tamanho das mensagens
enviadas. Para impedir que um transmissor rápido envie uma quantidade excessiva
de dados a um receptor mais lento, são utilizadas técnicas de controle de fluxo. Já
quando um pacote muito grande é recebido, é preciso fragmentá-lo e remontá-lo ao
fim da transmissão.
1.2.3 Serviço com conexão e sem conexão
Tanenbaum e Wetherall (2011), citam dois tipos de serviço que uma camada
pode prestar a camada superior, os serviços com conexão e os serviços sem
conexão.
Nos serviços com conexão é traçado uma rota previamente entre as duas
máquinas que desejam trocar informações, todos os dados percorrem o mesmo
caminho em todas as comunicações entre essas duas máquinas, normalmente os
dados chegam na ordem em que foram enviados.
19
Já os serviços sem conexão, onde cada fragmento de dado pode percorrer
um caminho diferente até chegar ao destino. Cada pacote tem o endereço do
destino e o roteamento é feito dinamicamente, frequentemente os pacotes chegam
fora de ordem, ficando por responsabilidade das camadas superiores a tarefa de
remontar a mensagem.
1.2.4 Vantagens e desvantagens das camadas
Uma das vantagens do uso do sistema de camadas é a flexibilidade que a
rede de computadores adquire, tornando fácil a alteração de algum aspecto da rede,
o meio de transmissão por exemplo. (TANENBAUM; WETHERALL, 2011)
Como observou Kurose e Ross (2010), alguns pesquisadores e engenheiros
de rede, no entanto, vêem algumas desvantagens potenciais no sistema de
camadas, a primeira é a duplicação de funcionalidade entre as camadas, só para
exemplificar, mais de uma camada pode ter o mesmo serviço de recuperação de
erros. Outra possível desvantagem é que para desenvolver um serviço, a camada
pode precisar de mais informações e estas estarem inacessíveis à ela.
1.3 PROTOCOLOS
A composição de uma rede de computadores dificilmente é feita por entidades
com as mesmas características de hardware e software. Por entidades entende-se
como qualquer dispositivo com capacidade de enviar e receber dados.
(FOROUZAN, 2008)
Em uma Local Area Network (LAN), que é uma rede local privada, um
escritório, por exemplo, seria possível já que o numero de máquinas é pequeno, mas
em uma Metropolitan Area Network (MAN) ou Wide Area Network (WAN) que são
redes de grande porte seria inviável. Para que haja uma comunicação entre as
entidades é preciso que elas falem a mesma língua, ou seja, estabeleçam um
acordo de como acontecerá a conversação.
O protocolo é um conjunto de regras de comunicação que atuam nas
camadas, essas regras são estabelecidas e devem ser respeitadas para que a
comunicação entre duas entidades ocorra sem problemas. A atual necessidade de
20
interconectividade a nível internacional é uma das justificas da importância dos
protocolos.
Ainda segundo Forouzan (2008), existem três elementos chave de um
protocolo, são eles:
Sintaxe: a estrutura ou formato dos dados e a ordem pela qual são
apresentados;
Semântica: diz como deve ser interpretada cada sessão de bits e o que deve
ser feito com base nessa interpretação;
Temporização: faz referência a duas características, quando e em qual
velocidade os dados devem ser enviados.
1.3.1 Padronização de protocolos
Forouzan (2008) diz que existem dois tipos de padrões em comunicação de
dados:
De facto: é adotado como padrão, porém ainda não foi aprovado por um
comitê organizado. Frequentemente é estabelecido por fabricantes de equipamentos
com o intuito de definir a funcionalidade de algum produto ou tecnologia.
De jure: são os padrões reconhecidos por um corpo ou comitê organizado.
Além da forma de imposição por parte dos fabricantes e consequentemente
aceitação, Tanenbaum e Wetherall (2011) consideram a existência de órgãos que
trabalham em conjunto na criação e estabelecimento dos padrões, são eles os
comitês de criação de padrões, fóruns e agências de regulamentação. A seguir tem-
se a descrição de alguns deles:
International Organization for Standardization (ISO): é uma organização
fundada em 1946 e formada por membros de diversos países sendo que a maioria
desses membros fazem parte dos comitês de criação de padrões de seu país. Suas
normas internacionais abrangem vários aspectos da tecnologia como, segurança
alimentar, computadores e cuidados com a saúde.
American National Standards Institute (ANSI): organização privada sem fins
lucrativos e sem vínculo com o governo dos Estados Unidos, porém todas suas
atividades são reconhecidas e tem apoio do governo americano.
Institute of Electrical and Electronics Engineers (IEEE): é a maior sociedade
21
profissional de engenheiros no mundo. Ajuda no avanço da teoria e da qualidade
dos produtos nos campos da engenharia elétrica e eletrônica. Como meta, a IEEE
supervisiona o desenvolvimento e a adoção de padrões internacionais para a
computação e as comunicações.
Fóruns: foram criados por grupos especializados com o intuito de agilizar
os acordos e facilitar os processos de padronização. Surgiu pelo fato dos comitês de
padronização, como consequência da rigidez em seus procedimentos, não
acompanharem o rápido desenvolvimento das tecnologias de telecomunicações.
São formados por representantes de corporações e trabalham em conjunto com as
universidades e os usuários para testar, avaliar e padronizar novas tecnologias.
Agências reguladoras: têm como propósito proteger o interesse público
regulamentando as comunicações. Toda e qualquer tecnologia de comunicação está
sujeita a regulamentação, seja rádio, televisão e a cabo. A Federal Communications
Commission (FCC) é uma dessas agências.
1.4 Modelos de referência
Na prática, são dois os modelos de referencias mais conhecidos, o modelo
Open System Interconnection (OSI) e modelo Transfer Control Protocol/Internet
Protocol (TCP/IP)
1.4.1 Modelo de referência OSI
Segundo Tanenbaum e Wetherall (2011) o modelo OSI surgiu como primeiro
passo dado pela ISO na tentativa de padronizar internacionalmente os protocolos
utilizados nas camadas. Os protocolos do modelo OSI raramente são usados e o
modelo em si nunca foi implementado seriamente, mas ainda é amplamente usado
como referência, pelo fato de não especificar os serviços e os protocolos utilizados,
mas sim informar o que cada camada deve fazer. Esse modelo possui sete
camadas, na sequência será dada uma descrição de cada camada.
A primeira camada do modelo de referência OSI é a camada física. Ela é
responsável pela transmissão dos bits pelo canal de comunicação. Deve garantir
que se uma estação enviar um bit 1 seja recebido o mesmo bit 1 e não um bit 0.
Para isso os protocolos devem levar em consideração fatores como a voltagem que
22
representará os bits, o tempo de duração de cada bit, o método de transmissão que
será utilizado e como será iniciada e encerrada a conexão. (TANENBAUM;
WETHERALL, 2011)
A segunda camada é a camada de enlace de dados, ela detecta e corrige
possíveis erros que podem acontecer na transmissão do meio físico. A verificação
de integridade é possível porque ela divide os dados em quadros e adiciona
cabeçalhos para controle de erros. Ela também cuida das retransmissões dos
quadros danificados ou perdidos ao longo do caminho. Outra função importante na
camada de enlace de dados é o controle de fluxo. (TANENBAUM; WETHERALL,
2011)
A camada de nível três é a camada de rede. Ela controla as operações da
sub-rede e é responsável pelo roteamento dos pacotes de origem até o destino. As
rotas podem ser estáticas ou podem ser determinadas no início de cada
conversação. (TANENBAUM; WETHERALL, 2011)
A camada de transporte recebe os dados da camada de sessão, se houver
necessidade divide os dados em unidades menores e repassa esses dados a
camada inferior a ela, a camada de rede. Esse serviço deve ser feito com eficiência,
isolando as camadas superiores de qualquer possível alteração de tecnologia de
hardware na rede. (TANENBAUM; WETHERALL, 2011)
A quinta camada é a camada de sessão. Ela permite que duas máquinas
estabeleçam sessões entre elas, uma sessão pode oferecer vários serviços como
controle de diálogo, isso estabelece quem deve transmitir em um determinado
momento e a sincronização da comunicação, que através de pontos de checagem
consegue restabelecer a comunicação de onde parou após ela ser interrompida
bruscamente.(TANENBAUM; WETHERALL, 2011)
A camada de apresentação é a sexta, ela cuida da sintaxe e da semântica
das informações trocadas. Antes de serem transmitidas as informações são
convertidas em bits, a camada de apresentação faz essa tradução garantindo o
entendimento independente do sistema de codificação utilizado. (TANENBAUM;
WETHERALL, 2011)
A camada mais elevada do modelo OSI é a camada de aplicação, ela permite
que o usuário, seja uma pessoa ou um software tenha acesso a rede, é a interface
entre o processo de usuário e os protocolos de comunicação, como e-mail e acesso
a páginas web. (TANENBAUM; WETHERALL, 2011)
23
Todas as camadas do modelo OSI descritas anteriormente são exibidas na
figura 1.1.
Figura 1.1 – Camadas do modelo OSI Fonte: Tanenbaum e Wetherall, 2011, p.28
1.4.2 Modelo TCP/IP
O modelo TCP/IP possui 4 camadas, são elas: camada de enlace, Internet,
transporte e aplicação. A posição de cada uma delas no modelo pode ser
visualizada na figura 1.2.
Figura 1.2 – Camadas do modelo TCP/IP Fonte: Tanenbaum e Wetherall, 2011, p.28
Segundo Tanenbaum e Wetherall (2011) o modelo TCP/IP surgiu na primeira
rede de computadores geograficamente distribuída, a ARPANET. A ARPANET era
24
patrocinada pelo Departamento de Defesa dos Estados Unidos e interligava
centenas de universidades e repartições públicas por meio de linhas telefônicas
dedicadas. Os problemas começaram a surgir quando foram criadas as redes de
rádio e satélite, pois os protocolos usados levaram a necessidade de uma nova
arquitetura onde o objetivo principal era interligar várias redes de maneira uniforme.
O Departamento de Defesa tinha outra preocupação, a que seus
equipamentos de sub-rede fossem destruídos em razão de um ataque motivado pela
guerra fria, o que causaria o fim da rede, então foi definido outro requisito para a
arquitetura, a rede deveria se manter ativa mesmo com falha em alguns
equipamentos que compunham a sub-rede. Assim nasceu o modelo TCP/IP.
(TANENBAUM; WETHERALL, 2011)
Na primeira camada do modelo TCP/IP, camada de enlace, existe uma
lacuna, o modelo não especifica exatamente o que deve ser feito, exceto que os
hosts precisam se conectar a rede utilizando algum tipo de protocolo.
(TANENBAUM; WETHERALL, 2011)
A camada de Internet é a segunda camada, ela abrange toda a arquitetura e é
baseada em serviços sem conexão, Suas funções se assemelham com a camada
de rede do modelo OSI. Uma delas é permitir que os hosts enviem pacotes em
qualquer rede e garantir que eles cheguem ao seu destino de forma independente,
possivelmente chegarão fora de ordem, cabendo as camadas superiores a função
de organizá-las. O protocolo IP atua nessa camada. (TANENBAUM; WETHERALL,
2011)
A camada de transporte é a terceira camada, é nela que atua o protocolo TCP
que em conjunto com o protocolo IP dá nome ao modelo. Sua função é permitir que
as entidades de origem e destino estabeleçam comunicação. (TANENBAUM;
WETHERALL, 2011)
Os protocolos de níveis mais altos ficam na camada de aplicação, como o
protocolo de terminal virtual TELNET, o protocolo de transferência de arquivos File
Transfer Protocol (FTP), e o de correio eletrônico Simple Mail Transfer Protocol
(SMTP).(TANENBAUM; WETHERALL, 2011)
1.4.3 Comparações entre modelo OSI e TCP/IP
Os modelos OSI e TCP/IP surgiram de formas distintas e por isso se
25
diferenciam em alguns aspectos.
O modelo OSI foi criado antes dos protocolos nele implementados e teve
evoluções conforme novas tecnologias surgiam, em razão disso esse modelo é mais
genérico e flexível. (TANENBAUM; WETHERALL, 2011)
Já o modelo TCP/IP foi criado baseado em protocolos, e suas camadas são
praticamente uma descrição de cada um desses protocolos. A consequência disso é
um modelo que dificilmente se adapta a outras pilhas, não tendo utilidade para
descrever outras redes que não utilizam os protocolos TCP/IP. (TANENBAUM;
WETHERALL, 2011)
Apesar do número de camadas diferentes, existem três camadas que estão
presentes nos dois modelos, a camada de rede, transporte e aplicação. No modelo
OSI a camada de rede é compatível com a comunicação sem conexão e
comunicação orientada a conexão, mas na camada de transporte só aceita a
comunicação orientada a conexão. No TCP/IP a camada de rede só aceita
comunicação sem conexão, mas aceita os dois modos na camada de transporte,
oferecendo ao usuário a opção de escolha.
Tanenbaum e Wetherall (2011) afirmam que provavelmente a maior
contribuição do modelo OSI é tornar explicito a distinção entre três conceitos
fundamentais em que o modelo se fundamenta, os serviços, as interfaces e os
protocolos. A definição desses três conceitos não é tão clara no modelo TCP/IP, o
que faz com que os protocolos do modelo OSI sejam mais bem encapsulados,
podendo ser substituídos com certa facilidade conforme mudança de tecnologia.
Em conclusão, o modelo OSI se tornou muito útil para a discussão das redes
de computadores, em contraste com o modelo TCP/IP onde o modelo em si é
praticamente inexistente, mas seus protocolos são amplamente utilizados.
1.5 PROTOCOLO IP
Segundo Forouzan (2008) o protocolo IP é o principal protocolo da camada de
rede e tem como responsabilidade entregar os datagramas da origem ao destino.
Segundo Kurose e Ross (2010) um pacote na camada de rede é denominado
datagrama. Há duas versões do protocolo IP em uso atualmente, a versão 4,
também conhecida como IPV4 e a versão 6 ou IPV6, a versão IPV6 não será
26
abordada neste trabalho.
1.5.1 ENDEREÇO IP
Um endereço IPv4 tem comprimento de 32 bits que equivale a 4 bytes, quase
4 bilhões de endereços possíveis, porém segundo a Corporação da Internet para
Atribuição de Nomes e Números (ICANN), em 2010 restavam apenas 10% desses
endereços livres. (KUROSE; ROSS, 2010) (ICANN, 2010)
Um host conectado a Internet possui um endereço IP que codifica seu número
de rede e seu número de host, esse endereço é exclusivo e dois hosts na Internet
nunca tem o mesmo endereço. Esse endereço está associado a interface e não ao
host, Kurose e Ross (2010) descrevem interface como sendo a fronteira entre o
hospedeiro e o enlace físico, dessa maneira para um host estar em duas redes ele
precisa de dois endereços IP.(TANENBAUM; WETHERALL, 2011)
Segundo Forouzan (2008) os endereços IP podem ser escritos com notação
binária ou decimal. Na notação binária, o endereço IP é representado por meio de
32 bits como no exemplo: 01110101 10010101 00011101 11101010.
Com o intuito de tornar os endereços IP mais legíveis, é comum escrevê-los
em forma decimal separando cada byte por ponto, por exemplo, 128.11.3.31. Em
virtude de cada byte ser formado por 8bits, qualquer número na notação decimal
deve ficar restrito a faixa entre 0 e 255. (FOROUZAN, 2008)
Entretanto, alguns endereços são reservados para fins específicos, como por
exemplo, todos os endereços com formato 127.xx.yy.zz são utilizados para fazer
referência a própria máquina e utilizado para comunicação interna. IP com o
identificador do host valendo 0 é utilizado para identificar a rede e com valor 255 é
usado para broadcast. (TANENBAUM; WETHERALL, 2011)
1.5.2 Datagrama IP
Conforme citado por Tanenbaum e Wetherall (2011) um datagrama IP possui
duas partes, uma de cabeçalho e outra de dados. Seus campos podem ser vistos na
figura 1.3.
De acordo com Forouzan (2008) um datagrama IP possui tamanho que
varia de 20 a 60 bytes,a seguir a descrição de cada campo do datagrama IP.
27
Versão: campo de 4 bits que determina a versão do protocolo IP. O
roteador analisa esse campo e determina como interpretar o restante do datagrama,
já que diferentes versões do IP utilizam diferentes versões de datagrama. (KUROSE;
ROSS, 2010)
Tamanho do cabeçalho: campo de 4 bits que define o tamanho do cabeçalho,
é necessário para determinar em que lugar no datagrama os dados realmente
começam, pois o tamanho do datagrama IP pode ter tamanho variável. (KUROSE;
ROSS, 2010) (FOROUZAN, 2008)
Tipo de serviço: esse campo foi adicionado no IPV4 com o propósito de
diferenciar os tipos de datagramas IP. Um exemplo de uso deste campo é que
Datagramas de aplicações de tempo real, como telefonia, podem ser diferenciados
de aplicações que não são em tempo real. Esse campo será melhor abordado nos
capítulos seguintes.(KUROSE; ROSS, 2010)
Comprimento do datagrama: esse campo possui 16 bits e possui a somatória
em bytes do tamanho do cabeçalho e do tamanho do datagrama. O tamanho
máximo do datagrama IP é 65.535 bytes, porém raramente são maiores que 1.500
bytes. (KUROSE; ROSS, 2010)
Identificador: para um datagrama IP chegar ao seu destino, ele pode passar
por várias redes diferentes. Nesse trajeto os roteadores desencapsulam um
datagrama do frame recebido e encapsulam-no de novo em um frame com formato
que depende do tipo de protocolo utilizado pela rede. Esse campo identifica os
frames que pertencem ao mesmo datagrama. Esse número de identificação auxilia o
host de destino no processo de reagrupamento do datagrama. (FOROUZAN, 2008)
Flags: esse campo de três bits diz respeito a fragmentação do datagrama. O
primeiro bit é reservado, o segundo bit é denominado não fragmentar, quando esse
campo possui valor 1 o host não deve fragmentar, se o valor for 0 pode ocorrer a
fragmentação. O terceiro bit é denominado mais fragmento, esse campo com valor 1
significa que este fragmento não é o ultimo, com bit 0 significa que esse fragmento é
o ultimo ou único.(FOROUZAN, 2008)
Deslocamento de fragmentação: esse campo possui tamanho de 13 bits e
mostra a posição do fragmento em relação ao datagrama como um todo.
(FOROUZAN, 2008)
Tempo de vida: esse campo é importante para garantir que datagramas não
circulem para sempre na rede. Tanenbaum e Wetherall (2011) o descrevem como
28
um contador para limitar a vida útil do datagrama. Seu valor é decrementado em
uma unidade a cada roteador em que é processado, se o valor do campo chegar a
zero ele deve ser eliminado. (KUROSE; ROSS, 2010)
Protocolo da camada superior: o valor desse campo informa a que processo
de transporte o datagrama IP deve ser entregue. Por exemplo, o valor 6 indica que
deve ser passado ao TCP. (TANENBAUM; WETHERALL, 2011) (KUROSE; ROSS,
2010)
Soma de verificação do cabeçalho: “esse campo auxilia os roteadores na
detecção de erros de bits em um datagrama IP recebido.” (KUROSE; ROSS, 2010,
p. 249)
Por meio de um algoritmo que soma os valores dos bytes se encontra o valor
deste campo. Os roteadores calculam o valor e se esse for diferente do que está no
campo considera que esse fragmento está com erro. (KUROSE; ROSS, 2010)
Endereço IP de fonte e de destino: campo com endereço IP do host de origem
e destino. (FOROUZAN, 2008)
Opções: esse campo foi projetado para permitir que versões posteriores do
protocolo incluam novas informações, possibilitando a experimentação de novas
ideias e evitando a alocação de bits de cabeçalho para informações
raramente necessárias. (TANENBAUM; WETHERALL, 2011)
Dados: o último e mais importante campo do datagrama, é nela que é contida
a informação de fato, também conhecida como payload. (KUROSE; ROSS, 2010)
Figura 1.3 – Campos do datagrama IP. Fonte: Kurose e Ross, 2010
29
O propósito deste capítulo foi abordar de forma simples os conceitos de
software de redes, arquitetura de software e o protocolo IP. Nos capítulos que
seguem será abordado os conceitos de qualidade de serviço.
30
2 QOS
Esse capítulo tem por finalidade explicar os conceitos da QoS em redes de
computadores, para isso inicia-se com um breve histórico do seu surgimento nas
primeiras redes de telecomunicações, em seguida são abordados os parâmetros
que são usados para medição, bem como algumas técnicas utilizadas atualmente.
2.1 SURGIMENTO DA QoS
Conforme descrito por Park (2005) no início das telecomunicações haviam
duas redes distintas, a rede telefônica que transportava voz e a rede IP que
transportava dados. Cada rede foi projetada para transportar um tipo especifico de
informação o que ocasionou em diferentes modos de funcionamento e na maneira
de obter qualidade nos serviços oferecidos.
A rede telefônica inicial utilizava o telefone como dispositivo terminal, porém a
maior parte da inteligência se encontrava na rede, que por sua vez era bem mais
complexa, a conexão era dedicada a uma chamada durante toda sua duração e ao
fim, os circuitos eram usados para configurar outra chamada. (PARK, 2005)
Uma vez que, transportando voz, coube aos projetistas encontrar métodos
para obter qualidade que eram coerentes com os tipos de serviços oferecidos pela
rede, serviços esses que em maioria era de comunicação em tempo real. Foram
duas as principais medidas tomadas, a primeira medida foi garantir o fornecimento
necessário de circuitos para se estabelecer uma ligação. Para isso criou-se o
bloqueio de chamada, que ocorria antes de iniciar a ligação, na ausência de circuitos
disponíveis. Estabelecida a conexão, a segunda medida foi na qualidade de voz, que
está diretamente ligada a qualidade de transmissão. Para isso a rede telefônica foi
projetada para aperfeiçoar a transmissão fim-a-fim, para que as deficiências da rede
como ruídos, ecos e atrasos fossem razoáveis. (PARK, 2005)
A rede IP se diferenciava e muito da rede telefônica, a começar pelo tipo de
informação transportada. Ao contrário de voz, dados são em maioria serviços em
tempo não real, podendo ser armazenado e entregue posteriormente. (PARK, 2005)
A rede IP foi projetada para ter o funcionamento mais simples possível, sua função
31
principal é transportar pacotes de um nó para outro os tratando da mesma maneira.
Os pacotes são armazenados em um buffer e encaminhados em ordem.
Segundo Park (2005), outro ponto em que as redes se diferenciam é no
dispositivo terminal, que na rede IP é um típico computador hospedeiro, diferente do
telefone, nele foi depositado a maior parte da inteligência. Um exemplo disso é que o
terminal receptor, ao receber um pacote com erro, consegue identificá-lo e pedir a
retransmissão, tudo isso sem conhecimento da rede.
Em virtude do simples funcionamento da rede IP e do tipo de informação
transportada, a rede pode operar no modo Best Effort (Melhor Esforço), onde todos
os pacotes são tratados de forma igual. (PARK, 2005)
O objetivo do projeto principal da rede IP era certificar-se de que o terminal do usuário final teve os protocolos e inteligência necessários para garantir dados confiáveis a transmissão de forma que a rede pode operar tão simples quanto possível. (PARK, 2005, p.3, tradução nossa).
Por terem características de tráfego e requisitos de desempenho distintos, foi
possível obter o melhor caminho para o transporte das informações por duas redes
separadas, porém em meados de 1990 teve início o que foi conhecido como
Convergência de Voz e Dados, as duas redes começaram a se fundir com o
propósito de criar uma única rede para transportar os dois tipos de informação.
Consolidada a convergência, um novo desafio técnico surgiu, nessa nova rede o
funcionamento melhor esforço, utilizado na rede IP, não era o suficiente para
atender os diversos requisitos de desempenho dos diferentes tipos de serviços
oferecidos. QoS foi a tecnologia utilizada para resolver esse problema.(PARK, 2005)
2.2 DEFINIÇÃO DE QOS
Na recomendação E.800 de 1994 do setor de normalização das
telecomunicações ITU-T, um dos braços da União Internacional de
Telecomunicações, contém a seguinte definição para QoS: efeito coletivo do
desempenho do serviço, que determina o grau de satisfação de um usuário do
serviço.
Essa definição abrange somente a percepção do usuário, porém, segundo
Park (2005), além do ponto de vista do usuário, a QoS também pode ser definida a
32
partir do ponto de vista da rede, que está na sua capacidade de prover condições
para que a QoS do ponto de vista do usuário final ocorra.
Essas condições podem ser alcançadas por meio de técnicas de QoS e
mensuráveis através de parâmetros.
2.3 PARÂMETROS DE QOS
De acordo com Tanenbaum e Wetherall (2011) um fluxo de dados exige
quatro parâmetros de qualidade, são eles o atraso, largura de banda, flutuação e
confiabilidade. Para Park (2005), o entendimento desses parâmetros é vital para a
compreensão da QoS.
Atraso (ou retardo): de acordo com Kurose e Ross (2010) um pacote se
origina em um sistema final, passa por uma série de roteadores e tem como destino
outro sistema final, ao percorrer esse trajeto, o pacote sofre atrasos. Segundo
Forouzan (2008) os atrasos ocorrem porque existem filas nos roteadores e buffers
que armazenam os dados antes e depois de serem processados. Kurose e Ross
(2010) descrevem o atraso como sendo a soma do atraso de processamento
(identificação e direcionamento do pacote), atraso de fila (tempo de espera para ser
transmitido), atraso de transmissão (tempo de transmissão de todos os bits do
pacote para o enlace) e o atraso de propagação (tempo que um bit leva para
atravessar o meio físico). Os atrasos que um pacote sofre são ilustrados na figura
2.1. Aplicações como transferência de arquivos e correio eletrônico não são
sensíveis ao retardo. (TANENBAUM; WETHERALL, 2011)
Figura 2.1 – Filas no roteador Fonte: Kurose; Ross, 2010, p.27
33
Largura de banda: segundo Forouzan (2008),é formada pelos valores de taxa
máxima de dados (indica a largura de banda máxima que uma rede pode suportar),
taxa média (define a largura de banda média necessária ao tráfego) e tamanho
máximo de rajada (intervalo de tempo em que o tráfego consegue se manter na taxa
máxima). Aplicações como de vídeo-conferência exigem alta largura de banda.
(TANENBAUM; WETHERALL, 2011)
Flutuação (ou jitter): variação de tempo de chegada dos pacotes do mesmo
fluxo. Aplicações do tipo Voice over Internet Protocol (VoIP) são sensíveis a
flutuação.
Confiabilidade: em uma rede pouco confiável há uma grande quantidade de
perda e retransmissão de pacotes. Aplicações como a de acesso a web e
transferência de arquivos necessitam de uma rede confiável. (FOROUZAN, 2008)
Alguns desses parâmetros podem ser melhorados com a correta configuração
dos elementos da rede, por exemplo, switches, protocolos e o serviço de Domain
Name System (DNS).
2.4 TÉCNICAS DE QOS
A qualidade de uma rede de computadores pode ser alcançada por diferentes
meios, atualmente existem diversas técnicas, porém, o uso de uma somente não é
suficiente para a obtenção de uma QoS eficiente e segura, isso só é possível por
meio de uma combinação de várias técnicas. (TANENBAUM; WETHERALL, 2011)
Em uma rede de computadores onde não existe nenhum método de QoS
atuante, a rede trata todos pacotes da mesma maneira e faz o melhor possível para
entregar os pacotes ao destino, esse método é conhecido como melhor esforço.
(PARK, 2005)
2.4.1 Técnicas de controle de congestionamento
É muito comum técnicas de QoS atuarem no controle de congestionamento
em virtude da sua proximidade. (FOROUZAN, 2008)
Forouzan (2008, p. 559) se propôs a refletir: ‘’as duas técnicas são tão
próximas que melhorar uma, significa melhorar a outra e ignorar uma, geralmente
significa ignorar a outra. ’’
34
Segundo Forouzan (2008), as técnicas de controle de congestionamento
podem ser de prevenção ou de contenção. As técnicas preventivas são aplicadas
nos hosts de origem ou destino e atuam antes de o congestionamento acontecer. As
técnicas de contenção são aplicadas em hosts ou em elementos da rede, roteadores
por exemplo, e atuam durante o congestionamento, tentando aliviá-lo ou eliminá-lo.
Existem várias unidades métricas que podem ser utilizadas para monitorar a
rede a fim de verificar a ocorrência de congestionamento. Alguns deles são os
números de pacotes descartados por falta de espaço em buffer, tamanho médio da
fila e retardo médio de pacotes. (FOROUZAN, 2008)
2.4.2 Serviços integrados e serviços diferenciados
A Internet Engineering Task Force (IETF) propôs vários modelos de
mecanismos para atender a demanda de QoS, entre os resultados desses estudos
estão os serviços integrados e serviços diferenciados. (XIAO; NI, 1999)
Segundo Xiao e Ni (1999), o serviço integrado é caracterizado pela reserva de
recursos e utiliza o protocolo Resource Reservation Protocol (RSVP).
O modelo de serviço integrado identifica um fluxo de IP pelos seguintes
parâmetros: identificador do protocolo, endereço IP do destino, endereço de porta do
destino, endereço IP de origem e endereço de porta de origem. (PARK, 2005)
A reserva de recursos é realizada pelo protocolo RSVP, essa reserva é feita
por troca de mensagens entre o remetente e o receptor, esse diálogo pode ser
melhor observado na figura 2.2.
Figura 2.2 – Funcionamento do protocolo RSVP Fonte: Xiao; Ni, 1999, p.4
Primeiramente o remetente envia uma mensagem PATH que contém a
especificação do fluxo ao receptor. Essa mensagem passa pelos roteadores da rede
35
que registram a especificação, de modo que quando a mensagem RESV, que
contém a solicitação dos recursos, fizer o caminho inverso os roteadores possam
relacionar as mensagens PATH e RESV, alocar largura de banda e espaço em
buffer. (XIAO; NI, 1999) (PARK, 2005)
Segundo Tanenbaum e Wetherall (2011) o modelo de serviço integrado
oferece boa qualidade de serviço a um ou mais fluxos porque eles reservam os
recursos necessários ao longo da rota, porém esse modelo também possui suas
desvantagens, uma delas é a configuração antecipada para cada fluxo, o que não
funciona bem com um grande número de fluxo. Outra desvantagem segundo Xiao e
Ni (1999) é a necessidade de todos os roteadores da rede implementarem o RSVP,
o que em uma rede de grande porte se torna uma arquitetura não escalável.
A IETF então criou um modelo mais simples que se baseava na classe e não
no fluxo. Segundo Xiao e Ni (1999) o modelo de serviço diferenciado foi introduzido
devido a dificuldade da implementação dos serviços integrados e do protocolo
RSVP.
Park (2005) descreve que no modelo de serviço diferenciado os fluxos não se
distinguem e são agregados em classes de tráfego. Dessa maneira o tratamento
diferenciado, como largura de banda e outros recursos, se dá sobre essas classes.
A classe de serviço é identificada no campo denominado DS, que substituiu o
campo Type Of Service (TOS) no cabeçalho do pacote IP, por indicação da IETF.
(FOROUZAN, 2008)
Segundo Tanenbaum e Wetherall (2011) os serviços diferenciados podem ser
oferecidos por um conjunto de roteadores que formam um domínio administrativo, o
Internet Service Provider (ISP). Segundo Xiao e Ni (1999) para receber o serviço
diferenciado, o cliente deve ter uma Service Level Agreement (SLA), que nada mais
é do que um contrato que, dentre outras coisas, especifica as classes de serviços
suportadas e quantidade de tráfego permitida.
O modelo de serviço diferenciado possui dois conjuntos de elementos
funcionais, as funções de bordas, que são formadas pela classificação de pacotes e
o condicionamento de tráfego; e função central, formada pelo envio (KUROSE;
ROSS, 2010):
Funções de borda: quando um pacote passa pelo primeiro host ou
roteador habilitado a serviço diferenciado ele é marcado no campo DS com um
valor, assim ele pode receber tratamento diferenciado;
36
Função central: quando um pacote marcado chega em um roteador
habilitado a serviço diferenciado ele é repassado até o próximo salto, de acordo com
o comportamento associado a classe de serviço.
O modelo de serviço diferenciado é escalável e flexível, a necessidade de
escalabilidade vem do número de fluxos simultâneos, passando em um roteador da
Internet e a necessidade de flexibilidade vem do fato de que novas classes de
serviços podem surgir e as existentes se tornarem obsoletas. (KUROSE; ROSS,
2010)
Neste capítulo foram abordados os conceitos de QoS, seus parâmetros e
algumas técnicas utilizadas. No capítulo seguinte serão abordados os serviços de
firewall e o serviço de controle de tráfego, suas características e funcionamento.
37
3 SERVIÇOS DE REDE
A facilidade de acesso a Internet nos últimos anos contribuiu para a
popularização desses serviços, alguns deles, fundamentais em ambientes
empresariais. Nesse ambiente, além das vantagens financeiras que eles podem
gerar, ainda existem as vantagens competitivas, pois agilizam processos e
automatizam tarefas.
Nesse capítulo, busca-se apresentar os serviços de controle de tráfego e
firewall, que juntamente com a QoS serão utilizados para validação da pesquisa
posteriormente nos testes práticos.
3.1 CONTROLE DE TRÁFEGO
Controle de tráfego é o nome dado aos conjuntos de sistemas de filas e
mecanismos pelos quais os pacotes são recebidos e transmitidos em um roteador.
Isso inclui decidir quais pacotes aceitar e a que taxa de transmissão passará pela
interface, bem como determinar quais pacotes transmitir, em qual ordem e a que
taxa de transmissão irá passar pela interface de saída. (BROWN, 2006)
Há exemplos de filas em todos os tipos de software. A fila é uma forma de
organizar as tarefas ou dados. No caso de um servidor compartilhando o mesmo link
para Internet com outros computadores, poderá ocorrer disputa por banda, com isso
o controle de tráfego ajuda na melhor divisão deste recurso. (BROWN, 2006)
Quando bem utilizado, o controle de tráfego conduz ao uso mais previsível e
na melhor distribuição dos recursos da rede de computadores. Por exemplo, um
download pode ser realizado sem afetar outras aplicações. Segundo Brown (2006) a
configuração de controle de tráfego representa uma política que foi comunicada aos
usuários, os usuários (e, por consequência, aplicações) sabem o que esperar da
rede.(BROWN, 2006)
De acordo com Brown (2006) a complexidade é a desvantagem mais
significativa no controle de tráfego, ainda segundo o autor, existem maneiras de se
familiarizar com as ferramentas, mas a identificação de um erro de configuração
pode ser um grande desafio. Dessa maneira, muitas empresas adquirem mais
38
largura de banda como solução para seus problemas ao invés de investir em
treinamento e em ferramentas de controle de tráfego. (BROWN, 2006)
3.2 FIREWALL
Datado em meados dos anos 80, o primeiro firewall foi desenvolvido pela Bell
Labs por encomenda da AT&T, o objetivo da ferramenta era filtrar todos os pacotes
que saíssem e entrassem na rede corporativa, sendo possível manipulá-los de
acordo com regras predefinidas pelos cientistas da Bell Labs. (NETO, 2004)
A evolução da tecnologia não suprimiu a necessidade do uso do firewall, pelo
contrário, o tornou extremamente importante, principalmente pelo número de
computadores conectados por meio da Internet e sujeitos a ataques de diversos
tipos e motivados por diversas razões. Segundo o site Centro de estudos, reposta e
tratamento de incidentes de segurança no Brasil (CERT), em 2012 foram reportados
a ele 466029 incidentes no Brasil. O CERT é um grupo responsável por tratar
incidentes de segurança em computadores que envolvam redes conectadas à
Internet brasileira. Com o propósito de conscientizar sobre os problemas de
segurança os incidentes reportados são exibidos em forma de gráficos, como ilustra
a figura 3.1.
Figura 3.1 – Tipos de incidentes reportados á CERT em 2012 Fonte: CERT, 2013
Segundo Neto (2004) firewall é um programa que detém autonomia concedida
pelo sistema para pré-determinar e disciplinar todo tipo de tráfego existente entre o
mesmo e outros hosts/rede.
Comumente o firewall está situado entre a rede Internet e o ponto em que os
computadores da rede local se conectam, esse ponto pode ser um switch ou um
39
hub. Nessas condições, faz-se uso de um computador com duas placas de rede,
onde uma é conectada a Internet e outra a rede local. (MORIMOTO, 2006)
Dessa maneira o firewall se torna o único elemento conectado diretamente a
Internet e automaticamente a primeira defesa dessa rede. Tem funcionamento
parecido com a de uma barreira, isolando as duas redes. Todos os pacotes que
entram e saem da rede passam por ele, possibilitando a filtragem e o monitoramento
de todo tráfego. O posicionamento do firewall pode ser mais bem observado na
figura 3.2.
Figura 3.2 – Posicionamento do firewall na rede de computadores Fonte: Forouzan, 2008, p.560
3.2.1 Firewall filtro de pacotes
A filtragem de pacotes é a principal e mais utilizada função do firewall, em
uma rede onde ele está configurado para realizar essa função, é possível analisar os
cabeçalhos dos pacotes enquanto eles trafegam e filtrar o tráfego com base em
regras predefinidas, assim direcionando os pacotes ao seu devido destino (NETO,
2004)
Conforme citado por Tanenbaum e Wetherall (2011), em geral a filtragem de
pacotes é baseada em tabelas configuradas pelo administrador do sistema. Nelas
estão listadas as origens ou destinos aceitáveis e bloqueados e as regras padrão
que orientam o que deve ser feito com pacotes recebidos de outras maquinas ou
destinados a elas.
De acordo com Kurose e Ross (2010) as decisões de filtragem podem ser
baseadas em endereço IP de destino ou origem, tipos de protocolos, porta de
40
destino ou origem, entre outros.
Para exemplificar, em um ambiente corporativo onde é proibido o acesso a
Internet, isso pode ser feito bloqueando todos os pacotes de saída com destino a um
IP com porta 80. (TANENBAUM; WETHERALL, 2011)
41
4 IPTABLES
O iptables é uma ferramenta nativa do Linux que possibilita controlar as
tabelas do módulo Netfilter, é popularmente conhecido como um firewall, porém
essa é só uma de suas funções. (NETO, 2004)
O iptables foi desenvolvido por Rusty Russell em colaboração com Michel
Neuling e implementado na versão 2.4 do Kernel do Linux em 1999.
Para melhor entendimento da ferramenta iptables, é necessário conhecermos
onde ela está localizada e do que é composta, a seguir uma melhor abordagem
sobre esses elementos.
4.1 KERNEL
A criação do Kernel teve inicio em 1991 por Linus Torvalds quando ele era um
estudante na universidade de Helsinki na Finlândia, a primeira versão do Kernel veio
a público em setembro desse mesmo ano. O Kernel do Linux foi a ultima e mais
importante peça de código necessária para completar o sistema operacional UNIX-
Like. (NEGUS, 2010)
Segundo Silva (2010) o Kernel é a peça central do sistema operacional Linux,
ele controla os dispositivos e os demais periféricos do sistema como disco rígido e
placa de rede. A localização do Kernel pode ser melhor observada na figura 4.1.
Figura 4.1 – Localização do Kernel Fonte: CLIPATEC INFORMÁTICA, 2011
Negus (2010) descreve o Kernel como sendo um software que inicia junto
com o computador e permite a comunicação eficaz entre os hardwares do
computador e os programas.
42
4.2 MÓDULO NETFILTER
Segundo Silva (2010), um módulo é uma parte do Kernel inicializada somente
quando solicitada por algum aplicativo ou dispositivo e descarregada da memória
quando não é mais utilizada. São importantes porque evitam a construção de um
Kernel muito grande que ocupa grande parte da memória e também por permitir que
partes do Kernel ocupem espaço em memória só quando necessário.
Tudo o que acontece no sistema operacional, independente da camada,
passa pelo Kernel, tarefas comum a um computador como o gerenciamento de
processos e gerenciamento de memória por si só já exigem bastante do Kernel, por
isso a necessidade de criar módulos que trabalhem em conjunto com o Kernel. O
modulo Netfilter foi criado para que o kernel pudesse controlar seu próprio fluxo
interno. (NETO, 2004)
O módulo Netfilter é composto por tabelas, regras e chains, a seguir uma
melhor descrição de cada um desses elementos.
4.3 TABELAS
Segundo Neto (2004) é possível ver o Netfilter como um banco de dados que
contém três principais tabelas, a Filter, Network Address Translation (NAT) e
Mangle, cada uma com regras para uma finalidade específica, além de possuir as
tabelas raw e security que não serão abordados nesse trabalho.
As tabelas são os locais onde ficam armazenadas as chains e o conjunto de
regras com uma determinada característica em comum. (SILVA, 2010)
4.3.1 Tabela Filter
Filter é a tabela padrão do iptables, é nela que ficam armazenadas as regras
referentes a um firewall filtro de pacotes. (NETO, 2004)
Por ser a tabela padrão, toda regra em que não é especificada a tabela o
iptables assume que a tabela ma qual será inserida a regra é a filter. (NETO, 2004)
As situações de fluxo, ou seja, as chains possíveis nessa tabela são:
INPUT: todos os pacotes que tem como destino a máquina em que o iptables
está em funcionamento;
43
OUTPUT: todos os pacotes gerados pela máquina onde o iptables está em
funcionamento
FORWARD: todos os pacotes que passam pelo iptables vindo de uma
máquina e direcionado a outra. A figura 4.2 ilustra como os pacotes são tratados
pela tabela filter.
Figura 4.2 – Esquema da tabela Filter Fonte: Filho, 2013
4.3.2 Tabela NAT
Segundo Silva (2010) a tabela NAT é utilizada quando são geradas outras
conexões. As situações possíveis na tabela NAT são:
PREROUTING: utilizado quando é preciso fazer alterações no pacote antes
de serem roteados. (NETO, 2004)
OUTPUT: utilizado quando pacotes gerados localmente precisam ser
modificados antes de serem roteados. (SILVA, 2010)
POSTROUTING: utilizado quando é preciso modificar pacotes após o
roteamento. (SILVA, 2010) O roteamento da tabela NAT é ilustrado pela figura 4.3.
Figura 4.3 – Esquema da Tabela NAT
Fonte: Filho, 2013
44
4.3.3 Tabela Mangle
A tabela mangle é utilizada para fazer tratamentos mais profundos nos
pacotes como alterar a prioridade de entrada e saída de um pacote baseado no
campo tipo de serviço. (NETO, 2004)
As situações possíveis para essa tabela são:
INPUT: usado para alterar pacotes com direção ao próprio firewall
OUTPUT: usado para alterar pacotes gerados localmente antes do
roteamento
FORWARD: usado para alterar pacotes sendo roteados no firewall
PREROUTING: usado para alterar pacotes recebidos antes do roteamento.
POSTROUTING: usado para alterar pacotes antes de sairem (IPTABLES,
2013)
4.4 REGRAS
Neto (2004) entende as regras como pré-definições aplicadas a fim de
disciplinar todo um tráfego de dados em uma rede ou host.
Segundo Silva (2010) as regras são comandos passados pela ferramenta
iptables ao módulo Netfilter, para que ele tome determinada ação com base em
informações. As regras são armazenadas dentro das chains e processadas na
ordem que são inseridas.
4.5 CHAIN
As regras do firewall definidas pelo usuário ficam localizadas nas chains.
Segundo Silva (2010) existem dois tipos de chains, as embutidas e as criadas pelo
usuário.
Neto (2004) descreve as chains como situações vividas pelo Kernel. ‘’Logo,
uma situação de entrada trataria-se, na verdade de uma INPUT chain, uma situação
de redirecionamento uma FORWARD chain e uma situação de saída uma OUTPUT
chain.’’ (NETO, 2004, pag. 21,22)
45
4.6 FERRAMENTA IPTABLES
Para que fosse possível inserir, modificar e apagar as regras no módulo
Netfilter foi criada a ferramenta iptables. Ela não requer grande poder computacional
e é composta por 4 outras aplicações. a iptables que é utilizada para manipular as
regras referente ao protocolo ipv4, o ip6tables que é usado para o protocolo IPv6,
iptables-save utilizado para salvar as regras inseridas da sessão ativa em um
arquivo informado pelo administrador da rede e o iptables-restore que restaura as
regras salvas em um arquivo. (NETO, 2004)
Segundo Neto (2004) a síntese das regras do iptables é:
Iptables [tabela] [comando] [alvo] [ação]
4.6.1 Comandos
A seguir um descritivo dos comandos do iptables e alguns exemplos.
-A: adiciona uma regra ao fim da lista de regras.
root@ubuntu:/home/mauricio# iptables -t filter -A INPUT -s
192.168.0.10 -j DROP
Essa regra descarta todo pacote entrando no firewall vindo do endereço
192.168.0.10
-D: Apaga uma regra da lista, pode ser utilizado substituindo o –A por –D ou
inserindo o número da regra.
root@ubuntu:/home/mauricio# iptables -t filter -D INPUT -s
192.168.0.10 -j DROP
-L: lista as regras de uma tabela.
root@ubuntu:/home/mauricio# iptables -L
Chain INPUT (policy ACCEPT)
Target prot opt source destination
DROP all -- 192.168.0.10 anywhere
46
Chain FORWARD (policy ACCEPT)
Target prot opt source destination
Chain OUTPUT (policy ACCEPT)
Target prot opt source destination
Esse comando lista as regras da tabela filter.
-P: altera a política padrão das chains, inicialmente todas elas são ACCEPT.
root@ubuntu:/home/mauricio# iptables -t filter -P INPUT DROP
Essa regra define como política padrão a ação de descarte para a chain
INPUT.
-F: remove todas as entradas da lista de regras sem alterar a política padrão
root@ubuntu:/home/mauricio# iptables –F
Essa regra remove todas as regras da tabela filter, mas mantém a política
padrão
-I: insere uma nova regra no início da lista
root@ubuntu:/home/mauricio# iptables -I INPUT -d 192.168.0.0 -
j ACCEPT
A regra acima aceita todo pacote vindo da rede 192.168.0.0
-R: substitui uma regra da lista por outra
root@ubuntu:/home/mauricio# iptables -R INPUT 1 -d 192.168.0.5
-j DROP
Essa regra substitui a rede 192.168.0.0 e a ação de ACCEPT da regra
anterior pelo endereço 192.168.0.5 e a ação DROP.
-N: cria uma nova chain
root@ubuntu:/home/mauricio# iptables -t nat -N internet
root@ubuntu:/home/mauricio# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
Target prot opt source destination
Chain INPUT (policy ACCEPT)
47
Target prot opt source destination
Chain OUTPUT (policy ACCEPT)
Target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
Target prot opt source destination
Chain internet (0 references)
Target prot opt source destination
As primeira regra usada cria uma chain na tabela filter com o nome de internet
e em seguida é listada as chains da tabela filter.
-E: renomeia uma chain criada pelo administrador
root@ubuntu:/home/mauricio# iptables -t nat -E internet
permitirAcesso
root@ubuntu:/home/mauricio# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
Target prot opt source destination
Chain INPUT (policy ACCEPT)
Target prot opt source destination
Chain OUTPUT (policy ACCEPT)
Target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
Target prot opt source destination
Chain permitirAcesso (0 references)
Target prot opt source destination
Aqui é renomeado a chain criada anteriormente com o nome de internet para
permitirAcesso.
-X: apaga uma chain criada pelo administrador
root@ubuntu:/home/mauricio# iptables -t nat -X permitirAcesso
Essa regra apaga a chain criada com o nome de permitir Acesso
48
4.6.2 Alvo
A seguir a lista de alvos possíveis da ferramenta iptables e alguns exemplos -p: especifica o protocolo aplicado a regra;
root@ubuntu:/home/mauricio# iptables -A INPUT -p udp -j DROP
Essa regra rejeita todo pacote do protocolo UDP entrando no firewall
-i: especifica a interface de entrada na regra.
root@ubuntu:/home/mauricio# iptables -A INPUT -i eth1 -j
ACCEPT
Essa regra aceita todos os pacotes que entram no firewall pela interface eth1
-o: especifica a interface de saída na regra
root@ubuntu:/home/mauricio# iptables -A OUTPUT -o eth1 -j
ACCEPT
Essa regra permite a saída de todos os pacotes pela interface eth1.
-s: especifica a origem dos pacotes na regra.
root@ubuntu:/home/mauricio# iptables -A INPUT -s 192.168.0.4 -
j REJECT
Essa regra rejeita todos os pacotes vindo do endereço 192.168.0.4
-d: especifica o destino dos pacotes na regra.
root@ubuntu:/home/mauricio# iptables -A INPUT -d 192.168.0.3 -
j ACCEPT
Essa regra aceita todos os pacotes com origem o IP 192.168.0.3
!: é utilizado para especificar uma exceção
root@ubuntu:/home/mauricio# iptables -A OUTPUT ! -o eth0 -j
DROP
Essa regra rejeita todos os pacotes vindo de todas as interfaces com exceção
da interface eth0.
--sport: define a porta de origem.
49
root@ubuntu:/home/mauricio# iptables -A INPUT -p tcp --sport
80 -j DROP
Essa regra descarta todos os pacotes com porta de origem 80.
--dport: define a porta de destino na regra
root@ubuntu:/home/mauricio# iptables -A OUTPUT -p tcp --dport
21 -j DROP
Essa regra descarta todos os pacotes que a porta de destino é a 21.
4.6.3 Ação
Toda regra possui uma ação em relação ao pacote, as ações vem depois da
opção –j e as possíveis são:
ACCEPT - aceita o pacote,
DROP - descarta o pacote sem notificar a origem do pacote
REJECT - descarta o pacote e envia uma mensagem icmp notificando a
origem do pacote
LOG – cria uma entrada no arquivo de log, a localização do arquivo pode
variar de distribuição para distribuição, no Ubuntu Server a localização é
/var/log/kern.log,
SNAT – altera o endereço de origem do pacote antes de serem roteados
DNAT– altera o endereço de destino do pacote
REDIRECT – é utilizada em conjunto com a opção –to-port par realizar o
redirecionamento de porta
TOS – prioriza a entrada e saída de pacotes baseando no campo tipo de
serviço localizado no cabeçalho do pacote IPv4
Neste capitulo foram apresentadas as regras para uso da ferramenta iptables.
No capítulo seguinte serão apresentados os testes implementados para avaliação da
ferramenta, bem como apresentação dos resultados de cada simulação.
5 IMPLEMENTAÇÃO
De modo a avaliar a ferramenta iptables em diferentes aspectos da gerencia
de redes de computadores realizamos testes que abrangem as áreas de segurança,
gerência de tráfego e qualidade de serviço.
50
Para testar o iptables como ferramenta de segurança exercendo a função de
firewall os testes focaram a proteção contra ataque de varredura de portas e ataque
de Ping Flood, uma variante do ataque Denial of Service (DoS), esses serão melhor
abordados durante os testes.
No aspecto da gerencia de tráfego foi utilizado o iptables em conjunto com
outras ferramentas, no teste foi simulado uma situação em que há a necessidade de
fazer a melhor divisão dos recursos da rede, mais especificamente o link da Internet.
Na qualidade de serviço foi priorizado o serviço de FTP reservando uma
largura de banda maior e classificando como tráfego prioritário.
5.1 CENÁRIO
Os testes foram realizados em sistemas operacionais virtualizados no
software VirtualBox. As configurações dos computadores utilizados estão descritos
na tabela 5.1.
Tabela 5.1 - Configuração das máquinas virtuais utilizadas
Descrição Servidor/firewall Host A Host B Atacante
S.O. Linux Ubuntu Server
12.04.3
Windows
XP
Windows
XP
Linux Ubuntu
Server
12.04.3
Memória 512MB 512MB 512MB 512MB
HD 8G 8G 8G 8G
Interface eth1 – 192.168.0.102
eth2 – 192.168.1.1
eth3 – 192.168.2.1
192.168.1.2 192.168.2.2 192.168.0.104
Fonte: Elaborado pelo autor, 2013
Os hosts estão interligados ao servidor por meio da opção rede interna do
Virtualbox. O cenário pode ser observado na figura 5.1.
51
Figura 5.1 – Organização da rede de testes Fonte: Elaborado pelo autor, 2013
5.2 SEGURANÇA
Para simular os ataques foi inserido dois computadores na mesma rede,
sendo o atacante e o servidor com as configurações citadas anteriormente.
Figura 5.2 – Cenário de testes de segurança Fonte: Elaborado pelo autor, 2013
5.2.1 Ataque de varredura de portas
O ataque de varredura de portas tem como finalidade identificar quais
computadores estão ativos e quais serviços são disponibilizados por eles. Esse
ataque é amplamente utilizado por atacantes para identificar potenciais alvos, pois
permitem associar possíveis vulnerabilidades aos serviços habilitados em um
computador. (CERT, 2013)
Esse tipo de ataque faz solicitações de conexão nas portas do alvo, ou seja,
envia um pacote que solicita sincronização e aguarda resposta. Em redes de
computadores, antes de iniciar a comunicação entre dois hosts ocorre um processo
de sincronização chamado Handshake de três vias. O cliente que deseja iniciar uma
comunicação envia um pacote com a flag SYN ativa que solicita sincronização, o
servidor então responde com um pacote SYN + ACK que aceita a sincronização,
52
esse processo é encerrado com o pacote ACK que parte do cliente, em seguida tem
início a comunicação de fato. (SMITH, 2011)
O handshake de três vias pode ser observado com ferramentas de capturas
de pacote, como no exemplo da figura 5.3 em que são capturados pacotes do inicio
de uma conexão Security Shell (SSH) com a ferramenta WireShark.
Figura 5.3 – Handshake de três vias Fonte: Elaborado pelo autor, 2013
A varredura de portas pode iniciar em uma porta baixa e seguir a ordem
crescente, pode iniciar em uma porta alta e seguir a ordem decrescente, como pode
também analisar apenas uma série de portas pré-determinadas pelo atacante.
(NMAP, 2013)
5.2.2 Teste de segurança contra ataque de varredura de portas
Sem conhecimento de quais serviços estão em execução no alvo e em quais
portas eles aguardam solicitação, a varredura passa por várias portas fechadas
antes de encontrar uma aberta. O módulo recent nos permite criar dinamicamente
uma lista de endereços IP e combina-la com outras regras. (IPTABLES, 2013)
Foi feito uso desse módulo e foi utilizado o número de tentativas de acesso
que não obtiveram sucesso como regra para inseri-lo na lista.
Antes de iniciarmos as explicações das regras utilizadas, é importante
esclarecer o funcionamento da política padrão. Dentre as regras contidas em um
script de firewall estão as regras que dão permissões de entrada, saída e
roteamento no firewall. Tudo o que não estiver permitido será tratado pela política
padrão, que nos testes é DROP, ou seja, toda requisição que não estiver
explicitamente permitida nas regras do script será descartada.
Dando início as explicações, a primeira regra é inserida no fim do script e atua
antes da política padrão.
iptables -A INPUT -m recent --set --name BLACKLISTSCAN
53
Quando uma requisição passa por essa regra o endereço IP de origem é
inserido em uma lista com nome BLACKLISTSCAN. Duas regras fazem uso da lista
BLACKLISTSCAN para evitar o ataque, a primeira regra atualiza o número de vezes
que o endereço IP aparece na lista e se for a quinta vez ou mais na ultima uma hora
gera um log. Para não encher o arquivo de log foi limitado a criação de uma
mensagem por minuto conforme linha de comando a seguir.
iptables -A INPUT -m recent --update --hitcount 5 --name
BLACKLISTSCAN -m limit --seconds 3600 --limit 1/m -j LOG --
log-prefix ALERTA_DE_PORTSCAN --log-ip-options
A terceira regra repete a verificação da regra anterior, porém sua ação é de
descarte do pacote. O parâmetro que atualiza o número de vezes em que o
endereço IP aparece na lista BLACKLISTSCAN é o –-update, o parâmetro que
verifica se o IP já foi inserido 5 vezes ou mais na lista é o hitcount 5. O
parâmetro –-seconds 3600 determina o tempo de validade da regra, ou seja, se
o IP foi inserido na lista na ultima hora. A ação de descarte é determinada pelo
parâmetro –j DROP.
iptables -A INPUT -m recent --update --hitcount 5 --name
BLACKLISTSCAN --seconds 3600 -j DROP
No desenvolvimento dos testes foi usado como ferramenta de ataque o
Nmap, que é uma ferramenta livre e de código aberto, utilizada para testes de
segurança. (NMAP, 2013)
No primeiro teste, o servidor estava sem regras de firewall ativas. O comando
utilizado pelo atacante faz uma varredura iniciando na porta de número 1 até a porta
de número 1024. O resultado da varredura de portas pode ser visto na figura 5.4, em
que todos os serviços ativos são exibidos, como o serviço de FTP que aguarda
solicitações na porta 21, o serviço de SSH na porta 22, o servidor de e-mail que
utiliza a porta 25 e o servidor web que faz uso da porta 80. Além dos serviços em
execução no servidor a varredura de portas conseguiu identificar o endereço físico
da interface.
54
Figura 5.4 – Varredura de portas com êxito Fonte: Elaborado pelo autor, 2013
No segundo teste as regras do firewall estavam ativas. O comando utilizado
para iniciar o script de nome iptables que contêm as regras e está localizado em
/etc/init.d é:
root@ubuntu:/home/mauricio# /etc/init.d/iptables start
A figura 5.5 ilustra a inicialização do script.
Figura 5.5 – Iniciando script de regras Fonte: Elaborado pelo autor, 2013
Agora com as regras ativas no firewall foi feita uma nova varredura com a
máquina do atacante, a figura 5.6 exibe o resultado do ataque.
Figura 5.6 – Varredura de portas sem êxito Fonte: Elaborado pelo autor, 2013
55
Com as regras do firewall em execução o ataque de varredura de portas não
obteve sucesso, todos os pacotes originários do atacante serão bloqueados por 1
hora e os logs foram gerados no sistema, como é possível observar na figura 5.7.
Figura 5.7 – Log do sistema operacional Fonte: Elaborado pelo autor, 2013
A segurança pode ser maior se substituir as portas padrão dos serviços por
portas altas, como ilustra a figura 5.8, em que a porta do SSH foi alterada para 2222
e a porta do FTP para 2121.
.
Figura 5.8 – Lista de portas alteradas Fonte: Elaborado pelo autor, 2013
5.2.3 DoS: Ping Flood
Segundo o CERT (2013) o ataque de DoS ocorre quando um atacante utiliza
um computador para tirar de operação um serviço, computador ou rede.
Em síntese o ataque de DoS se baseia em enviar a vitima uma quantidade de
solicitações maior do que ela consegue suportar, dessa forma, negando o serviço.
(ALECRIM, 2012)
56
O ataque de DoS é possível devido a algumas características do protocolo
TCP/IP, portanto qualquer computador que utilize esse protocolo está suscetível a
esse tipo de ataque. (ALECRIM, 2012)
Outro fator que o torna bastante utilizado é a sua facilidade de utilização.
(AX3 SOFT, 2013)
O ataque de DoS possui formas diferentes de atingir seu objetivo, uma das
variantes é o Ping Flood que faz uso do pacote ICMP do tipo echo request,
popularmente conhecido como ping.
O ping é comumente utilizado pelos administradores de redes de
computadores para testar a comunicação entre dois equipamentos. (AX3 SOFT,
2013)
5.2.4 Testes de segurança contra ataque de Ping Flood
Com a ferramenta iptables é possível dificultar o sucesso do ataque de Ping
Flood limitando a quantidade de pings recebido. A primeira regra permite a entrada
de uma solicitação de echo request por segundo. Caso mais que uma solicitação
seja recebida no intervalo de um segundo as próximas regras do script que tratam
requisições icmp irão atuar.
iptables –A INPUT –p icmp –icmp-type echo-request –i eth1 –m
limit –limit 1/s –j ACCEPT
A regra da sequência gera um log no sistema notificando o ataque. Também
para não enchermos o arquivo de log, limitamos a quantidade de 1 log por minuto.
iptables –A INPUT –p icmp –icmp-type echo-request –i eth1 –m
limit –limit 1/m –j LOG –log-prefix DoS –log-ip-options
A última regra rejeita a solicitação de echo request que não foi aceita pela
primeira regra.
iptables –A INPUT –p icmp –icmp-type echo-request –j DROP
57
O teste foi realizado utilizando dois computadores, sendo um com sistema
operacional Windows 7 e a outra com o sistema operacional Ubuntu Server
virtualizado. Ao mesmo tempo as duas máquinas enviaram solicitações ao firewall.
Como é possível observar na figura 5.9 logs foram gerados notificando o
administrador.
5.9 – Log de Ping Flood Fonte: Elaborado pelo autor, 2013
Os resultados dos testes de segurança realizados com o iptables
demonstraram bom desempenho e de certo pode ser utilizado como um firewall sem
necessidade de outra ferramenta em conjunto.
5.3 CONTROLE DE TRÁFEGO
O objetivo dos testes documentado abaixo é demonstrar a variedade de
possibilidades de classificação dos pacotes IP utilizando o iptables e a eficiência no
gerenciamento de tráfego em conjunto à ferramenta Traffic Control (TC) e a
disciplina Hierarchical Token Bucket (HTB).
5.3.1 Cenário
Segundo Tanenbaum e Wetherall (2011), a princípio, o interesse em interligar
dois ou mais computadores fisicamente próximos era a possibilidade do
compartilhamento de recursos, como arquivos, impressoras e leitores de CDs, esse
58
modelo de arquitetura é conhecido como cliente servidor. O cenário de testes para
controle de tráfego se baseia nesse modelo.
Foi simulada uma rede com duas máquinas clientes conectadas ao servidor e
com acesso a Internet fazendo uso de NAT. A máquina Host A possui endereço IP
192.168.1.2 e em suas atividades necessita de mais velocidade de upload do que
download, portanto foi classificada para utilizar 300kbit de upload 250kbit de
download. A máquina Host B possui endereço IP 192.168.2.2 e necessita de mais
download do que upload, assim, foi classificada para usar 100kbit de upload e
500kbit de download.
5.3.2 Ferramentas para controle de tráfego
Segundo Boxman (2005) a capacidade de controle de tráfego está disponível
no Kernel do Linux desde a versão 2.2, porém o iptables não tem como função o
controle de tráfego, para realizar essa função no Linux usa-se uma ferramenta do
iproute2. Segundo Brown (2006) iproute2 é um conjunto de utilitários de linha de
comando que manipulam estruturas do Kernel para a configuração de rede IP.
Dentre suas ferramentas a única que realiza a função de controle de tráfico é o TC.
A ferramenta TC permite ao administrador da rede controlar as filas e os
mecanismos de enfileiramento em um dispositivo de rede, interage com o Kernel
para gerenciar a criação, exclusão e modificação de estruturas de controle de
tráfego. (BROWN, 2006)
Em conjunto ao TC utilizamos a disciplina HTB. Entende-se por disciplina um
algoritmo que controla o tráfego de uma rede de computadores. (FILHO, 2007)
Segundo Filho (2007), o Kernel Linux trabalha com dois tipos de disciplina de
enfileiramento, são elas a Classfull e a Classless, as disciplinas Classfull utilizam
várias classes, por exemplo a disciplina Class Based Queueing (CBQ) e o HTB. As
disciplinas Classless utilizam apenas uma classe, por exemplo, o Stochastic
Fairness Queuing (SFQ) e o Packet First in First Out (PFIFO).
No controle de tráfego o iptables é usado para marcar pacotes direcionando o
fluxo a uma determinada classe com características de tráfego pré-definidas.
5.3.3 Testes de controle de tráfego
59
No inicio do script foi usado duas regras para remover toda configuração de
controle de tráfego pré-existente na interface eth1, eth2 e eth3.
tc qdisc del dev eth1 root
tc qdisc del dev eth2 root
tc qdisc del dev eth3 root
Segundo Filho (2007) o HTB utiliza um conceito de tráfego controlado por
classes hierarquizadas, um exemplo da hierarquia de classes do HTB pode ser
visualizado na figura 5.10. No topo da hierarquia está a disciplina root. Essa regra
faz com que a interface de rede trabalhe com a disciplina HTB e não com outra
disciplina. Abaixo da disciplina root estão as classes que contém as limitações a
serem respeitadas.
Figura 5.10 – Hierarquia de classes no HTB Fonte: Elaborado pelo autor, 2013
Para melhor entendimento, antes de darmos inicio as inserções das regras no
script, na tabela 5.2 será descrito alguns parâmetros do TC segundo Leite (2013).
Tabela 5.2 – Definições de parâmetros do TC
Parâmetro Definição
class add Indica a criação de uma classe
parent Indica que uma classe é pai de outra, ou seja, se originou dela.
Classid Código de identificação da classe
60
Rate Este valor representa a taxa desejada com que os pacotes devem
deixar esta classe
Ceil Largura de banda máxima que a classe pode usar
Prio Nível de prioridade associada à classe.
Fonte: Elaborado pelo autor, 2013
Para a configuração de controle de tráfego foram criadas as disciplinas root
de todas as interfaces, para isso bastam os seguintes comandos:
tc qdisc add dev eth1 root handle 1:0 htb default 50
tc qdisc add dev eth2 root handle 2:0 htb default 50
tc qdisc add dev eth2 root handle 3:0 htb default 50
Cada disciplina possui um identificador, a disciplina da interface eth1 tem
identificador 1:0, da interface eth2 identificador 2:0 e da eth3, 3:0.
Depois de criada as disciplinas root, foram criadas as classes. A primeira
classe é filha da disciplina root, e será pai das próximas classes que serão criadas.
Cada classe tem um identificador e rate de 100Mbit.
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1Mbit
tc class add dev eth2 parent 2:0 classid 2:1 htb rate 1Mbit
tc class add dev eth3 parent 3:0 classid 3:1 htb rate 1Mbit
Na sequência, foi inseridas as regras que irão controlar a velocidade do
tráfego que sai dos clientes e vão em direção a Internet, o upload. Essas regras
ficam localizadas na Interface de saída, ou seja, na eth1. Serão criadas duas classes
diferentes, uma com identificador 1:10, filha da classe 1:1, com rate de 100kbit,
largura máxima de banda de 100kbit e nível de prioridade 5. A segunda classe tem
identificador 1:11, o mesmo valor de rate e prioridade, porém, largura máxima de
banda de 300kbit.
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 100kbit
ceil 100kbit prio 5
61
tc class add dev eth1 parent 1:1 classid 1:11 htb rate 100kbit
ceil 300kbit prio 5
Na sequência foi criada a regra para controle do tráfego que tem origem na
Internet e se destina a um cliente da rede. Primeiramente foram criadas as regras
para o host A. A regra é filha da classe 2:1, tem como identificador 2:11, possui
100kbit de rate, largura máxima de banda de 250kbit e nível de prioridade 5.
tc class add dev eth2 parent 2:1 classid 2:10 htb rate 100kbit
ceil 250kbit prio 5
O mesmo procedimento é feito para a interface eth3, a classe possui
identificador 3:11, é filha da classe 3:1, possui rate de 100kbit, largura máxima de
banda de 500kbit.e o mesmo nível de prioridade da classe 2:11.
tc class add dev eth3 parent 3:1 classid 3:10 htb rate 100kbit
ceil 500kbit prio 5
Finalizado o processo de criação das classes, basta criarmos as marcações
com o iptables. Para isso utilizamos a tabela mangle. Iniciamos com o
gerenciamento do host A.
Como dito anteriormente, na simulação o host A necessita de mais velocidade
de upload do que download, portanto, foi classificado conforme essa necessidade. A
primeira marcação é referente ao tráfego de upload, nela todo tráfego que tem como
origem o IP 192.168.1.2 é classificado com a classe 1:11.
iptables -t mangle -A FORWARD -s 192.168.1.2 -j CLASSIFY --
set-class 1:11
Em seguida foi classificado todo tráfego vindo da Internet, ou seja, tráfego de
download com destino o IP 192.168.1.2 com a classe 2.10.
iptables -t mangle -A FORWARD -d 192.168.1.2 -j CLASSIFY --
set-class 2:10
62
Por fim foi classificado o tráfego do host B, primeiro o tráfego de upload e
depois o de download.
iptables -t mangle -A FORWARD -s 192.168.2.2 -j CLASSIFY --
set-class 1:10
iptables -t mangle -A FORWARD -d 192.168.2.2 -j CLASSIFY --
set-class 3:10
Após o término das configurações e deixarem-nas ativas, basta efetuar os
testes. Os testes foram realizados no site http://speedtest.copel.net/, esse mede a
velocidade de download e upload de uma conexão. O primeiro teste foi realizado no
Host A e o resultado chegou bem próximo ao limite imposto pelas classes. O
resultado pode ser visto na figura 5.11.
Figura 5.11 – Teste de velocidade Host A Fonte: Elaborado pelo autor, 2013
O resultado do teste realizado no Host B também fica bem próximos ao
imposto pelas classes. O resultado é exibido na figura 5.12
63
Figura 5.12 - Teste de velocidade Host B Fonte: Elaborado pelo autor, 2013
Concluiu-se ao fim dos testes de controle de tráfego que a ferramenta iptables
pode ser utilizada para efetuar essa gerência, porém necessita de outras
ferramentas em conjunto para efetuar essa tarefa.
5.4 QoS
Para testar a ferramenta iptables com relação a qualidade de serviço foi
mantido o mesmo cenário do teste de controle de tráfego. Porém agora simulamos
uma situação em que um Host necessita utilizar com frequência o serviço de FTP e
para isso pode utilizar mais largura de banda, mas esse recurso só pode ser
utilizado para o serviço de FTP. Dessa forma foi priorizado somente o tráfego do
serviço FTP.
5.4.1 Teste de qualidade de serviço
Primeiramente foi criada a classe para o serviço de FTP que atua na interface
eth2 e limita a 500kbit a banda. Além disso, é marcada como prioridade 1, assim se
houver outro tráfego no momento, o tráfego dessa classe terá prioridade em relação
as outras.
64
tc class add dev eth2 parent 2:1 classid 2:15 htb rate 100kbit
ceil 500kbit prio 1
Em seguida foi marcado com o iptables o tráfego do serviço FTP. Segundo
Marques (2013) o FTP pode funcionar de dois modos, ativo e passivo. No modo
ativo utiliza a porta 21 para comunicação de comandos e a porta 20 para
transferência de arquivos. No modo passivo o servidor e o host fazem a
transferência de arquivos utilizando uma porta alta. A primeira marcação é para o
FTP no modo passivo e em seguida para o modo ativo:
iptables -t mangle -A FORWARD -d 192.168.1.2 -p TCP --sport
1024:65535 -j CLASSIFY --set-class 2:15
iptables -t mangle -A FORWARD -d 192.168.1.2 -p TCP --sport
20:21 -j CLASSIFY --set-class 2:15
Para testar o funcionamento da QoS foi feita uma transferência FTP de um
arquivo A largura de banda utilizada na transferência ficou bem próxima ao limitado
na regra como é possível visualizar na figura 5.13.
Ao fim do teste é possível afirmar que o serviço de FTP pode ser utilizado
com mais qualidade em comparação a outros serviços em execução. Essa mesma
priorização pode ser aplicada para outros tipos de serviços e protocolos, para isso
basta marca-los com o iptables, especificando a porta de origem, de destino e o
protocolo utilizado.
Outra informação que necessita ser frisada é que, os valores utilizados nos
testes de controle de tráfego e qualidade de serviços foram meramente simbólicos,
não foi levado em conta fatores como disponibilidade de recursos da rede e a
necessidade dos usuários. Essas informações devem ser identificadas no ambiente
em que serão aplicadas as técnicas, para assim obter a solução mais adequada.
65
Figura 5.13 - Teste de QoS no serviço de FTP Fonte: Elaborado pelo autor, 2013
66
CONCLUSÃO
Em relação ao objetivo inicial, demonstrar a ferramenta iptables como uma
alternativa para gerenciamento em diferentes aspectos de redes de computadores,
pode-se dizer que o objetivo proposto foi atingido. Embora existam limitações na
execução das tarefas somente com o uso do iptables, essas tarefas podem ser
facilmente superadas com o uso conjunto de outras ferramentas livres também
presentes no Kernel do Linux, como foi demonstrado neste trabalho com a
ferramenta Traffic Control.
Quanto ao sistema de testes implementado, os resultados foram aceitáveis
em relação ao objetivo proposto, e se comparado à ferramentas específicas para as
funções avaliadas, pode-se considerar que os resultados foram positivos.
Nos testes de segurança realizados o iptables, sem auxilio de outra
ferramenta, foi capaz de evitar os ataques de Ping Flood e Varredura de portas. Já
nos testes de controle de tráfego e QoS, foi necessário o uso de outra ferramenta
em conjunto para que a função pudesse ser realizada, nos resultados desses testes
observou-se que os valores de largura de banda definidos foram respeitados, isso
garante o controle desses aspectos ao administrador da rede.
Durante o desenvolvimento dos testes houve dificuldade em encontrar
informações referentes aos módulos avançados do iptables, prevalecendo na
Internet, principal fonte de informação utilizada, somente informações relacionadas
as funções básicas, o que dificultou o conhecimento aprofundado em alguns
recursos disponibilizados pela ferramenta.
Pode perceber que o iptables é uma ferramenta rica em possibilidades, possui
diversos módulos e em suas regras permite diferenciar protocolos, portas, endereço
de origem e destino.
Sugere-se como trabalhos futuros a realização de testes para obtenção de
qualidade de serviço em um ambiente real, utilizando somente o iptables como
ferramenta de marcação para priorização de serviços.
67
REFERÊNCIAS BIBLIOGRÁFICAS
ALECRIM, E. Ataques DoS (Denial of Service) e DDoS (Distributed DoS). 2012. Disponível em: <http://www.infowester.com/ddos.php>. Acesso em: 19 out. 2013. AX3 SOFT. How to Prevent Denial of Service (DoS) Attack. 2013. Disponível em: <http://www.ids-sax2.com/articles/PreventDosAttacks.htm>. Acesso em: 19 out. 2013. BERNARDES. G. Gerência de Redes - A importância do bom Gerenciamento. 2011. Disponível em: <http://gesielbernardes.blogspot.com.br/2011/10/gerencia-de-redes-importancia-do-bom.html> Acesso em: 13 mai. 2013. BROWN, M. A. Traffic Control HOWTO. 2006. Disponível em: <http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/>. Acesso em 30 out. 2013. BOXMAN. J. A Practical Guide to Linux Traffic Control. 2005. Disponível em: <http://edseek.com/~jasonb/articles/traffic_shaping/>. Acesso em: 05 out. 2013. CENTRO DE ESTUDOS, REPOSTA E TRATAMENTO DE INCIDENTES DE SEGURANÇA NO BRASIL. Incidentes Reportados ao CERT -- Abril a Junho de 2013. 2013. Disponível em: <http://www.cert.br/stats/incidentes/2013-apr-jun/tipos-ataque.html>. Acesso em 19 out. 2013. CLIPATEC INFORMÁTICA. O que é Kernel?. 2011. Disponível em: <http://www.clipatecinformatica.com.br/2011/11/o-que-e-kernel.htm>. Acesso em: 06 out. 2013. FILHO, J. E. M. Controle de tráfego com TC, HTB e Iptables. 2007. Disponível em: <http://eriberto.pro.br/wiki/index.php?title=Controle_de_tr%C3%A1fego_com_TC,_HTB_e_Iptables>. Acesso em: 05 out. 2013. ______. Firewall com iptables. 2013. Disponível em: <http://eriberto.pro.br/iptables/3.html>. Acesso em 05 out. 2013. FOROUZAN, B. A. COMUNICAÇÃO DE DADOS E REDES DE COMPUTADORES. Tradução Glayson Eduardo de Figueiredo. 3. ed. Porto Alegre: Bookman, 2008. ICANN. Quase 4.294.967.296 endereços alocados – Resta menos de 10% do espaço de endereços IPv4: a adoção do IPv6 é essencial. 2010. Disponível em: <http://www.icann.org.br/announcements/announcement-29jan10.htm>. Acesso em: 23 set. 2013. IPTABLES. Manual iptables. Disponível em: <http://ipset.netfilter.org/iptables.man.html>. Acesso em: 11 jul. 2013.
68
ITU - International Telecommunication Union. Key statistical highlights: ITU data release June 2012. 2012. Disponível em: <http://www.itu.int/ITU-D/ict/statistics/material/pdf/2011%20Statistical%20highlights_June_2012.pdf>. Acesso em: 18 mar. 2013. LEITE. R. P. C. Parâmetros das Filas-de-Espera. Disponível em: <http://paginas.fe.up.pt/~mrs01003/queues.html>. Acesso em: 27 nov. 2013. KUROSE, J. F.; ROSS, K, W. Redes de computadores e a Internet. 5. ed. São Paulo: Pearson, 2010. MARQUES, E. M. Um byte de cada vez: Seu FTP é ativo ou passivo?. Disponível em: <http://www.pop-rs.rnp.br/~berthold/etcom/redes2-2000/trabalhos/FTP_EltonMarques.htm>. Acesso em: 08 nov. 2013. MORIMOTO, C. E. Linux Redes e Servidores. 2. ed. São Paulo: GDH Press e Sul Editores, 2006. NEGUS, C. Linux Bible 2010 Edition. Indianapolis, Indiana: Wiley Publishing, Inc, 2010. NETO, Urubatan. Dominando Linux Firewall Iptables. Rio de Janeiro: Editora Ciência Moderna LTDA., 2004. NMAP. Nmap network scanning. Disponível em: <http://nmap.org/man/pt_pt/man-examples.html>. Acesso em: 15 out. 2013. PARK, K. I. QoS IN PACKET NETWORK. Estados Unidos: Springer Science + Business Media, Inc, 2005. SMITH, A. Entendendo o Three-way Handshake (Handshake de Três Vias). 2011. Disponível em: <http://www.softwarelivre-ac.org/areas/geral/66-redes/12-entendendo-o-three-way-handshake-handshake-de-tres-vias.html>. Acesso em: 01 nov. 2013. SILVA, G. M. Kernel e Módulos. 2010. Disponível em: <http://www.guiafoca.org/cgs/guia/intermediario/ch-kern.html>. Acesso em: 01 nov. 2013. TANENBAUM, A. S; WETHERALL, D. J. Redes de computadores. Tradução Daniel Vieira. 5. ed. São Paulo: Prentice Hall (Pearson), 2011. TANENBAUM, A. S.; WOODHULL. A. S. Sistemas operacionais projeto e implementação. Tradução Edson Furmankiewicz. 2. ed. Porto Alegre: Bookman, 2002. XIAO, X.; NI, L.M. Internet QoS: A Big Picture. East Lansing: Michigan State University, 1999.
69
ANEXOS
ANEXO A – Script utilizado nos testes práticos
#!/bin/bash
case "$1" in
start)
echo "...INICIANDO SCRIPT..."
#<------------ZERANDO REGRAS----------------->
#LIMPANDO REGRAS
iptables -F
iptables -t nat -F
iptables -t mangle -F
tc qdisc del dev eth1 root
tc qdisc del dev eth2 root
tc qdisc del dev eth3 root
#<------------ZERANDO REGRAS----------------->
#<------------CONFIGURAÇÕES PADRAO----------------->
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT DROP
#PERMITIR COMUNICAÇÃO DE LOOPBACK
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
#<------------CONFIGURAÇÕES PADRAO----------------->
#<------------CONTROLE DE TRÁFEGO----------------->
70
tc qdisc add dev eth1 root handle 1:0 htb default 50
tc qdisc add dev eth2 root handle 2:0 htb default 50
tc qdisc add dev eth3 root handle 3:0 htb default 50
tc class add dev eth1 parent 1:0 classid 1:1 htb rate 1mbit
tc class add dev eth2 parent 2:0 classid 2:1 htb rate 1mbit
tc class add dev eth3 parent 3:0 classid 3:1 htb rate 1mbit
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 100kbit
ceil 100kbit prio 5
tc class add dev eth1 parent 1:1 classid 1:11 htb rate 100kbit
ceil 300kbit prio 5
tc class add dev eth2 parent 2:1 classid 2:10 htb rate 100kbit
ceil 250kbit prio 5
tc class add dev eth2 parent 2:1 classid 2:15 htb rate 100kbit
ceil 500kbit prio 1
tc class add dev eth3 parent 3:1 classid 3:10 htb rate 100kbit
ceil 500kbit prio 5
#<------------CONTROLE DE TRÁFEGO----------------->
iptables -t mangle -A FORWARD -s 192.168.1.2 -j CLASSIFY --
set-class 1:11
iptables -t mangle -A FORWARD -d 192.168.1.2 -j CLASSIFY --
set-class 2:10
iptables -t mangle -A FORWARD -s 192.168.2.2 -j CLASSIFY --
set-class 1:10
iptables -t mangle -A FORWARD -d 192.168.2.2 -j CLASSIFY --
set-class 3:10
#<------------CONTROLE DE TRÁFEGO----------------->
#<------------QOS----------------->
iptables -t mangle -A FORWARD -d 192.168.1.2 -p TCP --sport
1024:65535 -j CLASSIFY --set-class 2:15
iptables -t mangle -A FORWARD -d 192.168.1.2 -p TCP --sport
20:21 -j CLASSIFY --set-class 2:15
#<------------QOS----------------->
71
#<-----------------------PING----------------------->
#LIBERAR PING DO FIREWALL
iptables -A OUTPUT -p icmp --icmp-type echo-request -j ACCEPT
#LIBERA PING VINDO DA REDE INTERNA
iptables -A INPUT -p icmp --icmp-type echo-request -i eth2 -j
ACCEPT
iptables -A INPUT -p icmp --icmp-type echo-request -i eth3 -j
ACCEPT
#ACEITA 1 PING POR SEGUNDO
iptables -A INPUT -i eth1 -p icmp --icmp-type echo-request -m
limit --limit 1/s -j ACCEPT
#CRIA LOG NOTIFICANDO ATAQUE DoS
iptables -A INPUT -p icmp --icmp-type echo-request -i eth1 -m
limit --limit 1/m -j LOG --log-prefix DoS --log-ip-options
#DESCARTA PING DA REDE EXTERNA
iptables -A INPUT -p icmp --icmp-type echo-request -j DROP
#<-----------------------PING----------------------->
#<---------------------PORT SCAN---------------------->
#CRIA UM LOG DE AVISO DE PORTSCAN
iptables -A INPUT -m recent --update --hitcount 5 --name
BLACKLISTSCAN -m limit --seconds 3600 --limit 1/m -j LOG --
log-prefix ALERTA_DE_PORTSCAN --log-ip-options
#DESCARTA TODOS PACOTES POR 1 HORA CUJA ORIGEM ESTÁ NA LISTA
BLACKLISTSCAN
iptables -A INPUT -m recent --update --hitcount 5 --name
BLACKLISTSCAN --seconds 3600 -j DROP
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 --sport 1024:65535 -m
multiport --dports 21,20,22,80,3000 -j ACCEPT
iptables -A OUTPUT -p TCP -s 192.168.0.102 --sport 20:21 -d
0/0 --dport 1024:65535 -j ACCEPT
72
#INSERE ORIGEM NA LISTA BLACKLISTSCAN
iptables -A INPUT -m recent --set --name BLACKLISTSCAN
#<---------------------PORT SCAN---------------------->
#<-------------REGRAS GENERICAS------------->
iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j
ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j
ACCEPT
;;
stop)
echo "...Removendo as regras do Firewall..."
#Remove as regras do iptables
iptables -F
iptables -t nat -F
iptables -t mangle -F
#Muda a politica padrão para ACCEPT
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
#NÃO PERMITE NAT
echo "0" > /proc/sys/net/ipv4/ip_forward
#LIMPAR TC
tc qdisc del dev eth1 root
tc qdisc del dev eth2 root
tc qdisc del dev eth3 root
;;
*)
73
echo "Usage: firewall {start|stop|restart|reload}"
exit 1
esac
exit 0
#!/bin/bash
