Se existirem perguntas ou comentários, por favor, envie-os para A versão mais recente desse documento vai estar sempre disponível

Tamanho: px
Começar a partir da página:

Download "Se existirem perguntas ou comentários, por favor, envie-os para walt@erudition.net. A versão mais recente desse documento vai estar sempre disponível"

Transcrição

1 IPFW FreeBSD

2 Se existirem perguntas ou comentários, por favor, envie-os para A versão mais recente desse documento vai estar sempre disponível em Os direitos de reprodução desse documento são reservados. Versão em português desse documento sob responsabilidade de Patrick Tracanelli e Maurício Goto A versão mais recente do mesmo estará sempre disponível em 1

3 Sumário 1. Informacoes gerais sobre a Filtragem de Pacotes de Rede Acionando o Ipfirewall(4) O /etc/rc.firewall e firewalls com política aberta (OPEN) Carregando Rulesets (conjunto de regras) Tipos de Firewall pré-definidos Tipos de Firewall Personalizado Sintaxe de regras básicas do Ipfw(8) Listando Regras Ativas Comandos básicos e suas funções Especificando Protocolos Especificando endereços de Origem e de Destino Uma introdução à Netmask e Bitmask Especificando Portas e Faixas de Portas Sintaxe de regras avançadas do ipfw(8) A ação "unreach" Controle de Interface e de Fluxo Combinando tipos de pacotes ICMP e TCP específicos icmptypes tcpflags, setup & established ipoptions Reconhecendo Pacotes Fragmentados Filtragem baeada em UID e GID Logs (Logging) Propriedades de Logs Configurações de Logs do sistema Opções do Kernel Configurando o syslog(8) Configuração do newsyslog(8) pra fazer rotacionamento de logs (log rotation) Configuração de log nas regras Introdução à filtragem 'Stateless' e 'Stateful' de pacotes Configurações 'Stateful' Iniciais Configurações 'Stateful' Avançadas Anatomia de uma Regra Dinâmica Traffic Shapping (controle de tráfego) Probabilidade de Ocorrências (Probability Matching) Dummynet Enfileiramento de pipes (Pipe Queues) Máscaras de pipes (Pipe Masks) Remanejamento de pacotes por pipes (Packet Reinjection) Fluxo do Tráfego pelo Firewall 31 Apêndice A: Exemplos de Configurações de Firewall 32 2

4 1. Informacoes gerais sobre a Filtragem de Pacotes de Rede. IPFW(8), a interface de comando do IPFIREWALL(4) é o utilitário mais comum e mais popular pra implementar a filtragem de pacotes IP e controle de tráfego de rede no FreeBSD, e é a ferramenta de FIREWALL nativa com a qual o FreeBSD trabalha por padrão (mesmo considerando que, inicialmente o firewall é desabilitado a nível de kernel). A forma lógica como o IPFW trabalha suas regras é parecida com a adotada em muitos outros filtros de pacotes (Packet Filters), com excessão do IPFilter, que opera com um padrão pra tratar as regras que é menos eficiente e requer bem mais cuidado na hora de ajustar o firewall (se você tem familiaridade com o ipf(8), por exemplo, perceba a utilização da chave 'quick', necessária para que o ipf(8) não traverse a regra inteira, todas as vezes que ela é lida; entre outros fatores particulares de utilização do IPFilter). Mas isso não tira a qualidade e o poder de implementação de firewalls do ipf(8), que tem também suas próprias vantagens. A escolha final em relação a qual ferramenta de Filtragem de Pacotes utilizar, é uma decisão pessoal, a não ser que você tenha necessidade de alguma característica de um Firewall que o outro não possua, contudo, nós vamos abordar uma comparação entre as duas ferramentas posteriormente. Como já dito antes, ipfirewall(4) é um firewall por filtragem de pacotes, o que significa que ele atua monitorando pacote-a-pacote todas as conexões, e a partir da série 4.x do FreeBSD (FreeBSD 4.0), o ipfirewall(4) também pode gerenciar uma filtragem por estado (stateful) de conexões mais rudimentares, de acordo com estados de conexão. Esse comportamento é sempre transparente pros usuários, ou seja, ninguém vai notar que existe um firewall presente, até que um evento aguardado seja bloqueado. Um firewall costuma ser arquitetado de diversas formas, mas todas as maneiras podem ser simplificadas com base em duas políticas de filtragem: aberto e fechado. O Firewall que segue uma política aberta permite que todos os pacotes sejam roteados por padrão, e bloqueia aqueles que pertencem a um tipo de conexão que não é desejado, ou seja, "abre tudo e bloqueia os indesejados". Já o firewall que segue uma política fechada, faz o inverso, bloqueando todo o roteamento de pacotes, e libera um a um o tráfego de conexões permitidas. Essa segunda implementação proporciona um firewall muito mais rígido, contudo sua configuração é bem mais trabalhosa, porque você pode facilmente bloquear o tráfego de algum serviço que esteja sendo utilizado na rede. Alguns protocolos estabelecem conexões dinâmicas, que são bem mais difíceis de se prever, mas você tem como estar atento a esse tipo de situação. 3

5 2. Acionando o Ipfirewall(4); O ipfirewall(4) pode ser iniciado de duas formas: você pode adicionar as opções apropriadas no seu kernel através do seu arquivo de configurações, e compilar um novo kernel pro seu sistema; ou você pode usar o kldload(8) pra carregar dinâmicamente o módulo base do ipfw(8), o ipfw.ko, no kernel. As duas abordagens funcionam bem pra adicionar um firewall(4) com configurações básicas, contudo, a compilação estática proporciona, com pouca diferença, uma melhor performance, mas permite ainda que se adicione opções mais detalhadas de configuração, como por exemplo, a geração e limitação de logs. Pra carregar o ipfw de forma dinâmica, simplesmente use o comando: kldload ipfw Pra acionar o ipfirewall(4) de forma estática, o equivalente seria adicionar a seguinte linha no arquivo de configurações do seu kernel: options IPFIREWALL Em seguida a compilação e instalação acionaria o ipfirewall(4) estático no kernel, logo após a próxima inicialização do sistema. Contudo, as coisas não são tão simples quanto parecem, se você simplesmente seguir os passos descritos acima quando estiver na frente da máquina, vai perceber que existe a necessidade de algumas opções adicionais pra poder usar a estação. Se você prestar atenção nos conceitos de política de firewall citados acima (aberto e fechado), vai entender porque o uso do equipamento vai se complicar muito, se você não perceber que o firewall usa uma política padrão fechada. Se você simplesmente adicionar o ipfirewall(4) sem nenhuma configuração posterior, todo o tráfego de rede vai ser bloqueado, ou seja, nenhum pacote será roteado. Isso fatalmente pode se tornar um tormento se você for adicionar o firewall remotamente. É claro que esse tipo de dor de cabeça pode ser evitada, mesmo considerando que não é recomendado acionar o ipfirewall(4) remotamente, tanto de forma estática quanto dinâmica. Se, de qualquer maneira, você quiser carregar o ipfirewall(4) de um computador remoto, então recomendados que se faça da seguinte forma: kldload ipfw && \ ipfw -q add allow all from any to any Assim você vai automaticamente adicionar uma regra pra permitir todo o tráfego da rede, ao invés de bloquea-lo, evitando assim que você perca a conexão com a máquina remota. De qualquer forma, é recomendável que se carregue o ipfirewall(4) dessa maneira em máquinas locais também, especialmente se elas estiverem conectadas em rede, pra não perder uma conexão em andamento. Acionar o ipfirewall(4) no kernel, de forma estátita em uma máquina remota, contudo, requer um pouco mais de trabalho. O motivo é simples, quando você termina de instalar um novo kernel, você é obrigado a rebootar a sua máquina, ai sim, a partir da próxima inicialização ela irá utilizar o novo kernel. Contudo se você somente adicionar o ipfirewall(4) no kernel, assim que o sistema estiver no ar, ele não vai estar roteando os pacotes, ou seja, você não vai conseguir estabelecer uma conexão remota novamente com a máquina. Então antes de inicializar o sistema com um novo kernel você tem que definir alguma maneira pra máquina aceitar a sua conexão, pra que assim você não seja bloqueado pelo seu próprio firewall. Pra você fazer isso, basta adicionar duas linhas no seu rc.conf, uma que vai acionar o firewall na inicialização da máquina, e outra pra definir o tipo de firewall que vai ser iniciado. No caso firewall do tipo aberto (OPEN). Então basta adicionar as seguintes entradas no seu /etc/rc.conf: firewall_enable="yes" firewall_type="open" Existem ainda outros tipos de firewall previamente definidos no /etc/rc.firewall, mas nós vamos tratar deles posteriormente. Por enquanto vamos começar com uma política de firewall aberta (OPEN). Ainda existe uma alternativa muito boa pra se definir uma política aberta como padrão pro ipfw(8) no kernel. Você pode simplesmente adicionar a seguinte linha no arquivo de configuração do seu kernel: options IPFIREWALL_DEFAULT_TO_ACCEPT 4

6 Nesse caso, as opções que nós adicionamos no rc.conf anteriormente não serão *necessárias*, porque nós não vamos *precisar* do /etc/rc.firewall pra configurar uma política aberta de firewall, porque essa política já vai ser iniciada por padrão no kernel. Contudo, ainda que você escolha definir uma política de firewall padrão no kernel, é interessante adicionar aquelas opções ao /etc/rc.conf porque posteriormente nós vamos usar o /etc/rc.firewall pra carregar nossas próprias regras de configurações de firewall. Adicionar essas opções ao /etc/rc.conf também é válido se você vai carregar o kernel dinâmicamente, porque se eventualmente seu sistema for reinicializado, o módulo ipfw.ko não vai ser carregado de forma automática. As funções de carregamento do firewall pelo /etc/rc.conf permite-nos carregar o módulo ipfw.ko automaticamente. Ainda existem outras opções pro ipfirewall(4) que são possíveis se nós formos acionar o firewall de forma estática no kernel, até o início da série 4.x do FreeBSD algumas dessas opções não podiam ser acionadas se não fosse de forma estática no kernel, mas nas versões mais recentes foram definidas algumas variávies do kernel, mutáveis via sysctl(8), que não restringem mais essas opções ao kernel estático. Além do IPFIREWALL_DEFAULT_TO_ACCEPT nós ainda temos as seguintes opções: options IPFIREWALL_VERBOSE options IPFIREWALL_FORWARD options IPFIREWALL_VERBOSE_LIMIT=# A opção IPFIREWALL_VERBOSE permite logar o tráfego de pacotes com o ipfirewall(4), ecoando informações sobre atividade dos pacotes pro syslogd(4), em cada regra que tiver a opção "log" definida. Vamos abordá-la com mais detalhes posteriormente. A opção IPFIREWALL_FORWARD permite que os pacotes sejam redirecionados para outros hosts, utilizando o comando "fwd" do ipfirewall(4). Redirecionar o pacote (FORWARD) é fazer com que ele siga de um ponto específico (host, rede, porta) para outro. Vamos tratar desse assunto com mais detalhes ao longo do documento. A opção IPFIREWALL_VERBOSE_LIMIT=# define um limite de pacotes que serão logados para uma regra específica. Dessa forma, o syslogd(8) não será sobrecarregado com mensagens relativas à atividades do ipfirewall(4), os comentários do kernel para essa opção diz que isso é uma forma de evitar negação de serviço com os logs gerados para algumas regras de firewall, caso um possível ataque gere muitas ocorrências da mesma regra. O "#" deve ser substituído com o número de vezes que se deseje que as atividades de cada regra seja logada. Dessa forma, se definirmos, por exemplo IPFIREWALL_VERBOSE_LIMIT=100 (padrão), quando existirem 100 ocorrências da mesma regra, as informações sobre a atividade de pacotes daquela regra deixará de ser logada. Se você usa IPv6, as seguintes opções no kernel terão efeito correspondente sobre as ações do firewall quanto a pacotes IPv6: options IPV6FIREWALL options IPV6FIREWALL_VERBOSE options IPV6FIREWALL_VERBOSE_LIMIT=100 options IPV6FIREWALL_DEFAULT_TO_ACCEPT Pra habilitar as mesmas opções do ipfirewall(4) sem recompilar o seu kernel, você vai definir as variáveis correspondentes por meio do sysctl(8), por exemplo: sysctl -w net.inet.ip.fw.verbose=1 sysctl -w net.inet.ip.fw.verbose_limit=100 sysctl -w net.inet.ip.forwarding=1 Ainda existem mais quatro opções relacioadas ao ipfirewall(4) que podem ser definidas no kernel, mas não serão discutidas no momento, porque não são necessárias para a implementação básica de um firewall. Essas opções envolvem situações mais complexas e específicas de roteamento de pacotes, e vamos tratar delas assim que começarmos a tratar essas configurações O /etc/rc.firewall e firewalls com política aberta (OPEN firewalls); Ainda que você defina ou não o tipo de firewall que você vai estar trabalhando, sempre que a opção firewall_enable="yes" é adicionada no rc.conf e o sistema é iniciado, o /etc/rc.firewall é lido e executado também, a partir das configurações definidas no rc.conf, e os seguintes comandos são sempre adicionados ao ipfw(8): 5

7 ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to /8 A variável ${fwcmd} é definida anteriormente no rc.firewall, implicando quando o ipfw(8) vai ser executado de forma silenciosa (opção -q) ou não. A primeira regra em questão, permite todo tráfego proveniente da interface de loopback (a lo0), e a segunda regra bloqueia todo o tráfego direcionado à rede localhost ( ). A primeira regra é necessária pra permitir comunicação inter-processos locais (local IPC), e a segunda regra evita que qualquer pacote externo adentre o endereço de host local (localhost address), que é o endereço de loopback, protegendo assim o tráfego local. Se essas regras não existirem e o firewall tiver uma política padrão fechada, você vai encontrar problemas na inicialização de alguns serviços, especialmente serviços RPC(3), entre outros problemas. Por isso vale ressaltar a impostância de se definir o firewall da forma correta, onde o uso do /etc/rc.firewall via rc.conf é altamente recomendável. Se você fizer a opção por um script shell que carregue todas as suas regras e que seja executado sempre que o sistema iniciar, você deve ficar atento a essas e outras regras que não devem faltar ao seu firewall. Em seguida, quando você define um firewall do tipo "OPEN" (aberto) no rc.conf, o rc.firewall ativa a seguinte regra no firewall: ${fwcmd} add pass all from any to any Essa regra permite que todo tráfego externo seja aceito como entrada (com excessão pro loopback, já que a rede localhost é previamente bloqueada) e todo o tráfego interno seja aceito como saída. A mesma função do IPFIREWALL_DEFAULT_TO_ACCEPT no kernel. Se a política aberta é definida no kernel, a regra número vai ser automaticamente carregada como "allow ip from any to any" no lugar de "deny ip from any to any", posteriormente adicionando a regra número Isso cria uma redundância de política de firewall aberta. Então, é mais indicado definir o tipo de firewall como "UNKNOWN" (desconhecido) se você adicionou a política aberta (IPFIREWALL_DEFAULT_TO_ACCEPT) no kernel, e não quer permitir mais nenhuma regra do rc.firewall. Para isso, inclua as seguintes linhas no seu /etc/rc.conf: firewall_enable="yes" firewall_type="unknown" Se você quer simplesmente habilitar o firewall para trabalhar algumas regras e ver como o ipfirewall(4) do FreeBSD funciona, ou ainda, apenas bloquear alguns hosts específicos, e manter as suas configurações propícias às suas próprias regras, então você pode seguramente pular pra nossa seção 3. Contudo, se sua intenção é usar algum dos conjuntos de regras nativas já existentes no rc.firewall, ou criar seu próprio conjunto de regras, então as opções "OPEN" ou "UNKNOWN" não são suficientes. Então não pule pra seção 3 (lol) Carregando Rulesets (conjunto de regras); Existem duas opções distintas em relação à um comjunto de regras pro seu firewall: a primeira opção é usar uma das definições de firewall já existentes no rc.firewall, e a segunda é criar sua própria definição, com seu próprio conjunto de regras. Os autores do firewwall nativo do FreeBSD, ipfirewall(4), recomendam o segundo caso, por duas rasões simples: - Você pode customizar suas regras de firewall pra satisfazerem da melhor forma as suas necessidades, sem nunca tocar no rc.firewall, que pode ser mantido como uma referência geral sempre que você precisar. - Você vai ser obrigado a se familiarizar com o uso do ipfw(8) e sua sintaxe, se tornando mais experiente na definição de firewall, e ficando mais a vontade com o ipfw(8) Tipos de Firewall pré-definidos; É óbvio que a decisão final é a do administrador da rede, ou do responsável pelo firewall, no caso você que está lendo esse documento. Se você preferir usar os conjuntos de regras de firewall prédefinidos no rc.firewall, então é recomendado que você leia todas elas, pra se tornar familiar e saber exatamente como cada tipo de firewall funciona, antes de ativar qualquer um dos tipos pré-definidos. O controle que gerencia qual definição de firewall carregar é feito pela opção firewall_type="" no rc.conf. Além de "OPEN" existem ainda mais 3 tipos de firewall disponíveis: 6

8 "CLIENT" - Essa definição de tipo de firewall (firewall_type) permite todo o tráfego proveniente da rede local (por exemplo, uma rede interna atrás de NAT) pra ela mesma. Bloqueia pacotes fragmentados, permite que mensagens de , resoluções de nomes (DNS) e NTP sejam enviadas pra dentro e fora da rede, e não permite nenhuma máquina que esteja fora da rede interna iniciar conexões TCP com máquinas dentro da rede. Se a rede estiver por trás de uma implementação básica de NAT sem nenhuma opção de proxie carregada isso já seria impossível. Esse tipo de firewall funciona com política aberta ou fechada, definida no kernel, ou seja, não faz diferença se você colocou IPFIREWALL_DEFAULT_TO_ACCEPT ou IPFIREWALL_DEFAULT_TO_DENY como padrão. "SIMPLE" - Esse tipo de firewall é uma contradição. Apesar do nome SIMPLE, ele é muito mais complexo que a definição CLIENT, e requer que o usuário tenha algum conhecimento nos padrões RFC de Internet pra poder entender suas definições de regras de firewall. Essa regra vai evitar spoofing (técnica onde uma máquina se faz passar por outra, alterando seu endereçamento IP) não permitindo a entrada de nenhum pacote que tenha um endereço de retorno igual ao endereço de qualquer host dentro da rede interna. Vai bloquear todos os pacotes endereçados como de redes privadas, conforme definido na RFC 1928, evitando o tráfego pra dentro ou fora da rede, e vai bloquear ainda todas as redes nãoroteaveis, conforme definido no Internet-Drafts da IETF (disponível em Esse tipo de firewall vai permitir tráfego de , de WWW, de DNS, e NTP, e vai permitir também pacotes fragmentados, e em relação às conexões TCP iniciadas por hosts fora da rede, o firewall não vai apenas bloquear, como na definição CLIENT, vai também logar todas essas tentativas. "CLOSED" - Tecnicamente essa definição não é um conjunto de regras de firewall, porque não adiciona nenhuma regra. Na verdade, aqui acontece tudo que nós insistimos que você deve evitar, ou seja, estabelece uma política fechada, negando todo e qualquer tráfego da rede (exceto o tráfego via lo0 que nós vimos anteriormente que é controlado por padrão). Essa definição simplesmente desabilita todos os serviços IP na rede, a não ser que no seu kernel você tenha adicionado a regra de política aberta. Então, ajustar o firewall pra CLOSED vai ser necessário em casos *extremos* onde você prefere (ainda que temporariamente) tirar toda a sua rede de funcionamento. Ou seja, não defina como padrão no rc.conf Tipos de Firewall Personalizado; Se você decidiu estabelecer um conjunto de regras customizado, então é recomendável que você especifique um arquivo, ao invés de um dos tipos de firewall abordados acima. A maneira de se estabelecer esse tipo personalizado de firewall é a mesma, utilizando a opção firewall_type no rc.conf, contudo, basta indicar o caminho (path) pro seu arquivo de regras: firewall_enable="yes" firewall_type="/etc/rc.firewall.rules" Dessa forma você vai poder definir sua própria configuração de firewall no arquivo /etc/rc.firewall.rules, o qual será carregado sempre que seu firewall for iniciado. Se você preferir ainda que seu firewall seja iniciado de forma silenciosa, basta incluir no rc.conf: firewall_quiet="yes" O formato do seu conjunto de regras será apresentado de forma um pouquinho diferente nesse arquivo, em relação ao que você encontra no rc.firewall. O motivo é simples, o rc.firewall é um 'shell script' sh(1) escrito de forma que possa rodar por si próprio, enquanto o arquivo que define as suas regras personalizadas estão ali simplesmente para serem processadas pelo ipfw(8). A principal diferença é que você não vai usar nada correspondente à variável ${fwcmd} usada no rc.firewall. Simplesmente as regras. Posteriormente, vamos construir um arquivo de regras próprio, e então vamos ver isso passo-a-passo. 7

9 3. Sintaxe de regras básicas do Ipfw(8); A sintaxe das regras de firewall no FreeBSD são simples. Qualquer regra pode ser adicionada pelo console, com o comando ipfw(8). Antes de nos aprofundarmos nas sintaxes das regras do ipfirewall(4), contudo, vamos verificar como podemos listar as regras que estão ativas no momento Listando Regras Ativas; A forma mais simples possível de se listar as regras ativas no firewall: ipfw list Dessa forma, você vai estar listando todas as regras ativas no momento, seguindo a ordem do número da regra. Por exemplo: ipfw list deny log logamount 100 tcp from any to / deny log logamount 100 tcp from any to / allow tcp from any any deny all from any to any Dessa forma, ainda que, a regra número tenha sido adicionada antes da regra 00101, a de número menor será mostra antes, porque a ordem das regras também influi na forma como o ipfirewall(4) vai se comportar. Pra mostrar a data e hora da última vez que um pacote coincidiu com uma regra basta usar a opção timestamp do ipfw(8): ipfw -t list Fri Sep 21 06:31: deny log logamount 100 tcp from any to / Tue Sep 18 00:33: deny log logamount 100 tcp from any to / Sat Sep 22 19:12: allow tcp from any any deny all from any to any date Sat Sep 22 19:12:24 GMT 2001 Ou seja, nesse caso, a última vez que a regra bloqueou um pacote foi na madrugada do dia anterior, a regra bloqueou um pacote também aos 33 minutos de 2 dias atrás, e o último pacote permitido pelo firewall foi há 9 segundos. Detalhe no comando date posterior que ilustra a data corrente. Por último, se nós queremos listar o número de vezes que um pacote passou (ou foi bloqueado) por uma regra, e o número de bytes que esse tráfego gerou, podemos fazer o seguinte: ipfw -a list ou ipfw show Os dois comandos vão apresentar as mesmas informações, dispostas da mesma maneira. A primeira coluna é o número da regra, em ordem como ela é verificada. A segunda coluna informa quantas vezes aquela regra coincidiu com um pacote, seguido do (terceira coluna) número de bytes que trafegaram pela regra, e finalmente a regra em sí. Existem algumas sintaxes curtas pra esses comandos. Por exemplo, "ipfw s" tem o mesmo efeito que "ipfw show"; "ipfw l" o mesmo que "ipfw list", etc Comandos básicos e suas funções; A partir de agora nós vamos, gradualmente, analisarmos cada opção e comandos disponíveis pra se construir um conjunto de regras de firewall. Por enquanto não vamos abordar regras com as opções de stateful, ou seja, estaremos trabalhando com regras stateless. Durante os nossos exemplos, não vamos estar utilizando o programa de controle do firewall (o /sbin/ipfw), que deve preceder cada um dos nossos comandos, caso estejamos configurando as regras de forma manual, pelo console do FreeBSD. O padrão abordado é como deve ser quando estamos trabalhando com um arquivo de regras pra ser passado pro ipfw(8) via firewall_type="/caminho/pro/arquivo.firewall" no rc.conf. 8

10 add 1000 allow all from any to any Esse é o exemplo mais simples de uma regra. Nós já encontramos a mesma regra anteriormente, com uma única diferença, que era o número da regra. Lembre-se que, na seção 2.1 quando nós discutimos sobre tipos de firewall "OPEN" (aberto) nós trabalhamos com o parâmetro "pass", que é como ele foi usado no rc.firewall. Bom, acontece que "pass", "allow" e "permit" são sinônimos pro ipfirewall(4), eles tem o mesmo efeito, contudo as variações permitem que o administrador fique o mais a vontade possível para escrever as suas regras quase que de forma literal. Nessa regra, "all" (todos) os pacotes vindos de "any" (qualquer) lugar para "any" (qualquer) destino são permitidos ("allow"). No ipfirewall(4), grande parte das vezes, sempre que um pacote combinar com uma regra, o ipfirewall(4) pára de examinar as outras regras pra aquele pacote, ou seja, a ordem como as regras são processadas no firewall do FreeBSD são do tipo "first match wins" onde, a primeira constatação do pacote evita que as outras sejam lidas. Por isso é extremamente importante estar atento a ordem (número) das regras. Sob circunstâncias especiais as outras regras podem ser procesadas. Então, de forma geral, a sintaxe mais simples pro ipfw(4) é: <comando> [<número da regra>] <ação> <protocolo> from <origem> to <destino> Os <comandos> mais importantes são "add" e "delete". Uma simples tradução seria o suficiente pra explicar que "add" adiciona uma regra e "delete" a exclui. O <número da regra> varia de 0 até 65535, e indica a ordem que essas regras serão processadas no firewall, portanto a última regra sempre define a política padrão do firewall no kernel. Mesmo se você tiver uma política de firewall aberta (OPEN) definida no seu /etc/rc.conf, a última regra vai sempre indicar a política do kernel. Isso é ótimo porque, como a ordem de busca das regras para de processar ao encontrarem uma regra que combina com o pacote, e se a penúltima regra é a de número 65000, definida pelo rc.firewall pra permitir todo o tráfego da rede, então todo tráfego vai ser liberado, mesmo que a última regra (65535) negue todos os pacotes, já que essa regra nunca vai ser processada. "<ação>" na sintaxe do ipfw(8) pode ser uma das seguintes: "allow" "pass" "permit" "accept" - Quando uma regra define essa ação, sempre que um pacote combinar com essa regra, será permitido seu roteamento pelo firewall, e o processamento das regras *pra esse pacote* termina. "deny" "drop" - Qualquer pacote que combinar com uma regra cuja ação seja "deny" ou "drop" são silenciosamente bloqueados pelo firewall, e o processamento das regras pra esse pacote termina. add 1100 deny all from any to any Essa regra nega todos os pacotes vindos de qualquer origem e indo pra qualquer destino. "reset" - Quando um pacote encontra uma regra com essa ação, o pacote é bloqueado, e o ipfirewall(4) tenta enviar um sinal (flag) de TCP Reset (RST) pro endereço de origem do pacote. O processamento das regras pra esse pacote termina. Como esse tipo de regra apenas se aplica pra pacotes TCP, o protocolo especificado na regra deve ser "tcp", para que apenas tais pacotes sejam processados por essa regra, e não todos (proto "all") os protocolos de pacotes IP. Vale notar que o uso do "reset" pode ser muito interessante pra enganar ferramentas que escaneiam as redes (network scanners), já que normalmente podem detectar um serviço por trás de uma porta filtrada, mesmo que ele esteja por trás de um firewall de bloqueio. Por outro lado, se alguém estiver praticando um ataque do tipo "network flood" em uma porta específica a qual o ipfirewall(4) está configurado para responder com pacotes RST, isso duplicaria o uso da sua banda de rede. Uma solução simples é bloquear, com uma regra prévia o endereço da máquina que está agindo dessa forma, endereço esse obtido de forma dinâmica por monitoramento. add 1200 reset tcp from any to any Essa regra 'precária' (risos) bloquearia todas as conexões TCP vindas de qualquer destino, indo para qualquer origem, e responderia com um pacote RST para cada uma delas. 9

11 "count" - Todos os pacotes que combinarem com uma regra cuja ação seja "count", determinará que o ipfirewall(4) incremente o contagem de pacotes, ou seja, a saída de "ipfw show" indicará mais uma ocorrência de pacotes nessa regra. Motivos estatísticos óbvios. O processamento das regras do firewall continuam a buscar por outras regras que combinem com os pacotes. add 1300 count all from any to any add 1310 count all from /24 to /24 Essa (primeira) regra incrementa o número de vezes que um pacote passou pelo firewall, vindo de qualquer lugar e indo pra onde quer que seja. Já a segunda regra conta quantos pacotes, dentre todos, estariam sendo enviados da rede /24 (origem) pra rede /24 (destino). Uma observação aqui: se o processamento das regras fosse terminado quando um pacote encontra uma regra cuja ação seja "count", então, no exemplo acima a regra 1310 não teria serventia alguma. "skipto <número da regra>" - Todos os pacotes que combinem com uma regra cuja ação seja "skipto <número>" vão fazer com que o ipfirewall(4) continue processando esse pacote e buscando ocorrência nas regras que sejam de ordem maior ou igual ao <número da regra> indicado pela ação. add 1400 skipto 1800 all from /24 to any Essa regra faria com que todo o tráfego vindo da rede /24 e indo pra qualquer destino seja processado pelas regras a partir da regra de número 1800 "reject" - Essa ação é pouco utilizada atualmente. Quando um pacote combina com uma regra cuja ação seja "reject", então o ipfirewall(4) bloqueia esse pacote e responde com uma mensagem ICMP do tipo "host unreachable", dando a impressão que a máquina se encontra fora da rede. Essa é uma forma não silenciosa de negar o tráfego pelo firewall, contudo, assim como a ação "reset", essa ação também aumenta o uso da sua banda de rede Especificando Protocolos; Protocolo (proto) em "protocolo" na sintaxe básica de uso do ipfw(8), é o protocolo de comunicação que você quer que aquela regra combine. Definições de protocolos do tipo "ip" ou "all" são especificações gerais que englobam todos os protocolos. Os protocolos mais comuns são "icmp", "udp" e "tcp", mas a relação de protocolos com os quais o ipfirewall(4) trabalha é enorme. Na verdade são todos os protocolos possíveis de uma rede. Para uma lista completa das possibilidades, fique a vontade: cat /etc/protocols 3.4. Especificando endereços de Origem e de Destino; O endereço de destino e de origem de um pacote tem o mesmo formato em uma regra de firewall. Eles podem ser um nome, definido no /etc/hosts e resolvido por DNS, pode ser um endereço IP, um endereço de rede com máscara de rede (bitmask/netmask) e, ainda podem definir uma ou várias portas, se o protocolo for tcp ou udp. Usar nomes ou endereços IP é indiferente, basta atentar ao fato que a resolução de nomes via DNS pode mudar sem seu conhecimento prévio. add 1000 allow all from minhamaquina to outramaquina add 1100 deny all from to any A primeira regra permite todo o tráfego vindo da "minhamaquina" para a "outramaquina", e a segunda regra nega toda conexão da máquina para qualquer outra estação. Sempre que um pacote coincidir com uma regra do firewall, o processamento pra aquele pacote termina, e o pacote é permitido ou negado, de acordo com a ação definida pela regra. Esse é um exemplo muito simples de um filtro baseado em estações, ou "host-based filtering", que filtra de acordo com o destino ou origem do pacote. Um firewall por filtragem de redes funciona de forma similar, distinguindo-se apenas a notação de redes, onde é necessário definir a máscara de subrede (netmask) ou ainda o bitmask. Vejamos: add 2000 allow all from /16 to any add 2100 deny all from any to :

12 A primeira regra permite todo o tráfego de pacotes vindo da rede cujo conjunto de endereços IP começa em até A regra usa uma máscara (bitmask) pra indicar a abrangência do endereçamento da rede. A máscara em bits também conhecida como bitmask especifica quantos bits do endereço de rede ( ) devem permanecer o mesmo pra cada pacote. Nesse caso, os primeiros 16 bits dos 32 bits do endereço vão continuar os mesmos. Como os primeiros 16 bits são os primeiros dois octetos do endereçamento da rede, então todos os endereços cuja origem seja a indicada nos dois primeiros octetos (ou nos 16 bits iniciais), nesse caso a rede , serão permitidos por essa regra. A segunda regra tem uma função similar, utilizando as máscaras de rede. A máscara de rede (netmask) indica quantos bits do endereço de rede deve ser monitorado pelo regra do firewall. No exemplo acima, a segunda regra (número 2100) tem a máscara de rede O primeiro octeto dessa regra é definido como 'bits altos', ou seja, os primeiros 8 bits são 'bits altos', o que indica pro firewall que apenas os pacotes cujos primeiros 8 bits do endereço da rede devem ser filtrados. Como os primeiros 8 bits da rede é igual a 10, então todos os pacotes cujo endereço de destino seja 10 no primeiro octeto (ou seja, toda a faixa de até ) vão combinar com essa regra, e então serão bloqueados, como indicado na ação da regra (deny). O firewall do FreeBSD oferece ainda a possibilidade de inverter a expressão apresentada na regra com o comando "not". Por exemplo, para que o ipfirewall(4) bloqueie todos os pacotes que não seja da estação : add 1000 deny all from not Uma introdução à Netmask e Bitmask; O princípio básico que envolve máscaras de rede e bits de rede (netmask e bitmask) são simples, mas frequentemente confundidos por pessoas que não tenham muito conhecimento em redes, e ainda requer um pouco de noção de números binários. É muito mais prático se nós trabalharmos com endereço IP em sua forma binária, contudo, a confusão que existe entre os conceitos binários e decimais costuma ser decisiva pra alguém sem muitos conhecimentos em rede. De qualquer forma, para uma referência rápida, a seguinte tabela ilustra que faixa de endereçamento IP corresponde a qual bitmask e respectivo netmask em uma classe C de rede. Alguns breves exemplos de bitmask e netmask adicionais são ilustradas, denotando algumas definições pra redes maiores.... Bitmask Netmask Total de IPs IPs usáveis e e ^3 (256^3) (todos IPs) 256^ 4 (256^4)-2 Como você pode ver existe um padrão definido. O número de endereço total de uma rede sempre sobra a partir da máscara que lhe foi atribuida, e o número total de Ips disponíveis (que podem ser usados por estações) é sempre o total disponível na rede menos 2 (total 2). O motivo também é simples, para cada rede/subrede existem dois endereços IP reservados para o endereço da rede e para o endereço de broadcast da rede. O último octeto da máscara de rede (netmask) começa com 255 e sempre se decrementa em valores múltiplos de 2, enquanto o bitmask se decrementa em múltiplos de 1. Vamos ver, de forma sucinta como usar a tabela acima. Vamos descobrir então qual é a faixa de IPs que compõe uma subrede cujo endereço seja: 11

13 /28 O primeiro detalhe ao qual atentamos é que o endereço da rede é , então sabemos que a subrede inicia nesse valor, ou seja, o endereço de rede é Então percebemos que o bitmask do endereço é 28. Isso quer dizer que todos os primeiros 28 bits do endereço são 'bits altos', ou seja, são endereços que não mudam. Portanto, concluímos de forma lógica que temos apenas 4 bits ajustados como 'bits baixos', já que um endereço completo de rede tem 32 bits, e 28 são altos (conforme indicado pela bitmask) subtraindo 28 de 32 restam-nos 4 bits (os bits baixos). Sabemos agora que existem apenas 2 valores possíveis para cada bit, já que o endereçamento não decimal é binário. Então elevamos dois (possibilidades binárias) à quatro (bits): 2^4. Agora sim já temos o número de estações que aquele bitmask está indicando: 2^4 = 16. Agora basta somar: = , portanto a faixa de endereçamento IP varia de até ; Se olharmos na tabela apresentada cima, veríamos que 16 endereços IP corresponde a um bitmask de 28, que é o nosso caso. Dessa forma poderíamos ter evitado todo esse cálculo matemático para encontrarmos o valor exato. Mas, vale lembrar que, nem sempre essa tabela vai estar disponível pra você consultar, a menos que você a imprima e ande com ela na carteira, portanto é muito mais valioso aprender como o endereçamento funciona e aplicar os cálculos necessários. Aprenda uma vez e use sempre Especificando Portas e Faixas de Portas; Você pode também controlar o tráfego de conexões baseando-se em filtragem de portas. Isso possibilita que você permita ou negue acesso a um serviço em específico ao invés de controlar o tráfego das estações todas. A definição das portas em uma regra de firewall com ipfw(8) é feita após a declaração do endereço de origem ou do endereço de destino, simplesmente definindo a porta após o endereço. Uma faixa de portas pode ser especificada com um hífen, podem ser separadas por vírgula, ou ainda, em casos mais elaborados, pode-se usar um netmask pra definir a faixa de portas. É importante lembrar que você não pode definir "all" como protocolo na regra que especifica portas, porque nem todos os protocolos trabalham com portas. add 1000 allow tcp from any to add 1100 allow tcp from any to add 1200 allow tcp from any to ,22,23 add 1300 deny udp from any to :8 Na primeira regra, todos os pacotes TCP cujo destino é a porta 25 da estação são permitidos pelo firewall. Na segunda regra todas as conexões TCP cujo destino seja qualquer porta da faixa 1021 até 1023 da estação também são permitidas pelo ipfirewall(4). Na terceira regra, todos os pacotes TCP destinados às portas 21, 22 ou 23 na estação é permitida. E, finalmente na quarta regra, todos os pacotes UDP destinados pra faixa de portas de 1024 à 1028 na estação são bloqueados. A apresentação da faixa de portas na última regra é interessante, porque faz uso de uma netmask pra declarar a mesma. Mas a matemática também é bem simples. Como agora estamos tratando de Bitmask pra porta 1024, o valor pra ela é 10 bits, e como a máscara indica 8 bits, tiramos 8 possibilidades de 10, restando-nos apenas 2 bits. Como o valor de cada bit é binário, elevamos os bits disponíveis (2) aos valores possíveis (binário = 2): 2^2, então temos 4 portas que compõe a faixa de endereçamento da porta 1024, ou seja, de 1024 até = 1024 até1028. O uso de máscaras para definição de faixas de portas são raramente usadas, mas são bem mais interessantes do que o uso de bitmask ou netmask pra endereços IP, já que o número de bits de uma porta varia dependendo da porta em questão. Por isso o uso de hífen é recomendado pra se definir uma faixa de portas, e vírgulas quando se deseja definir várias portas em uma mesma regra. Mas a declaração de máscaras para as portas indica que o firewall foi construído por alguém que domina completamente as definições de endereçamento de redes, e é estétitamente mais proveitoso. 12

14 4. Sintaxe de regras avançadas do ipfw(8); Embora o overview anterior sobre as criações de regras do ipfw(8) seja o bastante pra cobrir a maioria dos cenários e necessidades simples de um firewall, ele se mostra solenimente curto pra muitas situações mais complexas, como por exemplo, quando o sistema possui mais de uma interface de rede é possível que se queira definir ações especiais para algumas combinações de pacotes, ou então que se queira um maior controle sobre o direcionamento do tráfego. Então, vamos expandir o modelo de sintaxe que estávamos trabalhando no ipfw(8) para o seguinte: <comando> [<número da regra>] <ação> [log [logamount <número>]] <proto> from <origem> to <destino> [<interface-spec>] [<opções>] Todas as opções entre colchetes fazem menção à novas funcionalidades que iremos discutir nessa seção. Nós vamos inclusive cobrir uma nova "ação" que não foi relatada anteriormente. A Sintaxe pode parecer inicialmente confusa, mas nós vamos com calma, e montaremos as regras aos poucos A ação "unreach"; Primeiramente, vamos introduzir uma nova "ação": "unreach <código>" - Qualquer pacote que combine com uma regra cuja ação seja "unreach", serã respondido com um código 'ICMP unreach' (código ICMP de indisponibilidade), e posteriormente a leitra do conjunto de regras será terminada. As possibilidades de códigos pro 'ICMP unreach' pode ser indicada por número ou por nome. Segue agora uma breve lista de 'ICMP unreach codes' (os códigos em questão) e seus nomes correspondentes. Se você não sabe onde esses códigos são utilizados, não tem porque você tentar usa-los: net 0 net-prohib 9 host 1 host-prohib 10 protocol 2 tosnet 11 port 3 toshost 12 needfrag 4 filter-prohib 13 srcfail 5 host-precedence 14 net-unknown 6 precedence-cutoff 15 host-unknown 7 isolated Controle de Interface e Fluxo; Uma das mais importantes funcionalidades do ipfw(8), que não foi comentada anteriormente na seção 3 desse documento é o controle de fluxo e de interface, ou seja, a possibilidade de criar regras que verifiquem os pacotes de acordo com uma interface em especial (aplicável quando você tem um sistema com múltiplas interfaces de rede). Essas regras podem identificar de onde esses pacotes estão vindo, e em que direção estão indo. Até agora o senso de direção que nós adotamos simplesmente definia os endereços de origem e de destino, mas usar apenas essas opções pra definir de onde um pacote está vindo ou pra onde ele está indo via firewall não é muito confiável. Quando você quer filtrar pacotes que estão apenas entrando ou saindo pela rede, as opções "in" e "out" podem ser utilizadas com precisão. Ambas opções ("in" e "out") correspondem ao campo "interface-spec" no modelo de sintaxe dado anteriormente, e normalmente, são definidas próximas ao final de cada regra, antecedendo qualquer possível opção extra. Dessa forma, quando decidirmos filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar, poderíamos definir: add 1000 allow all from any to any in Pra filtrar pacotes indo através de uma interface em particular, podemos usar a opção literal "via", seguida do nome da interface. Dessa forma, se estivermos usando uma placa de rede 3Com 3c59x PCI, sua interface será "xl0". Pra filtrarmos qualquer pacote, vindos especialmente dessa interface, com origem e destinos quaisquer, o seguinte seria o suficiente: add 1100 allow all from any to any in via xl0 Ou talvez, se você tiver um sistemas com múltiplas interfaces, e quiser filtrar todos os pacotes vindos de qualquer lugar e indo pra qualquer lugar, mas que esteja ao menos saindo via *alguma* interface, pode fazer o seguinte: 13

15 add 1200 allow all from any to any out via any Você vai notar que, quando você listar as regras de firewall, as entradas que estiverem usando "in" ou "out" combinadas com "via", não apresentarão a utilização do "via" mas apresentará a citação "recv" ou "xmit", dependendo da definição de um "in" ou um "out" respectivamente. Veja só: ipfw add 7000 allow all from any to any out via xl0 ipfw list grep allow ip from any to any out xmit xl0 Portanto, você pode usar "recv" ou "xmit" no lugar de "via" quando você for criar alguma regra que faça uso de "in" e "out", contudo isso não é preciso, o ipfirewall(4) distingui se a interface está recebendo o transmitindo o dado, e, além do que, essa definição pode confundir usuários não experientes. No geral, essas opções oferecem muito mais controle sobre o tráfego da rede em um sistema de interfaces múltiplas, e qualquer outro sistema em geral, visto que elas permitem a filtragem de pacotes específicos vindo para o firewall, saindo por ele, e se deslocando através de uma interface especificada Combinando tipos de pacotes ICMP e TCP específicos; Pacotes ICMP, TCP e IP são apresentados em vários formatos distintos. Esses tipos de pacotes são definidos por várias _flags_ (opções de identificação). Nós podemos filtrar cada um desses tipos usando uma das seguintes opções do ipfw(8), ao final de cada regra: icmptypes (tipos icmp); "icmptypes <tipo>" - Essa opção filtra o pacote ICMP do <tipo> definido, e inverte a opção se uma '!' (exclamação) for devinida antes do <tipo>, ou seja, todos os pacotes que não forem desse tipo serão combinados. Existe, atualmente 15 tipos diferentes de pacotes ICMP que podem ser filtrados; cada um é definido por um número. Você pode ainda especificar faixas de 'icmptypes' utilizando hífen ou separando-os por vírgula. Os 15 tipos de pacotes ICMP são: 0 - Echo Reply (Resposta de Echo) 3 - Destination Unreachable (Destino Indisponível) 4 - Source Quench (Origem extinta) 5 - Redirect (Redireção) 8 - Echo Request (Pedido de Echo) 9 - Router Advertisement (SPAM de roteamento? :-)) 10 - Router Solicitation (Pedido de Roteamento) 11 - Time-to-Live Exceeded (TTL Excedido) 12 - IP header bad (Cabeçalho IP malformado) 13 - Timestamp Request (Pedido de Timestamp) 14 - Timestamp Reply (Resposta de Timestamp) 15 - Information Request (Pedido de Informação) 16 - Information Reply (Resposta de Informação) 17 - Address Mask Request (Pedido de Máscara de Rede) 18 - Address Mask Reply (Resposta de Máscara de Rede) Se você ficou curioso pra saber como esses tipos ICMP, especialmente o tipo 3, correspondem aos códigos de indisponibilidade que podem ser criados com a opção "unreach", então, saiba simplesmente que o tipo 3 identifica qualquer um desses códigos, ou seja, todos. Usar filtros de pacotes ICMP é muito útil, especialmente pra controlar ping; por exemplo, você pode permitir que qualquer cliente dentro da sua rede interna pingue qualquer estação pra fora da rede, enquanto você bloqueia que qualquer estação externa pingue o seu gateway, ou qualquer outro cliente interno. As três regras a seguir definem isso facilmente: add 1000 allow icmp from any to any out icmptypes 8 add 1100 allow icmp from any to any in icmptypes 0 add 1200 deny icmp from any to any in icmptypes 8 A primeira regra permite que todos os pacotes icmp do tipo 8 (pedido de echo) possam trafegar pra fora do firewall. A segunda permite que todos os pacotes icmp do tipo 0 (resposta de echo) entrem 14

16 pelo firewall, e a regra seguinte bloqueia todos os pacotes icmp do tipo 8 de entrarem. Em resumo, permite que qualquer cliente faça um pedido de echo pra fora, e permite a entrada da resposta pra dentro do firewall, e não permite que ninguém de fora faça um pedido de echo pra dentro do firewall, ou seja, todomundo protegido pelo firewall pode pingar qualquer estação externa, mas ninguém de fora pode pingar dentro. Naturalmente essas opções só podem ser definidas quando o protocolo da regra for "icmp" tcpflags, setup & established; "tcpflags <flag>" - Essa opção filtra qualquer pacote TCP cujo cabeçalho contenha alguma das flags (opções) identificadas. Uma definição inversa também pode ser utilizada se colocarmos uma '!' (exclamação) antes da <flag>, dessa forma filtrando todos os pacotes TCP que não possuam a <flag> em questão. Veja as opções de 'flags': fin - Request for connexion termination (pedido de finalização da conexão) syn - Request for connexion initiation (pedido de inicialização da conexão) rst - Reset Connexion (Redefinição da Conexão) psh - Push Flag (opção Push) ack - Acknowledgement (conhecimento, concordância com a conexão) urg - Indicate Urgent OOB data (indica um OOB de dados urgentes) A <flag> SYN é a mais interessante, visto que ela é enviada quando uma conexão TCP é iniciada. Por ser tão importante, existe inclusive uma opção separada do ipfw(8) dedicada especialmente pra definir pacotes TCP cujo cabeçalho tenha a flag SYN ajustada. Essa opção se chama "setup". É claro que só podemos trabalhar com a opção "setup" quando o protocolo indicado é o "tcp". "setup" - Qualquer regra contendo essa opção vai filtrar todos os pacotes TCP cujo cabeçalho indique a flag SYN ajustada. Dessa forma, se quizermos simplesmente negar todos os pacotes TCP que estiverem entrando no firewall com o cabeçalho SYN definido, temos duas opções: add deny tcp from any to any in tcpflags syn OU SIMPLESMENTE: add deny tcp from any to any in setup Em cada uma dessas regras, a mesma ação é tomada: todos os pacotes TCP SYN vindos de qualquer (any) origem para qualquer (any) destino serão negados. Vale a pena ilustrarmos a necessidade do protocolo ser "tcp" quando trabalharmos essas regras. "established" - Exatamente como existe uma opção especial que identifica um pedido de inicialização de conexão TCP ("setup"), existe também uma opção que identifica quando uma conexão já está estabelecida, ou seja, ja foi iniciada. Pela grande importância de facilitar o controle de conexões TCP, as opções "established" e "setup" foram disponibilizadas, dessa forma oferecendo facilidade na criação de regras. Utilizando estas opções (ou mesmo suas definições nativas correspondentes às "tcpflags") podemos ter inicialmente um controle de conexões TCP mais simples. Essa é a base de implementações "stateful" de um firewall. Vamos trabalhar com elas de forma mais detalhada depois ipoptions; "ipoptions <flag>" - Finalmente podemos trabalhar com alguns pacotes IP específicos. A <flag> que define um tipo de pacote IP é nomeada SSRR (para: Strict Source Route), LSRR (para: Loose Source Route), RR (para: Record Packet Route), e TS (para: Timestamp). Se você não sabe pra que serve cada uma dessas flags, então não haverá necessidade de construir regras que façam uso delas Reconhecendo Pacotes Fragmentados; Pacotes fragmentados podem ser filtrados com a opção "frag" do ipfw(8). Na grande maioria dos casos, os pacotes fragmentados devem ser bloqueados pelo firewall. Receber um número grande de pacotes fragmentados pode indicar a eminência de um ataque do tipo DoS (Denial of Service - ou Negação de Serviço). Mesmo considerando que o FreeBSD, e a maioria dos outros sistemas UNIX de verdade não são sucetíveis a esse tipo de ataque, os sistemas Windows são frequentemente muito vulneráveis. Dessa forma, se você tem clientes Windows por trás do firewall, dentro da sua rede, é recomendável bloquear pacotes fragmentados pra protege-los. Quando você for usar a opção "frag" pra filtrar (e bloquear) os pacotes fragmentados, tem duas regrinhas básicas que você deve seguir. A primeira é que você não pode usar "frag" quando também estiver usando a opção "tcpflags"; você define qualquer pacote fragmentado, ou não define nenhum. A segunda: você também não pode utilizar o "frag" se estiver especificando portas TCP ou UDP; você bloqueia todos os pacotes fragmentados, não importando pra qual porta ou serviço eles estejam sendo 15

17 enviados. Dito isso, podemos facilmente definir uma regra pra negar todos os pacotes fragmentados que estiverem entrando na rede: add deny all from any to any in frag 4.5. Filtragem baeada em UID e GID; Uma poderosa função que outros firewall (como o IPFilter) não possuem é a filtragem de pacotes baseada em GID/UID. O Ipfirewall(4) tem a capacidade de filtrar pacotes de acordo com o UID ou GID do dono do processo o qual originou uma conexão. Por motivos lógicos só se pode filtrar pacotes que tenham sido gerados por processos locais. As opções a serem utilizadas são "gid" ou "uid" seguidos do GID/UID ou do nome do usuário/grupo que estivermos filtrando. Um uso em potencial dessa função é restringir o número de IPs virtuais em um servidor de shell. Se você quer se assegurar que um ou mais Hosts Virtuais não poderão ser usados por ninguém mais que o dono do IP virtual, você pode definir uma regra baseada em filtragem de UID, para que, dessa forma, todo o tráfego do host virtual que não seja do próprio usuário seja bloqueado: add allow tcp from any to in add allow tcp from to any out uid patrick add deny tcp from to any Essas regras permitem que apenas o usuário 'patrick' vai poder utilizar a alias de IP (Apelido de IP, IP-Alias ou IP vhost) pra estabelecer conexões TCP pra fora da rede. Ninguém mais será permitido pendurar Bots, Clientes de IRC ou qualquer outra coisa que precise estabelecer conexão TCP (quase tudo) nesse endereço IP. O protocolo UDP também pode ser usado para filtragem de pacotes baseada em UID/GID, contudo nenhum outro protocolo fora esses dois podem. Outra utilização possível pra UID/GID seria habilitar limitação de uso de banda para cada usuário, ao invés de limitar pra cada estação ou rede. Por exemplo, você pode definir um grupo de usuários que tenham contas rápidas de FTP, definindo uma regra pro GID em questão, e em contrapartida ter um grupo de usuários de shell que não precisam de muita banda. Vamos ilustrar outras limitações de bandas definidas por GID posteriormente, quando estivermos cobrindo o "traffic shaping" com ipfirewall(4). Por motivos de segurança, talvez seja necessário voce logar o tráfego de rede de um usuário em particular, e nesse caso o filtro baseado em UID/GID também viria bem a acalhar. Na verdade sempre que se queira definir um comportamente distinto do firewall com base no usuário que acessa o serviço, o UID/GID do ipfw(8) sempre vem bem a acalhar. Uma pequena dica é sempre definir as regras baseadas em UID/GID antes das outras regras, visto que o ipfirewall(4) termina a verificação da lista das regras quando um pacote combina com alguma das regras em uso. Isso garante desempenho e evita que se bloqueie ou permita um pacote antes de verificar qual usuário originou o tráfego. 16

18 5. Logs (Logging); 5.1. Propriedades de Logs; As vantagens de manter os logs do firewall ativo são óbvias. A possibilidade de verificar posteriormente quais conexões foram negadas, de que endereços elas vieram, pra que rede ou estação elas estavam indo, se o conteúdo dos pacotes eram fragmentados (indicantivo de muitos ataques de negação de serviço DoS), enfim, possibilita saber onde as conexões estão sendo feitas, por quem e quando. Em especial, os logs de firewall são importantes pra rastrear crackers ou pessoas má intencionadas. Mas logar também tem o seu lado negativo, se você não for cuidadoso. Dependendo do tipo de dado que você está logando você pode se perder com a abundância de mensagens, e também utilizar muito espaço em disco pros arquivos de logs. Ataques de negação de serviço que tendem a sobrecarregar discos rígidos é um dos tipos mais antigos de atividade má intencionada, e por incrível que pareça ainda é sinônimo de perigo pra administradores imprudentes. Por isso a importância de se definir que tipos de regras serão logadas. Normalmente logar pacotes permitidos de serviços públicos (como WWW) não é uma boa indéia, visto que o próprio serviço (servidor WWW) também mantém logs das atividades de acesso, e a frequência de pacotes em um serviço como esse é muito grande. Por outro lado, o que a maioria dos novos administradores que experimentam quando eles habilitam o ipfirewall(4) pra logar, é o seu terminal abarrotado com mensagens sobre a atividade de pacotes. Esse pequeno inconveniente é o resultado da combinação de: - estar logando regras que combinam com pacotes muito frequentes; - não ter desabilitado logs pro console e pros terminais de root (péssima idéia); - não estar controlando limite de logs com o IPFIREWALL_VERBOSE_LIMIT; 5.2. Configurações de Logs do sistema; Opções do Kernel; Pra habilitar os logs do ipfirewalll(4) no FreeBSD, você tem que incluir ao menos as seguintes opções no kernel (não se esqueça de iniciar seu sistema com o novo kernel após a compilação do mesmo): options IPFIREWALL_VERBOSE Você ainda pode habilitar a seguinte opção: options IPFIREWALL_VERBOSE_LIMIT=# Nós já mencionamos essas opções anteriormente, quando estavamos revendo a ativação do firewall. Essa segunda opção do kernel limita o número de mensagens consecutivas enviados ao sistema de logs do FreeBSD, o syslogd(8), quando dada regra do firewall é ativada. Portanto, quando você aciona essa opção no kernel, o número de mensagens consecutivas relacionada a uma conexão em particular é limitada ao valor (número) específico. Considere o seguinte: options IPFIREWALL_VERBOSE_LIMIT=10 Com essa entrada definida no seu kernel, apenas 10 mensagens consecutivas a respeito de determinada conexão serão logadas no syslogd(8), e todas as outras ocorrências seriam identificadas sob uma expressão genérica como por exemplo: Jan 29 03:26:55 meuservidor last message repeated 45 times Normalmente essas mensagens são logadas em /var/log/messages além de serem impressas no console do sistema também. Se você quiser modificar esse comportando do syslogd(8), você terá que editar o /etc/syslog.conf. O syslog.conf(5) oferece uma flexibilidade considerável em relação à configuração sobre as formas com que o syslogd(8) vai tratar as mensagens do sistema. O limite definido pra IPFIREWALL_VERBOSE_LIMIT fica à critério do administrador, mas valores acima de 10 já proporciona um tráfego alto de mensagens em servidores muito requisitados. Mas se você quer definir um arquivo separado pra logar tudo de forma distinta, ao invés de simplesmente logar no arquivo padrão (/var/log/messages), isso pode ser feito também, e ainda, se você julgar ter espaço em disco o bastante pra trabalhar com rotacionamento de logs (Log Rotation) você não precisa definir a opção de limite de verbosidade no Kernel. 17

19 Configurando o syslog(8). Você pode configurar o syslogd(8) pra logar as atividades do ipfirewall(4) em um arquivo separado, seguindo três passos relativamente simples: 1) Crie o seu novo arquivo de log para o ipfw(8) e, como alternativa, crie também o diretório de logs que você achar conveniente. Vamos assumir então que você quer que todos os logs relativos ao ipfirewall(4) sejam armazenados em /var/log/ipfw/ipfw.log. Dessa forma você vai ter que criar o diretório em questão (/var/log/ipfw) e em seguida o arquivo de log (ipfw.log) sob tal diretório, pra isso vai utilizar o comando touch(1): mkdir /var/log/ipfw && touch /var/log/ipfw/ipfw.log Tenha certeza que o diretório e arquivo em questão não tenham permissões de leitura pra outros usuários senão o dono do arquivo, por questões óbvias de segurança. 2) Configure o syslog.conf(5) pra enviar todas as mensagens relativas ao ipfirewall(4) pro arquivo /var/log/ipfw/ipfw.log. A forma mais fácil de fazer isso é adicionar as seguintes linhas no final do syslog.conf(5):!ipfw *.* /var/log/ipfw/ipfw.log Atente pra usar <TAB> (tecla tab) nesse arquivo ao invés de espaços simplesmente. Mesmo assumindo que usar "tabs" não é obrigatório no FreeBSD pro arquivo /etc/syslog.conf, é de bom costume fazê-lo, caso você trabalhe também com outros UNIX, cuja maioria não aceita espaços no syslog.conf(5). Portanto mesmo você podendo ignorar a mensagem de advertência no início do /etc/syslog.conf, é sempre bom manter o bom hábito seguro de usar o syslog.conf(5) da forma indicada por ele. Você vai reparar que as mensagnes do tipo "last messages repeated # times" (ou seja: últimas mensagens repetidas # vezes) serão também logadas, além desse arquivo, pra qualquer outro cujo syslog.conf(5) aponte as seguintes entras: *.err, kern.debug, *.notice E ainda, o console também irá receber todas essas mensagens, como definido na linha: *.err;kern.debug;auth.notice;mail.crit /dev/console Lembre-se que o console na verdade é apenas o ttyv0 (ALT+F1). Os consoles virtuais e pseudo terminais se comportarão de forma distinta em relação à mensagens. Por padrão as seguintes linhas definirão quando as mensagens forem enviadas pra outros terminais: *.err root *.notice;news.err root *.alert root *.emerg * As linhas *.err e *.notice irão logar mensagens do kernel e também as exibirão no terminal onde o usuário especificado estiver logado. Note que o usuário em questão é o 'root', então, como por padrão você não deve logar como root a toa, o usuário root será sempre alertado. Não se recomenda de forma alguma que essas linhas sejam comentadas, informações de log para o root e pro terminal são extremamente importantes pra se manter atento a qualquer coisa errada que estiver acontecendo com o servidor. Se por bom senso você costuma estar muito logado com outro usuário que não seja o root, também é considerável configurar o syslogd(8) pra alertar o seu usuário. Então vamos resumir o que deve ser feito quando você for configurar seus logs pelo arquivo de configuração syslog.conf(5): Insira a linha com "!ipfw" e indique o caminho pra onde as informações referentes às atividades do Firewall devem ser logadas. Não altere as mensagens que serão enviadas ao usuário Root se ele estiver logado. Indique os mesmos alertas pra um usuário que você usa com mais frequência. 3) Envie um sinal de reinicialização pro processo do syslogd(8). A forma mais fácil é usando o comando: killall -HUP syslogd Configuração do newsyslog(8) pra fazer Rotação (ou Rotacionamento) de Logs (log rotation); Agora que o ipfirewall(4) está configurado pra logar todas suas atividades, você deveria pensar seriamente em configurar o newsyslog.conf(5) de forma a garantir que o newsyslog(8) vá rotacionar os logs do ipfirewall(4), ou, como alternativa, optar por algum outro mecanismo de rotacionamento de logs. 18

20 Pra se ter uma boa noção de todas as configurações possíveis do newsyslog.conf(5) é recomendado que você leia a página de manual (man newsyslog.conf) do arquivo. Essa é uma poderosa ferramenta de logs, mas não tem porque nós explicarmos ela aqui, isso é tarefa pra um capítumo sobre administração do sistema FreeBSD, pro nosso caso de Firewall específico a seguinte entrada deve ser o bastante: /var/log/ipfw/ipfw.log * $W0D2 Z Essa linha pode ser adicionada no final do arquivo newsyslog.conf(5). A primeira entrada é um tanto quanto óbvia, ela indica qual arquivo vai ser rotacionado. A segunda indica os bits de permissões pros arquivos rotacionados. A terceira parte é o número de arquivo de logs que se deseja manter rotacionando até que o mais antigo seja apagado. O seguinte é o tamanho do arquivo quando ele deve ser rotacionado, não estamos usando essa opção. A quintar parte é quando (tempo) nós devemos rotacionar o arquivo, e finalmente a última opção, é uma opção especial. Como você já deve ter concluído, rotação de logs são definidas por dois critérios: tamanho ou data. No nosso caso, nós indicamos que queremos que o arquivo de log seja rotacionado às duas da manhã de todo domingo, não importando o tamanho do arquivo de log. Depois definimos (a última opção especial, "Z") que o arquivo deve ser comprimido com gzip(1) sempre que rotacionar, e definimos que vamos manter um histórico arquivado de 10 semanas. Se você deseja manter seus logs por mais que 10 semanas basta alterar o valor 10 pra qualquer um que você queira. Ou o ideal, criar uma rotina que faça backup em uma máquina separada (um LogHost) a cada 10 semanas, ou então gravar seus Logs em CD ou qualquer outra mídia barata e de grande capacidade quando for necessário. Uma vez configurado, o newsyslog.conf(5) vai cuidar do rotacionamento dos logs do ipfirewall(4). O newsyslog.conf(5) é ativado pelo cron(8) do FreeBSD, e por isso não precisa de um Daemon rodando, consequentemente você não tem que reiniciar nenhum processo. Você pode criar seu próprio script pra rotacionar logs ou usar de terceiros, com tanto que você confie. De qualquer forma é bom decidir uma maneira de controlar o crescimento dos logs dentro do seu sistema. Lembre-se, não existe nada que o cron(8) e um script não possa fazer nesse caso Configuração de Log nas Regras; Uma vez que tudo esteja pronto pra utilizar as funções de logs do ipfirewall(4), vamos começar a definir quais regras nós queremos logar quando elas forem filtradas. Existem dois parâmetros básicos pra usarmos em conjunto com nossas regras pra definirmos que queremos logar *aquela* regra. Vejamos: "log" É o parâmetro mais comum. Toda vez que uma regra que for definida o "log" for acionada, então a ação definida ("action") por aquela regra será logada todas as vezes que um pacote coincidir a regra. Por isso tome muito cuidado pra não defnir "log" pra uma regra que a terão pacotes frequentementes assimilados a ela, como por exemplo: add 0500 allow log all from any to any Essa é uma regra que permite todo o tráfego de todos os tipos de pacotes de todas as redes pra todas as redes, então imagine a frequência de informações que serão logadas sempre que cada pacote for permitido pelo seu firewall. Esse tipo de regra pode facilmente proporcionar problemas pro seu disco local ;-) Por outro lado, definir "log" pra uma regra geral de negação é uma pedida considerável: add deny log all from any to any Essa regra é mais considerável, porque é uma das últimas, em uma política clara de firewall do tipo "CLOSED" ou seja, tudo que deve ser permitido já o foi nas regras anteriores que suponhamos existir, portanto nos interessa manter logs das conexões negadas. Além do que o número da regra é 6500, o que, em relação à regra anterior (500) é muito mais seletiva, visto que é uma das últimas regras a serem checadas. Preste muita atenção pra escolher quais regras você quer logar e quais você não quer. "logamount <número>" - Esse parâmetro em seguida ao "log" define o número máximo de vezes que uma regra vai ser logada. Esse parâmetro é análogo à entrada de limite de verbosidade no kernel, e da muito mais controle ao administrador que pode, por exemplo, definir um número baixo pra uma determinada regra, e zerar a mesma uma vez ao dia, dessa forma só deixando de logar o período que um possível ataque ocorrer. Essa definição é possível no FreeBSD 4.x, FreeBSD 2.2.x e FreeBSD série 3 acina de 3.4.x. Nas versões anteriores à 3.4 no FreeBSD 3.x o padrão do "logamount" era 10. Sempre que uma regra é logada, as informações geradas pra tal pacote são: - Data & Hora 19

IPFW HOWTO. http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt

IPFW HOWTO. http://free.bsd.com.br/~eksffa/freebsd/ipfw.txt Atenção: este documento apesar de datado, é ainda considerado prático, e a melhor introdução ao IPFIREWALL(4) disponível publicamente na Internet. Todas as informações aqui disponíveis continuam válidas

Leia mais

Iptables. Adailton Saraiva Sérgio Nery Simões

Iptables. Adailton Saraiva Sérgio Nery Simões Iptables Adailton Saraiva Sérgio Nery Simões Sumário Histórico Definições Tabelas Chains Opções do Iptables Tabela NAT Outros Módulos Histórico Histórico Ipfwadm Ferramenta padrão para o Kernel anterior

Leia mais

Máscaras de sub-rede. Fórmula

Máscaras de sub-rede. Fórmula Máscaras de sub-rede As identificações de rede e de host em um endereço IP são diferenciadas pelo uso de uma máscara de sub-rede. Cada máscara de sub-rede é um número de 32 bits que usa grupos de bits

Leia mais

Orientador de Curso: Rodrigo Caetano Filgueira

Orientador de Curso: Rodrigo Caetano Filgueira Orientador de Curso: Rodrigo Caetano Filgueira Definição O Firewal é um programa que tem como objetivo proteger a máquina contra acessos indesejados, tráfego indesejado, proteger serviços que estejam rodando

Leia mais

ADMINISTRAÇÃO DE REDES I LINUX. Firewall. Frederico Madeira LPIC 1, CCNA fred@madeira.eng.br www.madeira.eng.br

ADMINISTRAÇÃO DE REDES I LINUX. Firewall. Frederico Madeira LPIC 1, CCNA fred@madeira.eng.br www.madeira.eng.br ADMINISTRAÇÃO DE REDES I LINUX Firewall Frederico Madeira LPIC 1, CCNA fred@madeira.eng.br www.madeira.eng.br São dispositivos que têm com função regular o tráfego entre redes distintas restringindo o

Leia mais

Segurança de Redes. Firewall. Filipe Raulino filipe.raulino@ifrn.edu.br

Segurança de Redes. Firewall. Filipe Raulino filipe.raulino@ifrn.edu.br Segurança de Redes Firewall Filipe Raulino filipe.raulino@ifrn.edu.br Introdução! O firewall é uma combinação de hardware e software que isola a rede local de uma organização da internet; Com ele é possível

Leia mais

Endereço IP Privado. Endereçamento IP. IP Protocolo da Internet. Protocolos da. Camada de Inter-Rede (Internet)

Endereço IP Privado. Endereçamento IP. IP Protocolo da Internet. Protocolos da. Camada de Inter-Rede (Internet) Protocolos da Camada de Inter- (Internet) IP Protocolo da Internet. Não Confiável; Não Orientado à conexão; Trabalha com Datagramas; Roteável; IPv 4 32 bits; IPv 6 128 bits; Divisão por Classes (A,B,C,D,E);

Leia mais

01 - Entendendo um Firewall. Prof. Armando Martins de Souza E-mail: armandomartins.souza@gmail.com

01 - Entendendo um Firewall. Prof. Armando Martins de Souza E-mail: armandomartins.souza@gmail.com 01 - Entendendo um Firewall. Prof. Armando Martins de Souza E-mail: armandomartins.souza@gmail.com O que são Firewalls? São dispositivos constituídos por componentes de hardware (roteador capaz de filtrar

Leia mais

IPTABLES. Helder Nunes Haanunes@gmail.com

IPTABLES. Helder Nunes Haanunes@gmail.com IPTABLES Helder Nunes Haanunes@gmail.com Firewall Hoje em dia uma máquina sem conexão com a internet praticamente tem o mesmo valor que uma máquina de escrever. É certo que os micros precisam se conectar

Leia mais

Segurança com Iptables

Segurança com Iptables Universidade Federal de Lavras Departamento de Ciência da Computação Segurança com Iptables Alunos : Felipe Gutierrez e Ronan de Brito Mendes Lavras MG 11/2008 Sumário 1 - Introdução...1 2 Softwares de

Leia mais

NAT com firewall - simples, rápido e funcional

NAT com firewall - simples, rápido e funcional NAT com firewall - simples, rápido e funcional Todo administrador de redes aprende logo que uma das coisas mais importantes para qualquer rede é um bom firewall. Embora existam muitos mitos em torno disto,

Leia mais

Oficina de ferramentas de Gerência para Redes em Linux

Oficina de ferramentas de Gerência para Redes em Linux Oficina de ferramentas de Gerência para Redes em Linux Introdução Mesmo as pessoas menos familiarizadas com a tecnologia sabem que a internet não é um "território" livre de perigos. É por esta razão que

Leia mais

Tutorial de TCP/IP Parte 21 Roteiro Para Resolução de Problemas

Tutorial de TCP/IP Parte 21 Roteiro Para Resolução de Problemas Introdução: Tutorial de TCP/IP Parte 21 Roteiro Para Resolução de Problemas Prezados leitores, esta é a primeira parte, desta segunda etapa dos tutoriais de TCP/IP. As partes de 01 a 20, constituem o módulo

Leia mais

Obs: Endereços de Rede. Firewall em Linux Kernel 2.4 em diante. Obs: Padrões em Intranet. Instalando Interface de Rede.

Obs: Endereços de Rede. Firewall em Linux Kernel 2.4 em diante. Obs: Padrões em Intranet. Instalando Interface de Rede. Obs: Endereços de Rede Firewall em Linux Kernel 2.4 em diante Classe A Nº de IP 1 a 126 Indicador da Rede w Máscara 255.0.0.0 Nº de Redes Disponíveis 126 Nº de Hosts 16.777.214 Prof. Alexandre Beletti

Leia mais

Autor: Armando Martins de Souza Data: 12/04/2010

Autor: Armando Martins de Souza <armandomartins.souza at gmail.com> Data: 12/04/2010 http://wwwvivaolinuxcombr/artigos/impressoraphp?codig 1 de 12 19-06-2012 17:42 Desvendando as regras de Firewall Linux Iptables Autor: Armando Martins de Souza Data: 12/04/2010

Leia mais

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim

Redes TCP/IP. Prof. M.Sc. Alexandre Fraga de Araújo. alexandref@ifes.edu.br. INSTITUTO FEDERAL DO ESPÍRITO SANTO Campus Cachoeiro de Itapemirim Redes TCP/IP alexandref@ifes.edu.br Camada de Redes 2 O que acontece na camada de rede Transporta segmentos do hospedeiro transmissor para o receptor Roteador examina campos de cabeçalho em todos os datagramas

Leia mais

ICMP. Tipos de mensagens ICMP

ICMP. Tipos de mensagens ICMP ICMP Tipos de mensagens ICMP ICMP (Internet Control Message Protocol) Normalmente considera-se que o ICMP faz parte da camada de rede Comunica mensagens de erro, mensagens de informação, mensagens de resposta

Leia mais

www.professorramos.com

www.professorramos.com Iptables www.professorramos.com leandro@professorramos.com Introdução O netfilter é um módulo que fornece ao sistema operacional Linux as funções de firewall, NAT e log de utilização de rede de computadores.

Leia mais

FIREWALL COM IPTABLES. www.eriberto.pro.br/iptables. by João Eriberto Mota Filho 3. TABELAS. Tabela Filter ESQUEMA DA TABELA FILTER

FIREWALL COM IPTABLES. www.eriberto.pro.br/iptables. by João Eriberto Mota Filho 3. TABELAS. Tabela Filter ESQUEMA DA TABELA FILTER FIREWALL COM IPTABLES www.eriberto.pro.br/iptables by João Eriberto Mota Filho 3. TABELAS Tabela Filter Vejamos o funcionamento da tabela filter (default) e as suas respectivas chains: ESQUEMA DA TABELA

Leia mais

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1

Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW. Free Powerpoint Templates Page 1 Segurança na Web Capítulo 6: Firewall Prof. Roberto Franciscatto 4º Semestre - TSI - CAFW Page 1 Introdução Qual a função básica de um firewall? Page 2 Introdução Qual a função básica de um firewall? Bloquear

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores CAMADA DE REDE DHCP NAT IPv6 Slide 1 Protocolo DHCP Protocolo de Configuração Dinâmica de Hospedeiros (Dynamic Host Configuration Protocol DHCP), RFC 2131; Obtenção de endereço de

Leia mais

O endereço IP (v4) é um número de 32 bits com 4 conjuntos de 8 bits (4x8=32). A estes conjuntos de 4 bits dá-se o nome de octeto.

O endereço IP (v4) é um número de 32 bits com 4 conjuntos de 8 bits (4x8=32). A estes conjuntos de 4 bits dá-se o nome de octeto. Endereçamento IP Para que uma rede funcione, é necessário que os terminais dessa rede tenham uma forma de se identificar de forma única. Da mesma forma, a interligação de várias redes só pode existir se

Leia mais

Firewalls em Sistemas BSD Unix

Firewalls em Sistemas BSD Unix Firewalls em Sistemas BSD Unix Alexandre Vasconcelos Administrador de Sistemas Unix SSP/GO * Este documento pode ser redistribuído livremente de acordo com a licença BSD Agenda Introdução/Conceitos Opções

Leia mais

Nmap Diferenças entre estados de porta (Parte 1)

Nmap Diferenças entre estados de porta (Parte 1) Autor: ryuuu Contato: ryuuu @hotmail.com Nmap Diferenças entre estados de porta (Parte 1) Embora o Nmap tenha crescido em funcionalidade ao longo dos anos, ele começou como um eficiente scanner de portas,

Leia mais

Uso do iptables como ferramenta de firewall.

Uso do iptables como ferramenta de firewall. Uso do iptables como ferramenta de firewall. Rafael Rodrigues de Souza rafael@tinfo.zzn.com Administração em Redes Linux Universidade Federal de Lavra UFLA RESUMO O artigo pretende abordar o uso de firewalls

Leia mais

genérico proteção de rede filtragem dos pacotes Sem estado (stateless) no próprio pacote. Com estado (stateful) outros pacotes

genérico proteção de rede filtragem dos pacotes Sem estado (stateless) no próprio pacote. Com estado (stateful) outros pacotes FIREWALLS Firewalls Definição: Termo genérico utilizado para designar um tipo de proteção de rede que restringe o acesso a certos serviços de um computador ou rede de computadores pela filtragem dos pacotes

Leia mais

Firewall - IPTABLES. Conceitos e Prática. Tópicos em Sistemas de Computação 2014. Prof. Dr. Adriano Mauro Cansian adriano@acmesecurity.

Firewall - IPTABLES. Conceitos e Prática. Tópicos em Sistemas de Computação 2014. Prof. Dr. Adriano Mauro Cansian adriano@acmesecurity. Firewall - IPTABLES Conceitos e Prática Tópicos em Sistemas de Computação 2014 Prof. Dr. Adriano Mauro Cansian adriano@acmesecurity.org Estagiário Docente: Vinícius Oliveira viniciusoliveira@acmesecurity.org

Leia mais

Curso de extensão em Administração de sistemas GNU/Linux: redes e serviços

Curso de extensão em Administração de sistemas GNU/Linux: redes e serviços Curso de extensão em Administração de sistemas GNU/Linux: redes e serviços Italo Valcy - italo@dcc.ufba.br Gestores da Rede Acadêmica de Computação Departamento de Ciência da Computação Universidade Federal

Leia mais

Controlando o tráfego de saída no firewall Netdeep

Controlando o tráfego de saída no firewall Netdeep Controlando o tráfego de saída no firewall Netdeep 1. Introdução Firewall é um quesito de segurança com cada vez mais importância no mundo da computação. À medida que o uso de informações e sistemas é

Leia mais

Proxyarp O Shorewall não exige qualquer configuração

Proxyarp O Shorewall não exige qualquer configuração SEGURANÇA Firewall fácil com o Shorewall Domando o fogo, parte 2 Na segunda parte de nosso tutorial de uso do poderoso Shorewall, aprenda a criar um firewall mais complexo e a proteger sua rede com muita

Leia mais

Tipos de Firewalls. porta de origem/destino, endereço de origem/destino, estado da conexão, e outros parâmetros do pacote.

Tipos de Firewalls. porta de origem/destino, endereço de origem/destino, estado da conexão, e outros parâmetros do pacote. IPTables Firewall: o que é? Qualquer máquina capaz de tomar decisões em relação ao tráfego de rede. Mecanismo que separa a rede interna e externa, objetivando aumentar o processo de segurança e controle

Leia mais

1. Capturando pacotes a partir da execução do traceroute

1. Capturando pacotes a partir da execução do traceroute Neste laboratório, iremos investigar o protocolo IP, focando o datagrama IP. Vamos fazê-lo através da analise de um trace de datagramas IP enviados e recebidos por uma execução do programa traceroute (o

Leia mais

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO

Prof. Luís Rodolfo. Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Prof. Luís Rodolfo Unidade III REDES DE COMPUTADORES E TELECOMUNICAÇÃO Redes de computadores e telecomunicação Objetivos da Unidade III Apresentar as camadas de Transporte (Nível 4) e Rede (Nível 3) do

Leia mais

Firewalls. Firewalls

Firewalls. Firewalls Firewalls Firewalls Paredes Corta-Fogo Regula o Fluxo de Tráfego entre as redes Pacote1 INTERNET Pacote2 INTERNET Pacote3 Firewalls Firewalls Barreira de Comunicação entre duas redes Host, roteador, PC

Leia mais

Senha Admin. Nessa tela, você poderá trocar a senha do administrador para obter acesso ao NSControl. Inicialização

Senha Admin. Nessa tela, você poderá trocar a senha do administrador para obter acesso ao NSControl. Inicialização Manual do Nscontrol Principal Senha Admin Nessa tela, você poderá trocar a senha do administrador para obter acesso ao NSControl. Inicialização Aqui, você poderá selecionar quais programas você quer que

Leia mais

ICMP Internet Control Message Protocol

ICMP Internet Control Message Protocol TCP UDP ICMP Internet Control Message Protocol ARP IP ICMP Acesso à rede Funcionalidade Mensagens ICMP Internet Control Message Protocol - ICMP Funcionalidades Informar máquina de origem da ocorrência

Leia mais

PROJETO DE IMPLEMENTAÇÃO DE UM SERVIDOR FIREWALL LIVRE UTILIZANDO IPTABLES

PROJETO DE IMPLEMENTAÇÃO DE UM SERVIDOR FIREWALL LIVRE UTILIZANDO IPTABLES PROJETO DE IMPLEMENTAÇÃO DE UM SERVIDOR FIREWALL LIVRE UTILIZANDO IPTABLES 1. Introdução O IPTABLES é um software usado para analisar os pacotes que passam entre redes. A partir desse princípio podemos

Leia mais

Usando o Nmap. A instalação do Nmap é bem simples. Após obter o código fonte execute os comandos abaixo: tar xjvpf nmap-3.48.tar.bz2 cd nmap-3.

Usando o Nmap. A instalação do Nmap é bem simples. Após obter o código fonte execute os comandos abaixo: tar xjvpf nmap-3.48.tar.bz2 cd nmap-3. Usando o Nmap Este artigo irá explicar como instalar e utilizar algumas funções do Nmap. Todos os comandos foram testados com a versão 3.48 do Nmap. É bem provável que alguns comandos não funcionem em

Leia mais

Professor Claudio Silva

Professor Claudio Silva Filtragem caso o pacote não seja permitido, ele é destruído caso seja permitido, ele é roteado para o destino Além das informações contidas nos pacotes o filtro sabe em que interface o pacote chegou e

Leia mais

Configuração de Rede

Configuração de Rede Configuração de Rede 1. Configuração de rede no Windows: A finalidade deste laboratório é descobrir quais são as configurações da rede da estação de trabalho e como elas são usadas. Serão observados a

Leia mais

ANÁLISE DE USABILIDADE DA FERRAMENTA IPFIREWALL PARA FIREWALL

ANÁLISE DE USABILIDADE DA FERRAMENTA IPFIREWALL PARA FIREWALL ANÁLISE DE USABILIDADE DA FERRAMENTA IPFIREWALL PARA FIREWALL Marcelo Antonio Ferreira Furin Graduado em Sistemas de Informação pela LIBERTAS Faculdades Integradas. Dorival Moreira Machado Junior Mestra

Leia mais

Professor: Macêdo Firmino Configuração TCP/IP no Windows 7

Professor: Macêdo Firmino Configuração TCP/IP no Windows 7 Professor: Macêdo Firmino Configuração TCP/IP no Windows 7 Se você tem mais que um computador ou outros dispositivos de hardware, como impressoras, scanners ou câmeras, pode usar uma rede para compartilhar

Leia mais

A Camada de Rede. Romildo Martins Bezerra CEFET/BA Redes de Computadores II

A Camada de Rede. Romildo Martins Bezerra CEFET/BA Redes de Computadores II A Camada de Rede Romildo Martins Bezerra CEFET/BA Redes de Computadores II A Camada de Rede e o protocolo IP... 2 O protocolo IP... 2 Formato do IP... 3 Endereçamento IP... 3 Endereçamento com Classes

Leia mais

IP - endereçamento. Endereço IP. Ex.: Identificador de 32 bits para interfaces de roteadores e hospedeiros

IP - endereçamento. Endereço IP. Ex.: Identificador de 32 bits para interfaces de roteadores e hospedeiros Endereço IP Ex.: Identificador de 32 bits para interfaces de roteadores e hospedeiros 223.1.1.1 = 11011111 00000001 00000001 00000001 223 1 1 1 Endereços de interfaces e sub-redes (fonte: Kurose) No ex.,

Leia mais

FIREWALL PROTEÇÃO EFICIENTE

FIREWALL PROTEÇÃO EFICIENTE FIREWALL PROTEÇÃO EFICIENTE Antonio Josnei Vieira da Rosa 1 João Carlos Zen 2 RESUMO. Firewall ou porta corta fogo pode ser definido como uma barreira de proteção cuja função é controlar o trafego de uma

Leia mais

www.projetoderedes.com.br Gestão da Segurança da Informação Professor: Maurício AULA 09 Firewall

www.projetoderedes.com.br Gestão da Segurança da Informação Professor: Maurício AULA 09 Firewall www.projetoderedes.com.br Gestão da Segurança da Informação Professor: Maurício O que é Firewall Um Firewall é um sistema para controlar o aceso às redes de computadores, desenvolvido para evitar acessos

Leia mais

Projeto e Instalação de Servidores Servidores Linux Aula 6 Firewall e Proxy

Projeto e Instalação de Servidores Servidores Linux Aula 6 Firewall e Proxy Projeto e Instalação de Servidores Servidores Linux Aula 6 Firewall e Proxy Prof.: Roberto Franciscatto Introdução FIREWALL Introdução Firewall Tem o objetivo de proteger um computador ou uma rede de computadores,

Leia mais

Redes de Computadores. Trabalho de Laboratório Nº2

Redes de Computadores. Trabalho de Laboratório Nº2 Redes de Computadores Curso de Eng. Informática Curso de Eng. de Electrónica e Computadores Trabalho de Laboratório Nº2 Configuração de TCP/IP numa rede de computadores Utilização de Ipconfig, Ping e Tracert

Leia mais

Pós Graduação Tecnologia da Informação UNESP Firewall

Pós Graduação Tecnologia da Informação UNESP Firewall Pós Graduação Tecnologia da Informação UNESP Firewall Douglas Costa Fábio Pirani Fernando Watanabe Jefferson Inoue Firewall O que é? Para que serve? É um programa usado para filtrar e dar segurança em

Leia mais

Firewalls. Prática de Laboratório. Maxwell Anderson INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA PARAÍBA

Firewalls. Prática de Laboratório. Maxwell Anderson INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA PARAÍBA Firewalls Prática de Laboratório Maxwell Anderson INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA PARAÍBA Sumário Firewall do Windows... 2 O que é um firewall?... 2 Ativar ou desativar o Firewall

Leia mais

SEG. EM SISTEMAS E REDES. Firewall

SEG. EM SISTEMAS E REDES. Firewall SEG. EM SISTEMAS E REDES Firewall Prof. Ulisses Cotta Cavalca Belo Horizonte/MG 2014 SUMÁRIO 1) Firewall 2) Sistema de detecção/prevenção de intrusão (IDS) 3) Implementação de

Leia mais

O Protocolo IP (2) Prof. José Gonçalves Pereira Filho Departamento de Informática zegonc@inf.ufes.br

O Protocolo IP (2) Prof. José Gonçalves Pereira Filho Departamento de Informática zegonc@inf.ufes.br O Protocolo IP (2) Prof. José Gonçalves Pereira Filho Departamento de Informática zegonc@inf.ufes.br O IP e a Máscara de Sub-Rede O IP se baseia em duas estruturas para efetuar o roteamento de datagramas:

Leia mais

Redes. Entenda o que são ICMP, ping e traceroute Autor: Hélder Garcia Email: hlbognfspam@sounerd.com Março de 2004

Redes. Entenda o que são ICMP, ping e traceroute Autor: Hélder Garcia Email: hlbognfspam@sounerd.com Março de 2004 Entenda o que são ICMP, ping e traceroute Autor: Hélder Garcia Email: hlbognfspam@sounerd.com Março de 2004 O ICMP - - é um protocolo que faz parte da pilha TCP/IP, enquadrando-se na camada de rede (nível

Leia mais

Firewall. Tutorial Firewall em Linux Acadêmicos: Felipe Zottis e Cleber Pivetta

Firewall. Tutorial Firewall em Linux Acadêmicos: Felipe Zottis e Cleber Pivetta Tutorial Firewall em Linux Acadêmicos: Felipe Zottis e Cleber Pivetta Firewall Firewall é um quesito de segurança com cada vez mais importância no mundo da computação. À medida que o uso de informações

Leia mais

Segurança de Redes de Computadores

Segurança de Redes de Computadores Segurança de Redes de Computadores Aula 8 Segurança nas Camadas de Rede, Transporte e Aplicação Firewall (Filtro de Pacotes) Prof. Ricardo M. Marcacini ricardo.marcacini@ufms.br Curso: Sistemas de Informação

Leia mais

Na Figura a seguir apresento um exemplo de uma "mini-tabela" de roteamento:

Na Figura a seguir apresento um exemplo de uma mini-tabela de roteamento: Tutorial de TCP/IP - Parte 6 - Tabelas de Roteamento Por Júlio Cesar Fabris Battisti Introdução Esta é a sexta parte do Tutorial de TCP/IP. Na Parte 1 tratei dos aspectos básicos do protocolo TCP/IP. Na

Leia mais

Componentes de um sistema de firewall - I

Componentes de um sistema de firewall - I Componentes de um sistema de firewall - I O que são Firewalls? Os firewalls são sistemas de segurança que podem ser baseados em: um único elemento de hardware; um único elemento de software instalado num

Leia mais

Instalação e Configuração Iptables ( Firewall)

Instalação e Configuração Iptables ( Firewall) Instalação e Configuração Iptables ( Firewall) Pág - 1 Instalação e Configuração Iptables - Firewall Desde o primeiro tutorial da sequencia dos passo a passo, aprendemos a configurar duas placas de rede,

Leia mais

Laboratório 11.2.3b Listas de acesso estendidas para DMZ simples

Laboratório 11.2.3b Listas de acesso estendidas para DMZ simples Laboratório 11.2.3b Listas de acesso estendidas para DMZ simples Objetivo Situação Neste laboratório, será explorado o uso de listas de acesso estendidas para criação de uma Zona Desmilitarizada (DMZ).

Leia mais

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com /

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini E-mail: prof.andre.luis.belini@gmail.com / andre.belini@ifsp.edu.br MATÉRIA: SEGURANÇA DA INFORMAÇÃO Aula N : 09 Tema:

Leia mais

1. PRINCIPAIS PROTOCOLOS TCP/IP

1. PRINCIPAIS PROTOCOLOS TCP/IP 1. PRINCIPAIS PROTOCOLOS TCP/IP 1.1 IP - Internet Protocol RFC 791 Esse protocolo foi introduzido na ARPANET no início dos anos 80, e tem sido utilizado juntamente com o TCP desde então. A principal característica

Leia mais

I Workshop do POP MG. Firewall IPTABLES. Fernando Resende Coelho frcoelho@pop mg.rnp.br

I Workshop do POP MG. Firewall IPTABLES. Fernando Resende Coelho frcoelho@pop mg.rnp.br Firewall IPTABLES Fernando Resende Coelho frcoelho@pop mg.rnp.br Sumário Conceitos Diagrama de fluxo Sintaxe Passo a passo Referências O que é um Firewall? Um firewall é uma barreira inteligente entre

Leia mais

Redes de Computadores

Redes de Computadores 8. Segurança de Rede DIN/CTC/UEM 2008 : o que é? Dispositivo que permite conectividade segura entre redes (interna e externa) com vários graus de confiabilidade Utilizado para implementar e impor as regras

Leia mais

Compartilhamento da internet, firewall

Compartilhamento da internet, firewall da internet, firewall João Medeiros (joao.fatern@gmail.com) 1 / 29 Exemplo de transmissão 2 / 29 Exemplo de transmissão Dados trafegam em pacotes com até 1460 bytes de dados e dois headers de 20 bytes

Leia mais

Redes de Computadores I - Protocolos de Controle: ICMP. por Helcio Wagner da Silva

Redes de Computadores I - Protocolos de Controle: ICMP. por Helcio Wagner da Silva Redes de Computadores I - Protocolos de Controle: ICMP por Helcio Wagner da Silva Introdução Na Internet, cada roteador opera de maneira autônoma X X X X 2 Introdução Infelizmente, nada funciona corretamente

Leia mais

Redes de Computadores

Redes de Computadores s de Computadores s de Computadores s de Computadores 2 1 Roteamento como visto cada gateway / host roteia mensagens não há coordenação com outras máquinas Funciona bem para sistemas estáveis e sem erros

Leia mais

Protocolos, DNS, DHCP, Ethereal e comandos em Linux

Protocolos, DNS, DHCP, Ethereal e comandos em Linux Redes de Computadores Protocolos, DNS, DHCP, Ethereal e comandos em Linux Escola Superior de Tecnologia e Gestão Instituto Politécnico de Bragança Março de 2006 Endereços e nomes Quaisquer duas estações

Leia mais

1 TCI/IP... 3 1.1 MODELO TCP/IP... 3 1.1.1 Camada de Aplicação... 4

1 TCI/IP... 3 1.1 MODELO TCP/IP... 3 1.1.1 Camada de Aplicação... 4 TCP/IP Brito INDICE 1 TCI/IP... 3 1.1 MODELO TCP/IP... 3 1.1.1 Camada de Aplicação... 4 1.1.1.1 Camada de Transporte... 4 1.1.1.2 TCP (Transmission Control Protocol)... 4 1.1.1.3 UDP (User Datagram Protocol)...

Leia mais

Linux Network Servers

Linux Network Servers Firewall Nos tempos atuais tem se falado muito em segurança, pois a internet se tornou um ambiente perigoso. Todos nossos servidores que estão expostos para a internet necessitam de uma proteção para que

Leia mais

Modulo 4. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados

Modulo 4. Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados Modulo 4 Professor: Leandro Engler Boçon E-mail: leandro@facear.edu.br Disciplina: Comunicação de dados 1 Protocolo ICMP Internet Control Message Protocol 2 ICMP Internet Control Message Protocol IP funciona

Leia mais

Administração de Redes Redes e Sub-redes

Administração de Redes Redes e Sub-redes 1 MINISTÉRIO DA EDUCAÇÃO SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA CAMPUS SÃO JOSÉ SANTA CATARINA Administração de Redes Redes e Sub-redes Prof.

Leia mais

Endereços Lógicos, Físicos e de Serviço

Endereços Lógicos, Físicos e de Serviço Endereçamento IP O IP é um protocolo da Camada de rede É um endereço lógico único em toda a rede, portanto, quando estamos navegando na Internet estamos utilizando um endereço IP único mundialmente, pois

Leia mais

Capítulo 9: Listas de Controle de Acesso

Capítulo 9: Listas de Controle de Acesso Unisul Sistemas de Informação Redes de Computadores Capítulo 9: Listas de Controle de Acesso Roteamento e switching Academia Local Cisco UNISUL Instrutora Ana Lúcia Rodrigues Wiggers Presentation_ID 1

Leia mais

Elaboração de Script de Firewall de Fácil administração

Elaboração de Script de Firewall de Fácil administração Elaboração de Script de Firewall de Fácil administração Marcos Monteiro http://www.marcosmonteiro.com.br contato@marcosmonteiro.com.br IPTables O iptables é um firewall em NÍVEL DE PACOTES e funciona baseado

Leia mais

SUMÁRIO 1. AULA 7 INTRODUÇÃO À REDES PONTO A PONTO = PARTE 1:... 2

SUMÁRIO 1. AULA 7 INTRODUÇÃO À REDES PONTO A PONTO = PARTE 1:... 2 SUMÁRIO 1. AULA 7 INTRODUÇÃO À REDES PONTO A PONTO = PARTE 1:... 2 1.1 Introdução... 2 1.2 Montando Redes Ponto-a-Ponto... 3 1.2.1 Parte lógica... 3 1.2.2 Escolhendo o sistema operacional... 3 1.2.3 Instalação

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Prof. Macêdo Firmino Camada de Redes Macêdo Firmino (IFRN) Redes de Computadores Junho 2012 1 / 68 Pilha TCP/IP A B M 1 Aplicação Aplicação M 1 Cab M T 1 Transporte Transporte Cab

Leia mais

Firewall. Professor: João Paulo de Brito Gonçalves Disciplina: Serviços de Redes. Campus Cachoeiro Curso Técnico em Informática

Firewall. Professor: João Paulo de Brito Gonçalves Disciplina: Serviços de Redes. Campus Cachoeiro Curso Técnico em Informática Firewall Professor: João Paulo de Brito Gonçalves Disciplina: Serviços de Redes Campus Cachoeiro Curso Técnico em Informática Firewall (definições) Por que do nome firewall? Antigamente, quando as casas

Leia mais

3) Na configuração de rede, além do endereço IP, é necessário fornecer também uma máscara de subrede válida, conforme o exemplo:

3) Na configuração de rede, além do endereço IP, é necessário fornecer também uma máscara de subrede válida, conforme o exemplo: DIRETORIA ACADÊMICA DE EDUCAÇÃO E TECNOLOGIA COORDENAÇÃO DOS CURSOS DA ÁREA DE INFORMÁTICA! Atividade em sala de aula. 1) A respeito de redes de computadores, protocolos TCP/IP e considerando uma rede

Leia mais

Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Conexão de Redes. Protocolo TCP/IP. Arquitetura Internet.

Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Protocolo TCP/IP. Conexão de Redes. Protocolo TCP/IP. Arquitetura Internet. Origem: Surgiu na década de 60 através da DARPA (para fins militares) - ARPANET. Em 1977 - Unix é projetado para ser o protocolo de comunicação da ARPANET. Em 1980 a ARPANET foi dividida em ARPANET e MILINET.

Leia mais

OS endereços IP v.4 consistem em 4 octetos separados por pontos. Estes endereços foram separados

OS endereços IP v.4 consistem em 4 octetos separados por pontos. Estes endereços foram separados Endereçamento IP V.4 e Roteamento Estático Pedroso 4 de março de 2009 1 Introdução OS endereços IP v.4 consistem em 4 octetos separados por pontos. Estes endereços foram separados em 5 classes, de acordo

Leia mais

Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento. Associação dos Instrutores NetAcademy - Julho de 2007 - Página

Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento. Associação dos Instrutores NetAcademy - Julho de 2007 - Página Capítulo 9 - Conjunto de Protocolos TCP/IP e Endereçamento IP 1 História e Futuro do TCP/IP O modelo de referência TCP/IP foi desenvolvido pelo Departamento de Defesa dos Estados Unidos (DoD). O DoD exigia

Leia mais

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway

Funcionamento de ARP entre redes (sub-redes) distintas. Mecanismos de entrega. Funcionamento entre redes (sub-redes): default gateway Introdução Inst tituto de Info ormátic ca - UF FRGS Redes de Computadores Protocolos ARP e ICMP Aula 18 A camada de rede fornece um endereço lógico Uniforme, independente da tecnologia empregada pelo enlace

Leia mais

M3 Redes de computadores avançado (36 horas - 48 TL)

M3 Redes de computadores avançado (36 horas - 48 TL) M3 Redes de computadores avançado (36 horas - 48 TL) Redes de Comunicação Ano lectivo 2013/2014 Camada de rede do modelo OSI Routers e portos de interface de routers (I) 2 Nesta camada imperam os routers.

Leia mais

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

TRANSMISSÃO DE DADOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 4 - A CAMADA DE REDE (Parte 2) 1. Flooding (Inundação) Outro algoritmo estático é o algoritmo de inundação, no qual cada pacote de entrada é enviado para todas as linhas de saída, exceto para aquela

Leia mais

Introdução a Firewalls no Linux (Netfilter/Iptables)

Introdução a Firewalls no Linux (Netfilter/Iptables) IntroduçãoaFirewallsnoLinux (Netfilter/Iptables) RicardoKléberMartinsGalvão www.ricardokleber.com.br ricardo.galvao@ifrn.edu.br RicardoKléber::IntroduçãoaFirewallsnoLinux RicardoKléber ProfessordoIFRN(SegurançadeRedes)

Leia mais

Segurança em Sistemas de Informação

Segurança em Sistemas de Informação Segurança em Sistemas de Informação Introdução O Iptables é um código de firewall presente nas versões a partir da 2.4 do kernel, que substituiu o Ipchains (presente nas séries 2.2 do kernel). Ele foi

Leia mais

Laboratório - Visualização das tabelas de roteamento do host

Laboratório - Visualização das tabelas de roteamento do host Laboratório - Visualização das tabelas de roteamento do host Topologia Objetivos Parte 1: Acessar a tabela de roteamento de host Parte 2: Examinar as entradas da tabela de roteamento de host IPv4 Parte

Leia mais

Prof. Samuel Henrique Bucke Brito

Prof. Samuel Henrique Bucke Brito Sistema Operacional Linux > Firewall NetFilter (iptables) www.labcisco.com.br ::: shbbrito@labcisco.com.br Prof. Samuel Henrique Bucke Brito Introdução O firewall é um programa que tem como objetivo proteger

Leia mais

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO

ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO ESCOLA SUPERIOR DE TECNOLOGIA E GESTÃO PROJECTO E INSTALAÇÃO DE REDES LOCAIS DE COMPUTADORES O Modelo TCP/IP: Camada Internet Discentes: Ricardo Alexandre Revez Costa, nº5963 Manuel José Terlica Revés,

Leia mais

Capítulo 4 TCP/IP FIREWALLS.

Capítulo 4 TCP/IP FIREWALLS. Capítulo 4 TCP/IP FIREWALLS. O que é uma firewall? É um router entre uma rede privada e uma rede pública que filtra o tráfego com base num conjunto de regras. GRS - Capitulo 4 1/1 Arquitecturas de redes

Leia mais

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança

3 SERVIÇOS IP. 3.1 Serviços IP e alguns aspectos de segurança 3 SERVIÇOS IP 3.1 Serviços IP e alguns aspectos de segurança Os serviços IP's são suscetíveis a uma variedade de possíveis ataques, desde ataques passivos (como espionagem) até ataques ativos (como a impossibilidade

Leia mais

Segurança de redes com Linux. Everson Scherrer Borges Willen Borges de Deus

Segurança de redes com Linux. Everson Scherrer Borges Willen Borges de Deus Segurança de redes com Linux Everson Scherrer Borges Willen Borges de Deus Segurança de Redes com Linux Protocolo TCP/UDP Portas Endereçamento IP Firewall Objetivos Firewall Tipos de Firewall Iptables

Leia mais

Redes de Computadores

Redes de Computadores Redes de Computadores Redes de Computadores Nível de Rede Redes de Computadores 2 1 Nível de Rede Internet Nível de Rede na Internet O ambiente inter-redes: hosts conectados a redes redes interligam-se

Leia mais

Aula pratica 4 Testar Conexões TCP/IP em Redes Industrias Usando os comandos Ping e Net View (1.a Parte)

Aula pratica 4 Testar Conexões TCP/IP em Redes Industrias Usando os comandos Ping e Net View (1.a Parte) 1 Aula pratica 4 Testar Conexões TCP/IP em Redes Industrias Usando os comandos Ping e Net View (1.a Parte) Objetivo: Esta aula tem como objetivo apresentar aos alunos como testar a conectividade de uma

Leia mais

Camada de Rede. Prof. Leonardo Barreto Campos 1

Camada de Rede. Prof. Leonardo Barreto Campos 1 Camada de Rede Prof. Leonardo Barreto Campos 1 Sumário Introdução; Internet Protocol IP; Fragmentação do Datagrama IP; Endereço IP; Sub-Redes; CIDR Classes Interdomain Routing NAT Network Address Translation

Leia mais

Fundamentos dos protocolos internet

Fundamentos dos protocolos internet Fundamentos dos protocolos internet - 2 Sumário Capítulo 1 Fundamentos dos protocolos internet...3 1.1. Objetivos... 3 1.2. Mãos a obra...4 Capítulo 2 Gerenciando... 14 2.1. Objetivos... 14 2.2. Troubleshooting...

Leia mais

Laboratório Firewall IPv6

Laboratório Firewall IPv6 Sobre a licença Para cada novo uso ou distribuição, você deve deixar claro para outros os termos da licença desta obra. No caso de criação de obras derivadas, os logotipos do CGI.br, NIC.br, IPv6.br e

Leia mais

SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL. Curso Técnico em Informática

SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL. Curso Técnico em Informática SERVIÇO NACIONAL DE APRENDIZAGEM COMERCIAL Curso Técnico em Informática Estrutura de Endereçamento IP e Mascara de Subrede Endereçamento IP e Classes Autoridade para Atribuição de Números da Internet http://www.iana.org/

Leia mais

Roteador de Perímetro DMZ Hosts de Segurança Gateway de Aplicativo

Roteador de Perímetro DMZ Hosts de Segurança Gateway de Aplicativo Roteador de Perímetro DMZ Hosts de Segurança Gateway de Aplicativo Conectando-se à Internet com Segurança Soluções mais simples. Sistemas de Segurança de Perímetro Zona Desmilitarizada (DMZ) Roteador de

Leia mais