RES: [MASOCH-L] Seguran ç a em ProvedorWISP -SAGU_PRO

Tue Apr 4 12:49:37 BRT 2006

Eduardo, eu acho que antes de preocupação com segurança, você deveria
analisar a parte física.

Acho que irei extrapolar o assunto mas seria bacana trocarmos ideias.

Como o Frederico falou, o importante é o domínio de colisão, evitando que a
performance de rede caia.
Ele usa equipamento de qualidade que permite filtrar alguns protocolos.

O que acontece é que,  pelo menos em minha experiência profissional, já
realizei consultoria em diversos provedores que colocavam equipamentos
indoor, limitados em todos os aspectos (CPU/Memória/Recursos) em cima de uma
torre, socava 1 antena omni e pronto, o caos estava completado.

Seria interessante você analisar a infra do provedor que você está prestando
a consultoria e partir daí, com base no que o hardware dele dispõe, adotar a
melhor opção.

Se o hardware não suportar muitos recursos de filtro, implementar PPPoE vai
ser uma dor de cabeça, você terá cada cliente procurando, por broadcast o
servidor PPPoE. Se sua estrutura não estiver afinada como o exemplo do
Frederico, você irá piorar as coisas.

Daí você tem que analisar. Por exemplo, em alguns casos, uso o BSD 6.0
embarcado (tinybsd) ao inves dos radios (já que eles são de uso indoor e o
cliente não adquire um AP de qualidade mesmo), fazendo filtros camada 2,
filtros contra portas de vírus, etc etc.

Depois dos problemas sanados, fica mais fácil, com base em gráficos,
relatórios, etc etc, verificar qual solução é melhor, PPPoE, WPA, WEP(!!),
nocat, etc etc.

On 4/4/06 12:40, "Eduardo Oliveira Hernandes" <tuxstrike at gmail.com> wrote:

> :( minha situação é exatamente essa, uns 500 usuarios, problemas de todo o
> tipo, uma bomba ehee
> 
> por isso estou tentando ver a melhor solucao, nao conheço toda a estrutura
> fisica ainda, por isso ta meio complicado aqui....
> 
> 2006/4/4, Frederico Terra Boechat <fboechat at mar.com.br>:
>> 
>> Deixe-me tentar explicar a estrutura:
>> 
>> São 11 AP´s, normalmente Karlnet, Orinoco ou Ap-plus (todas são iguais, só
>> mudou o nome), interligadas por ponto-a-ponto até o provedor. No provedor
>> tem o servidor PPPoE, um FreeBSD 6.0
>> 
>> Todas as ap´s são bridge, ou seja, não são necessários relay pra PPPoE.
>> Então, em tese todas as estações estão ligadas direto ao provedor.
>> 
>> Ai viria uma pergunta: Se todas as ap´s são bridge, o domínio de broadcast
>> seria gigante, certo?
>> 
>> Em tese, sim. Mas em cada AP eu filtro todos os protocolos MENOS PPPoE.
>> Isso
>> me garante que, entre outras coisas, que um usuário com ip só chegue a
>> interface externa da AP, mais nada. Então, o excesso de broadcast não
>> chega
>> ao provedor.
>> 
>> Na AP, tem uma opção que NÃO permite que o cliente veja diretamente o
>> outro.
>> Acredito que as AP´s mais baixa-renda não tenham essa opção, por isso
>> esses
>> modelos sõa mais caros e um diferencial enorme. Logo, se um cliente tentar
>> sniffar algo na rede, vai dificultar um pouco mais.
>> 
>> O provedor concorrente, que tem mais de 700 usuários, tentou o nocat e não
>> deu certo. Por quê?
>> 
>> Ele passa cabo de rede do provedor até o cliente. Nem preciso dizer que é
>> uma técnica deplorável por N motivos e N razões, que isso inflinge normas
>> da
>> Anatel, etc et al. Mas mesmo assim, ele funciona ainda. Teve que tirar o
>> nocat pela simples razão: clientes tentaram forjar MAC. o nocat por algum
>> motivo, não sei se má instalação ou se é natureza do soft, começou a
>> recusar
>> usuários válidos, a tabela ARP do servidor começou a ter MAC zerados,
>> entre
>> outros mais que não me recordo.
>> 
>> Ele pensa em implementar PPPoE. Imagine o que vai ser ir na casa de mais
>> de
>> 700 usuários pra instalar?
>> Agora imagine isso tudo sem controle algum?
>> 
>> Realmente, cada caso é caso, e no dele é um caso muito delicado. Começou
>> errado, e agora pra corrigor, vai ter trabalho.
>> 
>> Bom..o que eu quero dizer? realmente, cada caso é um caso isolado, e
>> dependendo de vários fatores, como tamanho da rede, problemas que já vem
>> ococrrendo, etc, uma solução pode ser mais viável do que a outra, mas não
>> a
>> mesma solução pra todos.
>> 
>> Abraços a todos
>> 
>> Frederico Boechat
>> ----- Original Message -----
>> From: "Helio Loureiro" <helio at loureiro.eng.br>
>> To: "Mail Aid and Succor, On-line Comfort and Help"
>> <masoch-l at eng.registro.br>
>> Sent: Monday, April 03, 2006 8:30 PM
>> Subject: Re: RES: [MASOCH-L] Segurança em ProvedorWISP -SAGU_PRO
>> 
>> 
>>> Em Seg, 2006-04-03 às 15:01 -0300, Thomas Britis escreveu:
>>>> Senhores,
>>>> 
>>>> Em uma rede sem túneis, como é que fica a segurança da rede quando
>>>> alguém fizer a "clonagem" dos dados do gateway ? (IP e/ou MAC) ?
>>>> 
>>>> Dependendo da topologia da rede E do AP utilizado é possível fazer o
>>>> redirecionamento dos pacotes para uma interface específica e, nessa
>>>> interface ter somente o gateway, porém, fora isso, acho que sempre há o
>>>> risco.
>>>> 
>>> 
>>> 
>>> Caros,
>>> 
>>> Somente agora via a thread sobre o assunto.  Notei que ninguém citou
>>> WPA2 (desculpas se alguém comentou e eu não vi).  Tá certo que a
>>> configuração é muuuuuuito mais trabalhosa, mas é um método seguro e
>>> provavelmente será o caminho futuro da segurança wireless (e um dia não
>>> será mais difícil que configurar um dhcp).
>>> 
>>> Eu implementei tanto com WPA2, que depende do suporte do AP, quanto com
>>> 802.1x, que funciona no nível do switch, em Debian (radius server).  Foi
>>> trabalhoso pois o Debian não tem suporte nativo ao EAP no freeradius por
>>> motivos de licença (coisa besta).  Tive de baixar um patch e recompilar
>>> os pacotes a partir do deb-src.  Deixe algumas migalhas de pão em
>>> "
>> http://helio.loureiro.eng.br/index.php?option=com_content&task=view&id=25&Ite
>> mid=31
>> "
>>> para poder me lembrar do que fiz, mas na brincadeira acabei perdendo um
>>> dia inteiro (e era apenas o início...).
>>> 
>>> Como cliente de conexão, utilizei o wpa_supplicant.  Como a coisa foi
>>> meio complicada (na verdade bem mais que isso), e se mais pessoas
>>> estiverem interessadas, posso depois publicar um "lazy dog" de tudo o
>>> que foi feito.
>>> --
>>> []'s
>>> +--------------------------------------+-------------------------------+
>>> |  Helio Alexandre Lopes Loureiro      | Unix _is_ user friendly. It's |
>>> |[helio arroba loureiro pto eng pto br]| just selective about who its  |
>>> |   http://helio.loureiro.eng.br       | friends are.  Marco Molteni.  |
>>> +--------------------------------------+-------------------------------+
>>> 
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>> 
>> 
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>> 
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
> 

--
Renato Frederick
FreeBSD Brasil LTDA.
Fone: (31) 3281-9633
http://www.freebsdbrasil.com.br