Firewalling and Proxy Server HOWTO

Mark Grennan, markg@netplus.net,
V0.4, 8 de novembro de 1996
Traduzido por: Bruno H. Collovini - buick@microlink.com.br
Tradução 17 de Julho de 1997.

Aviso: Este tradução não está relacionada com o projeto de documentação para o Linux (LDP) que no Brasil é representada pela LDP-BR em <http://www.dca.fee.unicamp.br/~malheiro/linux/LDP-br.html>, este material é uma tradução técnica e básica somente para auxiliar os colegas com a leitura em português.

Outros documentos você pode obter em: <http://www.microlink.com.br/~buick/>

Este documento é projetado para ensinar os fundamentos de sistemas de firewall e lhe dar algum detalhe em como montar um filtro e um proxy firewall no Linux baseado em PC. Uma versão deste documento em HTML está disponível em <http://okcforum.org/~markg/Firewall-HOWTO.html>

1. Introdução

O Firewall-HOWTO original foi escrito por David Rudder, drig@execpc.com. Eu gostaria de agradecer-lhe por permitir a atualização do seu trabalho.

Os Firewalls ganharam grande fama últimamente com a Segurança para a Internet. Como a maioria das coisas que ganham fama, com a fama veio uma péssima divulgação. Este HOWTO revisará os fundamentos do que é um firewall, e o que é um servidor proxy, como configurar um servidor proxy, e as aplicações desta tecnologia fora da segurança real.

1.1. Realimentação

Qualquer realimentação é muito bem-vinda. POR FAVOR INFORME QUALQUER INEXATIDÃO NESTE DOCUMENTO!!! Eu sou humano, e propenso a cometer enganos. Se você achar qualquer erro, e os corrigir é do meu maior interesse. Eu tentarei responder há todos e-mails, mas eu estou ocupado, assim não se sinta insultado se eu não responder.

Meu endereço de email é <markg@netplus.net>

1.2. Retratação

EU NÃO RESPONSABELIZO-ME POR QUALQUER DANO OCORRIDO DEVIDO A AÇÕES BASEADAS NESTE DOCUMENTO. Este documento é como uma introdução para trabalhar com firewalls e servidores proxy. Eu não sou, e nem pretendo ser um perito em segurança. Eu sou um simples sujeito que leu muito e que gosta de computadores mais do que a maioria das pessoas. Por favor, eu estou escrevendo isto para pessoas que peçam help em subject, e Eu não irei ler aposto a minha vida na precisão do que está aqui.

1.3. Direitos autorais A menos que seja contrário, Os documentos HOWTO do Linux são registrados pelos proprios autores respectivos. Os documentos HOWTO do Linux podem ser reproduzidos e distribuído em todo ou em parte, em qualquer meio físico ou eletrônico, contanto que esta advertência de direitos autorais seja mantida em todas as cópias. A redistribuição comercial é permitido e é encorajada; porém, o autor iria gostar de ser notificado de qualquer forma de distribuição.

Todas as traduções, trabalhos derivados, ou trabalhos incorporando agregados a qualquer Linux devem ser informados nos documentos de HOWTO debaixo desta advertência de direito autorais.

Quer dizer, você pode não produzir um trabalho derivado de um HOWTO e pode impor restrições adicionais em sua distribuição. Exceções para estas regras pode ser concedido debaixo de certas condições; por favor contate o Coordenador de HOWTo para o Linux.

Em resumo, nós desejamos promover a disseminação desta informação por tantos canais quanto possível. Porém, nós desejamos reter os direito autorais nos documentos de HOWTO, e gostaria-mos de ser notificado de qualquer plano para redistribuição dos HOWTOs.

Se você tem qualquer pergunta, por favor contacte Mark Grennan em .

1.4. Minhas Razões por Escrever

Embora houvesse muitas discussões em comp.os.linux.* em cima do último ano sobre firewalling, eu achei difícil achar informações da qual eu precisava para o setup do firewall. A versão original deste HOWTO era útil mas ainda faltava muito. Eu espero que esta versão do HOWTO Firewall de David Rudder de a todo mundo informação que elas precisam para criar um firewall em horas, não em semanas.

Eu também sintia que devia devolver algo à comunidade do Linux.

1.5. TODO

· Algumas instruções para configuração de clientes

· Achando um servidor de Proxy UDP bom que trabalhe com o Linux

1.6. Mais Leituras adiante

· O NET-2 HOWTO

· O Ethernet HOWTO

· O Multiple Ethernet Mini HOWTO

· Networking with Linux

· O PPP HOWTO

· o Guia de TCP/IP Network Administrator's por O'Reilly and Associates

· A Documentação para o TIS Firewall Toolkit

O Sistema confiado em Informação (TIS) no web sites tem uma coleção grande de documentação de firewalls e material relacionado. http://www.tis.com/ Também, estou trabalhando num projeto de segurança que estou chamando de Linux Secure. No Web site do Linux Secure estou juntando todas as informações, documentações e programas que você precisa para criar um Sistema de Linux confiável. Envie-me email se você gosta deste tipo de informação.

2. Compreendendo Firewalls

Um firewall é um termo usado para uma parte do carro. Em carros, os firewalls são objetos físicos que separam a máquina dos passageiros. O significado deles é proteger o passageiro no caso de fogo no motor do carro enquanto ainda o motorista têm acesso aos controles do carro.

Um firewall em computadores é um dispositivo que protege uma network privada da parte pública (ou internet como um todo).
O computador de firewall, firewall "de agora em diante chamado", pode alcançar ambas network protegida e a internet. A network protegida não pode alcançar a internet, e a internet não pode alcançar os protegidos desta network.

Para alguém alcançar a internet de dentro da network protegida, deve dar um telnet para o firewall, e usar a internet de lá.

A forma mais simples de um firewall é um sistema de homed-dual. (um sistema com duas conexões de network) Se você pode CONFIAR EM TODOS os seus usuários, você pode simplesmente configurar o Linux (compile com forwarding/gatewaying de IP DESLIGADO!) e todo o mundo ira acessar. Eles poderão usar o login neste sistema através de telnet, usar o FTP, ler email, e usa qualquer outro serviço com que você conta. Com esta configuração, o único computador em sua network privada saberá qualquer coisa sobre o mundo externo é o firewall. O outro sistema em sua network protegida precisa de uma rota default.

Isto precisa de redeclarações. Para o firewall acima trabalhar VOCÊ TÊM QUE CONFIAR EM TODOS OS SEUS USUÁRIOS! Eu não recomendo isto.

2.1. Desvantagens com os Firewalls

O problema com a filtração de firewalls é dele inibir o acesso a sua network através da internet. Só serviços do sistema que tem acesso a filtros de passagem o poderão. Como alguns usuários do servidor de proxy acessão o login no firewall e então acessãor qualquer parte de sua network privada.

Também, alguns tipos novos de clientes de network que acessam diariamente. Quando eles querem você tem que achar um modo novo para permitir o acesso de controle antes de que estes serviços possam ser usados.

2.2. Tipos de Firewalls

Há dois tipos de firewalls.

  1. IP ou Filtro de Firewalls - aquele bloco todo menos a network selecionada no tráfico.

  2. Servidores de proxy - faz as conexões da network para você.

2.2.1. Filtrando IP em Firewalls

Um firewall que filtra trabalhos de IP ao nível de pacote. É projetado para o controle do fluxo de pacotes baseado no destino, porta e informação do tipo de pacote que contem em cada pacote.

Este tipo de firewall é muito seguro mas falta utilidades. Pode bloquear as pessoas de ter acesso ao sistema privado mas vai vetar o acesso a seus sistemas públicos ou a quem tem acesso do interior.

Filtros para firewalls são filtros absolutos. Até mesmo se você quer que alguém acesse de fora os seus servidores privados você não pode sem dar para todo o mundo o acesso para os servidores.

O Linux incluiu um pacote de software que filtra software no kernel começando com a versão 1.3.x.

2.2.2. Servidores de proxy

Servidores de proxy permitem o acesso há internet indiretamente pelo acesso ao firewall. O melhor exemplo de como trabalha é um telnet a um sistema e então um telnet de lá para outro. Só com um servidor de proxy o processo é automático. Quando você conecta a um servidor de proxy com o seu software de cliente, o servidor de proxy começa e o software cliente (proxy) passa os dados para você.

Servidores de proxy duplicam todas as comunicações que eles podem fazer e anota tudo o que fazemos.

A grande coisa sobre servidores de proxy é que eles são completamente seguros, quando configurados corretamente. Eles não permitem acessa-lo. Não há uma rota de IP direto.

3. Configurando um Firewall

3.1. Exigências de hardware

Para o nosso exemplo, o computador é um 486-DX66 com 16 meg de memória e uns 500 meg de partição para o Linux. Este sistema tem duas placas de rede uma conectada a nossa LAN privada e a outra conectada a uma LAN chamada de zona desmilitarizada (DMZ). O DMZ tem um roteador conectado a uma conexão para a internet.

Esta é uma configuração basica para um negócio. Você poderia usar uma placa de rede e um modem com PPP para a internet. O ponto é, o firewall têm que ter dois números de IP na network.

Eu sei que muitas pessoas têm LANs pequenas em casa com dois ou três computadores. Algo que você poderia considerar era por todos os seus modems num Linux encaixotado (talvez num velho 386) e conectando todos eles para a internet com balanceamento de linha. Com esta configuração quando uma única pessoa pede dados os modems dobram o processamento :-)

4. Software de Firewalling

4.1. Pacotes disponíveis

Se tudo o que você deseja é um filtro de firewall, você só precisa do Linux e do pacotes básicos de networking. Um pacote com o que poderia não vir na sua distribuição é a Ferramente de Administração de IP Firewall.

(IPFWADM) Vem de <http://www.xos.nl/linux/ipfwadm/>

Se você quer configurar um servidor de proxy você precisará destes pacotes.

  1. SOCKS

  2. TIS Firewall Toolkit (FWTK)

4.2. O TIS Firewall Toolkit vs SOCKS

O Sistema confiado em Informação (http://www.tis.com) publicou uma coleção de programas projetados para a facilitação de firewalling. Os programas fazem a mesma coisa basica que os pacotes de SOCKS, mas com uma estratégia diferente. Onde os SOCKS têm um programa que cobre todas as transações da internet, o TIS tem um programa para cada utilidade que deseja usar o firewall.

Para contrastar os dois, usaremos o exemplo para world wide web e de acesso por Telnet. Com o SOCKS, você monta um arquivo de configuração e um daemon. Por este arquivo de daemon, telnet e WWW são habilitados, como também qualquer outro serviço que você não incapacitou.

Com o toolkit de TIS, você monta um daemon para cada WWW e telnet, como também configura cada arquivo. Depois que você fizer isto, outro acesso de internet ainda é proibido explicitamente até que seja configurado. Se um daemon para uma utilidade específica não foi configurado (como o talk), há um daemon "plug-in", mas não é flexível, nem fácil de configurar, como as outras ferramentas.

Isto poderia parecer secundário, mas faz uma grande diferença. O SOCKS permite que você use algo malfeito. Como uma configuração pobre para o servidor de SOCKS, alguém de dentro poderia ganhar mais acesso para a internet que era originalmente pretendido. Com o toolkit da TIS, tanto o lado de dentro como o de fora somente as pessoas que o administrador permiti o acesso irão os ter.

SOCKS são mais fáceis de montar, mais fácil de compilar e permitem uma maior flexibilidade. O toolkit da TIS está mais seguro se você quer regular os usuários de dentro da sua network protegida. Ambos provêem absoluta proteção do exterior.

Eu cobrirei a instalação e a configuração de ambos.

5. Preparando o sistema do Linux

5.1. Compilando o Kernel

Comece com uma instalação nova de sua distribuição de Linux. (Eu usei RedHat 3.0.3 e os exemplos aqui estão baseado nesta distribuição.)

Menos os software que você carregou para o seu sistema, e/ou os bugs de backdoors que podem introduzir problemas de segurança em seu sistema, assim carregue só um conjunto mínimo de aplicações.

Escolha um kernel estável. Eu usei o Kernel 2.0.14 do Linux para o meu sistema.

Assim esta documentação está baseado nestas condições.

Você precisa recompilar o kernel do Linux com as opções necessárias. Neste momento, você deveria ler o HOWTO KERNEL, o HOWTO Ethernet e o HOWTO NET-2 se você não o fez isto antes.

Aqui está o relatório que você precisa configurar para a network Eu vou usar o 'make config'

1. Debaixo da configuração Geral
   a. Turn Networking Support ON

2. Debaixo das Opções de Networking
   a. Turn Network firewalls ON
   b. Turn TCP/IP Networking ON
   c. Turn IP forwarding/gatewaying OFF (A MENOS QUE você deseje usar filtro de IP)
   d. Turn IP Firewalling ON
   e. Turn IP firewall packet loggin ON (isto não é requerido mas é uma idéia boa)
   f. Turn IP: masquerading OFF (eu não estou cobrindo este assunto aqui.)
   g. Turn IP: accounting ON
   h. Turn IP: tunneling OFF
   i. Turn IP: aliasing OFF
   j. Turn IP: PC/TCP compatibility mode OFF
   k. Turn IP: Reverse ARP OFF
   l. Turn Drop source routed frames ON

3. Debaixo do suporte para device de network
   a. Turn Network device support ON
   b. Turn Dummy net driver support ON
   c. Turn Ethernet (10 or 100Mbit) ON
   d. Selecione a sua placa de rede

Agora você deve recompilar, reinstalar o kernel e reiniciar. Sua placa de rede devem mostrar as informações caso o seu boot tenha ocorrido com sucesso. Se não, revise os outros HOWTOs novamente até que esteja funcionando.

5.2. Configurando duas placas de redes

Se você tem duas placas de rede no seu computador, você provável irá precisar colocar uma declaração no append no seu arquivo de /etc/lilo.conf para reconhecimento do IRQ e endereço de ambas placas de rede. No meu lilo anexei a seguinte declaração:

append="ether=12,0x300,eth0 ether=15,0x340,eth1"

5.3. Configurando os Endereços da rede

Esta é a parte realmente interessante. Agora você tem algumas decisões para fazer. Desde que nós não queremos a internet para ter acesso a qualquer parte da nossa network privada, nós não precisamos usar endereços reais. Há vários endereços de internet definidos aparte para networks privadas. Porque todo mundo precisa demais endereços e porque estes endereços não podem cruzar a Internet eles são uma ótima escolha.

Destes, 192.168.2.xxx, serão configurados e nós os usaremos em nossos exemplos.

Seu firewall de proxy será um sócio de networks e assim pode passar os dados por ele para a network privada.


              199.1.2.10   __________    192.168.2.1
        _  __  _        \ |          | /           _______________
       | \/  \/ |        \| Sistema  |/           |               |
      / Internet \--------| Firewall |------------| Workstation/s |
      \_/\_/\_/\_/        |__________|            |_______________|
   
Se você for usar um flitro de firewall você ainda podm usar estes números. Você precisará usar IP mascarading para fazer isto funcionar.

Com este processo o firewall remeterá os pacotes e os traduzira num IP "REAL" para dirigir-se então para a Internet.

Você tem que nomear o IP real para a placa de rede da network do lado da Internet (fora). E, nomear 192.168.2.1 para a placa de rede do lado de dentro. Este será o seu endereço de IP do proxy/gateway. Você pode nomear todas as outras máquinas na network protegida com algum número do alcance de 192.168.2.xxx. (192.168.2.2 até 192.168.2.254)

Desde que eu uso o Linux RedHat (Ei sujeitos, queiram me dar uma cópia de plugs? ;-) para configurar a network no momento do boot eu somei um arquivo 'ifcfg-eth1' no diretório de /etc/sysconfig/network-scripts. Este arquivo é lido durante o processo de boot para configurar a sua network e a tabela de rotas. Aqui esta o meu ifcfg-eth1 olhe ele;

      #!/bin/sh
      #>>>Device type: ethernet
      #>>>Variable declarations:
      DEVICE=eth1
      IPADDR=192.168.2.1
      NETMASK=255.255.255.0
      NETWORK=192.168.2.0
      BROADCAST=192.168.2.255
      GATEWAY=199.1.2.10
      ONBOOT=yes
      #>>>End variable declarations
Você também pode usar este script para conectar automaticamente através de um modem o seu provedor. Olhe o script ipup-ppp.

Se você vai usar um modem para a sua conexão com a internet o seu endereço de IP de fora será nomeado pelo seu provedor ao se conectar-se.

5.4. Testando a sua network

Comece conferindo o ifconfig e o route. Se você tem duas placas de network seu ifconfig deve parecer-se com algo assim:

    #ifconfig
    lo        Link encap:Local Loopback
              inet addr:127.0.0.0  Bcast:127.255.255.255  Mask:255.0.0.0
              UP BROADCAST LOOPBACK RUNNING  MTU:3584  Metric:1
              RX packets:1620 errors:0 dropped:0 overruns:0
              TX packets:1620 errors:0 dropped:0 overruns:0

    eth0      Link encap:10Mbps Ethernet  HWaddr 00:00:09:85:AC:55
              inet addr:199.1.2.10 Bcast:199.1.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0
              TX packets:0 errors:0 dropped:0 overruns:0
              Interrupt:12 Base address:0x310

    eth1      Link encap:10Mbps Ethernet  HWaddr 00:00:09:80:1E:D7
              inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:0 errors:0 dropped:0 overruns:0
              TX packets:0 errors:0 dropped:0 overruns:0
              Interrupt:15 Base address:0x350
e sua tabela de rotas deve ser assim:
    #route -n
    Kernel routing table
    Destination     Gateway         Genmask         Flags MSS    Window Use Iface
    199.1.2.0       *               255.255.255.0   U     1500   0       15 eth0
    192.168.2.0     *               255.255.255.0   U     1500   0        0 eth1
    127.0.0.0       *               255.0.0.0       U     3584   0        2 lo
    default         199.1.2.10      *               UG    1500   0       72 eth0
Nota: 199.1.2.0 é o lado de Internet deste firewall e 192.168.2.0 é o lado privado. Agora tente pingar a internet do firewall. Eu usava nic.ddn.mil como meu ponto de teste. Ainda é um bom teste, mas provou ser menos fidedigno do que eu tinha esperado. Se não funcionar no princípio, tente pingar outros lugares que não são conectados a sua LAN. Se isto não funcionar, então a sua configuração de PPP esta incorreta. Re-leia o HOWTO Net-2, e tente novamente.

Logo, tente pingar um host de dentro da network protegida do firewall. Todos os computadores devem ser capazes de pingar um ao outro. Se não, revise o HOWTO NET-2 novamente e trabalhe na network um pouco mais.

Então, tente o ping no endereço externo de firewall de dentro da network protegida. (NOTA: isto é nem todos os números IP 192.168.2.xxx.) Se você pode, então você não desligou o IP Forwarding. Tenha certeza que este é o modo que você quer. Se você deixou ligado você deve passar pela seção de Filtração de IP desde documento.

Agora tente pingar a internet por detrás do seu firewall. Use o mesmo endereço antes que usamos. (I.E. nic.ddn.mil) Novamente, se você tem o IP Forwarding desligado, isto não deve acontecer. Mas, se você tem o IP Forwarding, deve ocorrer.

Se o IP Forwarding estiver ligago e você estiver usando o endereço do IP "REAL" (não o 192.168.2.*) para a sua network privada, e você não puder pingar para a internet mas você puder pingar da internet ao seu firewall, cheque, se o seu sistema de roteamento não está removendo os pacotes do seu endereço da network privada. (Seu provedor pode ter que fazer isto para você).

Se você criou a sua network protegida em 192.168.2.*, então não podem ser removidos os pacotes de qualquer maneira. Se você saltou à frente e você já tem IP masquerading ligado, este teste deve funcionar.

Agora, você tem a sua configuração básica do sistema.

5.5. Segurança no Firewall

O firewall não é muito bom se permanecer aberto a ataques por um serviço novo. Um "sujeito" ruim poderia ganhar acesso para o firewall e modificar para as suas próprias necessidades.

Comece desligando qualquer serviço desnecessário. Olhe o arquivo /etc/inetd.conf. Este arquivo controla o que é chamado de "super servidor" super. Estes controles são um grupo de daemons do servidor e os começa quando eles são pedidos.

Definitivamente desligue o netstat, systat, tftp, bootp, e o finger. Para desligar um serviço, ponha # como o primeiro caráter da linha do serviço. Quando acabado, envie um SIG-HUP ao processo digitando "kill -HUP <pid>", onde <pid> é o número de processo do inetd. Isto fará com que o inetd releia o seu arquivo de configuração (inetd.conf) e reinicia-lo.

Teste através do telnet a porta 15 do firewall, a porta do netstat. Se você acessar a saida do netstat, você não reiniou corretamente.

6. Configuração do filtro para IP (IPFWADM)

Para começar, você deveria ter o IP Forwarding ligado no seu kernel e o seu sistema deve ser reinicado e remetendo sempre o IP. Sua tabela de rotas deve apresentar os lugares e você deve ter acesso a tudo, ambos atráves da saida e pela entrada.

Mas, nós estamos construindo um firewall e assim nós precisamos começar desligado para que todo o mundo tem acesso.

No meu sistema eu criei várias scripts para configurar o firewall policiando o forwarding e contando o policiamento. Eu chamo os scripts dentro do /etc/rc.d assim o meu sistema é configurado no momento do boot.

Através do default do IP Forwarding o sistema no kernel do Linux remete tudo. Por causa disto, seu script de firewall deve começar negando acesso para tudo e enxaguando qualquer registro de da ultima vez que você redou. Este script fará este truque.

    #
    # setup para pacote IP Accounting and Forwarding
    #
    #   Remetendo(Forwarding)
    #
    # O default é negando todos os serviços
    ipfwadm -F -p deny
    # Flush all commands
    ipfwadm -F -f
    ipfwadm -I -f
    ipfwadm -O -f
Agora nós temos o último firewall. Nothing can get through. Você não deve ter alguma dúvida sobre os serviços que você precisa remeter estão aqui alguns exemplos que devem ser úteis.

    # Forward email para o seu servidor
    ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 192.1.2.10 25

    # Forward email de conexões para a saída do servidor de email
    ipfwadm -F -a accept -b -P tcp -S 196.1.2.10 25 -D 0.0.0.0/0 1024:65535

    # Forward Web de conexões do seu Servidor de Web
    /sbin/ipfwadm -F -a accept -b -P tcp -S 0.0.0.0/0 1024:65535 -D 196.1.2.11 80

    # Forward Web de conexões para a saída do seu Servidor de Web
    /sbin/ipfwadm -F -a accept -b -P tcp -S 196.1.2.* 80 -D 0.0.0.0/0 1024:65535

    # Forward Trafico do DNS
    /sbin/ipfwadm -F -a accept -b -P udp -S 0.0.0.0/0 53 -D 196.1.2.0/24
Você também poderia se interessar pela resposta do tráfico que vai para o seu firewall. Este script conta os pacote. Você pode somar uma linha ou responder por pacotes que vão para um único sistema.

    # Flush the current accounting rules
    ipfwadm -A -f
    # Considerando os Accounting
    /sbin/ipfwadm -A -f
    /sbin/ipfwadm -A out -i -S 196.1.2.0/24 -D 0.0.0.0/0
    /sbin/ipfwadm -A out -i -S 0.0.0.0/0 -D 196.1.2.0/24
    /sbin/ipfwadm -A in -i -S 196.1.2.0/24 -D 0.0.0.0/0
    /sbin/ipfwadm -A in -i -S 0.0.0.0/0 -D 196.1.2.0/24
Se tudo o que você quis era um filtro para o firewall você pode parar aqui. Desfrute :-)

7. Instalando o Servidor de Proxy TIS

7.1. Buscando o software

O TIS FWTK se encontra em ftp://ftp.tis.com/.

Não cometa o mesmo engano que eu fiz. Quando você esta nos arquivos de ftp do TIS, LEIA OS README's. O fwtk do TIS é colocado em diretório escondido no servidor deles.

TIS requer que você envie um email para fwtk-request@tis.com com a palavra SEND no corpo da mensagem para saber o nome do diretório escondido. Não é necessário nenhum assunto na mensagem. O sistema deles verá a correspondência e então você receberá o nome do diretório (bom durante 12 horas) para baixar o arquivo.

Enquanto eu estou escrevendo o TIS está lançando a versão 2.0 (beta) do FWTK.

Esta versão parece compilar bem (com alguns exceções) e tudo está funcionando para o meu uso. Esta é a versão que eu estarei cobrindo aqui. Quando eles lançar o código final eu atualizarei o HOWTO.

Instale o FWTK, crie um diretório fwtk-2.0 no seu diretório /usr/src. Mova a sua cópia do FWTK (fwtk-2.0.tar.gz) para este diretório e descompacta ele (tar -zxf fwtk-2.0.tar.gz).

O FWTK não faz proxy SSL de documentos Web mas há um complemento para isto escrito por Jean-Christophe Touvet. É encontra-se no ftp://ftp.edelweb.fr/pub/contrib/fwtk/ssl-gw.tar.Z. Touvet não faz apóio sobre o código.

Eu estou usando uma versão modificada que inclui acesso para o Secure Netscape e o servidores de notícias escritos por Eric Wedel. Está disponível em

ftp://mdi.meridian-data.com/pub/tis.fwtk/ssl-gw/ssl-gw2.tar.Z.

Em nosso exemplo eu usarei a versão do Eric Wedel.

Instale ele, simplesmente crie um diretório de ssl-gw em seu diretório /usr/src/fwtk-2.0 e o ponha lá.

Quando eu instalei este gateway ele requeriu algumas mudanças antes de compilar com o resto do toolkit.

A primeira mudança era ao arquivo de ssl-gw.c. Eu achei que não precisava incluir este arquivo.

    Defined(__linux de #if)
    #include        <sys/ioctl.h>
    #endif
Segundo é que não veio com um Makefile. Eu copiei um outro do diretório do gateway e substitui o nome do gateway por ssl-gw.

7.2. Compilando o TIS FWTK

Versão 2.0 do FWTK compilou fácil em relação as mais velhas versões. Eu ainda achei várias coisas que precisaram ser mudadas antes de que a versão BETA compilace completamente. Espero ansiomente estas mudanças sejam feitas na versão final.

Arrume ele, comece mudando o diretório de /usr/src/fwtk/fwtk contido no arquivo Makefile.config.linux em cima do arquivo Makefile.config NÃO RODE o FIXMAKE. As instruções lhe dizem que o execute. Se você o faz o arquivo makefile quebra em relação a cada diretório.

Eu tive uma dificuldade com o fixmake. O problema é o script do sed adicione um '.' e '' para a linha que contem o Makefile. Estes é o trabalho no script do sed.

      sed 's/^include[        ]*\([^  ].*\)/include \1/' $name .proto > $name
Logo nós precisamos editar o arquivo de Makefile.config. Há duas mudanças que você pode precisar fazer.

O autor fixou o diretório de fonte para o diretório home dele. Nós iremos compilar o nosso código em /usr/src assim você deve mudar a variável FWTKSRCDIR para refletir isto.

    FWTKSRCDIR=/usr/src/fwtk/fwtk
Segundo, pelo menos alguns sistema do Linux o banco de dados de gdbm. O Makefile.config está usando dbm. Você pode precisar mudar isto. Eu tive que fazer para RedHat 3.0.3.

    DBMLIB=-lgdbm
A última dificuldade está no x-gw. O bug na versão BETA é no código do socket.c. Configure isto removendo estas linhas de código.

    #ifdef SCM_RIGHTS  /* 4.3BSD Reno and later */
                         + sizeof(un_name->sun_len) + 1
    #endif
Se você somar o ssl-gw ao seu fonte FWTK no diretório que você precisa some na lista de diretório no Makefile.

      DIRS=   smap smapd netacl plug-gw ftp-gw tn-gw rlogin-gw http-gw x-gw ssl-gw
Agora rode-o.

7.3. Instalando o TIS FWTK

Rode o make install.

O diretório de instalação default é /usr/local/etc. Você pode mudar isto (eu não o fiz) para um diretório mais seguro. Eu escolhi mudar o acesso a este diretório para 'chmod 700'.

Depois agora resta é configurar o firewall.

7.4. Configurando o TIS FWTK

Agora é que realmente começa a diversão. Nós temos que ensinar o sistema a chamar os novos serviços e criar uma tabela de controles.

Eu não vou tentar ré-escrever o manual do TIS FWTK aqui. Eu mostrarei a você a colocação de como estou trabalhado e explico os problemas que ocorreram quando eu fui rodar eles.

Há três arquivos que compõem estes controles.

· /etc/services

· Chama um serviço para a porta do sistema aberta.

· /etc/inetd.conf

· Chama o programa inetd que define quando alguém bate em uma porta de serviço.

· /usr/local/etc/netperm-table

· Chama os serviços de FWTK que permitir e negam os serviços.

Para chamar as funções do FWTK, você precisa edita os arquivos acima. Editando os arquivos de serviços sem o arquivo inetd.conf ou netperm-table configurados corretamente o seu sistema pode ficar inacessível.

7.4.1. O arquivo de netperm-table

Estes controles do arquivo podem ter acesso aos serviços do TIS FWTK. Você deva pensar no tráfico que é usar o firewall de ambos os lados.

Pessoas de fora da sua network deveriam se identificar antes de ganhar acesso, mas as pessoas de dentro de sua network poucos poderiam ser permitidos.

Assim as pessoas podem se identificar, o firewall usa um programa chamado authsrv para manter um banco de dados de IDs do usuário IDs e a password. A seção de autenticação do netperm-table controla onde o banco de dados é mantem quem pode ter acesso.

Eu tive alguma dificuldade de fechar o acesso para este serviço. Note a linha premit-host Eu usei um '*' para dar ha todo mundo acesso. A colocação correta para esta linha é '' authsrv: localhost de premit-host localhost se você quer trabalhar com isto.

    #
    # Proxy configuration table
    #
    # Authentication server and client rules
    authsrv:      database /usr/local/etc/fw-authdb
    authsrv:      permit-hosts *
    authsrv:      badsleep 1200
    authsrv:      nobogus true
    # Client Applications using the Authentication server
    *:            authserver 127.0.0.1 114
Inicializar o banco de dados, su para o root, e executar ./authsrv no Diretório do /var/local/etc para criar o registro de usuário administrativo. Aqui é uma sessão de amostra.

Leia a documentação de FWTK para aprender a somar os usuários e grupos.

      #
      # authsrv
      authsrv# list
      authsrv# adduser admin "Auth DB admin"
      ok - user added initially disabled
      authsrv# ena admin
      enabled
      authsrv# proto admin pass
      changed
      authsrv# pass admin "plugh"
      Password changed.
      authsrv# superwiz admin
      set wizard
      authsrv# list
      Report for users in database
      user   group  longname           ok?    proto   last
      ------ ------ ------------------ -----  ------  -----
      admin         Auth DB admin      ena    passw   never
      authsrv# display admin
      Report for user admin (Auth DB admin)
      Authentication protocol: password
      Flags: WIZARD
      authsrv# ^D
      EOT
      #
A porta de controle do telnet (tn-gw) são dianteiros e o primeiro você deve montar.

Eu permito que o host de dentro da network privada possa passar em meu exemplo, sem se autenticar. (permit-hosts 19961.2.* -passok) Mas, qualquer outro usuário tem que entrar no ID do usuário e com a password para usar o proxy. (permit-hosts * -auth)

Eu também permito que um outro sistema (196.1.2.202) tenha acesso ao meu firewall diretamente sem passar pelo firewall. As duas linhas inetacl- in.telnetd do in.telnetd faz isto. Eu explicarei como estas linhas são chamadas posteriormente.

O intervalo de Telnet deveria ser mantido pequeno.

    # telnet gateway rules:
    tn-gw:                denial-msg      /usr/local/etc/tn-deny.txt
    tn-gw:                welcome-msg     /usr/local/etc/tn-welcome.txt
    tn-gw:                help-msg        /usr/local/etc/tn-help.txt
    tn-gw:                timeout 90
    tn-gw:                permit-hosts 196.1.2.* -passok -xok
    tn-gw:                permit-hosts * -auth
    #Só o Administrador pode acessar o telnet diretamente para o Firewall pela Porta 24
    netacl-in.telnetd: permit-hosts 196.1.2.202 -exec /usr/sbin/in.telnetd
Os r-comandos trabalham do mesmo modo como o telnet.

      # rlogin gateway rules:
    rlogin-gw:    denial-msg      /usr/local/etc/rlogin-deny.txt
    rlogin-gw:    welcome-msg     /usr/local/etc/rlogin-welcome.txt
    rlogin-gw:    help-msg        /usr/local/etc/rlogin-help.txt
    rlogin-gw:    timeout 90
    rlogin-gw:    permit-hosts 196.1.2.* -passok -xok
    rlogin-gw:    permit-hosts * -auth -xok
    # Somente o administrador pode acessar o telnet diretamente do firewall via Porta
    netacl-rlogind: permit-hosts 196.1.2.202 -exec /usr/libexec/rlogind -a
Você não deve que ninguém tenha acesso ao seu firewall diretamente e isso inclui o FTP assim não põe um servidor de FTP, no seu firewall.

Novamente, a linha de permit-hosts permite que qualquer um na network protegida acesse livremente a Internet e tudos os outros têm que autenticar eles. Eu incluí um arquivo de logs de envio e recebimento no meu controle. (-log { retr stor })

O intervalo do ftp controla quanto tempo leva para derrubar um conexão péssima como também quanto tempo uma conexão ficará aberto com nenhuma atividade.

    # ftp gateway rules:
    ftp-gw:               denial-msg      /usr/local/etc/ftp-deny.txt
    ftp-gw:               welcome-msg     /usr/local/etc/ftp-welcome.txt
    ftp-gw:               help-msg        /usr/local/etc/ftp-help.txt
    ftp-gw:               timeout 300
    ftp-gw:               permit-hosts 196.1.2.* -log { retr stor }
    ftp-gw:               permit-hosts * -authall -log { retr stor }
Web, gopher e browser baseado em ftp são controlados pelo http-gw. As primeiras duas linhas criam um diretório para armazenar documentos do ftp e do web de como eles estão atravessando o firewall. Eu faço estes arquivos na raiz e pôs o em um diretório acessível só através da raiz.

A conexão de Rede deve ser mantida pequena. Controlar quanto tempo o usuário espere em uma conexão ruim.

    # www and gopher gateway rules:
    http-gw:      userid          root
    http-gw:      directory       /jail
    http-gw:      timeout 90
    http-gw:      default-httpd   www.afs.net
    http-gw:      hosts           196.1.2.* -log { read write ftp }
    http-gw:      deny-hosts      *
O ssl-gw é uma passagem real como qualquer outra porta. Seja cuidadoso com isto. Neste exemplo eu permito que qualquer um de dentro da network protegida possa se conectar a qualquer servidor de fora da network menos nos endereços 127.0.0.* e 192.1.1.* e então só em portas 443 até 563. Portas 443 até 563 são portas conhecidas do SSL.

    # ssl gateway rules:
    ssl-gw:         timeout 300
    ssl-gw:         hosts           196.1.2.* -dest { !127.0.0.* !192.1.1.* *:443:563 }
    ssl-gw:         deny-hosts      *
Aqui é um exemplo de como usar um plug-gw permitir que as conexões para um servidor de news. Neste exemplo eu permito que qualquer um dentro da network protegida possa conectar a só um sistema e só para isto é a porta de news.

A segunda linha permite ao servidor de notícias passar os seus dados através da network protegida.

Porque a maioria dos clientes espera ficar conectados enquanto o usuário leia as notícias, o intervalo para um servidor de news deve ser longo.

      # NetNews Pluged gateway
    plug-gw:        timeout 3600
    plug-gw: port nntp 196.1.2.* -plug-to 199.5.175.22 -port nntp
    plug-gw: port nntp 199.5.175.22 -plug-to 196.1.2.* -port nntp
A porta do finger é simples. Qualquer um de dentro da network protegida deve logar-se primeiro e então nós lhes permitimos usar o programa finger no firewall. Se não é enviado uma mensagem.

    # Enable finger service
    netacl-fingerd: permit-hosts 196.1.2.* -exec /usr/libexec/fingerd
    netacl-fingerd: permit-hosts * -exec /bin/cat /usr/local/etc/finger.txt
Eu não tenho configuração de Correio e serviços de X-window assim eu não estou incluindo estes exemplos. Se qualquer um tem um exemplo em funcionamento, por favor envia-me um email.

7.4.2. O arquivo de inetd.conf

Aqui esta um arquivo de /etc/inetd.conf completo. Tudos serviços têm um comentário por fora. Eu incluí o arquivo completo para mostrar como desligar tudo, e como também as configurações para os novos serviços do firewall.

    #echo stream  tcp  nowait  root       internal
    #echo dgram   udp  wait    root       internal
    #discard      stream  tcp  nowait  root       internal
    #discard      dgram   udp  wait    root       internal
    #daytime      stream  tcp  nowait  root       internal
    #daytime      dgram   udp  wait    root       internal
    #chargen      stream  tcp  nowait  root       internal
    #chargen      dgram   udp  wait    root       internal
    # FTP firewall gateway
    ftp-gw      stream  tcp  nowait.400  root  /usr/local/etc/ftp-gw  ftp-gw
    # Telnet firewall gateway
    telnet        stream  tcp  nowait      root  /usr/local/etc/tn-gw /usr/local/etc/tn-gw
    # local telnet services
    telnet-a    stream  tcp  nowait      root  /usr/local/etc/netacl in.telnetd
    # Gopher firewall gateway
    gopher        stream  tcp  nowait.400  root  /usr/local/etc/http-gw /usr/local/etc/http-gw
    # WWW firewall gateway
    http  stream  tcp  nowait.400  root  /usr/local/etc/http-gw /usr/local/etc/http-gw
    # SSL firewall gateway
    ssl-gw  stream  tcp     nowait  root /usr/local/etc/ssl-gw   ssl-gw
    # NetNews firewall proxy (using plug-gw)
    nntp    stream  tcp     nowait  root    /usr/local/etc/plug-gw plug-gw nntp
    #nntp stream  tcp     nowait  root    /usr/sbin/tcpd  in.nntpd
    # SMTP (email) firewall gateway
    #smtp stream  tcp     nowait  root    /usr/local/etc/smap smap
    #
    # Shell, login, exec and talk are BSD protocols.
    #
    #shell        stream  tcp     nowait  root    /usr/sbin/tcpd  in.rshd
    #login        stream  tcp     nowait  root    /usr/sbin/tcpd  in.rlogind
    #exec stream  tcp     nowait  root    /usr/sbin/tcpd  in.rexecd
    #talk dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
    #ntalk        dgram   udp     wait    root    /usr/sbin/tcpd  in.ntalkd
    #dtalk        stream  tcp     waut    nobody  /usr/sbin/tcpd  in.dtalkd
    #
    # Pop and imap mail services et al
    #
    #pop-2   stream  tcp  nowait  root  /usr/sbin/tcpd    ipop2d
    #pop-3   stream  tcp  nowait  root  /usr/sbin/tcpd    ipop3d
    #imap    stream  tcp  nowait  root  /usr/sbin/tcpd    imapd
    #
    # The Internet UUCP service.
    #
    #uucp    stream  tcp  nowait  uucp  /usr/sbin/tcpd  /usr/lib/uucp/uucico -l
    #
    #Serviço de Tftp é provido principalmente para boot.  Na maioria dos locais
    #só corra quando uma máquinas que agem como "servidor de boot". Não descomente
    #isto a menos que você *precise* disto.
    #
    #tftp dgram   udp     wait    root    /usr/sbin/tcpd  in.tftpd
    #bootps       dgram   udp     wait    root    /usr/sbin/tcpd  bootpd
    #
    #finger, systat e netstat distribuem informação de usuário que pode ser
    #potencialmente valiosas "para quebra do sistema". Muitos locais escolhem incapacitar
    #alguns ou tudos estes serviços para melhora segurança.
    #
    #cfinger é para GNU troque que não está atualmente em uso no RHS Linux
    #
    finger        stream  tcp  nowait  root   /usr/sbin/tcpd  in.fingerd
    #cfinger      stream  tcp  nowait  root   /usr/sbin/tcpd  in.cfingerd
    #systat       stream  tcp  nowait  guest  /usr/sbin/tcpd  /bin/ps -auwwx
    #netstat      stream  tcp  nowait  guest  /usr/sbin/tcpd  /bin/netstat -f inet
    #
    # Serviço para sincronização do relógio.
    #
    #time stream  tcp  nowait  root  /usr/sbin/tcpd  in.timed
    #time dgram   udp  wait    root  /usr/sbin/tcpd  in.timed
    #
    # Authentication
    #
    auth          stream  tcp  wait    root  /usr/sbin/tcpd  in.identd -w -t120
    authsrv       stream  tcp  nowait  root  /usr/local/etc/authsrv authsrv
    #
    # End of inetd.conf
7.4.3. O arquivo de /etc/services

Isto é aonde tudo começa. Quando um cliente conecta o firewall isto conecta em uma porta conhecido (menos em 1024). Por exemplo o telnet conecta na porta 23. O deamon do inetd ouve esta conexão e olha para o nome deste no arquivo de /etc/services. E então chamada o programa definido no nome do arquivo /etc/inetd.conf.

Alguns dos serviços que nós estamos criando normalmente não são no arquivo /etc/services. Você pode nomear alguns deles a qualquer porta que você quer.

Por exemplo, eu nomeei o telnet do administrador para porta(telnet-a) 24. Você poderia nomear isto para aportar 2323 se você desejar. Para o administrador (VOCÊ) conectar diretamente ao firewall você vai precisar que o telnet não acesse 24 nem 23 e se você configurar o seu arquivo netperm-table, como eu fiz, você só será capaz de dentro da sua network protegida.

    telnet-a        24/tcp
    ftp-gw          21/tcp           # this named changed
    auth            113/tcp   ident    # User Verification
    ssl-gw          443/tcp
8. O Servidor de Proxy do SOCKS

8.1. Configurando um Servidor de Proxy

O servidor de proxy do SOCKS está disponível em ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz.
Também há um exemplo de config dentro deste diretório chamado de "socks-conf". Descompacte e utilizar o tar no arquivo em um diretório do seu sistema, e siga as instruções em como instalar. Eu tive alguns problemas quando eu fiz isto. Tenha certeza que seu Makefiles estão corretos.

Uma coisa importante para notar é que o servidor de proxy precisa ser anexado no /etc/inetd.conf. Você tem que anexar a seguinte linha:

    socks  stream  tcp  nowait  nobody  /usr/local/etc/sockd  sockd
avisa ao servidor para roda-lo quando pedido.

8.2. Configurando o Servidor de Proxy

Os programas SOCKS precisam de dois arquivos de configuração separados. Um conta o acesso permitido, e um dirigi os pedidos apropriados para o servidor de proxy. O arquivo de acesso deve ser colocado no servidor. O arquivo de roteamento deve ser colocado em toda máquina Un*x. O DOS e, presumivelmente, computadores Macintosh farão o seu próprio roteamento.

8.2.1. O Arquivo de Acesso

Com o socks4.2 Beta, o arquivo de acesso é chamado de "sockd.conf". Deve conter 2 linhas, uma de permição(permit) e um de linha de negação(deny). Cada linha terá três entradas:

· O Identifier (permit/deny)

· O endereço do IP

· O modificador de endereço

O identifier é o que permite ou nega. Você deve ter ambos um linha de permição e um de negação.

O endereço IP é formado de quatro byte de enreçamento de IP típico de anotação. I.E. 192.168.2.0.

O modificador de endereço também é um IP típico que envia quatro número de byte. Funciona como um netmask. Verefique este número para ser 32 bits (1s ou 0s). Se o bit é um 1, o bit correspondente do endereço que isto está conferindo tem que emparelhar o bit correspondente no campo do endereço IP. Por exemplo, se a linha é:

      permit 192.168.2.23 255.255.255.255
permitirá que somente o endereço IP se emparelhar com todo o bit em 192.168.2.23, isto é, somente 192.168.2.3. A linha:

      permit 192.168.2.0 255.255.255.0
permita que todo número dentro de grupo 192.168.2.0 até 192.168.2.255, a Classe C inteira do domínio. Você não deve ter a seguinte linha:

      permit 192.168.2.0 0.0.0.0
como isto permitirá todos os endereço, indiferentemente.

Assim, primeiro permite todo endereço que você quer permitir, e então negue o resto. Permiti que todo mundo no domínio 192.168.2.xxx, com a seguintes linhas:

      permit 192.168.2.0 255.255.255.0
      deny 0.0.0.0 0.0.0.0
configure corretamente. Note que o primeiro "0.0.0.0" na linha de negação. Com um modificador de 0.0.0.0, o IP se dirigem ao campo não se importando. Todos os 0's é a norma porque é fácil de digitar.

Mais de uma entrada de cada é permitido.

Também podem ser concedidos a usuários específicos ou podem ser negados acesso. Isto é via a autenticação do ident. Nem todos os sistemas apóiam o ident e incluindo o Trumpet Winsock, assim eu não irei mostra isto. A documentação do socks é bastante adequado neste assunto.

8.2.2. O Arquivo de roteamento

O arquivo de rotemaneto no SOCKS é chamado probremente de "socks.conf". Eu digo "chamado pobremente" porque é parecido com o nome do arquivo de acesso isto é fácil para obter duas confusões.

O arquivo de roteamento é chamado para os clientes do SOCKS quando usa o socks e quando não. Por exemplo, em nossa network, 192.168.2.3 não vai precisar usar o socks para falar com 192.168.2.1, firewall. Tem uma conexão direta por Ethernet. Define 127.0.0.1, o loopback, automaticamente. Claro que você não precisa de SOCKS para acessar a você mesmo.

Há três entradas:

· negação (deny)

· direct

· Sockd

Negue os acessos para o SOCKS quando rejeitar um pedido. Esta entrada tem o mesmo três campos como em sockd.conf, identificador, endereço e modificador.

Geralmente, desde que isto também seja para o sockd.conf, o arquivo de acesso, o campo de modificador é fixado em 0.0.0.0. Se você quer impedir você pode chamar de qualquer lugar, você pode fazer isto aqui.

A entrada direct conta quais são os endereços que não usaram o socks. Estes são todos os endereços que podem ser alcançados sem o servidor de proxy. Novamente nós temos os três campos, identificador, endereço e modificador. Nosso exemplo seria:

      direct 192.168.2.0 255.255.255.0
 
Indo direto assim a qualquer parte de nossa network protegida. A entrada do sockd conta ao computador que o host tem o servidor de daemon de socks. A sintaxe é:
    sockd @=<serverlist> <IP address> <modifier>
Note a entrada @=. Isto permite lhe definir os endereços de IP de um lista de servidores de proxy. Em nosso exemplo, nós usamos somente um servidor de proxy. Mas, você pode ter muitos para permitir uma maior carga e para a redundância em caso de fracasso.

O endereço de IP e campos do modificador trabalham igual como nos outros exemplos. Você tem que especificar quais os endereços que vão poder acessar. 6.2.3. DNS por detrás de um Firewall

Configurar um Serviço de Nomes de Domínio por detrás um firewall é um tarefa relativamente simples. Você precisa montar o DNS somente na máquina com o firewall. Então, definir cada máquina atrás do firewall para usar este DNS.

8.3. Trabalhando Com um Servidor de Proxy

8.3.1. Unix

Para ter suas aplicações trabalhando com o servidor de proxy, eles precisam ter o "sockified". Você precisará de dois telnets diferente, um para acessar a comunicação, e um para comunicação pelo servidor de proxy. O SOCKS vem com instruções de como definir um programa SOCKify, como também vários programas de pre-SOCKified. Se você usa a versão de SOCKified para acessar algum direct, o SOCKS trocarão automaticamente um pelo outra versão para você. Por causa disto, nós queremos mencionar novamente que todos os programas em nossa network protegida é substituida com os programas do SOCKified. "finger" se torna "finger.orig , "telnet" se torna "telnet.orig", etc.

Você tem que dizer ao SOCKS sobre cada um destes no arquivo de include/socks.h.

Certos programas acessarão o roteamento e o sockifying nisto. O Netscape é um deles. Você pode usar um servidor de proxy dentro do Netscape com entradas no endereço do servidor (192.168.2.1 em nosso caso) nos campos de Socks dentro do Proxy. Cada aplicação precisará de pelo menos um pouco de arrumação embora de como acessar um servidor de proxy.

8.3.2. MS Windows com o Trumpet Winsock

O Trumpet Winsock vem embutido com capacidades para oe servidor de proxy. No menu de "setup", entre o endereço IP do servidor, e os endereços de todo os computadores que acessam diretamente. O Trumpet define todos os pacotes de inicialização.

8.3.3. Acessando um Servidor para usar pacotes com UDP

O SOCKS trabalha somente com pacotes do TCP, e não UDP. Isto faz com que prejudique em muitas utilizações. Muitos programas úteis, como o talk, o Archie, use o UDP. Há um pacote projetadou para ser usado com um servidor proxy para pacotes de UDP chamado UDPrelay, por Tom Fitzgerald, <fitz@wang.com>. Infelizmente, na hora deste trabalho, ele ainda não é compatível com o Linux.

8.4. Desvantagens com o Servidores de Proxy

O servidor de proxy é, acima de tudo, um dispositivo de segurança. Usando para acessar a internet e aumentar os endereços de IP limitados terá muitas desvantagens. Um servidor de proxy permitirá maior acesso de dentro da sua network protegida para o exterior, mas manterá o interior completamente inacessesivel do exterior. Isto significa que nenhum servidor, usará conexões de talk ou o archie, ou acessar aos computadores interiores. Estas desvantagens poderiam parecer leves, mas pensa do seguinte modo:

· Que você deixou um relatório que você está fazendo em seu computador dentro de um network protegida com firewall. Você está em casa, e decide que você gostaria de revisar. Você não pode. Você não pode alcançar o seu computador porque está atrás de um firewall. Você tenta acessar no firewall primeiro, mas então todo mundo tem o acesso do servidor de proxy, e ninguém, montou uma conta para você.

· Que sua filha vai para faculdade. Você quer enviar um email para ela. Você tem algumas coisas privadas para falar, e teria seu mail enviado diretamente da sua máquina. Você confia em no seu administrador de sistema completamente, mas ainda, este é um mail privado.

· A inabilidade para usar pacotes de UDP representa uma desvantagem grande com o servidores de proxy. Eu imagino outras capacidades de UDP que estarão vindo brevemente.

O FTP causa outro problema com um servidor de proxy. Se você usar um ls, o servidor de FTP abre uma cova na máquina de cliente e envia a informação. Um servidor de proxy não permiti isto, assim o FTP não trabalha particularmente.

E, servidores de proxy rodam lentamente. Por causa do overhead, quase todos os pedidos necessitam de acesso rapidamente.

Basicamente, se você tem um endereço IP, e você não está preocupado com a segurança, não use firewall e/ou servidores de proxy. Se você não tem um endereço de IP, mas você também não esta preocupado com a segurança, você também pode querer olhar sobre emluador de IP, como o Term, Slirp ou TIA. O Term está disponível no ftp://sunsite.unc.edu, Slirp esta disponível em ftp://blitzen.canberra.edu.au/pub/slirp, e TIA esta disponível em marketplace.com. Estes pacotes rodam mais rapidos, permiti conexões melhores, e provê um nível maior de acessos para dentro da network da internet. Servidores de proxy são bons para cadeias que têm muitos hosts que querem conectar a internet voando, com uma configuração e pouco trabalho depois.

9. Configurações avançadas

Há uma configuração que eu gostaria de revisar antes de acabar este documento. Eu há pouco esbocei suficientemente provavelmente bastará para a maioria das pessoas. Porém, eu penso que o próximo esboço mostrará uma configuração mais avançada que pode clarear algumas perguntas. Se você tiver perguntas além do que eu há pouco cobri, ou há está interessado na versatilidade de servidores de proxy e firewalls, prosseguida lendo.

 9.1. Uma grande network com ênfase na segurança

Por exemplo, digamos que você seja o líder de millisha e você quer uma network local. Você tem 50 computadores e um subnet de 32 (5 bits) numeros de IP.

E você precisa de vários níveis de acesso dentro de sua network porque você diz para os seus seguidores coisas diferentes. Então, você vai precisar proteger certas partes da sua network do resto.

Os níveis são:

1. O nível externo. Este é o nível para o que é mostrado para todo mundo. todo o mundo. Aqui é aonde você divulga e delira para adquirir os novos voluntários.

2. Tropa Este é o nível das pessoas além do que adquiriram do nível externo. Aqui é onde você os ensina sobre o governo demôniaco e como fazer bombas.

3. Mercenário Aqui é onde são mantidos realmente os planos. Neste nível é armazenado toda a informação em como o 3º governo mundial vai assumir o mundo, seus planos envolvendo o Newt Gingrich, a Cidade de Oklahoma, lown se preocupam produtos e que realmente é armazenado e cabe nesta área 51.

9.1.1. A Configuração da Network

Os números de IP são organizados como:

· O número 1 é o 192.168.2.255 que é o broadcast e não é utilizável.

· São alocados 23 dos 32 endereços de IP para 23 máquinas que serão acessível a internet.

· 1 IP extra vai para uma linux naquela cadeia

· 1 extra vai para um linux diferente naquela cadeia.

· 2 IP #'s vão para o roteador

· 4 permanecem, menos os que são determinados domínio nomeiados como paul, ringo, john, e george, só para confundir as coisas um pouco.

· As networks protegidas têm os endereços 192.168.2.xxx

Então, são construídas duas networks separadas, cada uma quartos diferentes. Elas são roteadas por Ethernet de infra-vermelho de forma que são completamente invisíveis para o quarto externo. Por sorte, o funcionamento de ethernet de infra-vermelho há pouco funcionam como uma ethernet normal.

Estas networks são cada conectados a um dos linux com um endereço extra de IP. Há um servidor de arquivo que conecta as duas networks protegidas. Isto porque os planos por assumir o mundo envolvem algumas das Tropas mais altas. O servidor de arquivo assegura o endereço 192.168.2.17 para a Network da tropa e 192.168.2.23 para a network Mercenária. Elas tem IP diferente que acessam porque tem que ter placas deEthernet diferentes. O IP Forwarding está desligado.

IP Forwarding em ambas os Linux também estão desligados. O roteador não vai por pacotes que destinaram para 192.168.2.xxx a menos que explicitamente contasse para fazer isto, assim a internet não podera entrar. A razão para IP Forwarding estar desligado aqui é de forma que os pacotes da Network da Tropa não podeça alcançar a network Mercenária, e vica-versa.

O servidor de NFS também pode ser definido aqui para oferecer arquivos diferentes para as networks diferentes. Isto pode ser feito à mão, e um pouco de artifícios com vínculos simbólicos pode fazer isto de forma que os arquivos comuns pode ser compartilhados com todos. Usando esta ligação e outra placa de ethernet podemos oferecer um servidor de arquivos para todas as três networks.

9.1.2. A Configuração do Proxy

Agora, desde que todos os três níveis querem poder monitorar a network para os próprios propósitos desviados, toda as três necessitam ter acesso certo. A network externa é conectada diretamente na internet, assim nós não temo que fazer configuração dos servidores de proxy aqui. A netowrks dos Mercenário e da Tropa estão atrás de firewalls, assim é necessário montar o servidor de proxy.

Ambas as cadeias serão muito semelhantemente na configuração. Ambas têm o mesmo Endereços de IP nomeadas nelas. Eu defini vários parâmetros, só fazer isto mais interessante.

1. Ninguém pode usar o servidor de arquivo para acesso a internet. Isto expõe o servidor de arquivo para vírus e outras coisas sórdidas, e é bastante importante, assim se for fora dos limites.

2. Nós não permitir-mos o acesso de tropa ao World Wide Web. Eles estão em treinando, e este tipo de poder de recuperação de informação poderia danificar o aprendizado.

Assim, o arquivo do sockd.conf arquivam no linux da Tropa terá esta linha:

      deny 192.168.2.17 255.255.255.255
e na máquina Mercenária:
      deny 192.168.2.23 255.255.255.255
E, no linux da Tropa terá esta linha
      deny 0.0.0.0 0.0.0.0 eq 80
Isto diz para negar o acesso para todas as máquinas que tentam acessar a porta igual (eq) a 80, a porta de http. Isto ainda permitirá todos os outros serviços, só neguando o acesso ao Web.

Então, ambos os arquivos terão:

      permit 192.168.2.0 255.255.255.0
permiti que todos os computadores na network 192.168.2.xxx pode usar o servidor de proxy com exceção desses que já foram negados (ie. o servidor de arquivo e o acesso a Web da network da Tropa).

O arquivo de sockd.conf da Tropa será assim:

      deny 192.168.2.17 255.255.255.255
      deny 0.0.0.0 0.0.0.0 eq 80
      permit 192.168.2.0 255.255.255.0
e o arquivo do Mercenário será como:

      deny 192.168.2.23 255.255.255.255
      permit 192.168.2.0 255.255.255.0
Isto deve configurar tudo corretamente. Cada network está isolada adequadamente, com a quantidade formal de interação. Todo o mundo deve estar contente.

Agora, assuma o mundo!


[Help OnLine] [Distribuições] [Novidades] [Eventos] [Usuários] [Aplicativos] [Hardware] [Projetos] [Vendedores] [Serviços]
[Linux Brasil]
WebSite Design: Buick
Copyright © 1997-1998 - Buick. All Rights Reserved.
[Linux-Org]