[FUGSPBR] Re: [FUGSPBR] Re: [FUGSPBR] Gateway com Firewall que não ta qurendo funcionar
Armindo Gomes
armindo em redetec.org.br
Ter Abr 2 10:02:44 BRT 2002
Valeu grande.
Me será de grande valor essa informação!
Armindo Gomes
----- Original Message -----
From: "Cristian Thiago Moecke" <moecke em lmp.ufsc.br>
To: <fugspbr em fugspbr.org>
Sent: Tuesday, April 02, 2002 9:53 AM
Subject: Re: [FUGSPBR] Re: [FUGSPBR] Gateway com Firewall que não ta qurendo
funcionar
> 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.
>
----
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