É cliente da NOS (antiga ZON)? Possui o router/HUB desta? Então este artigo é para si.
Aviso desde já que é um longo artigo. Seria importante ler tudo, mas deixo alguns “cliques rápidos”.
– Inicio
Antes de tudo, e para evitar problemas mais adiante, é importante referir que este artigo possui apenas carácter informativo. Com este apenas pretendo partilhar o que recentemente descobri e, nas minhas pesquisas, penso que seja do desconhecimento de muitos. Acho importante partilhar algo que possa afetar diretamente a nossa privacidade enquanto utilizadores da Internet e cidadãos.
Passando ao importante: Não é segredo nenhum que, se uma operadora assim o pretender, pode saber exatamente o que qualquer cliente faz na Internet. A NOS não é exceção.
Sendo eu próprio cliente da NOS, e possuindo um router/hub desta, sempre me interessei por saber mais acerca do equipamento que esta fornece. Afinal, qualquer “aventureiro” nestas andanças pretende saber as potencialidades do que possui.
Atualmente a NOS disponibiliza dois tipos de routers (ver site), que apesar de diferentes no aspeto, possuem em base o mesmo sistema (Jungo OpenRG, agora Cisco Videoscape OpenRG). Estes permitem aos clientes acederem à internet e contam com uma variedade adicional de funcionalidades, como a configuração de discos externos e impressoras em rede.
Em base, o router até é de qualidade e com funcionalidades agradáveis, isto se tivermos em vista a maioria das operadoras em Portugal e os equipamentos que estas fornecem.
No entanto, o importante neste campo é o software. A interface do router pode ser acedida pelo tradicional 192.168.1.1, sendo que permite um rápido acesso a várias funcionalidades.
A NOS/ZON sempre ocultou muitas das funcionalidades mais avançadas do router. Em parte esta medida evita que os clientes realizem alterações que possam levar a problemas, e consequentemente reduzem o número de pedidos de assistência técnica neste sentido.
Os mais aventureiros devem-se lembrar de páginas escondidas no hub, como a “active_page=page_conn_settings_ra0” ou a “active_page=page_conn_settings_vw0”. Estas páginas permitiam alterar várias definições da rede sem fios e por cabo. A título de exemplo, poderia-se aplicar servidores DNS específicos ou alterar a velocidade da rede sem fios para 300Mbps (atenção, é a velocidade da rede sem fios, não da internet =) )
No entanto, tão rapidamente quanto as páginas surgiram, a ainda antiga ZON disponibilizou uma atualização no software que, basicamente, “matou” todas as possibilidades de aceder às mesmas. A versão mais recente do router (atualmente, no caso do Zon Hub v3, é a versão 4.11.3.7.62.3.52) impede o acesso a todas as páginas anteriormente conhecidas, sendo que agora apenas surge o erro de uma página expirada:
Isto foi bom para a ZON, já que reduziu (provávelmente) problemas técnicos, mas também revoltante para certos utilizadores. Afinal, a própria empresa encontra-se a evitar o acesso a muitas das funcionalidades que os utilizadores poderiam ter acesso para melhorar o equipamento que possuem. E o hub até possui boas capacidades, mas agora encontram-se “perdidas” entre os impedimentos da empresa (que, leia-se, esta encontra-se no direito de impedir o acesso, por muito revoltante que seja).
A piorar o caso, em meados de 2013 começaram a surgir notícias relativas a possíveis acessos remotos ao hub por parte da empresa
Qualquer utilizador com um equipamento da ZON possui sempre acessível, publicamente na Internet, a porta 7654 (IP_EXTERNO:7654). Este acesso encontra-se limitado, segundo a empresa, para questões técnicas, mas, mesmo assim, é uma potencial vulnerabilidade externa que pode afetar qualquer utilizador da NOS em vários sentidos.
Quando um utilizador tenta aceder a esta porta, e realiza o login com sucesso (“acs” em ambos os campos de login) apenas se depara com uma mensagem de erro “405”.
Isto ocorre devido ao acesso não ter sido realizado a partir de um servidor remoto autenticado.
O acesso remoto é providenciado como parte de uma das funcionalidades do Jungo OpenRG, o utilizado no router. Este apenas é possível de ser realizado externamente a partir de um servidor próprio da NOS, que possui uma chave única. Qualquer outro acesso não possui funcionalidade prática.
E é aqui que se encontra o primeiro ponto de discórdia para muitos. Em tempos vários utilizadores criticaram o facto de a empresa poder ter acesso remoto aos hubs. E a verdade é que, apesar de a empresa poder controlar o que é seu, com o acesso remoto qualquer funcionário da assistência técnica pode alterar definições no router, ver quais os equipamentos ligados na rede e sabe-se lá mais o que.
Depois de esta “vulnerabilidade” ter sido revelada, vários sugeriram medidas para ultrapassar o acesso remoto, entre as quais se encontra a alteração da password e nome de utilizador do login. Mas será que resulta?
Sendo eu aventureiro, decidi perder um tempo a verificar bem o que se encontra no equipamento que todos os clientes da NOS/ZON possuem e o que realmente é feito, sendo que fiquei realmente com certas questões.
– Ponto 1
Comecemos voltando um pouco atrás, nomeadamente às páginas que se encontram “escondidas”.
Quando se acede à interface de administração do router, após o login deve-se aceder a um link similar a este:
http://192.168.1.1/index.cgi?host_mac=XXXXXXXX&active_page=page_sys_overview&prev_page=page_ln_overview&req_mode=0&(…)
Basicamente, vários parâmetros encontram-se a ser enviados via o ficheiro “index.cgi” para aceder aos conteúdos da interface. Entre estes podemos destacar:
– “host_mac”, que indica o MAC do equipamento
– “active_page”, que indica a página atualmente aberta
Entre outras…
Enquanto me encontrava a verificar a interface, decidi remover a ligação do cabo do router à rede da ZON, deixando assim de ter ligação à internet. Quem já alguma vez teve alguns erros na ligação, em certos casos deve verificar que é apresentada uma página de erro genérica da ZON, a informar a indisponibilidade da mesma ou que a ligação se encontra a ser realizada, dependendo do tipo de ação realizada.
No entanto, o que me chamou à atenção foram várias variáveis que se encontravam no link do endereço. A título de exemplo, quando tentamos aceder a “Google.pt”, e surge a página de erro, deve-se a ter ocorrido um redireccionamento da ligação para a página interna no router. No mesmo formato, algo similar a:
http://192.168.1.1/index.cgi?host_mac=XXXXXXXX&(…)
Só que, neste caso, são transmitidas novas variáveis. Depois de explorar um pouco as novas variáveis, e de várias tentativas e erros, cheguei a algo curioso.
Quando se realiza o acesso a uma página que, supostamente, não deveríamos ter acesso ou com variáveis não autorizadas, é quase sempre apresentada a mensagem de erro de “página expirada”. Só que, depois das tentativas que realizei (e que, leia-se, foram bastantes), cheguei a esta página:
Como se pode verificar pela imagem, aparenta ser a página inicial da interface, mas com alguns erros estéticos.
Tendo realizado o login com o utilizador “home_admin” (para quem não sabe, permite o acesso a mais opções dentro da interface do router), fui verificar o registo da firewall e identifiquei algo similar a isto:
Ou seja, tinha realmente conseguido realizar o login na interface e sobre variáveis que, em casos normais, deveriam apresentar a página de erro de expiração.
Mas o interessante é que este acesso foi baseado no método de “tentativa e erro”. Apenas comecei a alterar/introduzir variáveis do link e a introduzir códigos nas mesmas que iam surgindo, sendo que, após várias horas, lá consegui entrar com uma combinação especifica.
Uma das variáveis que introduzi foi a “active_page” que, como referi anteriormente, indica a página que se encontra ativa para o utilizador. Depois de ter conseguido realizado o acesso com as variáveis corretas, mais uma vez, lá tentei alterar esta variável para uma das que tinham sido anteriormente bloqueadas, e voilá:
Neste exemplo utilizei a página “page_conn_settings_ra0”, mas pode ser alterada para qualquer outra que seja conhecida, e o utilizador poderá ter acesso à mesma.
Apesar disto, nem sempre o acesso ocorre como o esperado. Para alternar entre as abas é necessário introduzir uma nova variável: tab4_selected=XX
Esta foi obtida tendo em conta o link das próprias abas, bem como o número associado (XX):
Se tentarmos alternar diretamente para uma aba, sem utilizar a variável no link, a página apenas atualiza para o já conhecido erro de “página expirada”.
O mesmo ocorre quando tentamos clicar em botões como o de “Aplicar” ou “OK”. Sim, isso indica que muitas das alterações que poderia realizar nestas páginas não poderão ser guardadas. Mas a verdade é que estas são guardadas, na generalidade dos casos.
Quando clicamos num botão para guardar os dados introduzidos (como o OK ou Aplicar), somos redirecionados para a página de erro ou a página inicial da interface regular, mas podemos retroceder no navegador novamente para a página das configurações e clicar uma segunda vez nos botões, sendo que, repetindo mais uma vez o processo, os dados ficam guardados (na maioria dos casos – nada é perfeito =) ).
Ou seja, resumindo, nesta primeira parte comecei por descobrir como aceder às páginas que anteriormente se encontravam bloqueadas. E o mais engraçado é que nem foi preciso muito para tal nem recorrer a métodos mais invasivos. Basta ter paciência e ir tentando. E, sendo totalmente sincero, nem sei totalmente como consegui. Apenas comecei a alterar, adicionar e remover variáveis no link até lá ter chegado à combinação certa.
Ao que tudo indica, a falha pode ser explorada devido ao facto do ficheiro CGI encontrar-se a interpretar incorretamente as variáveis ou as permissões associadas (mas posso estar totalmente errado). As páginas bloqueadas apenas deveriam ser acessíveis a um utilizador que possuísse permissões para tal. O utilizador “home_admin” é, atualmente, o conhecido como tendo as maiores permissões de acesso, mas não deverá ser o único. É provável que existam outros utilizadores dentro da interface do router, mas dos quais para “nós”, enquanto clientes, não tenhamos acesso. Ou que esteja apenas acessivel via software externo.
Para este método funcionar basta que o utilizador possua acesso à interface de gestão do router. Não necessita de ser um utilizador com permissões completas de acesso à mesma.
Importante também de referir que, apesar de tudo, e antes de se começar a “apontar dedos” à NOS, este acesso é possível devido sobretudo ao software utilizado (Jungo OpenRG) e não à NOS em si. Basicamente, é uma falha do próprio software presente no router, não do router em si ou da NOS. Apesar de não ter testado diretamente, é provável que o mesmo pudesse ser utilizado em qualquer outro equipamento com o OpenRG, seja da NOS ou não.
Com este ponto tratado, comecei a explorar um pouco mais o sistema. E assim avançamos para o ponto 2.
– Ponto 2
Como referi inicialmente, a interface do router é baseado no sistema OpenRG, da Jungo. A Jungo foi entretanto adquirida pela Cisco, pelo que faz parte agora desta.
Entre o portefólio de serviços e funcionalidades da Jungo encontra-se o do acesso remoto a routers por parte dos ISP’s (que é exatamente o que ocorre na NOS com a porta 7654, mas não só, como iremos ver adiante).
Sabendo qual o sistema que o router possui, não é muito difícil procurar na internet páginas específicas para a interface deste. Neste caso, o que importa seriam os termos que podem ser adicionados na variável “active_page”, e pesquisando na Internet, ainda se encontram alguns.
Deixo alguns exemplos que descobri:
– “page_about”
Esta página pode também ser acedida normalmente pela interface, via o termo “page_sys_overview” – http://192.168.1.1/index.cgi?active_page=page_sys_overview – no entanto, utilizando o método anterior, apresenta mais informações sobre as funcionalidades ativas no router.
No caso do router da NOS apresenta-nos esta listagem de funcionalidades:
NetFilter Linux Firewall, ICMP ALG, Port trigger (TFTP) ALG, FTP/FTPS ALG, QuickTime/RealAudio/RealPlayer (RTSP) PROXY, H323 ALG (Netmeeting, CuSeeMe …), SIP ALG, MGCP ALG, PPTP Client (multiuser) ALG, Microsoft Network Messenger/Windows Messenger ALG, IPSec (multiuser) ALG, L2TP ALG, AOL Instant Messenger ALG, DNS ALG, DHCP ALG, Switch, Bridge, VLAN 802.1Q bridge, VLAN 802.1Q interfaces management, Media Server, IGMP Proxy, Jungo Firewall, NAT, Secure HTTP (SSL), Permanent Storage, Reverse NAT, Universal Plug & Play, Remote Upgrade from WAN, DNS, Dynamic DNS, Email Notification, Generic Proxy, RADIUS Client – External Authentication, DHCP Server, DHCP Client, DHCP Relay Agent, Static HTML Management, Web Based Management, Reduce Support Calls, TimeZone support, HTTP Server, Telnet Server, SysLog, Command Line Interface, TOD Client, File Server, Print Server, Internet Printing, Remote Update Management, Remote Management Server, Event Logging, QOS support, 802.1p to DSCP translate
A partir daqui podemos encontrar algumas das funcionalidades que o router possui. No entanto, nem todas aparentam encontrarem-se ativas, como é o caso do servidor Telnet. Para surgirem nesta lista, até poderão encontrar-se efetivamente no router, mas deverão encontrar-se sobre localizações/páginas diferentes.
– “page_conn_settings_XXX”
Estas são as páginas de configurações avançadas das redes. Bastará substituir o “XXX” pela interface associada (como ra0 ou br0) para aceder às respetivas páginas de configuração.
– “page_system_settings”
Aqui encontram-se as definições principais do router. É possível alterar nome do mesmo ou as portas de acesso (por exemplo, a porta de acesso tradicional 80). Destaque ainda para a funcionalidade de “Swap” que pode ser ativada, caso se possua uma pen ligada ao router. Por padrão encontra-se desativada, mas não identifiquei diferenças significativas em ativar a opção.
De sublinhar ainda a existência da opção de alterar as portas do serviço “jungo.net”, que corresponde ao serviço de acesso remoto (iremos analisar este ponto mais à frente).
– “page_upnp”
Permite ativar ou desativar a limpeza automática das definições UPnP
– “page_wins_server”
Permite alterar definições relacionadas com servidores “wins” na rede local. Útil apenas em alguns casos…
Estas são apenas algumas das páginas que poderemos ter acesso, mas que se encontram bloqueadas no acesso regular. Existem mais, e podem ser rapidamente encontradas com uma pesquisa na Internet.
No entanto vamos avançar para duas páginas particularmente interessantes: a “page_remote_admin” e “page_jnet_client”.
Começando pela “page_remote_admin”, esta permite configurar o router para autorizar ligações a partir da internet (WAN). Ou seja, poderemos configurar o router para que seja acedido via o IP externo da ligação à internet, tal como se fosse acedido via a rede interna.
Pode ser util para certos utilizadores que pretendam controlar remotamente o router, mas também podem levar a acessos indevidos. Neste campo são utilizados os dados de login dos utilizadores, tal como ocorre na rede interna (por padrão admin e home_admin).
Encontramos ainda opções de ativação do servidor Telnet. Infelizmente, estas opções não produzem efeito. Enquanto podemos guardar todas as restantes opções desta página, as relacionadas com o telnet são eliminadas. Provavelmente isto ocorre devido ao facto do software não permitir o acesso telnet (e não encontrei forma de ultrapassar isso). Existe também uma opção de “Ferramentas de Diagnostico”, que permite a ativação de suporte a ping/traceroute externo ao router.
No entanto o interessante é a secção “Jungo.net (jnet)”.
O Jungo.net trata-se do serviço da Jungo/Cisco que permite o acesso remoto ao router por parte da NOS. Podemos verificar que temos a opção para ativar/desativar a mesma, bem como algumas opções relativas ao servidor remoto de acesso.
Neste caso temos o domínio “jrms.zon.pt”, que diz respeito ao sistema do qual a NOS poderá aceder ao router. Basicamente, apenas os servidores que se encontrem dentro deste domínio, e possuam a chave SSL correta (bem como os dados de login), é que poderão aceder ao router externamente.
E aqui entra a suposta porta 7654. Esta deveria ser a porta que os técnicos utilizariam para aceder, mas, verificando as definições anteriores do router, na página “page_system_settings”, verificamos que existem duas portas distintas para o acesso: a “4683” e “4684” (sem ou com ligação SSL).
Como não tenho acesso ao software da jungo, não sei bem o que é realizado. No entanto isto leva-me a crer que a ligação à porta 7654 pode não ser a única a ser realizada de forma remota.
Antes de tudo, sublinhar que isto são apenas suposições, pois não tenho forma em concreto de verificar isto (pelo menos não descobri nenhuma), mas se as configurações do router possuem especificadas as portas 4683 e 4684, não faria sentido que fossem essas as portas utilizadas para o acesso remoto que a NOS/ZON realiza? Então qual o motivo da porta 7654 se encontrar acessível?
Não sei se existe algum reencaminhamento das portas, de forma interna (e é o que parece ser mais provavel), mas a verdade é que me deixou confuso sobre qual é realmente a porta utilizada. Em ambos os casos, as portas 468X não possuem acesso externo aparente, como ocorre na 7654.
Avançando, temos ainda as opções “Jungo.net ACS URL” e “Página inicial do jungo.net”, que dizem ambas respeito ao domínio remoto que a NOS utiliza para aceder. Temos a indicação da página https://jrms.zon.pt/jnet_rg2.cgi, que basicamente é onde residem as configurações do acesso remoto da NOS (segundo a documentação que encontrei da Jungo). No entanto, quando se tenta aceder à mesma, ocorre um erro na ligação SSL.
Este erro ocorre visto que o sistema da Jungo necessita que o ISP crie uma chave única para a ligação remota. Desta forma, a menos que esta chave esteja guardada no computador que se encontra a aceder, os utilizadores comuns não deverão ter acesso ao sistema da NOS (e ainda bem que assim é).
A ligação via SSL não é, portanto, possível de ser realizada, mas a ligação normal (sem segurança SSL) é. Quando acedemos via regular, a página específica do ficheiro CGI não nos dá muitas informações, já que apenas fica em carregamento e sem utilização aparente. Isto provavelmente porque o acesso apenas é possível via o SSL, e com a respetiva chave, mas é um avanço.
Se acedermos diretamente a http://jrms.zon.pt/ surge-nos uma mensagem de erro “404” (Not found). Mas, novamente, via SSL surge-nos a informação de erro na ligação (tendo em conta o referido em cima).
Teoricamente, se eu desativar a opção “Jungo.net (jnet)” nesta página do router, deverei impedir que a NOS tenha acesso remoto ao mesmo, visto que estarei a desativar o serviço neste. Será que desativa a ligação à porta 7654?
Teste depois de ter desativado a opção:
Não obtive mutios resultados neste aspecto. A porta permanece ativa externamente e acessivel, sendo apresentado o mesmo erro.
No entanto existem alguns resultados positivos. Na página correspondente ao registo do sistema podemos encontrar isto:
Isto poderá indicar que o serviço utilizado no acesso remoto foi parado e, portanto, não deverá agora ser possível utilizar o mesmo para o acesso ao router. Resumindo, a porta permanece efectivamente ativa, mas a funcionalidade que é utilizada (jnet – Jungo.net) não, pelo que fica sem efeito. Novamente, não sei clarificar exatamente se a opção está realmente desativada, mas assim aparenta.
E aqui se põem uma questão: porque razão não fornece a empresa o acesso a esta funcionalidade, possibilitando assim os utilizadores que consideram esta medida uma “invasão de privacidade” a desativação da mesma?
Questões à parte, vamos avançar para outro ponto. Neste caso passamos para a página “page_jnet_client”. Esta aparenta ser a página onde a equipa técnica da NOS iria aceder para realizar o login remoto:
Podemos verificar os campos de login, bem como vários links para Registar uma conta, Recuperar a password e Gerir a conta.
Estes links dizem respeito ao servidor “jrms.zon.pt”, sendo que, como vimos anteriormente, não se possui acesso direto aos mesmos. Clicando nos links apenas surge a indicação de erro 404.
No entanto verifiquei algo interessante nestes links. Vejamos o exemplo do link respeitante à opção de Registar uma nova conta Jungo:
http://jrms.zon.pt/index.cgi?register=y&u= KFpPTiBIVUIgZGF0YQogICh3Ym0KICAgICh0aGVtZShvcGVucmcyKSkKICAgICh (…)
Como se pode ver, existe uma variável “u”, seguida de um código. Os mais atentos deverão reparar que se trata de código codificado no formato “base64”. No link em cima ocultei uma grande parte do código, mas poderão testar a descodificação.
Já me tinha deparado com códigos similares que surgiram durante as minhas tentativas iniciais e durante o acesso às páginas de erro do router, mas depois de avançar mais, chega-se a algo…
Vendo o conteúdo do código, encontro algo um pouco inquietante:
O conteúdo deste código é o que, a mim, me deixa um pouco preocupado quanto à privacidade de alguns utilizadores. No campo referido em cima poderemos encontrar que, no código do link, encontra-se a referencia ao nome completo (full_name).
Este nome diz respeito ao que se encontra aplicado na lista de utilizadores, como sendo o nome completo do utilizador. Provavelmente, tratando-se de um link de registo de uma conta, seria utilizado para preencher automaticamente alguns campos no servidor remoto. Mas, mesmo assim, são dados pessoais que muitos alteram (principalmente os que tentaram no passado evitar o acesso remoto ao router).
Este dado encontra-se a ser enviado para servidores remotos, via uma linha não segura e uma encriptação básica como é o “base64”. É certo que este nome de utilizador nem sempre é alterado, mas os que assim o fizeram colocaram muito provavelmente o nome de utilizador que utilizam para realizar o login ou outro mais “pessoal”.
Se tentarmos aceder ao link em questão, porém, apenas surge a mensagem de erro 404…
Alguns poderão indicar que estes dados apenas são enviados quando realmente clicamos no link. E é verdade.
Mas como referi anteriormente, em muitos casos vi este mesmo código a ser introduzido nas páginas de erro que são apresentadas quando existe uma falha na ligação, com variáveis associadas a “send” e similares.
Do meu ponto de vista, não vejo isto como um problema grave, já que pouco de “privado” daqui se obtém, mas deixou-me aberto a outras questões.
Uma das páginas a que podemos ter acesso via o método referido em cima é a “page_dump_conf”.
Esta permite realizar o download dos ficheiros de configuração do sistema openRG. Basicamente, são todas as configurações aplicadas no router.
Utilizando este método, não consegui colocar a página a descarregar as configurações. Sempre que se tenta aceder surge o erro “500 Internal Server Error – CGI Failed”.
Esta página, em concreto a página no “iframe” e que corresponde ao botão para descarregar a configuração, pode igualmente ser acedida por qualquer um – http://192.168.1.1/rg_conf.cgi?is_dump=1 – mas sempre com o mesmo erro (a variável “is_dump” é opcional). Parto do pressuposto que o utilizador não possui permissões suficientes para aceder à página, e dai o erro.
De acordo com a documentação da OpenRG, entre as configurações que se encontram neste ficheiro estão os nomes de utilizadores registados na interface, bem como as passwords – Link do Manual
Vendo a documentação, no ponto 2.1 – Users, temos entradas que indicam o nome de utilizador e a password de acesso à interface web (a página do router).
Aqui entramos num campo de suposições. Não sei se a NOS possui acesso a estes ficheiros de configurações (fica na opinião de cada um se sim ou não), mas assim sendo, esta possui, via o acesso remoto anterior, acesso a todas as configurações do router, onde se inclui o nome de utilizador e a password de acesso.
Muitos dos métodos que foram difundidos para “bloquear” o acesso remoto via a porta 7654 baseavam-se na alteração do utilizador/password que era utilizado no login da interface web. Se a NOS realmente tiver acesso a estes dados (e sublinhe-se o “se”) então pouco adianta alterar os mesmos. Estes irão sempre ser enviados no ficheiro de configuração do OpenRG, supondo que o acesso via o sistema da Jungo não é bloqueado ou que existe um utilizador (até à data desconhecido) que possua permissões superiores à do home_admin.
Todos estes pontos são válidos se realmente a NOS tiver acesso à página para descarregar o ficheiro de configuração. Partindo do pressuposto que o erro 500 é devido às permissões ou a outra questão relacionada com o utilizador, então aqui se encontra algo importante.
Quantos são os que alteraram a password padrão do router, como a própria NOS indica no seu site? – http://www.nos.pt/particulares/ajuda/equipamentos-servicos/internet/internet-fixa/Pages/default.aspx
E quantos colocaram uma password que potencialmente utilizam em outros locais? Estão a ver onde quero chegar, certo? =)
Atenção que estes últimos pontos partem de completas suposições. Não sei se realmente a NOS possui acesso à página de configurações (e não existe forma de saber sem ser oficialmente). O erro 500 poderá ser um erro efetivo do software openRG, já que a página não deveria ser acedida. Nesse caso, a NOS também não deverá ter acesso à página e, portanto, os dados devem permanecer seguros. Mas existe igualmente a segunda opção: o reverso da medalha.
– Pontos Finais
Para finalizar tenho de dizer:
Enquanto cliente da NOS, nunca tive razões de queixa desta. Alias, até é uma das empresas que considero ser das melhores entre as existentes no mercado. Mas existem certos pontos que deveriam ser explicados um pouco em mais detalhe ao cliente.
O caso da porta 7654 é um deles, sendo que, na minha opinião, cada um deveria ter a possibilidade de desativar esta porta se assim o entende-se (e de a ativar também).
Este “longo” texto serve apenas para expor algo que considero ser importante para todos os clientes da empresa. Encontro muita informação relativa à porta 7654 e afins, datada dos últimos anos, mas nenhum relativamente a estes acessos de páginas adicionais e os dados que realmente são enviados para a NOS (ou qualquer outra empresa onde o sistema esteja implementado)
Ouvi e li muitos utilizadores a criticarem a NOS sobre este problema, mas ninguém soube dar uma explicação coesa sobre o que se encontra realmente por detrás da porta 7654 e espero que este meu artigo ajude nisso.
Utilizem o mesmo como entenderem, partilhem se assim quiserem… Mas é escusado questionarem-me “como fizeste isso?” ou similares. Não pretendo partilhar publicamente os métodos que utilizei para aceder às páginas “escondidas” (se realmente não forem já conhecidos) ou a qualquer outra das definições em cima referidas.
Não vejam isto como algo “rude” da minha parte. Existem boas razões para estas páginas encontrarem-se inacessíveis. Algo incorretamente aplicado e ficam com uma “pedra grande” em casa. Bem como podem levar trabalhos adicionais a quem se dedica à manutenção dos equipamentos. Este é um dos vários motivos para o qual não irei revelar como realizar estes procedimentos.
Nâo tenho problemas em indicar os passos à própria NOS, se assim o requeira, mas não a quem apenas pretenda “brincar” com o equipamento.
O meu objetivo ao partilhar este conteúdo é informar os clientes da NOS para o que PODE, sublinhe-se este ponto, encontrar-se a ocorrer dentro do equipamento que possuem. Vejam também como uma sugestão para a NOS em melhorar sobre vários pontos.
Se realmente qualquer fornecedor de acesso à internet quiser monitorizar um certo cliente, existem métodos muito mais simples e viáveis para esta. O acesso remoto via o sistema da Jungo é apenas uma medida, e provavelmente das mais básicas que existe, mas que também vos pode ajudar, enquanto clientes, quando tiverem problemas com as vossas ligações. Pensem nisso da proxima vez que a ligação à internet estiver com problemas e a NOS consiga ajudar “remotamente”.
Reforço que o problema também não é inteiramente da parte da NOS, mas sim do próprio software OpenRG utilizado no router, e do qual, da parte da NOS, acho que merecia uma séria atualização para algo mais seguro e consistente. E, como opinião própria, para algo que permita configurações aos utilizadores mais avançados.
Dito isto, fica ao critério de cada um as opiniões.
