e-cut, quem sabe se defender?? ta virando moda a galera clonar mac agora

[nonoque]

Se fosse criado um protocolo proprietário o problema poderia ser resolvido. Quem for no MUM dê um toque no pessoal ca mikrotik pois isso é de interesse coletivo.

[osmano807]

Se fosse criado um protocolo proprietário o problema poderia ser resolvido. Quem for no MUM dê um toque no pessoal ca mikrotik pois isso é de interesse coletivo.

Só fazer engenharia reversa uai.
A ideia não é fazer um protocolo proprietário, mas sim um protocolo com encriptação segura (AES por exemplo), ou de chave dupla (um ssh da vida), que mesmo todo o source aberto, não quebram.
Creio que isso é IPsec, não?

[naldo864]

vc matou a charada

[naldo864]

como assim

[AndrioPJ]

Em resumo, uma unica tecnologia nao garante segurança
o jeito é complicar mesmo.

criptografia wp2, dificultando o acesso de pessoas nao autorizadas na rede
senha no AP, evitando que o usuario acesse o AP e bisbilhote ele, troque mac, etc.
"1 conexao por user" e user/senha preso ao ip x mac, evitando que o usuario/senha seja usado por outra pessoa.

AP cliente em modo ISP e recebendo IP /30, AP torre com a opcao isolocao ativada (se possivel, usar um switch com vlan para interligar os AP torre), com isso dificultamos que seja realizado um scann na rede ou que haja compartilhamento.

[nonoque]

Tenho uma solução baseada em SSH. Mas ela sozinha não separa clientes.

Apresenta aí pra gente.

[AndrioPJ]

Tenho uma solução baseada em SSH. Mas ela sozinha não separa clientes.

Cliente recebendo IP/30
AP torre ativado isolação de cliente
Switch com vlan para interligar esses AP torre
sera que resolveria?

[nonoque]

Cliente recebendo IP/30
AP torre ativado isolação de cliente
Switch com vlan para interligar esses AP torre
sera que resolveria?

Ajuda muito.

[danilosceu]

a meu ver o PPPoE ja resolveria de uma vez todos esses problemas já que ele é criptografado e por usar mascara /32 já cria uma vlan amarrada por MACxIPxLOGINxSENHA.
e não existe broadcast no PPPoE

e aqui a senha de todos os radios só é conhecida pela empresa e o login e senha do PPPoE tambem.

concordo

[danilosceu]

Tenho uma solução baseada em SSH. Mas ela sozinha não separa clientes.

não vai falar né rsrsrs

[danilosceu]

a questao é que muitos administradores configuram o idle e o keeplive com tempo alto... e o usuario ainda por cima dificilmente fecha a sesão...
assim, aquela sesão continua aberta, bastando o camarada clonar o ip x mac.

o jeito nao é somente segmentar a rede... mas um conjunto de aplicacao.

uma rede bem configurada é praticamente impossivel o camarada conseguir o mac...
e mesmo que consiga de alguma forma (como ter dado manutencao na maquina da vitima), mesmo assim ele ainda precisaria do usuario e senha.
Se configurar o idle e keeplive com tamanho baixo (por exemplo: 5 min), mesmo que o cliente esqueça de finalizar a sesao... o camarada tera que clonar o ip x mac logo em seguida... pois se o camarada clonar o ip x mac depois da sesão ter sido finalizada, sera solicitado o user x senha.

verdade, isso resolveria alguns inconvenientes.

[danilosceu]

simples so mudar smtp server deve que vc deixou (public e ip 0.0.0.0/0) aponta isso para seu servidor e pronto
ninguem mais vai ver mac dos seus clientes.

nao testei isso ainda vou testar

[danilosceu]

post errado

[danilosceu]

a solução usando SSH não separa os clientes, mas garante a identidade deles.

a separação de clientes pode ser feita por várias outras técnicas, as duas juntas tornam a rede bastante confiável.

não adianta eu explicar pq depende de um programa que eu to fazendo (E haja... nunca consigo terminar programa nenhum).

consiste em usar o servidor SSH de uma maquina linux/bsd para autenticar os clientes. no computador do cliente roda um discador que loga no servidor SSH e autentica o usuário (Ao mesmo tempo verifica se o "certificado" do servidor não mudou, pra garantir a identidade do proprio servidor e evitar ataques de man-in-the-middle).

essa parte resolve o problema da identidade do cliente.

a segunda parte que é isolar os clientes pode ser feita com, amarração de ip/mac NO LADO do cliente, e pra ajudar a divisão da rede em /30 ou criando um AP virtual por cliente (essa é complexa pra carai e suga o processamento dos rádios).

unnn acho que entendi, tipo a chave ssh do mk, mais em servidor separado??

[rbginfo]

a solução usando SSH não separa os clientes, mas garante a identidade deles.

a separação de clientes pode ser feita por várias outras técnicas, as duas juntas tornam a rede bastante confiável.

não adianta eu explicar pq depende de um programa que eu to fazendo (E haja... nunca consigo terminar programa nenhum).

consiste em usar o servidor SSH de uma maquina linux/bsd para autenticar os clientes. no computador do cliente roda um discador que loga no servidor SSH e autentica o usuário (Ao mesmo tempo verifica se o "certificado" do servidor não mudou, pra garantir a identidade do proprio servidor e evitar ataques de man-in-the-middle).

essa parte resolve o problema da identidade do cliente.

a segunda parte que é isolar os clientes pode ser feita com, amarração de ip/mac NO LADO do cliente, e pra ajudar a divisão da rede em /30 ou criando um AP virtual por cliente (essa é complexa pra carai e suga o processamento dos rádios).

e isso não poderia ser feito se foce possivel aliar isso a um servidor radius??
algo do tipo que a autenticação pppoe foce gerada pelo login da chave ssh.
se foce possivel criar um autenticador dessa forma seria perfeito.

[claudinhohw]

bom galera se nem um nem outro até gora deu resultado 100% satisfatórios, e muito se fala não teria uma solução para bloquear no proprio mk esse programa que fica tentando invadir o servidor ou clonar o mac. não seria o caso de criar um programa para ficar no hd de cada cliente com uma key individual como é o caso do mk? eu sofro ataque no meu servidor quase que 24horas por algumas portas o log do meu mk fica vermelho de cima em baixo com nome e senhas que falharam acho até engraçado tem hora!
eu tenho um script no meu mk que faz ele desliga todo dia as 3:30 da manhã isso já dificulta um pouco para os fedepe que temtam invadir pois o mk reiniciando o programa deles creio que começa do zero novamente pois comparei alguns logs os nomes tentados são os msm! por favor me corrijam se eu estiver errado! só que não dá pra ficar reiniciando o mk durante o dia quando o trafego e intenso... gostaria das opiniões!

[nonoque]

Sobre ataque DDoS não conheço ainda bloqueio para ele eficiente. Quanto a idéia do SSH achei interessante. Se o amigo compartilhasse o desenvolvimento do programa quem sabe poderia ter ajuda e terminar mais rápido.

[rbginfo]

bom eu acredito que ficar reiniciando ajuda por esse ponto de zerar as tentativas...
mais não tem como ficar desligando o servidor... existem muitos clientes que botam arquivos grandes para baixar anoite, e a meu ver o uptime da rede é muito importante e mostra confiabilidade, e isso tambem zera o uptime da rede.

com relação ao sistema de autenticação do nosso amigo eu tambem fiquei muito intereçado e tambem me disponho a ajudar, não precisa abrir totalmente o projeto mas nos passar partes mais massivas e complexas para que possamos ajudar.
acredito que com uma forma de segurança dessa seria um passo importante nas nossas redes, principalmente com o surgimento de tecnologias que dispoe a venda de velocidades mais altas para os clientes, aposto que essas tentativas de ataque vão aumentar exponencialmente.

[nonoque]

É isso aí gente. Vamos nos unir e criar uma solução. À propósito, novamente, quem vai no MUM em Salvador pegue no pé do povo da Mikrotik por uma solução.

[nonoque]

Teria que ser como? Rodaria com o Captive portal em uma máquina separada?