Só que o problema não está só na borda colega mas sim no código da UBNT que está muito falho, mas de fato boas práticas são sempre bem vindas.Citação:
Postado originalmente por rpassistencia
Versão Imprimível
Só que o problema não está só na borda colega mas sim no código da UBNT que está muito falho, mas de fato boas práticas são sempre bem vindas.Citação:
Postado originalmente por rpassistencia
kkkkkkkkkkkkkkkk, aja regra velho pra fazer isso, mano sério já estou perdendo a paciência o último blackout foram mais de 600 dispositivos de uma rede que presto consultoria sério mano essas falhas estão osso! :(Citação:
Postado originalmente por Bruno
Rapaz, messa as palavras. O @Bruno conheço a alguns anos e sinceramente até agora o cara é muito bom no que faz, não é babando ou até mesmo coisa de fã boi mas o cara é bom mesmo. :)Citação:
Postado originalmente por rpassistencia
Citação:
Postado originalmente por Fallout
Bom dia, rapaz já vi aberrações mais igual esta daqui foi a gota d'água!
"sistema bom pode deixa a interface de gerenciamento aberta não tem ataque que invada"
Eu como profissional em segurança da informação estou chocado com tanta candura, mais respeito sua opinião.
Seguimos...
Caro colega, engano seu pensar que a Mikrotik é absoluta, para titulo de informação veja: https://wikileaks.org/ciav7p1/index.html.Citação:
Postado originalmente por jodrix
Entenda uma coisa, nada é absoluto! mais a gente pode dificultar sim a entrada dos mais diversos tipos de ataque.
Abraço
Citação:
Postado originalmente por Bruno
Caro Bruno, em momento nenhum a ubiquiti deixa falha de segurança, não nesta última notícia divulgada por eles, se é esperto vai entender o motivo do novo ataque.
Não defendo nem "a" e nem "b", mais se você analisar bem a ubiquiti divulgou um alerta falando que o Malware NÃO É ESPECÍFICO PARA O EQUIPAMENTO UBIQUITI e muito menos bug deles, apenas um botnet agressivo que compromete dispositivos de camera IP, DVR e etc... Sendo assim, o comunicado feito adverte os VETORES de ataque do botnet que são: Brute force de login e senha "fracas" e uma vulnerabilidade de dispositivos linux antiga!
Volto a frisar novamente! NADA É ABSOLUTO! qualquer fabricante esta vulnerável e eu posso provar isso pra você.
Até breve!
Boa noite para quem tem asn a melhor solução é de cara bloqueio dá porta 22 utp e TCP direto no Bgp com isto inibe o primeiro ataque nao vai ter nenhum técnico de ti incomodado reclamando desta porta com isto o programa que roda o vírus nao inicia ok e vocês tem que desabilitar a chave de ssh em baixo dá opção de ativar o ssh com isto nao tem como o vírus ser estalado vou postar mais tarde ums print de como resolvo isto em minha rede e nao estou atualizando o rádio para 6.03 meus rádios estão quase todos na 5.6.9 a versão 6.0x tem tem troca do quernel e umas falha de segurança logo compartilho com vocês braço
Aplicar regras de bloqueios no firewall para os serviços vulneráveis, só ter acesso por determinados IPs e manter os equipamentos ubiquiti isolados uns dos outros na rede, é básico e não precisa desse barulho todo não amigo.Citação:
Postado originalmente por rpassistencia
O única coisa que eu vi em todas as suas postagens, foi você falando que firmwares acima da versão 5.6.4 não aceitava mais CT, e um usuário aqui do fórum mostrar que era possível e te ensinar, até agora só vi você recebendo informações.
Se quer defender o fabricante fique a vontade, se quiser ajudar e for algo diferente do que já foi descrito, poste suas regras.
Isso aqui é uma comunidade que troca informações e não fica falando que faz e acontece sem mostrar.
E se você não consegue explicar porque um equipamento ubiquiti é mais vulneráveis que outras marcas na mesma rede, fica difícil acreditar no seu conhecimento absurdo em segurança da informação.
No mais, não estou falando com você em tom agressivo, estou mostrando minha posição nesse assunto apenas.
E no fórum da ubiquiti tem o script que escaneia os equipamentos, remove o vírus e aplica o firmware que corrige a falha mais grave.
Para essa nova falha no firmware que aceita o brutal-force e não tem como ativar a proteção no próprio firmware, só resta bloquear no firewall e torcer para o usuário não executar o script malicioso de dentro de sua rede doméstica.
Aqui o que faço é usar o firmware 5.5.6 e rodar um script em iptables fazendo basicamente o que o mikrotik faz com dois cliques, permitir apenas os IPs que quero que acessem os serviço, tanto da LAN como da WAN.
Coisa que a ubiquiti já deveria ter implementado de forma nativa. Mas mesmo assim ainda tem risco, pelo simples fato dessa versão de kernel que ela usa ser vulnerável.
Não tenho problemas usando elas dessa forma, mas isso foi uma alteração que eu efetuei em cima de uma falha grotesca que o fabricante possui.
Muita teoria por aqui...
Teoria não amigo, descrevi uma das várias possibilidades para aumentar a segurança nesses equipamentos, você quer os comandos para copiar e colar ? É isso ?Citação:
Postado originalmente por gutemberg
Acredito que bloqueando a porta 22 e 23 para toda a rede interna, ou seja rede interna sem acesso a essas portas. Um drop em IP > firewall > filter apontando para a rede interna especialmente das antenas, permitindo acesso somente de alguns ips específicos, proteje sobre qualquer, ataques nessas portas, tanto externo quanto interno.
Kkkk eu crio e passo para você. Copiar e colar.Citação:
Postado originalmente por ShadowRed
Os Picas de antigamente não estão mais entre nós por aqui.. Enjoados estão rsrs
Não ri não amigo, é muito importante nesse cenário o bloqueio na ubiquiti também, rodando no shell dela o filtro. Porque se você executar o exploit de uma máquina atrás dela, rede doméstica ela vai sofrer o ataque. E foi o que disse em relação a usar a versão mais antiga executando esse script.Citação:
Postado originalmente por gutemberg
Tranquilo.. [emoji6]Citação:
Postado originalmente por ShadowRed
olha eu gosto muito da ubiquiti, em 2010 quando comecei a migra minha rede 2.4 para 5.8
a ubiquiti com o seu AirMax (TDMA) mudou o provedor da agua pro vinho com custo baixo!
uso ubnt desde 2010 sempre fui fã, sempre vesti a camisa deles, principalmente aquela que eles deram no forum!!!! kkkk
mais eles falharam no seu sistema AirOS, esse worm comecou la em 2012 e foi evoluindo
e falar que eh culpa do ISP por nao ter firewall...... sei la acho isso um descaso!
agora mais descaso ainda eh o cidadao achar que uma RB450G vai fazer papel de firewall!! e vai proteger toda a sua rede!!! kkkkkkkkk
firewall bom eh cisco nao tem conversa, firewall bom cisco vai ate de 40 mil reais pra mais!
e ai vc vai por isso pra "proteger" antena roteada em cliente final?
piada neh!?
gnt o que o rpassistencia faz é somente trabalhar com vlan e ip de gerencia ex: o pppoe da o ip valido pro cliente e usa uma rede privada pra gerencia ai em cima desta rede privada ele faz um drop nas porta 80, 443 e 22 isto é normal
além de a gerencia ser em uma rede privada tem o firewall
isto tem que ser feito pq a ubnt vacila com a questão de segurança pois em outros fabricante vc não tem este problema
porem o dia que acontecer de uma versão ter falha de segurança permitindo o que a versao 5.5.9 permitiu e algum cliente com vivus na maquina que abra um socket não vai adianta vc ter a vlan rede de gerencia separada firewall etc, pois qualquer adm de segurança sabe em quanto existir engenharia reversa nada é inviolável
O fato dele pensar que cisco é vaidade mostra o quanto ele ainda é pequeno como ele diz AMADOR, espero que ele chegue em um ponto com o provedor dele que ele fale não , não tenho que colocar um cisco pois minha 1072 não esta aguentando
Sou novo no fórum mais já vi que tem uma panela de moderadores que não aceita ninguém discordar de suas opiniões.Citação:
Postado originalmente por rpassistencia
Bom dia pessoal!
Só para agregar...
Firewall não se limita ao ASA...
Com preços bem mais agressivos... Temos Sonicwall que devidamente licenciado, atua muito bem na proteção e solução mais robusta... Podem usar Fortinet com os pés nas costas.
Mas nenhum destes fabricantes tem o poder de proteger falhas de kernel.
@Bruno
27 Mil clientes?
meus parabéns cara, você é bom no que faz.
PHD?
O tópico mais longo que já vi durante todo o tempo que estou no under linux.
Devo concordar em partes que o @rpassistencia disse.
Como também digo, isso é falha não só da ubiquiti, mais sim de um bom firewall, não tenho o profundo conhecimento dos senhores, leio sempre os post para captar aprendizada.
Tenho muitos clientes, e nessa versão o vírus alegado pelo membro @netuai que abriu o tópico ainda não surgiu, mais já vou ficar de olho.
Eu sempre ajudo dentro das limitações do meu conhecimento. Procurando sempre ajudar com clareza e a melhorar maneira da pessoa que pediu ajudar aprender.
Uma vez decidi pedir ajuda aqui em uma área que não faço nem ideia pra onde vai, claro antes de pedir já vinha uns dias estudando sobre o assunto e teve uma pessoa que não me recordo o nome deu uma resposta padrão tipo "estude, pesquise, se não sabe mude de profissão" resumindo não ajudou, sequer disse oque poderia ser, eu só venho no fórum quando não encontro pelo menos uma pista do que possa ser.
Mais voltando ao assunto, até agora eu não tive este problema.
Bom dia e bom feriado a todos.
Não somente um Firewall, mas uma serie de tecnicas de segurança que em 90% dos casos não são praticados pelos proprios Administradores de Redes.Citação:
Postado originalmente por ab5x2
No caso do Windows, por questões de segurança, eu sempre faço o seguinte:
1 - Crio um outro usuario com permissão de administrador e desativo o usuario padrão (Administrador ou Administrator);
2 - Alterar a porta padrão do RDP
3 - Instalo um Firewall e um Anti virus.
4 - Se é servidor, eu desativo a execução automática nas portas USB.
5 - Crio um firewall para limitar quem pode fazer acesso remoto ao servidor, seja por IP conhecido por Know Port.
Deixo aqui algumas considerações:Citação:
Postado originalmente por jodrix
1 - Problema de segurança em firmware vai existir em todo e qualquer fabricante, é de responsabilidade do Administrador da rede ficar atento e manter a rede atualizada.
2 - Não precisa de um baita firewall... desde que você entenda o fluxo de pacotes, tenha conhecimento em TCP/IP e Protocolos de rede, um simples mikrotik já resolve.
3 - Não ha necessidade de desativar as portas padrão, mas sim alterar o endereço das portas padrão. OBS: se bem que tbm indico desativar as que você não vai usar.
4 - No mais, Nesse quesito de segurança, Roteada ou em bridge, dá na mesma meu caro, pois em qualquer uma delas é possivel o acesso a qualquer outro cliente na rede.
Discordo quanto a parte de não precisa mudar as portas, todo bom Administrador de rede sabe que isso é uma das técnicas básicas e essenciais para segurança.Citação:
Postado originalmente por rpassistencia
Até cisco tem vulnerabilidade, pesquise na internet por "cisco exploit" e veja os resultados.Citação:
Postado originalmente por Bruno
E olha que não precisamos ir longe, veja a data do alerta (19 de março de 2017): http://thehackernews.com/2017/03/cis...h-exploit.html
Nenhum fabricante está isento de falhas.
Alias, nenhum sistema na internet está isento.
Não existe proteção com apenas uma técnica.
A unica forma de minimizar os riscos é usar o máximo possível de técnicas de segurança.
O problema não é tão somente firewall, mas sim falta de uma serie de técnicas.Citação:
Postado originalmente por rpassistencia
Manter porta padrão é uma bela falha heim....Citação:
Postado originalmente por rpassistencia
Pelo que entendi, você isola a gerencia dos equipamentos, deixando eles "dentro de uma rede privada".Citação:
Postado originalmente por rpassistencia
Isso evitaria o acesso externo aos equipamentos.... mas, e quanto ao acesso interno?
Vindo do cliente?
Ou seja, o próprio cliente pegou um vírus, e esse vírus está tentando "invadir" o Gateway dele (a CPE da casa do cliente)?
Como fica essa questão? o cliente consegue acessar a CPE dele pelas portas padrões?
mas eu não estou me referindo ao trafego WAN dele (conexão ppoe).Citação:
Postado originalmente por rpassistencia
mas sim a conexão do cliente até a CPE dele.
Cliente ---- CPE ---- Internet (ou rede interna do provedor)
O cliente, de dentro da casa dele, consegue acessar a CPE dele nas portas padrões?
Pois se conseguir, já é uma falha.
Existem alguns virus que infectam os computadores dos clientes e somente então, tentam infectar o Roteador/Gateway.
Então o cliente disca o PPoE diretamente no computador dele?Citação:
Postado originalmente por rpassistencia
Não existe CPE no cliente ou a CPE fica em bridge?
Quais equipamentos você usa?
show, você exemplificou a rede.Citação:
Postado originalmente por rpassistencia
mas ainda não respondeu a pergunta.
Esqueça a rede interna do provedor, eu quero saber é da rede interna da casa do cliente... vou até refazer o desenho de antes:
Computador cliente ---- CPE --- Concentrador --- Internet
O cliente, de dentro da casa dele, consegue acessar a CPE dele (que está instalada lá na casa dele) nas portas padrões?
Pois se conseguir, já é uma falha.
Existem alguns virus que infectam os computadores dos clientes e somente então, tentam infectar o Roteador/Gateway.
Não, não entendi... quais equipamentos vc usa?Citação:
Postado originalmente por rpassistencia
Pois se for Ubiquiti, mesmo ativando a porta de gerencia externa em VLAN, o cliente ainda consegue, internamente, acessar a CPE que está na casa dele... pode não conseguir acessar de outros clientes do provedor, mas a dele ele consegue, a menos que vc troque as portas padrões.
Pelo que você disse, cliente recebe DHCP da CPE que está na casa dele.
Exemplo:
Cliente pegou o IP 192.168.1.30, Gateway 192.168.1.1
Logo, se o cliente for no navegador dele e digitar 192.168.1.1... ele acessa a CPE.
Veja que o trafego não saiu de dentro da rede interna dele.
isto eu quis expor é fato que o cliente vai conseguir acessar normal porém o virus vai afetar apenas aquela cpeCitação:
Postado originalmente por AndrioPJ
O modo que o @rpassistencia faz na sua rede esta correto faço assim tb isto segura vamos dizer 99% contra falha
ele simplesmente separa a rede de gerencia dos ips publicos e faz um drop na rede privada não deixando ambas se comunicar
conversamos durante horas no skype ambos queria falar a mesma coisa porém diferente
ai vcs pode me perguntar deste 1% é simples vamos supor que a ubnt em questão deixa uma falha de segurança deixando o gerenciamento por qualquer vlan ou pppoe
ai todo trabalho nosso em isolar o gerenciamento da conexão não vai servir pra nada
ex: o ip de gerencia do ubnt vai ser la 192.168.0.44 o ip do pppoe 200.100.10.2 entao unico ip que acessa as configurações ssh etc é o 192.168.0.44 mais por falha de segurança ele deixou acessar pelo 200.100.10.2 ai ferrou é isto que me refiro que firewall não segura tudo
opaCitação:
Postado originalmente por alextaws
sim 27k de cliente afinal é 18 anos de ISP
sim sou tenho meu doutorado em ciência da computação porém phd no brasil não tem ainda ai não rola fazer
Boas...
Sem me pronunciar muito, para não sair do contexto do tema, confesso que li quase todas as 2x páginas deste tópico, onde no mesmo eu li e reli imensas atrocidades de pessoas com, phd´s, doutorados, mestrados etc.etc.etc....
Enfim, dou acessoria para empresas com mais de 4mil antenas em concetradores PPPOE , 99% tem AS com blocos de IPs publicos, e mesmo com NAT ou não, nenhum foi afetado.
Não existe mistério, nem mágica tudo se resume a um único quesito "segurança" isso mesmo segurança de rede.
Óbvio tenho mais de uma dezena de anos brincando com linux e firewall o que me deu 90% do quesito conhecimento para estruturar uma rede com os minimos quesitos de segurança.
quero confessar sem tentar ofender ninguém pois todos temos o direito de lutar e conquistar o nosso espaço.
Porém no Brasil hoje vemos a banalidade "gato" com ou sem outorga, optando por preço ao invés de qualidade.
Existem centenas de milhares de provedores de internet maioria ilegal ainda compartilhando o "gato" da ADSL com os 100 vizinhos no Bairro, isto porque deu conta de entrar no "youtube" e viu um video de 4 cliques para ligar um cabo via DHCP LAN do roteador adsl para a RB450, isto porque o video mais complicado de botar o modem adsl em Bridge e autenticar PPPOE WAN na RB450 com balanceamento já é mais avançado.
Existem milhares de provedores legalizados com outorga, que compra o mesmo equipamento, porque o outro provedor na região também compra e vende, como já tem as configs e os scripts prontos é só configurar igual. Ou seja porque é simples e prático.
Existem centenas de provedores legalizados que planejam investem $$$ e se estruturam em aprendizado, instrução e conhecimento para "começar a pensar Outside the box" Aqueles que sabem que nem tudo é o que parece ser.
O problema é que muitos provedores de internet hoje ainda procuram "e claro não é por culpa deles, pois eles mesmo não tem conhecimento" mas a grande realidade é que maioria dos Provedores de Internet procuram o famoso TI aka "also known as" Serviços Gerais.
Sempre com a mesma conversa de agregar valor a empresa... um verdadeiro faz de tudo um pouco. Ou seja um verdadeiro carro FLEX nem é bom para uma coisa nem é bom para outra...
1- nunca existiu nem existe malware ou virus como se é chamado, quem realmente colocou as mãos no código como eu decompilei e analisei os que realmente entederam irão ver que nada mais é que um SCRIPT isso mesmo coisa comum no mundo linux. onde o mesmo explorava algumas vulnerabilidades no sistema.
Não adiantava ter uma senha padrão ou senha curta ou senha grande, a vulnerabilidade no exploit estava la que permitia carregar por GCI uma chave RSA ssh.. diferente onde essa chave continha a senha famosa entre outras coisas...
1- Já alguém se preocupou em analisar que tipo de sistema operativo funciona nos equipamentos ubiquiti ? Caso não tenham percebido é uma vertente Linux, tanto que alguns modelos antigos de produtos ubiquiti funcionam com firmware openWRT.. existem até umas placas novas de produtos ubiquiti sendo vendido com acesso ao código fonte linux para os interessados desenvolverem.
2- O iptables está la porque não tentar entender como funciona?
3- Por ultimo Filtrar vários Gbps de trafego em tempo Real ????? Simples não é fácil, mas também não é impossivel.
4- Também não é preciso filtrar o trafego para bloquear um script, que simplesmente poderia ter sido bloqueado com outros mecanismos de segurança... e não estou falando de equipamentos caros CISCO ou juniper....
5- 80% dos problemas se resolvem trocando portas padrão, desabilitando protocolos não utilizados nos equipamentos em uso diário, e claro gerar um certificado SSL para o ssh e para serviços Web, Senhas únicas para cada cliente acesso web... sei lá coisa do tipo oi adsl pppoe autenticador telf numero, ou alguns digitos unicos que identifiquem o cliente ou outro documento..
6- os outros 20% da proteção é feita com firewall.. existem inúmeras variantes para linux, ou até um safeBGP.
7- outro erro comum "ohhh vou usar firmware versão licenciada da pqp na torre" e vou instalar a ultima versão de firmware ou até uma mais antiga no cliente.. onde as correcões de bug são incompatíveis da rocket para a antena do cliente.. e depois se queixam que fica lento que trava do nada.. resumindo rocket com 5.6x e antena do cliente com 6.xx "ai não tem nem como tirar base para falar" o equipamento não presta, trava , perde pacotes, etc.etc.etc. sem pensar que pode estar ocorrendo problema de incompatibilidade ou os bugs não estarem corrigidos na versão da rocket que distribui o sinal dando problema para os clientes que estão com a versão totalmente diferente.
8- Erro comum da porra , cliente solicita o provedor para liberar a porta xxxyy na antena porque ele tem uma camera IP em casa onde ele quer acessar remoto no serviço dai o açogueiro que vai prestar o serviço não dá conta de efetuar um Port Forwarding no IP lan + porta especifica da Camera ou DVR.. dá um "buffer overflow" no cerebro dai vem a luz no fundo do tunel no pensamento "DMZ" Bingo problema resolvido.. quando dá conta o cliente tá ligando reclamado que foi hackeado ou sendo atacado , porque o acogueiro que não sabia criar uma regra simples para liberar uma unica Porta para um unico IP especifico, liberou o DMZ no equipamento colocando "Totalmente Fora da rede de proteção do firewall" o IP especifico da sua camera IP ou DVR..deixando assim todas as portas abertas naquela máquina na rede local "abrindo brecha para um bom exploit script" carregar e depois comecar a atacar ou saquear informacões de todos os outros computadores na rede.
Bom e por ai vai com outros periféricos ou tipo de equipamento
Bom o que eu quero resumir é simples "Segurança" e um bom conhecimento de Rede
DCHP e Pools ranges, discador PPPOE, balancemaneto de carga, todos sabem fazer e proteção na rede?
a Mesma coisa ocorre no dia a dia com Mikrotik "Tem muita função em um só equipamento" Dai o açogueiro vai e carrega a CCRxxxxx com tanta funcão e script, firewall, pppoe, bgp... dai com 500 clientes tá torrando processador "isso claro porque a grande maioria não sabe balancear a carga nos núcleos e dai quando verifica só tem um processador travado em 100%.
Resumindo cada macaco no seu galho..... um equipamento especifico para segurança, um equipamento especifico para link, um equipamento especifico para PPPOE autenticacão, um equipamento especifico para BGP, e por ai vai.
E claro "Contrate um técnico para cada área especifica no seu provedor" só assim irá conseguir se organizar e crescer corretamente.
Um faz de tudo por mais vontade que tenha, não dá conta nem tem tempo de se preparar para gerenciar tudo ao mesmo tempo, é igual ao meu comentário anterior.. Carro Flex
não é uma coisa nem outra, e infelizmente todo o conhecimento tem o seu preço.
Não querendo criticar ninguém mais uma vez repito, todos tem o direito de prosperar e tentar a sua sorte, apesar de sorte não ser um dos quesitos necessários para montar um provedor de internet. :dito: isso boa "Sorte.....conhecimento" a todos.
Agora se perderam acesso ao equipamento o mais adequado e full factory reset, subir telhado por telhado e resetar e limpar potenciais scripts que tenham ficado de algum firmware antigo rodando o script na rede ele consegue mapear os outros equipamentos.
Hummm confesso que fiquei confuso....quem deixou o serviço Webif habilitado para a WAN IP publico? quem deixou a porta padrão 80 e https 443 padrão, quem deixou a porta ssh padrão habilitada?Citação:
Postado originalmente por Bruno
Por ultimo quem falou que o script é executando usando o serviço SSH? A não ser que eu tenha analisado um script totalmente diferente...
O script que eu analisei e confirmo, ele mapeava na rede IP publico:porta padrão/cgi/xxxx
devido ao uso da porta padrão web tomando vantagem do bug no CGI ele tinha acesso ao equipamento ubiquiti sem necessitar sequer saber o usuário ou senha, uma vez penetrado pelo bug CGI, o mesmo começava o modo Zombie, verificava todos os outros equipamentos na mesma rede através do log do sistema da antena.
Lembrando que isso foi possível porque existia uma função no firmware denominada de Custom Scripts, onde foi possível desenvolver um script com funções customizadas para serem executados dentro do equipamento ou seja dando uma liberdade maior para ampliarmos as funcionalidades do equipamento. Porém foi também o grande tendão de Aquiles.
Aug 19 11:57:18 system: Start
Aug 19 11:57:18 syslogd started: BusyBox v1.11.2
Aug 19 11:57:19 FileSystem: Start check...
Aug 19 11:57:20 dnsmasq[1076]: started, version 2.47 cachesize 150
Aug 19 11:57:20 dnsmasq[1076]: compile time options: IPv6 GNU-getopt no-DBus no-I18N TFTP
Aug 19 11:57:20 dnsmasq[1076]: DHCP, IP range 1xx.xxx.xxx.xxx -- 1xx.xxx.xxx.xxx, lease time 10m
Aug 19 11:57:20 dnsmasq[1076]: no servers found in /etc/resolv.conf, will retry
Aug 19 11:57:20 dnsmasq[1076]: read /etc/hosts - 1 addresses
Aug 19 11:57:20 pppd[1075]: Plugin rp-pppoe.so loaded.
Aug 19 11:57:20 pppd[1075]: RP-PPPoE plugin version 3.3 compiled against pppd 2.4.4
Aug 19 11:57:20 pppd[1075]: pppd 2.4.4 started by intervia, uid 0
Aug 19 11:57:20 dropbear[1077]: Not backgrounding
Aug 19 11:57:24 FileSystem: End check.
Aug 19 11:57:29 wireless: ath0 New Access Point/Cell address:8x:xx:xx:xx:xx:xx
Aug 19 11:57:30 pppd[1075]: PPP session is 37092
Aug 19 11:57:30 pppd[1075]: Using interface ppp0
Aug 19 11:57:30 pppd[1075]: Connect: ppp0 <--> ath0
Aug 19 11:57:32 pppd[1075]: Remote message: Login ok
Aug 19 11:57:32 pppd[1075]: PAP authentication succeeded
Aug 19 11:57:32 pppd[1075]: peer from calling number 4x:xE:0x:x2:6x:4x authorized
Aug 19 11:57:32 pppd[1075]: local IP address 191.x.1xx.xxx
Aug 19 11:57:32 pppd[1075]: remote IP address 1xx.xx.xxx.xxx
Dai bingo com remote ip e local ip ele começa a brincar e a tentar se conectar a outros equipamentos comprometidos dentro da REDE.. e quando reparou já tem toda a sua rede comprometida...
Nota referente ao comentário no meu post anterior "BusyBox" :rock:
O que todos notaram foi que a senha tinha sido alterada, tanto para webif tanto para ssh, isso porque depois do script ser carregado no equipamento, o mesmo alterava os dados.
Porém ninguem se preocupou em descobrir como é que ele tinha entrado, e como ele tinha alterado os dados, e por ultimo como ele se estava espalhando para os outros equipamentos.
Eu cheguei a auxiliar outros provedores que não presto acessoria diretamente, mas que na hora do desespero pediram ajuda.
E eu comprovei,depois de remover o script de um equipamento de teste, apenas alterando usuário e senha unico, portas padrão 80,443,22 por outras portas foi o suficiente para eliminar o zombie de se espalhar na rede para os outros equipamentos.
Enquanto que outros equipamentos com as mesmas portas padrão, usuário e senha foram afetados.
O problema se deu na realidade ao uso de porta padrão 80,443 que estava configurado no script.
A grande verdade é essa, se você utiliza ASN com IP Publico no seu Provedor, e alguém de fora consegue acessar a porta WEB via IP publico do seu equipamento instalado no seu cliente, então você tem um problema de segurança sério.
Dos poucos modem adsl da Oi que trabalhei nunca vi nenhum com Porta 80 WebBrowser aberto por padrão default , onde qualquer pessoa digitando o seu IP publico conseguiria acessar.
Nunca vi nenhum equipamento de fibra da vivo vir com porta padrão 80,443 habilitado para porta WAN com IP publico.
Nunca vi nenhuma ONU fiberhome vir com porta padrão 80,443,22 habilitado para WAN IP publico por configuração padrão.
Isto porque as operadoras mencionadas ou fabricantes utilizam protocolo próprio para se comunicar com os equipamentos, atualizacão de firmware etc.. sem ter que habilitar ou colocar em risco nenhum das portas padrão ou protocolos disponíveis para uso de navegação a internet.
Então eu pergunto porque deixar WAN acesso com IP publico autenticado no cliente com porta padrão? Não faz sentido.
Caso o cliente queira assumir o risco, ele mesmo terá que solicitar, caso contrário tudo acesso WAN webif dos equipamentos deve ser fechado completo, em ultimo caso , se for realmente necessário configurar um ddns URL exclusivo ou IP fixo para acesso remoto, configuravel via IPtables
Olá...
Salve ao amigo PortaNET, que tem toda razão, só queria completar aqui se me permitem.
O pessoal que vem aqui no fórum reclamar de Ubiquiti e muitas vezes em grupos do Whats e outros lugares teimam em continuar comprando esse LIXO! Olha eu até acho engraçado que a maioria diz que usa UBNT por que MK é muito complicado, tem muita opção, resumindo acabam se declarando amadores e dando o títudo de "Pica da Galáxia" pra quem sabe trabalhar com MK. Leiam o que vocês mesmo vêm escrevendo a praticamente uma década sempre falando mal de UBNT e dizendo que MK é difícil, será que ainda não deu tempo pra entender que é só parar de ser preguiçoso e fazer igual o Saudoso Clóvis de Barros diz
https://www.youtube.com/watch?v=Utfv3h5Y_rE
Senta a bunda na cadeira e estuda ou paga pra alguém que sabe fazer o certo pra você, do contrário vão se passar mais uma década e você ainda vai estar ai falando mau de UBNT e continuando a usar ele. kkkkkkkkkkkkkkkkkkkkkkkk
Esse povo que vende ubiquiti olha uma promoção incrível e olha a oportunidade de ganhar uma grana as custas da desgraça dos outros, ai compra uma montanha dessas porcarias a preço de banana e faz uma promoção ai manda pro dono do provedor, o cara não sabe contabilizar custo X benefício, esquece de contar o tempo, combustível, stress, desconto de mensalidade e uma porrada de complicações que todo mundo já sabe que essas merdas de UBNT causam o cara na hora de por a mão no bolso só pensa em custo = valor do equipamento e benefício = ??? muita gente pensa, que por ser 5.8 não sei quantos Db de potencia, e não sei mais o quê, acha que é tudo a mesma coisa....porra, a diferença de um UBNT ou qqr outra marca lixo salvo as que tem precedentes pra um MK é astronômica então aprenda de uma vez por todas, se você comprar lixo você vai ter um monte de sujeira pra limpar depois.
Minha rede tem muito mais RMA em ubiquiti.
Virus somente em ubiquiti
problemas de sinal e lan off somente em ubiquiti
Onde rodo com mk é só alegria.
Desejo a falencia dessa empresa xulera
E nao me venham com essa de lição de casa