http://www.zago.eti.br/firewall/firewall-cont2.txt Este arquivo FAQ é continuação de firewall.txt, foi dividido para diminuir o tamanho do arquivo. Use CTRL+F para refinar a pesquisa. Linha de: **************** separa mensagens ou tópicos. ******************************************************** Zago http://www.zago.eti.br/menu.html FAQ e artigos sobre Linux ***************************************************** Varias mensagens sobre um longa discussão sobre firewall: De: Edilson Rahal Tavares Para: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 10 Feb 2005 14:32:45 -0200 Olá Carlos, sem alterar os IPs não será possível, a menos que você altere a estrutura. O mais comum neste caso seria você ter uma DMZ (Rede desmilitarizada) onde ficariam os servidores. Esses servidores utilizariam IPs inválidos (por exemplo 192.168.1.2 e 192.168.1.3) O Firewall ficaria entre o roteador e os servidores fazendo o trabalho de segurança e tradução dos endereços (válidos para inválidos, etc). Abraços, Edilson. Em Qui 10 Fev 2005 07:32, Carlos escreveu: > Oi pessoal, > Tenho um roteador com o endereço 200.xxx.xxx.1 e dois servidores com os > endereços: 200.xxx.xxx.2 (dns1 e email) e o outro 200.xxx.xxx.3 (dns2 e > www). Quero colocar uma maq com firewall entre o roteador e os > servidores mas sem alterar os ips e a estrutura de rede(posso alocar > mais dois ips verdadeiros p/ o fw). É possivel? como devo fazer? > > Obrigado. > > Carlos De: Antonio da Silva Martins Junior Para: Carlos Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br)Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 10 Feb 2005 14:28:39 -0200 (BRDT) On Thu, 10 Feb 2005, Carlos wrote: > Tenho um roteador com o endereço 200.xxx.xxx.1 e dois servidores com os > endereços: 200.xxx.xxx.2 (dns1 e email) e o outro 200.xxx.xxx.3 (dns2 e > www). Quero colocar uma maq com firewall entre o roteador e os > servidores mas sem alterar os ips e a estrutura de rede(posso alocar > mais dois ips verdadeiros p/ o fw). É possivel? como devo fazer? Olá, Use uma bridge com firewall, você irá criar uma firewall "invisível". De uma procurada no Goggle que você acha :) Antonio. De: Thiago Macieira Para: linux-br@bazar2.conectiva.com.br, Carlos Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 10 Feb 2005 15:51:21 -0200 Edilson Rahal Tavares wrote: >sem alterar os IPs não será possível, a menos que você altere a > estrutura. Vou mais além: sem alterar a estrutura não vai ser possível. Afinal, se você quer colocar um firewall *entre* o roteador e os servidores, que estão na mesma rede hoje, vai ter que dividir a rede em duas. >O mais comum neste caso seria você ter uma DMZ (Rede desmilitarizada) >onde ficariam os servidores. Esses servidores utilizariam IPs inválidos >(por exemplo 192.168.1.2 e 192.168.1.3) Nesse caso não é DMZ. >O Firewall ficaria entre o roteador e os servidores fazendo o trabalho > de segurança e tradução dos endereços (válidos para inválidos, etc). Não acho uma boa colocar servidores com IPs privativos. Dê-lhes os IPs públicos de uma vez por todas. O único problema será a divisão da sua rede. Uma opção é fazer sub-redes, mas há desperdício de IPs dessa maneira. O que eu recomendo é mais ou menos assim: Internet ----| roteador |--------------| firewall |---------| rede interna 200.x.x.1 192.168.0.1 192.168.0.2 200.x.x.4 200.x.x.0/24 O seu roteador você deverá configurar com as seguintes rotas: destino máscara gateway dispositivo 0.0.0.0 0.0.0.0 o seu gateway de Internet 192.168.0.2 255.255.255.0 - o da interface 192.168.0.1 200.x.x.0 255.255.255.0 192.168.0.2 - Já o seu firewall, que eu assumo ser um Linux, você deverá ter as rotas: destino máscara gateway dispositivo 0.0.0.0 0.0.0.0 200.x.x.1 - 192.168.0.1 255.255.255.0 - o da interface 192.168.0.2 200.x.x.1 255.255.255.255 192.168.0.1 - 200.x.x.0 255.255.255.0 - o da interface 200.x.x.4 Certifique-se que o frwarding está ativado e o Linux deverá fazer automagicamente um proxyarp para o 200.x.x.1. A sua rede você configurará normalmente, com gateway 200.x.x.1 ou 200.x.x.4 -- Thiago Macieira - thiago (AT) macieira (DOT) info De: Antonio da Silva Martins Junior Para: Linux-BR Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips Data: Thu, 10 Feb 2005 16:48:11 -0200 (BRDT) Thiago Macieira wrote: >Edilson Rahal Tavares wrote: >>sem alterar os IPs não será possível, a menos que você altere a >> estrutura. > >Vou mais além: sem alterar a estrutura não vai ser possível. Afinal, se >você quer colocar um firewall *entre* o roteador e os servidores, que >estão na mesma rede hoje, vai ter que dividir a rede em duas. Como disse antes, _é possivel_ :) Nunca diga não é possivel! Sempre tem alguém inventando uma solução :) Na verdade é possivel de duas maneiras! A primeira usando proxy-arp, que não recomendo, e a segunda criando uma bridge e filtrando o trafégo através dela, com a vantagem que a sua firewall será virtualmente invulnerável pois não necessita de um endereço IP (a firewall, não os servidores). De uma olhada aqui: http://ebtables.sourceforge.net/ Sobre a configuração sugerida pelo Thiago, também funciona, só recomendo mover o IP da interface interna do router (ethernet) para a rede interface interna da firewall, e deixar tanto a ethernet do router como a interface externa da firewall com IPs invalidos, facilita na hora de criar as rotas! Assim: Internet --- router 192.168.0.1 --- 192.168.0.2 firewall 200.X.Y.1 -> rede Acho que deu para entender, agora é só escolher a solução :) Antonio. De: Wellington Terumi Uemura Responder A: Wellington Terumi Uemura Para: Thiago Macieira Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Sat, 12 Feb 2005 17:29:29 -0200 Desculpe entrar no meio da briga :) Mas não entendo sua lógica, qual a diferença da sua configuração com a tradicional DMZ? A única diferença que eu vejo é que os papeis se inverteram mas no fim dá na mesma. http://www.phoneboy.com/bin/view.pl/FAQs/SampleConfigurationWithNAT Lembrando que ip's válidos são roteáveis na internet! Outro ponto importante, o seu esquema é inseguro pelo fato de revelar através de IP's válidos que você tem além de clientes, servidores com vários IP's válidos. O fato de um servidor ter um ip inválido na internet não significa que ele não vai funcionar, desde que, configurado por uma pessoa capacitada ele deve funcionar de forma totalmente transparente para o usuário. De uma maneira ou de outra mesmo você não gostando de NAT você nessa sua configuração está fazendo NAT, por isso não entendo sua lógica, que diferença tem fazer NAT de ip inválido para válido e ip válido para ip inválido e ip válido novamente??? No final você tem um network overhead desnecessário... Seu exemplo Internet ----| roteador |--------------| firewall |---------| rede interna 200.x.x.1 192.168.0.1 192.168.0.2 200.x.x.4 200.x.x.0/24 Meu exemplo Internet ----| roteador |----------| firewall |------------------| rede interna x.x.x.x__200.x.x.x___200.x.x.x___192.168.x.x__192.168.x.x/x No seu exemplo você tem que fazer 2 processos de NAT e 2 roteamentos, IP válido > Ip inválido > IP Válido No meu exemplo você tem que fazer 1 processo de roteamento e 1 NAT, IP inválido > ip válido. Por questões de funcionalidade, internamente ter um ip inválido não deve reduzir em nada as funcionalidades dos servidores....Vamos por exemplo pegar o cabeçalho de uma mensagem que envie de dentro do meu servidor para o gmail. Servidor de email: mail.interno.local IP: 10.1.1.19 Domínio: empresa.com.br Windows 2003 Active Directory Domain: interno.local PS: mail.interno.local e empresa.com.br não tem nada haver uma com a outra mas estão dentro de uma mesma estrutura. X-Gmail-Received: 685dfc4faca421efad5a466d98db2226241b26a0 Delivered-To: wellingtonuemura@gmail.com Received: by 10.54.5.65 with SMTP id 65cs11337wre; Sat, 12 Feb 2005 09:32:13 -0800 (PST) Received: by 10.38.89.1 with SMTP id m1mr44718rnb; Sat, 12 Feb 2005 09:32:13 -0800 (PST) Return-Path: Received: from mail.empresa.com.br (200-xxx-xxx-xx.empresa.com.br [xxx.xxx.xxx.xx]) by mx.gmail.com with ESMTP id 64si183971rna.2005.02.12.09.32.10; Sat, 12 Feb 2005 09:32:13 -0800 (PST) Received-SPF: pass (gmail.com: domain of wellington.uemura@empresa.com.br designates xxx.xxx.xxx.xx as permitted sender) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51131.7920C4AC" Subject: Estamos usando NAT? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 12 Feb 2005 15:34:23 -0300 Message-ID: <192BDF2668FA294E94D6CC10A1AFD2AA0B7FB4@mail.empresa.com.br> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall sample Thread-Index: AcURMXkeTW/WtPqSTT++F0t0El670Q== From: "Wellington Uemura" To: Você não vê nenhum sinal de informação do servidor interno no cabeçalho, como o IP 10.1.1.19 ou mail.empresa.local Exemplo do firewall para SMTP: #!/bin/sh IPT="/sbin/iptables" IP_EXT="xxx.xxx.xxx.xx" $IPT -t filter -F $IPT -t nat -F #Protecao contra IP Spoofing for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 1 > $i done #CONFIG $IPT -t filter -P INPUT DROP $IPT -t filter -P OUTPUT DROP $IPT -t filter -P FORWARD DROP echo "1" > /proc/sys/net/ipv4/ip_forward echo "8000" > /proc/sys/net/ipv4/ip_conntrack_max # Previne Denial of Service Attack echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time echo 1 > /proc/sys/net/ipv4/tcp_window_scaling echo 0 > /proc/sys/net/ipv4/tcp_sack echo 1280 > /proc/sys/net/ipv4/tcp_max_syn_backlog # Definindo status de conexões $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT -m state --state INVALID -j DROP $IPT -A OUTPUT -m state --state INVALID -j DROP $IPT -A FORWARD -m state --state INVALID -j DROP # Proteção contea Stealth Scans e TCP State Flags # Todos os bits são apagados $IPT -A INPUT -p tcp --tcp-flags ALL NONE -j DROP $IPT -A FORWARD -p tcp --tcp-flags ALL NONE -j DROP # Definindo SYN e FIN $IPT -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP $IPT -A FORWARD -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP # Definindo SYN e RST $IPT -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP $IPT -A FORWARD -p tcp --tcp-flags SYN,RST SYN,RST -j DROP # Definindo FIN e RST $IPT -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP $IPT -A FORWARD -p tcp --tcp-flags FIN,RST FIN,RST -j DROP # Definindo apenas FIN, para aqueles que não acompanham um ACK $IPT -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP $IPT -A FORWARD -p tcp --tcp-flags ACK,FIN FIN -j DROP # Definindo apenas PSH, para aqueles que não acompanham um ACK $IPT -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP $IPT -A FORWARD -p tcp --tcp-flags ACK,PSH PSH -j DROP # Definindo apenas URG, para aqueles que não acompanham um ACK $IPT -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP $IPT -A FORWARD -p tcp --tcp-flags ACK,URG URG -j DROP # INPUT $IPT -t filter -A INPUT -i eth1 -p tcp -s $IP_EXT -d 10.1.1.19 --sport 1024:65535 --dport 25 -m state --state NEW,RELATED -j ACCEPT # OUTPUT $IPT -t filter -A OUTPUT -o eth1 -p tcp -s $IP_EXT -d 10.1.1.19 --dport 1024:65535 --sport 25 -m state --state NEW,RELATED -j ACCEPT $IPT -t filter -A OUTPUT -o eth0 -p tcp -s 10.1.1.19 -d $IP_EXT --sport 1024:65535 --dport 25 -m state --state NEW,RELATED -j ACCEPT # FORWARD $IPT -A FORWARD -i eth1 -o eth0 -p tcp --sport 1024:65535 -s $IP_EXT -d 10.1.1.19 --dport 25 -m state --state NEW -j ACCEPT $IPT -A FORWARD -i eth0 -o eth1 -p tcp --sport 25 -d $IP_EXT -s 10.1.1.19 --dport 1024:65535 -m state --state NEW -j ACCEPT # NAT $IPT -t nat -A PREROUTING -p tcp -i eth1 --dport 25 -j DNAT --to 10.1.1.19 Log... Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED DROP all -- anywhere anywhere state INVALID DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE DROP tcp -- anywhere anywhere tcp flags:FIN,SYN/FIN,SYN DROP tcp -- anywhere anywhere tcp flags:SYN,RST/SYN,RST DROP tcp -- anywhere anywhere tcp flags:FIN,RST/FIN,RST DROP tcp -- anywhere anywhere tcp flags:FIN,ACK/FIN DROP tcp -- anywhere anywhere tcp flags:PSH,ACK/PSH DROP tcp -- anywhere anywhere tcp flags:ACK,URG/URG ACCEPT tcp -- xxx.xxx.xxx.xx 10.1.1.19 tcp spts:1024:65535 dpt:smtp state NEW,RELATED Chain FORWARD (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED DROP all -- anywhere anywhere state INVALID DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE DROP tcp -- anywhere anywhere tcp flags:FIN,SYN/FIN,SYN DROP tcp -- anywhere anywhere tcp flags:SYN,RST/SYN,RST DROP tcp -- anywhere anywhere tcp flags:FIN,RST/FIN,RST DROP tcp -- anywhere anywhere tcp flags:FIN,ACK/FIN DROP tcp -- anywhere anywhere tcp flags:PSH,ACK/PSH DROP tcp -- anywhere anywhere tcp flags:ACK,URG/URG ACCEPT tcp -- xxx.xxx.xxx.xx 10.1.1.19 tcp spts:1024:65535 dpt:smtp state NEW ACCEPT tcp -- 10.1.1.19 xxx.xxx.xxx.xx tcp spt:smtp dpts:1024:65535 state NEW Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT tcp -- xxx.xxx.xxx.xx 10.1.1.19 tcp spt:smtp dpts:1024:65535 state NEW,RELATED ACCEPT tcp -- 10.1.1.19 xxx.xxx.xxx.xx tcp spts:1024:65535 dpt:smtp state NEW,RELATED Se feito corretamente como mostra o exemplo os resultados serão os mesmos que o meu sem ter nenhuma perda de funcionalidade. No caso do nosso amigo que deseja intercalar um firewall na rede as opções de regras valem para a sua configuração, só não sendo necessário a linha que tem a opção de NAT uma vez que você vai trabalhar com IP's válidos dos dois lados, mas o ideal mesmo seria trabalhar com ip inválido atrás do firewall. Espero que tenha ajudado. T+ > Não acho uma boa colocar servidores com IPs privativos. Dê-lhes os IPs > públicos de uma vez por todas. O único problema será a divisão da sua > rede. > > Uma opção é fazer sub-redes, mas há desperdício de IPs dessa maneira. > > O que eu recomendo é mais ou menos assim: > > Internet ----| roteador |--------------| firewall |---------| rede interna > 200.x.x.1 192.168.0.1 192.168.0.2 200.x.x.4 200.x.x.0/24 De: Antonio da Silva Martins Junior Para: Wellington Terumi Uemura Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Mon, 14 Feb 2005 08:01:07 -0200 (BRDT) On Sat, 12 Feb 2005, Wellington Terumi Uemura wrote: > Desculpe entrar no meio da briga :) > Mas não entendo sua lógica, qual a diferença da sua configuração com a > tradicional DMZ? Nenhuma, mas eu só dei uma sujestão para economizar endereços IP públicos (roteáveis). A minha sujestão para o problema seria uma firewall-bridge :) > Outro ponto importante, o seu esquema é inseguro pelo fato de revelar > através de IP's válidos que você tem além de clientes, servidores com > vários IP's válidos. O fato de um servidor ter um ip inválido na > internet não significa que ele não vai funcionar, desde que, > configurado por uma pessoa capacitada ele deve funcionar de forma > totalmente transparente para o usuário. Concordo em parte, o fato do IP do servidor ser publico ou privado não é relevante para mais ou menos sergurança. O serviço principal (ou outros) sempre será acessivel (p.ex. http), e uma falha nele poderá ser explorada com NAT ou sem NAT, pois o acesso é liberado pela firewall! > De uma maneira ou de outra mesmo você não gostando de NAT você nessa > sua configuração está fazendo NAT, por isso não entendo sua lógica, > que diferença tem fazer NAT de ip inválido para válido e ip válido > para ip inválido e ip válido novamente??? No final você tem um network > overhead desnecessário... Onde você viu NAT no meu exemplo? Não é feito NAT na firewall ou no router! A configuração que enviei economiza IPs e simplifica a tabela de roteamento, somente isso. A firewall teria somente as regras de bloqueio / permissão, sem NAT que neste caso é desnecessário. > Seu exemplo > Internet ----| roteador |--------------| firewall |---------| rede interna > 200.x.x.1 192.168.0.1 192.168.0.2 200.x.x.4 200.x.x.0/24 > > Meu exemplo > Internet ----| roteador |----------| firewall |------------------| rede interna > x.x.x.x__200.x.x.x___200.x.x.x___192.168.x.x__192.168.x.x/x > > No seu exemplo você tem que fazer 2 processos de NAT e 2 roteamentos, > IP válido > Ip inválido > IP Válido > No meu exemplo você tem que fazer 1 processo de roteamento e 1 NAT, > IP inválido > ip válido. No meu exemplo: sem NAT :) > Por questões de funcionalidade, internamente ter um ip inválido não > deve reduzir em nada as funcionalidades dos servidores....Vamos por > exemplo pegar o cabeçalho de uma mensagem que envie de dentro do meu > servidor para o gmail. Isto, depende do serviço alguns dependem (H323, FTP) de módulos especificos, e em alguns casos não funcionam! Outros serviços (HTTP, SMTP) funcionam sem problemas! Antonio. De: Thiago Macieira Para: Edilson Rahal Tavares Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 10 Feb 2005 16:39:58 -0200 Edilson Rahal Tavares wrote: >> Não acho uma boa colocar servidores com IPs privativos. Dê-lhes os IPs >> públicos de uma vez por todas. O único problema será a divisão da sua >> rede. > >qual seria o motivo para não utilizar IPs inválidos para servidores ? Primeiramente, vamos dar nomes aos bois. Os IPs são muito bem válidos, tanto que você pode usá-los. O termo mais correto é "privativo" ou "reservado". IPs inválidos seriam algo como 0.0.0.0, 255.255.255.255 ou IPs destinados aos endereços de rede ou broadcast. Não recomendo colocar servidores atrás de NAT em nenhum caso. O motivo é bem simples: eles são servidores, logo devem ser acessados de fora. Colocar um NAT no caminho só complica as coisas -- mesmo que seja um NAT 1:1. Se não for 1:1 é pior ainda. Mas mesmo assim, veja o caso de serviços como FTP ou H.323 que requerem que o daemon saiba o IP externo. Se o ftpd mandar na conexão a resposta 227 Entering Passive Mode (192,168,0,2,237,108). o seu cliente não conseguirá transferir arquivos ou listar direteórios. Isso é só um exemplo das coisas que podem dar errado. Eu recomendo, em todas as ocasiões em que for possível, evitar-se o NAT. Sempre que possível, dê um IP público às máquinas. -- Thiago Macieira - thiago (AT) macieira (DOT) info De: Edilson Rahal Tavares Para: Thiago Macieira Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 10 Feb 2005 18:03:27 -0200 Olá Thiago, > >qual seria o motivo para não utilizar IPs inválidos para servidores ? > > Primeiramente, vamos dar nomes aos bois. Os IPs são muito bem válidos, > tanto que você pode usá-los. O termo mais correto é "privativo" ou > "reservado". IPs inválidos seriam algo como 0.0.0.0, 255.255.255.255 ou > IPs destinados aos endereços de rede ou broadcast. desculpe. O termo que usei é um termo "de mercado" e você utilizou um termo acadêmico. > Não recomendo colocar servidores atrás de NAT em nenhum caso. O motivo é > bem simples: eles são servidores, logo devem ser acessados de fora. > Colocar um NAT no caminho só complica as coisas -- mesmo que seja um NAT > 1:1. Se não for 1:1 é pior ainda. Mas mesmo assim, veja o caso de > serviços como FTP ou H.323 que requerem que o daemon saiba o IP externo. > > Se o ftpd mandar na conexão a resposta > 227 Entering Passive Mode (192,168,0,2,237,108). > > o seu cliente não conseguirá transferir arquivos ou listar direteórios. Acho curioso, utilizo normalmente NAT para servidores externos sem qualquer tipo de problema ou efeito colaterial, já há bastante tempo. De qualquer forma, obrigado pela informação. Grande abraço, Edilson. De: Jorge Godoy Para: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Fri, 11 Feb 2005 10:16:54 -0200 Em Thu 10 Feb 2005 18:03, Edilson Rahal Tavares escreveu: > desculpe. > O termo que usei é um termo "de mercado" e você utilizou um termo > acadêmico. Eu diria que o termo do Thiago e' o correto, o do "mercado" e' o incorreto. Alias, eu encontro pessoas no "mercado" usando os termos corretos. Geralmente sao pessoas que realmente conhecem o que fazem. Os que usam o termo incorreto geralmente sao os "quebra-galhos". O uso da nomenclatura tecnica de forma correta contribui para mostrar o nivel de profissionalismo que voce tem. E' uma opiniao que tenho e que ja' vi outros empresarios comentarem tambem. > Acho curioso, utilizo normalmente NAT para servidores externos sem qualquer > tipo de problema ou efeito colaterial, já há bastante tempo. Voce usa recursos do iptables onde ele carrega os modulos adequados para o NAT, correto? Diversos outros firewall fazem o mesmo. Eu tenho uma opiniao adversa aa do Thiago, mas sei do impacto no desempenho que tal solucao apresenta e sei que o projeto deve ser mais cuidadoso e levar em conta a adicao destes componentes. Sds, Godoy. De: Henrique Cesar Ulbrich Para: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 10 Feb 2005 19:07:24 -0200 Historiadores acreditam que, em Qui 10 Fev 2005 15:51, Thiago Macieira disse: > Edilson Rahal Tavares wrote: > >sem alterar os IPs não será possível, a menos que você altere a > > estrutura. > > Vou mais além: sem alterar a estrutura não vai ser possível. Afinal, se > você quer colocar um firewall *entre* o roteador e os servidores, que > estão na mesma rede hoje, vai ter que dividir a rede em duas. Não vai não! Na Linux Magazine Brasil, edição 5 (que vai estar nas bancas em duas semanas) vai ter uma matéria sobre BRIDGING FIREWALL, ou seja, um filtro de pacotes que funciona na camada 2 OSI - no caso, Ethernet - e, portanto, é completamente invisível à rede. Relembrando, por trabalhar com Ethernet a bridge não precisa de números IP em suas interfaces. Uma bridge não divide uma rede em duas subredes distintas - pelo contrário, uma bridge pode unir duas redes distantes como se fossem uma só. Mesmo dividida em dois segmentos, é a mesma rede, com o mesmo endereçamento etc. Uma matéria sobre isso também saiu na revista Geek há um tempo atrás, sobre o mesmo assunto, mas usando FreeBSD como Bridge. A matéria que sairá na Linux Magazine usa Linux mesmo. Portanto, reiterando, SIM, É POSSÍVEL COLOCAR UM FIREWALL ENTRE O ROTEADOR E OS SERVIDORES SEM ALTERAR A ESTRUTURA DA REDE, desde que seja uma bridge. Espere sair a revista na banca e compre. A edição 5 é dedicada a Firewalls. Vale a pena, você não vai se arrepender. Ops, all caps... -- Henrique We've always had him! http://www.ericblumrich.com/thanks.html De: Henrique Cesar Ulbrich Para: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Thu, 17 Feb 2005 14:34:00 -0200 Historiadores acreditam que, em Sex 11 Fev 2005 17:47, Antonio da Silva Martins Junior disse: > > Na Linux Magazine Brasil, edição 5 (que vai estar nas bancas em duas > > semanas) vai ter uma matéria sobre BRIDGING FIREWALL, ou seja, um filtro > > de pacotes que funciona na camada 2 OSI - no caso, Ethernet - e, > > portanto, é completamente invisível à rede. > > Não, será na edição 6... a 5 está nas bancas e trata de desktops :) Yep, a 6. -- Henrique We've always had him! http://www.ericblumrich.com/thanks.html De: Jorge Godoy Para: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Fri, 11 Feb 2005 10:21:29 -0200 Em Thu 10 Feb 2005 19:07, Henrique Cesar Ulbrich escreveu: > Portanto, reiterando, SIM, É POSSÍVEL COLOCAR UM FIREWALL ENTRE O ROTEADOR > E OS SERVIDORES SEM ALTERAR A ESTRUTURA DA REDE, desde que seja uma bridge. Tecnicamente isso e' uma inverdade. Na pratica o efeito eh bem parecido -- nao e' identico pois ha' fatores que sao alterados --, mas voce realizou uma mudanca na topologia de rede. Sds, Godoy. De: Antonio da Silva Martins Junior Para: Henrique Cesar Ulbrich Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Fri, 11 Feb 2005 17:40:23 -0200 (BRDT) On Fri, 11 Feb 2005, Henrique Cesar Ulbrich wrote: > Historiadores acreditam que, > em Sex 11 Fev 2005 10:21, Jorge Godoy disse: > > Tecnicamente isso e' uma inverdade. Na pratica o efeito eh bem parecido -- > > nao e' identico pois ha' fatores que sao alterados --, mas voce realizou > > uma mudanca na topologia de rede. > > Hummm... explique. O Godoy está afirmando que a topologia de rede foi alterada pois foi incluido um elemento (a bridge) entre o router e o switch (ou hub) onde estão ligados os servidores. Ele está correto, se você trocar um switch por um hub (ou vice-versa) também estara alterando a topologia da rede, mesmo que a funcionalidade permaneça (quase) inalterada. Antonio. De: Thiago Macieira Para: Wellington Terumi Uemura Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Sat, 12 Feb 2005 18:47:40 -0200 Wellington Terumi Uemura wrote: >Mas não entendo sua lógica, qual a diferença da sua configuração com a >tradicional DMZ? DMZ = rede protegida por firewall, mas ainda acessível externamente, com IPs públicos. >Lembrando que ip's válidos são roteáveis na internet! Todo IP (v4) é roteável, exceto os inválidos, tais como 0.0.0.0 ou 255.255.255.255. Até mesmo o 127.0.0.1 é roteável e roteado. >Outro ponto importante, o seu esquema é inseguro pelo fato de revelar >através de IP's válidos que você tem além de clientes, servidores com >vários IP's válidos. Em algum lugar você quis dizer privativos. Acho que foi o segundo. E não são servidores: são apenas roteadores. E qual é o problema em revelar alguns IPs privativos no meio? Faz alguma diferença? Não serão acessíveis e não têm nenhum serviço rodando. São apenas roteadores. Tem muito provedor por aí que faz isso. Não vejo problema algum. >O fato de um servidor ter um ip inválido na >internet não significa que ele não vai funcionar, desde que, >configurado por uma pessoa capacitada ele deve funcionar de forma >totalmente transparente para o usuário. Ou seja: além de configurar o IP da forma tradicional, o administrador deverá carregar os módulos de NAT, configurar os serviços com os IPs externos, proxies, etc. E além disso, só poderá utilizar os daemons que forem capazes de funcionar atrás de NAT. FTP é um exemplo. >De uma maneira ou de outra mesmo você não gostando de NAT você nessa >sua configuração está fazendo NAT, Não há NAT algum na minha proposta. >por isso não entendo sua lógica, >que diferença tem fazer NAT de ip inválido para válido e ip válido >para ip inválido e ip válido novamente??? No final você tem um network >overhead desnecessário... Não há NAT. > >Seu exemplo > Internet ----| roteador |--------------| firewall |---------| rede > interna 200.x.x.1 192.168.0.1 192.168.0.2 200.x.x.4 > 200.x.x.0/24 Certo. Há apenas roteamento. > >Meu exemplo >Internet ----| roteador |----------| firewall |------------------| rede > interna x.x.x.x__200.x.x.x___200.x.x.x___192.168.x.x__192.168.x.x/x > >No seu exemplo você tem que fazer 2 processos de NAT e 2 roteamentos, Não. Há apenas roteamento. >IP válido > Ip inválido > IP Válido Não. É apenas roteamento. Acompanhe a proposta de rotas que eu fiz. O processo inteiro existe sem NAT. Existe apenas uma rede privativa entre o roteador e o firewall que usa IPs privativos. Poderia muito bem usar IPs públicos também. Aliás, dependendo do roteador, você pode colocar o mesmo IP nas duas interfaces. >Por questões de funcionalidade, internamente ter um ip inválido não >deve reduzir em nada as funcionalidades dos servidores.... Suponha um serviço genérico qualquer que transmita no seu trem de bits o endereço IP para uma conexão secundária. Mais ou menos como o FTP: o cliente pede "abra conexão secundária" e o servidor responde "ok, o IP é x.x.x.x e a porta é Y". Isso não funciona atrás de NAT, a não ser que: 1) o daemon em questão seja capaz de contactar um proxy ou 2) o servidor de NAT seja capaz de identificar a conversa passando e alterar o conteúdo da mesma, fazendo o NAT do IP sendo informado e preparando-se para a conexão secundária. Imagine agora que o protocolo seja criptografado e a opção #2 seja impossível. Ou então que não haja suporte no firewall-NAT para tal protocolo genérico, ao contrário do FTP. Imagine ainda mais que o daemon em questão é o único do gênero, não suporta proxies e trocá-lo seja impraticável. Você está numa situação em que um servidor atrás de NAT simplesmente não funciona. Se quiser um exemplo concreto, eu posso lhe dar um: H.323. Existe um patch para ele para os Netfilter, mas no kernel padrão do Linux, ele não é suportado. >Vamos por >exemplo pegar o cabeçalho de uma mensagem que envie de dentro do meu >servidor para o gmail. Estamos falando de conexões de fora para dentro. De dentro para fora não há problema algum com NAT. >Received: by 10.54.5.65 with SMTP id 65cs11337wre; > Sat, 12 Feb 2005 09:32:13 -0800 (PST) >Received: by 10.38.89.1 with SMTP id m1mr44718rnb; > Sat, 12 Feb 2005 09:32:13 -0800 (PST) Esses IPs privativos são do GMail? >Você não vê nenhum sinal de informação do servidor interno no >cabeçalho, como o IP 10.1.1.19 ou mail.empresa.local Porque a conexão foi de dentro para fora. E o protocolo de SMTP não requer conexões secundárias, como o FTP o faz. SMTP não é um caso crítico. >Se feito corretamente como mostra o exemplo os resultados serão os >mesmos que o meu sem ter nenhuma perda de funcionalidade. Para o SMTP eu concordo. Tente com o FTP ou um serviço genérico qualquer, cujo formato interno você não conhece. Mas você teve de configurar uma regra extra (a do NAT) que não seria necessária caso o servidor de SMTP tivesse um IP público. Em qual dos dois casos é mais provável haver algum engano de configuração: com 0 ou 1 regras? >No caso do nosso amigo que deseja intercalar um firewall na rede as >opções de regras valem para a sua configuração, só não sendo >necessário a linha que tem a opção de NAT uma vez que você vai >trabalhar com IP's válidos dos dois lados, mas o ideal mesmo seria >trabalhar com ip inválido atrás do firewall. Não concordo e expus minhas razões acima. Além disso, tenho que dizer é NAT é ruim para a Internet como um todo. O ideal seria que ele não existisse e todo mundo tivesse os IPs dos quais precisa. Com NAT, a conectividade global é quebrada porque nem todos os nós da rede são acessíveis por todos os outros nós. (Estou falando do ponto de vista teórico, não do prático) -- Thiago Macieira - thiago (AT) macieira (DOT) info PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste. De: Wellington Terumi Uemura Responder A: Wellington Terumi Uemura Para: Thiago Macieira Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Sun, 13 Feb 2005 15:37:13 -0200 > DMZ = rede protegida por firewall, mas ainda acessível externamente, com > IPs públicos. DMZ é uma rede ou parte dela separada por um firewall que permite entrada ou saída de tráfego determinadas por este. O fato de se usar ip válido ou restrito não tem nada haver com isso. > Todo IP (v4) é roteável, exceto os inválidos, tais como 0.0.0.0 ou > 255.255.255.255. Até mesmo o 127.0.0.1 é roteável e roteado. Você entendeu o que quiz dizer. > E qual é o problema em revelar alguns IPs privativos no meio? Faz alguma > diferença? Não serão acessíveis e não têm nenhum serviço rodando. São > apenas roteadores. Coloque seus servidores direto na internet então, dá o mesmo efeito. > Tem muito provedor por aí que faz isso. Não vejo problema algum. Sim, claro que tem, por isso veja o exemplo da telefônica que está listada em tudo quanto é blacklist da internet e nem mesmo o Terra que é da telefônica aceita emails da sua própria rede. > Ou seja: além de configurar o IP da forma tradicional, o administrador > deverá carregar os módulos de NAT, configurar os serviços com os IPs > externos, proxies, etc. E além disso, só poderá utilizar os daemons que > forem capazes de funcionar atrás de NAT. Não há novidade nenhuma nisso. > FTP é um exemplo. O problema do FTP já foi resolvido faz tempo. > Acompanhe a proposta de rotas que eu fiz. O processo inteiro existe sem > NAT. Existe apenas uma rede privativa entre o roteador e o firewall que > usa IPs privativos. > > Poderia muito bem usar IPs públicos também. Aliás, dependendo do roteador, > você pode colocar o mesmo IP nas duas interfaces. Entendo, mas o problema da sua proposta é colocar IP's válidos dentro da rede e o mais importante, que estes IP's pertençam a você e dependendo da quantidade de servidores internos estes não serão suficientes. > Suponha um serviço genérico qualquer que transmita no seu trem de bits o > endereço IP para uma conexão secundária. Mais ou menos como o FTP: o > cliente pede "abra conexão secundária" e o servidor responde "ok, o IP é > x.x.x.x e a porta é Y". > > Isso não funciona atrás de NAT, a não ser que: > 1) o daemon em questão seja capaz de contactar um proxy > ou > 2) o servidor de NAT seja capaz de identificar a conversa passando e > alterar o conteúdo da mesma, fazendo o NAT do IP sendo informado e > preparando-se para a conexão secundária. [corta] > Você está numa situação em que um servidor atrás de NAT simplesmente não > funciona. Se quiser um exemplo concreto, eu posso lhe dar um: H.323. > Existe um patch para ele para os Netfilter, mas no kernel padrão do > Linux, ele não é suportado. Já ví que seu problema se resume básicamente em FTP, temos dois servidores de FTP Windows por trás de um firewall linux (iptables) funcionando sem problemas, talvez com um pouco de boa vontade de pesquisar mais sobre o assunto possam tirar essa sombra do FTP de suas costas. Veja por exemplo esta documentação que lhe dá uma idéia de como fazer as coisas funcionarem: http://www.chinalinuxpub.com/doc/www.siliconvalleyccie.com/linux-hn/ftp-server.htm H.323, SIP... tem mais algum que gostaria de de informar?? Talvez você não tenha visto ainda o site http://openh323proxy.sourceforge.net/ mas sem problemas... Não me interessa o que o Linux, Windows, Machintosh, Unix, BSD's [....] pode ou não fazer, o que tem ou não tem suporte para tanto, o que me interessa é o que eles podem fazer, se um patch resolve meu problema ótimo, se um Linux me atende ótimo, caso contrário existem outras soluções. > Para o SMTP eu concordo. Tente com o FTP ou um serviço genérico qualquer, > cujo formato interno você não conhece. Eu estou bem com o FTP obrigado. > Mas você teve de configurar uma regra extra (a do NAT) que não seria > necessária caso o servidor de SMTP tivesse um IP público. Em qual dos > dois casos é mais provável haver algum engano de configuração: com 0 ou 1 > regras? É muito relativo, o erro pode haver tanto com uma ou nenhuma regra, eu posso montar uma super regra de firewall e não configurar o servidor corretamente e vice versa. > Além disso, tenho que dizer é NAT é ruim para a Internet como um todo. O > ideal seria que ele não existisse e todo mundo tivesse os IPs dos quais > precisa. > > Com NAT, a conectividade global é quebrada porque nem todos os nós da rede > são acessíveis por todos os outros nós. Vamos colocar do ponto de vista do usuário então, já que NAT é tão ruim então é mais lógico para você fazer com que um escritório com 500 computadores todos tenham IP's válidos, para não quebrar a "conectividade global" mas quebrar o bolso de quem paga por isso não tem problema. Ou mesmo o usuário de internet que tem três computadores em casa, só para não quebrar a conectividade global o ideal tem que pagar três vezes mais só para ter IP's válidos nos seus computadores. Talvez com a padronização do IPV6 seu sonho se torne realidade ou um pesadelo, pelo que eu lí o seu julgamento vem de alguma frustação de configuração de servidores, pois NAT é ruim por causa do FTP H.323.... Concordo que NAT não é perfeito, assim como Linux não é e Windows/Machintosh/seu_OS_preferido_aqui também não então, procure aquilo que lhe atenda e forneça a solução que precisa. De: Thiago Macieira Para: Wellington Terumi Uemura Cc: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Sun, 13 Feb 2005 17:09:49 -0200 Wellington Terumi Uemura wrote: >> E qual é o problema em revelar alguns IPs privativos no meio? Faz >> alguma diferença? Não serão acessíveis e não têm nenhum serviço >> rodando. São apenas roteadores. > >Coloque seus servidores direto na internet então, dá o mesmo efeito. Com um firewall na frente, criando uma DMZ. >> Tem muito provedor por aí que faz isso. Não vejo problema algum. > >Sim, claro que tem, por isso veja o exemplo da telefônica que está >listada em tudo quanto é blacklist da internet e nem mesmo o Terra que >é da telefônica aceita emails da sua própria rede. O fato de usar IPs privativos não tem nada a ver com o fato de estar listada em blacklists. Isso é causado por spams. >> FTP é um exemplo. > >O problema do FTP já foi resolvido faz tempo. Mas é um exemplo de necessidade de carregar um módulo extra para resolver um problema que não existiria se o IP fosse público. >Entendo, mas o problema da sua proposta é colocar IP's válidos dentro >da rede e o mais importante, que estes IP's pertençam a você e >dependendo da quantidade de servidores internos estes não serão >suficientes. Sim. Eu assumi, na minha resposta, que o Carlos tinha o bloco de IPs. Se já tem os IPs, para que não usar? Novamente, a minha recomendação resume-se a: quando possível, coloque os IPs públicos nos servidores. Evite o NAT tanto quanto possível. É claro que existem casos em que isso não é possível. Aí o NAT é o quebra-galho que funciona -- mas não deixa de ser quebra-galho para o problema real de não ter os IPs. >> Você está numa situação em que um servidor atrás de NAT simplesmente >> não funciona. Se quiser um exemplo concreto, eu posso lhe dar um: >> H.323. Existe um patch para ele para os Netfilter, mas no kernel >> padrão do Linux, ele não é suportado. > >Já ví que seu problema se resume básicamente em FTP, temos dois Não. Eu quis ilustrar um problema maior. O caso do FTP está resolvido porque existe o ip_conntrack_ftp/ip_nat_ftp no kernel do Linux. O caso do H.323, você resolve com um proxy H.323 (mais um serviço rodando, mais memória e carga, maior latência, mais um ponto de vulnerabilidade). Eu quis ilustrar o problema de um protocolo genérico qualquer, principalmente no caso de conexões criptografadas. >> Mas você teve de configurar uma regra extra (a do NAT) que não seria >> necessária caso o servidor de SMTP tivesse um IP público. Em qual dos >> dois casos é mais provável haver algum engano de configuração: com 0 >> ou 1 regras? > >É muito relativo, o erro pode haver tanto com uma ou nenhuma regra, eu >posso montar uma super regra de firewall e não configurar o servidor >corretamente e vice versa. Isso eu tenho que concordar. >Vamos colocar do ponto de vista do usuário então, já que NAT é tão >ruim então é mais lógico para você fazer com que um escritório com 500 >computadores todos tenham IP's válidos, para não quebrar a >"conectividade global" mas quebrar o bolso de quem paga por isso não >tem problema. Isso mesmo. Como eu coloquei no fim da mensagem, estou falando do ponto de vista teórico. Num mundo ideal, todo mundo teria tantos IPs quantos precisasse. Infelizmente não é a realidade. E justamente porque não é a realidade é que surgiu o NAT. Como disse acima, NAT é um quebra-galho para o problema real, da falta de IP. >Ou mesmo o usuário de internet que tem três computadores em casa, só >para não quebrar a conectividade global o ideal tem que pagar três >vezes mais só para ter IP's válidos nos seus computadores. Idealmente, ele não pagaria nada a mais por isso. Ter 1, 50 ou 1000 IPs deveria custar exatamente a mesma coisa. Essa é uma das propostas do IPv6. Propõe-se as seguintes alocações para usuários finais: - /128: quando se sabe com certeza absoluta que 1, e apenas 1 IP será necessário. - /64: quando se sabe com certeza que o usuário terá apenas 1 única rede. O total de IPs alocados é de 18.446.744.073.709.551.616. - /48: alocação padrão. São 65.536 redes de 18.446.744.073.709.551.616 IPs (ou 1.208.925.819.614.629.174.706.176 IPs). Provedores devem procurar alocações maiores, começando em /35 (ou 8192 alocações /48). Deixe-me repetir mais uma vez: se você tem os IPs, use-os. -- Thiago Macieira - thiago (AT) macieira (DOT) info PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 3. Ac seo woruld wearð geborod, swá se Scieppend cweað "Gewurde Unix" and wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung. De: Jorge Luiz Godoy Filho Para: linux-br@bazar2.conectiva.com.br Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Sun, 13 Feb 2005 20:50:47 -0200 Em Dom 13 Fev 2005 17:09, Thiago Macieira escreveu: > Wellington Terumi Uemura wrote: > >Ou mesmo o usuário de internet que tem três computadores em casa, só > >para não quebrar a conectividade global o ideal tem que pagar três > >vezes mais só para ter IP's válidos nos seus computadores. > > Idealmente, ele não pagaria nada a mais por isso. Ter 1, 50 ou 1000 IPs > deveria custar exatamente a mesma coisa. Na verdade não deveria. O caso do usuário doméstico tem o contrato assinado com a operadora... Algumas restringem o número de máquinas que poderiam conectar-se à Internet. Violar este número é uma quebra de contrato, mesmo com um único gateway. Se ele precisa de mais acessibilidade, ele deve contratar a acessibilidade necessária. -- Godoy. De: Jorge Luiz Godoy Filho Para: linux-br@bazar2.conectiva.com.br, Wellington Terumi Uemura Assunto: Re: (linux-br) Firewall entre roteador e dois servidores com ips verdadeiros Data: Sun, 13 Feb 2005 20:46:20 -0200 Em Dom 13 Fev 2005 15:37, Wellington Terumi Uemura escreveu: > > Todo IP (v4) é roteável, exceto os inválidos, tais como 0.0.0.0 ou > > 255.255.255.255. Até mesmo o 127.0.0.1 é roteável e roteado. > > Você entendeu o que quiz dizer. Ele estava apenas corrigindo a nomenclatura... > > E qual é o problema em revelar alguns IPs privativos no meio? Faz alguma > > diferença? Não serão acessíveis e não têm nenhum serviço rodando. São > > apenas roteadores. > > Coloque seus servidores direto na internet então, dá o mesmo efeito. Pelo contrário. Colocá-los em uma DMZ dá a garantia de que apenas os serviços autorizados trafegarão. Colocando-os diretamente expostos a todos na Internet forçaria a configuração de proteções adicionais e impediria diversas regras de proteção. Você teria, por exemplo, que configurar cada máquina para permitir ou negar a conexão via SSH. Em uma DMZ você permite a conexão e restringe a entrada de conexões diretamente no firewall, permitindo que todos da rede interna acessem as máquinas -- ou a faixa liberada no firewall -- e negando o acesso público. Isso para mostrar a diferença em apenas um dos serviços. > > Tem muito provedor por aí que faz isso. Não vejo problema algum. > > Sim, claro que tem, por isso veja o exemplo da telefônica que está > listada em tudo quanto é blacklist da internet e nem mesmo o Terra que > é da telefônica aceita emails da sua própria rede. Se esta fosse uma lista de engenharia de redes, poderíamos discutir mais sobre o assunto. O pessoal da GT-ER "adora" essas coisas. > Entendo, mas o problema da sua proposta é colocar IP's válidos dentro > da rede e o mais importante, que estes IP's pertençam a você e > dependendo da quantidade de servidores internos estes não serão > suficientes. Não é *dentro* da rede. É na *DMZ*. São três redes distintas, quando você cria uma DMZ: - Internet - intranet - DMZ Ninguém "entra" na intranet, nem mesmo a DMZ. Todos saem -- controlada ou livremente -- para a Internet. Apenas tráfego para determinados serviços entra na DMZ, independente da origem (costuma-se ter mais liberdade para tráfego originado na intranet). > Já ví que seu problema se resume básicamente em FTP, temos dois O exemplo dado foi com H.323, usado em VoIP (entre outros). Já são dois protocolos. Se você considerar as tecnologias mais leves e recentes, como SIP, já são três. Adicione a isto P2P, IRC, etc. que você começa a ter uma quantidade grande de protocolos a tratar. > H.323, SIP... tem mais algum que gostaria de de informar?? > Talvez você não tenha visto ainda o site > http://openh323proxy.sourceforge.net/ mas sem problemas... Mais um serviço rodando no firewall, ou seja, mais uma fonte de vulnerabilidades em potencial... O firewall ideal é firewall. Só. Não é proxy, não é servidor de email, não é servidor VPN, não é servidor de nada. Ao violar isto, você começa a adicionar pontos de falha e a tornar a rede mais vulnerável. > Não me interessa o que o Linux, Windows, Machintosh, Unix, BSD's > [....] pode ou não fazer, o que tem ou não tem suporte para tanto, o > que me interessa é o que eles podem fazer, se um patch resolve meu > problema ótimo, se um Linux me atende ótimo, caso contrário existem > outras soluções. Concordo plena e completamente. Mas, um remendo -- patch -- já começa com a preocupação do nome... E, além disso, há a fuga do conceito de firewall. > É muito relativo, o erro pode haver tanto com uma ou nenhuma regra, eu > posso montar uma super regra de firewall e não configurar o servidor > corretamente e vice versa. Você pode não configurar o servidor corretamente com DMZ, sem DMZ, com firewall e sem firewall. Esta é uma constante. Você adiciona, então, uma segunda camada de falhas: as regras no firewall. > Vamos colocar do ponto de vista do usuário então, já que NAT é tão > ruim então é mais lógico para você fazer com que um escritório com 500 > computadores todos tenham IP's válidos, para não quebrar a > "conectividade global" mas quebrar o bolso de quem paga por isso não > tem problema. O uso de IPv6 ainda não é tão difundido, mas eu tinha uma rede /48. Sem custos. Tinha um IP para cada formiga daqui de casa, para todos os computadores, e ainda sobravam IPs. A densidade de IPs por metro quadrado é bem maior que a densidade de máquinas que você consegue colocar e utilizar ali. > Ou mesmo o usuário de internet que tem três computadores em casa, só > para não quebrar a conectividade global o ideal tem que pagar três > vezes mais só para ter IP's válidos nos seus computadores. Ou usar IPv6. Pode até usar um gateway IPv6 -> IPv4, mas assim ele reduz a sua conectividade também... Eu, como já disse, não concordo com a abolição de NAT como prega o Thiago, mas também entendo muito bem os motivos que ele alega. No final, o engenheiro que projeta a rede deve decidir o modo como será feita a mesma. E ele deve justificar e apresentar as soluções para os problemas. Com as soluções, procura-se o software ou hardware que as implemente. Sds, -- Godoy. ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** ***************************************************** *****************************************************