Em Terça 20 Março 2001 14:16, Bráulio W. Gergull escreveu:
> Uma solução "porquinha" para tratar isso poderia ser feita usando uma
> combinação de regras do servidor DHCP + ipchains + proxy ARP:
>
> Assim não adianta que o usuário tente alterar o endereço IP para a faixa
> de IP's autorizados, porque vai haver uma entrada permanente na tabela
> ARP apontando p/ outro MAC ;)

Ola colegas da lista.

Gostaria de informar as pessoas q vem acompanhando as nossas "discussoes" q a 
solucao "porquinha" apontada pelo Braulio (obrigado Braulio) funcionou!!!

Para fornecer um "documento" mais completo sobre o assunto primeiramente vou 
descrever o problema e depois a implementacao da solucao.

O problema: Aqui na rede de nosso escritorio precisavamos montar um esquema 
de validacao de conexoes por endereco MAC. Ou seja, se a maquina possuisse 
determinado endereco MAC ela poderia navegar, caso contrario ela nao poderia.
Segundo o Braulio (q foi a primeira pessoa a me ajudar) eu deveria utilizar o 
kernel 2.4 em conjunto com o iptables (q possui suporte a filtros de pacotes 
por MAC address entre outras coisas). Porem esta solucao, apesar de ser 
"ideal", seria "dificil" de implementar devido as diversas "amarracoes" 
envolvidas em uma atualizacao de kernel. No decorrer das "discussoes" o 
Braulio me sugeriu uma "possivel" solucao onde eu deveria fazer uso de uma 
combinacao das seguintes ferramentas: DHCP + ipchains + proxy ARP.

A solucao: Conforme as sugestoes recebidas, consegui resolver o problema 
fazendo uso apenas das ferramentas ipchains + proxy ARP, sendo desnecessario 
(no meu caso) o uso de DHCP. A seguir listei os passos usados para 
implementar a solucao "porquinha" ;-)

- Verifiquei os enderecos MAC de todas as estacoes da rede q terao acesso ao 
"gateway" usando o comando ifconfig (no linux) ou winipcfg (no windows).

- Determinei uma "faixa" de ips para estas estacoes (por exemplo 
192.168.1.100-192.168.1.110).

- Inclui regras especificas para o "forward" relativas a estas estacoes e 
ainda setei a "policy" padrao de "forward" para DENY.

  ipchains -P forward DENY
  ipchains -A forward -s 192.168.1.100/32 -j MASQ
  ipchains -A forward -s 192.168.1.101/32 -j MASQ
  .
  .
  ipchains -A forward -s 192.168.1.110/32 -j MASQ

- Inclui "manualmente" na tabela ARP os enderecos ip x MAC relativos a estas 
estacoes usando o comando arp.

  arp -s 192.168.1.100 AA:BB:CC:DD:EE:FF
  .
  .
  arp -s 192.168.1.110 GG:HH:II:JJ:KK:LL

Pronto, eh soh isso.

Desta maneira para o pacote "sofrer" o "mascaramento" ele deve ter como 
endereco ip algum daqueles q eu reservei anteriormente. Alem disso, estes 
enderecos ip somente serao "aceitos" se estiverem "ligados" aos seus 
respectivos enderecos MAC. Como consequencia, se o usuario alterar o endereco 
ip para "fora" do range previamente definido, o ipchains ira "barra-lo", e se 
um usuario em uma estacao cujo MAC da placa de rede NAO esta cadastrada na 
tabela ARP utilizar um ip "dentro" do range, tambem nao conseguira acesso.

Para automatizar o processo de inclusao da tabela ARP eh soh criar o arquivo 
/etc/ethers e incluir as linhas:

192.168.1.100 AA:BB:CC:DD:EE:FF
..
..
192.168.1.110 GG:HH:II:JJ:KK:LL

OBS: Nota-se uma grande semelhanca deste arquivo com o /etc/hosts.

Feito isso eh soh incluir a chamada "/sbin/arp -s /etc/ethers" sem as aspas 
no script de inicializacao do sistema (geralmente /etc/rc.d/rc.local).

Conclusao: Pode-se concluir q a utilizacao desta solucao, embora NAO "ideal", 
quebra um galho enquanto "apanhamos" (eu pelo menos) a atualizar o sistema 
para o kernel 2.4.

Desculpem o tamanho da mensagem, porem espero ter ajudado a comunidade ao 
detalhar a solucao deste problema ;-)

Obrigado a todos. (em especial a Braulio e Sir Hamacker)

--
Jorge Luiz de Paula Martins Filho
Analista de Sistemas
Linux Registered User # 189215
--

'Back in the USSR' musica dos Beatles, por John Lenin e Ringo Stalin.

Assinantes em 20/03/2001: 2186
Mensagens recebidas desde 07/01/1999: 104538
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista: 
            mailto:[EMAIL PROTECTED]

Responder a