[FUGSPBR] Re: [FUGSPBR] Gateway com Firewall que não ta qurendo funcionar
Armindo Gomes
armindo em redetec.org.br
Ter Abr 2 09:06:00 BRT 2002
Patrick,
Aproveitando a sua explicação, para que serve a regra:
----- Original Message -----
From: "Patrick Tracanelli" <eksffa em bsd.com.br>
To: <fugspbr em fugspbr.org>
Sent: Monday, April 01, 2002 8:13 PM
Subject: Re: [FUGSPBR] Gateway com Firewall que não ta qurendo funcionar
> Cristian,
>
> Vamos assumir (entre outras coisas) que a sua rede deveria ser separada
> nao apenas logicamente, mas tambem fisicamente. Da forma como voce
> descreveu as provaveis solucoes iriam amenizar o seu problemas, mas
> qualquer engracadinho com um sniffer poderia te dar alguma dor de
> cabeca. Voce tem que pensar exatamente o que voce pode - e o que voce
> quer - fazer. Por exemplo. A solucao de colocar uma bridge entre o seu
> roteador e as redes eh valida, mas voce controlaria apenas o trafego e
> as acoes dos hosts que fossem passar pela bridge (em direcao ao router,
> obviamente). Nesse caso, se o seu NT fica antes do roteador (o que me
> pareceu ser o fato - pelo q vc explicou) a bridge nao controlaria nada,
> visto que esses usuarios da rede2 tentariam se logar como admins da rede
> 1 no NT - mesmo barramento fisico, antes do roteador.
>
> Entao qual uma solucao seria dividir as redes fisica e logicamente. Se
> voce tiver carta branca pra fazer isso dentro da sua faculdade, nao
> pense duas vezes.
>
> O esquema ficaria assim:
>
> [rede1]
> /\
> ||
> [roteador] <==> [FreeBSD]
> ||
> \/
> [rede2]
>
> Nem tenho ideia como vai sair esse esquema ai no seu cliente de email,
> hehehe, mas espero q seja legivel. Tambem nao sei se hoje voce usa IPs
> verdadeiros (nao reservados) nessas redes. Se voce usa, nao vai fazer
> muita diferenca a divisao logica das redes, mas a o principal - a fisica
> - vai estar pronta.
>
> Voce pode optar por esse freebsd ser uma bridge (ateh transparente, se
> necessario) ou ser uma maquina agindo como gateway/firewall e limitador
> de banda. Se voce for usar redes reservadas, voce vai ter que fazer NAT.
>
> Detalhe que agora, voce nao tem 2 placas de rede, e sim 3. Uma pro
> roteador - que te leva pra internet - e uma pra cada rede. Vamos assumir
> que voce vai usar redes reservadas.
>
> no rc.conf:
> ----------
>
> hostname="freebsd.seilaoq.ufsc.br"
>
> defaultrouter="IP-DO-ROTEADOR"
>
> ifconfig_fxp0="inet 200.IP.VERDADEIRO netmask 255.maskara.externa"
> ifconfig_fxp1="inet 192.168.0.1 netmask 255.255.255.0"
> ifconfig_fxp2="inet 192.168.1.1 netmask 255.255.255.0"
>
> network_interfaces="fxp0 fxp1 fxp2 lo0"
>
> gateway_enable="YES"
>
> firewall_enable="YES"
> firewall_type="OPEN"
>
> natd_enable="YES"
> natd_flags="-l -f /etc/natd.conf"
> natd_interface="fxp0"
> ----
>
> no /etc/natd.conf:
> -------
> # Interface Real segundo a RFC a qual eu esqueci :Pp
> interface fxp0
> # Definicoes de portas Dinamicas, tipo FTP, Netmeeting, DCC (IRC) CUCME
> etc...
> dynamic yes
>
> same_ports yes
> use_sockets yes
> # forward de redes privadas pra redes publicas via NATd
> # redirect_port se um dia precisar...
>
>
> Com isso voce vai esar fazendo NAT no esquemao divert natd all from any
> to any.
>
> Essa entrada vai estar sendo lida em /etc/rc.firewall automaticamente.
> Acontece que, quando sua rede ja estiver funcionando, voce vai querer
> mudar o firewall_type no rc.conf pro caminho do seu conjunto de regras.
>
> Ai voce tem que se lembrar de setar o divert via ipfw manualmente. A
> regra mais basica: ipfw add divert natd all from any to any via fxp0
>
> Depois voce melhora ela, adicionando divert apenas pra suas 2 redes.
>
> Bom, a estrutura fisica nesse modelinho ai, vai estar assim:
>
> O seu hub da rede 1 vai se conectar na fxp1 do freebsd
> o Hub da rede 2 vai se conectar na fxp2 do freebsd
> O roteador vai se conectar na fxp0 do freebsd.
>
> Se voce nao tiver um switch ou hub entre o freebsd e o roteador, o cabo
> deve ser crossover.
>
> Bom, nesse ponto, vamos assumir que todas as maquinas da sua rede 1 e
> rede 2 ja tem que estar pingando a internet -via netd ou via gateway
> simplesmente, se sua rede for verdadeira. Se isso nao estiver
> acontecendo, repense suas configuracoes.
>
> O gateway dos clientes de cada laboratorio sera o endereco IP da
> interface interna do freebsd, ou seja, 192.168.0.1 pro lab 1 e
> 192.168.1.1 pro lab2. O servidor DNS pode ser qualquer 1, dentro ou fora
> da rede privada, visto que ate agora voce nao restringiu nada no seu
> firewall, e qualquer IP verdadeiro ou nao pode ser alcancado. Se puder
> coloque esse proprio FreeBSD rodando um DNS Cache, assim ja serve pras
> duas redes - ou sei la, use o seu DNS atual, nao sei como ta hoje.
>
> Estando isso funcionando, agora voce precisa definir suas regras de
> firewall... crie um arquivo e aponte-o no rc.conf (entrada firewall_type)
>
> por exemplo, firewall_type="/usr/local/etc/minhas.regras"
>
> dentro dele, lembre-se que voce tem que fazer o divert - ja que voce nao
> vai estar usando mais o rc.firewall. A desvantagem de nao usar o
> rc.firewall eh que as vezes agente esquece de algumas regras que por
> boas maneiras, devem existir... por exemplo:
>
>
> seu-arquiv-de-regras:
> -----
> ## Bloco 1 - coizera basica
> add 00001 check-state
> #ranca fora se nao usar keep-state em lugar nenhum
> add 100 natd all from any to any via fxp0
> # depois nao se eskeca de melhorar essa regra
> add 110 pass all from any to any via lo0
> add 120 deny log all from any to 127.0.0.0/8
> add 130 deny log ip from 127.0.0.0/8 to any
> add 400 deny log tcp from any to 192.168.0.0/16 frag
> add 500 deny log tcp from any to 192.168.0.0/16 tcpflags syn,rst
> add 600 deny log tcp from any to 192.168.0.0/16 tcpflags syn,fin
>
> ## bloco 2 - mais um pokim de seguranca
> add 700 deny log all from 10.0.0.0/8 to any in via fxp0
> add 800 deny log all from 172.16.0.0/12 to any in via fxp0
> add 900 deny log all from 192.168.0.0/26 to any in via fxp0
> #eh obvio q vc nao vai querer redes privadas entrando pelo link publico
> add 950 allow log tcp from <host-confiavel> to me 22 in setup via fxp0
> keep-state
> add 955 deny log tcp from any to me 22 in
> #ssh - minimo
>
> ## bloco 3 - ordem na casa
> add 1000 deny tcp from 192.168.0.0/24 to 192.168.1.0/24 in via fxp1
> add 1100 deny tcp from 192.168.1.0/24 to 192.168.0.0/24 in via fxp2
> # aki vc estabelece que nao havera comunicacao entre a suas 2 redes
>
> #daki pra baixo voce faz o resto, separando quem pode e nao pode fazer oq
> #(por exemplo, quem pode ler email, de onde pra onde etc...)
>
> ## bloco 3 - dummynet
> add 5000 pipe 1 all from 192.168.1.0/24 to any out # UPLoad
> add 5100 pipe 2 all from any to 192.168.1.0/24 in # DownLoa
>
> pipe 1 config bw 64Kbit/s # Tunel 1 64Kbps UPLoad
> pipe 2 config bw 128Kbit/s # Tunel 2 128Kbps Download
> ----
>
>
> Acho que pelo que entendi do que voce precisa, essas regras ai devem ser
> o bastante pra satisfazer suas necessidades iniciais. Claro que elas sao
> apenas exemplos de como voce deve agir. Eu fiz isso de cabeca entao pode
> haver algum erro - mas acho q nao tem nao - enfim, voce vai melhorar
> muito isso de acordo com a sua rede...
>
> -------------
>
> Agora vamos la, e se voce decidiu nao fazer seu freebsd um gateway, e
> prefere fazer ele agir como bridge? Se eu fosse tentar explicar
> basicamente o que eh bridge esse email ia ficar chato de ler... voce
> deve ter o conceito basico... entao vamos la...
>
> obviamente voce precisade: suporte a bridge no kernel.
>
> Passado isso, suas configuracoes vao ser via o (poderoso) sysctl(8):
>
> # Faz essa Box uma bridge.
> sysctl -w net.link.ether.bridge_ipfw=1
> sysctl -w net.link.ether.bridge=1
> sysctl -w net.link.ether.bridge_cfg=fxp0,fxp1,fxp2
>
> Pronto, agora seu freebsd virou uma bridge (super complexo hein?)
> Voce nao precisar por nem IP nas interfaces, elas ja vao estar se
> comunicando diretamente apos isso... se voce nao definir IP, isso quer
> dizer que (thchanan) eh uma bridge transparente, ou seja, os gateways da
> sua rede interna vao continuar sendo o seu roteador la na outra ponto,
> visto que eles nao vai nem saber que existe um freebsd no meio da
> jogada... Talvez essa seja a forma mais fera de se fazer firewall (ao
> menos eh a que eu mais gosto...). E com ipfw eh ainda mais fera do que
> com ipfilter.
>
> Bom, quando voce ta fazendo firewall com bridge, lembre-se que voce tem
> que mudar um pouco os seus conceitos, e fazer suas regras apoiando-se
> nos "in/out via interface" muito mais do que baseado em IP (o ideal eh
> sempre as duas formas, claro). Outra coisa, voce fica restrito `a
> algumas funcionalidades.
>
> Mais uma coisa.. quando voce ta usando filtering-bridge, voce deve
> pensar na ordem de controle dos pacotes, visto que os mesmos podem
> passar uma unica vez, ou varias outras pelo firewall, dependendo da
> opcao net.inet.ip.fw.one_pass do sysctl(8).
>
> Enfim, sao varias coisinhas que voce tem que ficar atento. O melhor eh
> ler "man ipfw", "man dummynet", "man bridge" entre outros, que vao te
> dar boas nocoes de como agir...
>
> Mas pra te ajudar, o ipfw tem a opcao bridged, que identifica os pacotes
> que passaram pela bridge. Pra voce aprender como agir, dependendo do
> pacote, sugiro o seguinte:
>
> ipfw add count log all from any to any bridged
>
> Ai da uma linda rapido nos logs (pra debugar um pouquinho do que ta
> acontecendo no seu firewall).
>
> Lembre-se usar bridge transparente pode ser solucao ou problema,
> dependendo do quao bem voce se der com ela ;) Pra mim eh fera :)
>
> Vale atentar tambem pro tuning basico do seu kernel, se voce for usar
> bridge. Simplesmente por causa dos nMBUffers e dos nmbclusters que voce
> vai estar separando pro seu stack tcp/ip. E claro, quanto voce tem de
> memoria real disponivel na sua bridge :)
>
> man tuning - pode ajudar
>
> -----------------------------------------------------
>
> No seu kernel voce vai precisar de:
> (colar do meu kernel checklist ekeke)
> --------------------------------------
>
> ## IPFIREWALL:
> options IPFIREWALL # suporte a ipfirewall
> options IPFIREWALL_VERBOSE # suporte aos logs do ipfirewall
> options IPFIREWALL_FORWARD # suporte a ipfw fwd
> options IPFIREWALL_VERBOSE_LIMIT=500 #limite do log alterado,
> evita local DoS
> options IPFIREWALL_DEFAULT_TO_ACCEPT #politica de firewall
> (aberta)
>
> options INCLUDE_CONFIG_FILE #obvio
> options IPSTEALTH #stealth forwarding
>
> ## NATD:
> options IPDIVERT #suporte a NAT via socks de divert
>
> ## BRIDGE:
> options BRIDGE #suporte a bridging
>
> ## DUMMYNET:
> options DUMMYNET #suporte ao dummynet
> options HZ=1000 #altera o clock
>
> ## Network Tuning Basico:
> options NMBCLUSTERS=70000 # mem usada pelos clusters
> options NMBUFS=70000 # mem usada por cada cluster.
>
>
> ##
> mais uma dica pessoal, pra te ajudar em um tuning geral no kernel,
> defina maxusers no minimo igual a sua quantidade de RAM
> (por exemplo, meus servers tem maxusers=512 quando eu tenho 512MB de
> memoria principal)
>
> Evite colocar maxusers=0 porque voce vai no padrao de auto tuning do
> freebsd, padrao esse ainda bastante conservador. E pra um firewall legal
> nao eh bom ser conservador :>
>
> Se necessario, mude o send buffer e receive buffer do stack tcp/ip do
> freebsd (se tu tiver com freebsd 4.5 nem vai precisar mexer, anao ser em
> casos extremos).
>
> Tem um artigo que o Matt Dillon (VM/Soft Updates/tuning -etc etc)
> escreveu, que saiu em daily.daemonnews.org sobre tuning... da uma lida
> que nao vai se arrepender (eu nao lembro a url de cabeca).
>
> Acho que soh isso basta.
>
> Abracos,
>
> Paz Profunda,
> Patrick Tracanelli
>
>
>
> +-----------------------------------------------+---------+
> | Patrick Leandro Tracanelli do Carmo | ( ) |
> | Parallel Processing & BSD Unix enthusiastic | (O_O) |
> | FreeBSD 5.0-CURRENT i386 SMP #21 | \`-'/ w|
> | Faculdade de Tecnologia Taquaritinga / Unesp | ( )__||
> |===============================================| /m`m\ |
> | eksffa em bsd.com.br, eksffa em fatectq.com.br | FreeBSD |
> +-----------------------------------------------+---------+
> Long live Hanin Elias, Kim Deal!!! ;-)
> ~
> ~
>
> ----
> Para sair da lista envie um e-mail para majordomo em fugspbr.org
> com as palavras "unsubscribe fugspbr" no corpo da mensagem.
>
----
Para sair da lista envie um e-mail para majordomo em fugspbr.org
com as palavras "unsubscribe fugspbr" no corpo da mensagem.
Mais detalhes sobre a lista de discussão freebsd