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

[Frederico Terra Boechat]

Sobre ser broadcast, creio que voce se refira ao PPPoE Discover, que sim, 
usa broadcast. depois de o LCP ser iniciado, antes da autenticacao, eh um 
tunel PPP, logo comunicacao entre 2 hosts. Eu só uso 1 servidor e 11 AP 
transmitindo pra clientes.

Segurança, sim, se voce usar CHAP, diminui o risco, claro que nao pra 
totalmente.

Sobre captive portal, se 3 pessoas clonam mac numa rede de 200, o sistema 
começa a falhar e pode até cair. experiencia comprovada.

Não quero gerar guerra, acho que disc iturmos falhas é um bom aprendizado.

Frederico
----- Original Message ----- 
From: "Renato Frederick" <frederick at freebsdbrasil.com.br>
To: "Mail Aid and Succor, On-line Comfort and Help" 
<masoch-l at eng.registro.br>
Sent: Monday, April 03, 2006 12:58 PM
Subject: Re: RES: [MASOCH-L] Segurança em ProvedorWISP - SAGU_PRO


Só gostaria de tecer alguns comentários sobre o PPPoE.

Ele trabalha com broadcast, então, todos os clientes até o servidor PPPoE
tem que estar no mesmo segmento.

Dependendo do seu cenário, isso pode ser complicado.

Por exemplo, se há somente 1AP rodando Linux/BSD, irá funcionar OK. Mas se
seus clientes são muitos, você obviamente divide os clientes em celulas para
diminuir o broadcast.
Isso irá exigir implantação de diversos servidores PPPoE, ou rádios que
façam relay de PPPoE, dependendo do seu cenário.

Pessoalmente não vejo vantagens do PPPoE com relação a um "portal captativo"
(seja ele nocat, sagu ou outra solução livre/paga que venha a existir).

Creio que todos implementam PPPoE ou portal captativo para garantir que o
usuario X com a senha Y pagou a mensalidade e pode navegar, ou obter
informações de periodos de acesso, etc etc.

Mas, isto não garante **segurança**. Qualquer kiddie com um sniffer pode
pegar o login/senha do cliente que está autenticando no nocat, por exemplo.
Da mesma maneira, a sessao PPPoE não garate uma conexão fim a fim segura.

Se a ideia for segurança dos dados que estao sendo trafegados entre o
cliente e o AP, evitando clonagem de MAC, concorrentes desleais entupindo
sua célula com pacotes, etc etc, ai a solução é adotar, por exemplo WPA ou
outras alternativas (visto que o WEP de nada adianta).

Com relação ao uso de link, como já citaram, WPA/WEP/PPTP/IPSEC/PPPoE, todos
causam um aumento de banda, dependendo do cenário pode ser algo prejudicial.

Por fim, como tambem ja falaram, todas as alternativas exigiram alteração da
parte cliente (instalação de protocolos, alteração de conf das estações). O
PPPoE, por exemplo, exige atualização de dialup de alguns Windows e
instalação do RASPPoE. Isso pode gerar uma dor de cabeça para a equipe de
campo.

De todas, a mais "facil" de ser implementada é o portal captativo, já que
ele exige apenas um forward de regras nos gateway, e aceita autenticação
centralizada, por usar módulos que conversam com radius.

Não usei o SAGU, já que uso FreeBSD, mas creio que ele segue esta mesma
linha de raciocionio, no iptables.

Abraços!



On 4/22/06 11:36, "Frederico Terra Boechat" <fboechat at mar.com.br> wrote:

> Lembrem-se, a solução PPPoE do linux é EXPREIMENTAL (o próprio 
> desenvolvedor
> deixa claro em sua página), mas a solução usada nos BSD é nativa do 
> kernel.
>
> Autentico mais de 3000 usuários de 11 repetidoras sem problemas.
>
> Frederico


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



__
masoch-l list
https://eng.registro.br/mailman/listinfo/masoch-l