[FUGSPBR] Re: [FUGSPBR] Gateway com Firewall que não ta qurendo funcionar
Cristian Thiago Moecke
moecke em lmp.ufsc.br
Ter Abr 2 09:53:14 BRT 2002
Primeiro, Muito obrigado mesmo ao Patrick pela excelente explicação. Li ela
toda, vou por maos a obra agora. Se com esse "livro" eu não conseguir resolver o
problema, taco tudo aqui pela janela (ops, não tem janela, vai no chao mesmo) e
desisto de ser admin de rede (brincadeira, não faco isso nao... capaz de eu não
conseguir ainda dai ter q cumprir isso ae.....)
Pro Armindo... Se eu ja to comecando a entender alguma coisa, as regras abaixo
são para limitar a banda que passa pelas placas de rede...
>
> ## 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
>
Cria os "pipes". São "canos" que serao monitorados e por onde o trafego eh
direcionado. No caso, Tudo que vem da rede 192.168.1.* para qualquer lugar
(UpLoad) passa pelo pipe 1, e tudo que vem de qq lugar para a rede 192.168.1.*
passa pelo pipe 2
>
> pipe 1 config bw 64Kbit/s # Tunel 1 64Kbps UPLoad
> pipe 2 config bw 128Kbit/s # Tunel 2 128Kbps Download
>
Ai É colocada uma limitacao de banda. 64 Kbit/s p Upload (pipe 1) e 128 p/
dowload (pipe 2)
>
> Desde já te agradeço.
>
> Armindo Gomes
>
> ----- 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.
--
---------------------------------------
Cristian Thiago Moecke
CPD - LMP - UFSC
moecke em lmp.ufsc.br
---------------------------------------
----
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