Foro

Avatar de cerm
cerm
Yo probé el VDSL
28-02-2023
Resuelto

Reportando posible bug en router Mitrastar (HGU) GPT-2541GNAC

Estoy tratando de abrir ssh desde el exterior hacia una máquina interna. Eso siempre lo he hecho en configuración avanzada del router, en este caso NAT/Virtual Server. Se puede ver en la foto los datos que estoy intentando, y el error absurdo con el que me responde:

Router rechaza redirigir ssh!

El router dice que el puerto está usado por ssh. Pues claro, necesito usar el servicio ssh, pero en un puerto exterior alto. Si lo intento con telnet, me deja (telnet está en la lista de "select a service", pero ssh no).

 

Vale. Pues entonces me vuelvo a la configuración simple. Ved la foto:

Configuracion simple exitosa

Esta configuración la admite sin problemas. Veamos ahora en configuración avanzada, a ver qué es lo que ha hecho:

Éxito

Como se puede ver, ha hecho exactamente lo mismo que intentaba hacer antes y que decía que era imposible. Eso, en mi opinión, es un bug.

 

(Llevo una semana intentándolo)

 

Haciendo esta trampa, el ssh a mi máquina interna funciona perfectamente, tal como he venido haciendo durante años con el router anterior a este.

 

Gracias.

  • Avatar de cerm
    cerm
    21-04-2023

    Disculpad el retraso.

     

    El problema reportado en este hilo es un bug en el firmware del router, y sólo se solucionará cuando Telefónica desarrolle y publique el parche.

     

    El otro problema, la pérdida de paquetes entre router y switch, se ha solucionado con una actualización en el switch hace un par de días.

     

    De paso comentar que el router tiene otro bug, muy grave, y es que el cortafuegos de entrada no funciona en IPv6, dejando expuesta toda la intranet. Lo menciono aquí para que conste, y también lo he dicho en la zona Beta.

17 Respuestas

Las respuestas se han desactivado para esta discusión
  • Avatar de Theliel
    Theliel
    Yo probé el VDSL
    02-03-2023

    Buenas cerm 

     

    Me alegro que te sirviese 🙂

     

    Y sí, en lo personal es algo totalmente imprescindible, ya no solo por ahorrar tiempo, sino porque permite tener a tu mano un sin fin de posibilidades que de otro modo sería totalmente imposible, creo que el día que Movistar entienda que esto es un enorme valor añadido y que pesa mucho más que el querer los fabricantes o ellos mismos "ocultar" ciertas cuestiones. Pero creo que sería aportar y tener algo en el mercado que ningún otro ISP tiene a día de hoy: Transparencia, control por parte del usuario.

     

    No puedo ni imaginarme el gran nicho que habría con ello!! Hilos o incluso secciones propias para ello, de maravillas posibles que se podrían hacer, aunque no fuese con un soporte oficial de Movistar, es decir, un poco tu te lo guisas tu te lo comes. Pero... que le vamos a hacer.

     

    Saludos.

  • Avatar de cerm
    cerm
    Yo probé el VDSL
    02-03-2023

    Fantástico!

    cer@Telcontar:~> ssh  1234@192.168.1.1
    1234@192.168.1.1's password: 
     fail to read file > natp add Apache ppp0.1 TCP 6000:6000 6000:6000 192.168.1.16
    natp: add natp operation successfully on 'Apache'
     > natp show table
    DMZ Host Disabled
    
    Service waninterface protocol   externalport internalport IP Address     status
    Name                            start:end    start:end
    ssh     ppp0.1       TCP        5000:5000     22:22    192.168.1.16    Enable
    Apache  ppp0.1       TCP        6000:6000  6000:6000 192.168.1.16    Enable
     > quit
    
    Bye bye. Have a nice day!!!
    Connection to 192.168.1.1 closed.
    cer@Telcontar:~> 

    Pues es una fastidio que no lo publiquen. Con el tiempo que ahorra algunas veces...

    Gracias por el aporte 🙂

     

  • Avatar de Theliel
    Theliel
    Yo probé el VDSL
    01-03-2023

    Buenas cerm 

     

    No existe documentación, hace ya mucho tiempo que suprimieron la salida de prácticamente cualquier comando, con lo que es "complicado". No obstante hay "modos" de saberlo.  La Shell reducida en este caso si permite hacerlo, sería así:

     

    natp add ssh ppp0.1 TCP 5000:5000 22:22 192.168.1.45
    natp delete ssh
    natp show table

     

     

  • Avatar de cerm
    cerm
    Yo probé el VDSL
    01-03-2023

    No pasa nada 🙂

     

    Oye, ¿sabes si los comandos del ssh de este router están documentados en algún sitio? No responde ni a "help" ni a "?". En cambio, sí responde a "wan show", aunque protestando y soltando errores, los datos esperados los saca.

     

    Lo digo porque igual se puede configurar puertos por ese otro camino.

  • Avatar de Theliel
    Theliel
    Yo probé el VDSL
    01-03-2023

    Buenas cerm 

     

    Gracias por la aclaración compañero, el problema de no ver las imágenes y la costumbre de contestar algo que suele ser reiterativo, que no era tu caso, mis disculpas.

     

    Y si tienes razón, acabo de acceder por remoto a un par de unidades que controlo y el código está mal y no tiene mucho sentido, el puerto interno obviamente es el puerto del equipo local, en nada tiene que ver con el Router, el código está mal, lo estaba mirando...

     

    La primera parte es relativa al puerto 23,2169 y 161 (interfaz avanzada siempre), y lo que hace es comprobar si el puerto inicial/final externo es el mismo que el inicial/final interno (para esos 3 puertos), los cambia al 2323, 2121 y 1616 respectivamente... vale, puedo entenderlo, aunque aplicando esa lógica no te permite (tenga mucho sentido o no) mapear un 23 externo a un  45000 interno, porque no es el mismo puerto... pero vale

     

    La segunda parte es donde la han liado aun más, y se aplica al 7547, 22 y 443. En este caso no los cambian, vale, entiendo que es por importancia para el Router el poder usarlos, pero el problema es que en vez de comprobar el puerto externo, las comprobaciones la hacen con el puerto interno. El código en esencia dice que si el puerto inicial interno es menor o igual que 22 y el puerto interno final es mayor o igual que 22, mensaje de error y se aborta. Tiene poco sentido teniendo en cuenta que el puerto final no permite modificarlo y es siempre el mismo puerto que el inicial, pero bueno... y sin contar obviamente que lo que hace es mirar el puerto interno, no el externo

     

    Vamos, pifiada....

     

    Se puede de todos modos enviar la modificación lanzando la petición directamente, pero casi más fácil desde la interfaz simple:

     

    http://192.168.1.1/scvrtsrv.cmd?action=add&srvName=ssh&dstWanIf=ppp0.1&srvAddr=IP_LOCAL&proto=1,&eStart=5000,&eEnd=5000,&iStart=22,&iEnd=22,&sessionKey=KEY_SESION

     

    Donde IP_local es el equipo local y Key_sesion la genera una vez accedes, se puede mirar en el código cada vez.

     

    En cualquier caso sí, es un fallo de la firmware, nada tiene que ver con los puertos internos al uso, siento mi equivocación, un saludo y buen aporte.

  • Avatar de cerm
    cerm
    Yo probé el VDSL
    01-03-2023

    Theliel  ha escrito:

    Buenas cerm 

     

    Las imágenes no pueden verse hasta que no se habiliten, pero en cualquier caso te lo explico, no es "ningún" error.

     

    Los HGU, todos ellos, usan el 22/443 y algunos de ellos el 80 y 23 también, para uso externo propio, para la gestión del propio equipo. Esto hace como es lógico imposible su uso, porque ya se están usando. O lo usas para el acceso al Router o lo usas para el acceso a un equipo en LAN, obvio. Esto implica por ende que, si el Router no permite modificar los puertos internos, no puedes mapearlos.

    Deberías haber esperado a ver las fotos, porque yo no estoy abriendo el puerto 22. Estoy abriendo el puerto 5000 (en el router) al exterior. Lo que llega al 5000 exterior se manda al 22 de una máquina interior a la LAN, que no es el router.

     

    😉

     

     

     

     

     

  • Avatar de Theliel
    Theliel
    Yo probé el VDSL
    28-02-2023

    Buenas cerm 

     

    Las imágenes no pueden verse hasta que no se habiliten, pero en cualquier caso te lo explico, no es "ningún" error.

     

    Los HGU, todos ellos, usan el 22/443 y algunos de ellos el 80 y 23 también, para uso externo propio, para la gestión del propio equipo. Esto hace como es lógico imposible su uso, porque ya se están usando. O lo usas para el acceso al Router o lo usas para el acceso a un equipo en LAN, obvio. Esto implica por ende que, si el Router no permite modificar los puertos internos, no puedes mapearlos.

     

    A lo largo de los diferentes modelos han ido usando diferentes... "trucos" para permitirlo. Originariamente no se podía de ningún modo, y en mi opinión era la mejor opción para el usuario, luego explico por qué. Luego, más tarde, pero aun solo con los 2 primeros HGU en el mercado, permitieron que, dependiendo desde donde se configurase (Interfaz avanzada o propia) el Router no es que por arte de magia lo permitiese, es que el Router al realizar dicha operación detecta el puerto, y cambia el puerto interno propio, liberando de este modo el puerto para su uso. Esto no se implementó en ambas interfaces, el motivo no te lo podría asegurar. Con la llegada de los otros dos Router, apareció una sección en la configuración avanzada que sí permite modificar el puerto propio en gestión remota. Y con el HGU6 pasa un poco lo mismo.

     

    Dicho esto, he dicho que personalmente veo mejor como estaba originariamente, y es raro que yo diga esto cuando soy pro libertades. El problema es que existe un % enorme de usuarios que tienen conocimientos más bien nulos en redes, y menos aun en seguridad informática. Y que cada vez más los usuarios se van a buscar NAS y otros dispositivos para conectar a su red, dispositivos que hacen uso extensivo de HTTP/SSH/Telnet/FTP... muchos de ellos incluso por defecto y haciendo uso de upnp, es decir, que ni siquiera abren puertos.

     

    Este escenario se repite a diario, y termina con equipos, NAS, servidores HomeAssistant... y muchos otros dispositivos con Ransomware o controlados por usuarios mal intencionados. Cada dos semanas más o menos como mucho me llama cuando no es uno es otro por problemas similares.

     

    Cuando expones un dispositivo a Internet, el que sea, en un entorno además doméstico, con dispositivos domésticos, con conocimientos más que limitados... la 1º regla de oro es JAMAS EXPONER EL SERVICIO AL PUERTO POR DEFECTO. Así que paradójicamente al usar Movistar para uso propio dichos puertos, ha impedido en gran medida una ingente cantidad de dispositivos secuestrados/infectados, porque ha obligado al usuario a usar otro puerto. Lo cual por cierto se pudiese o no usar, jamás recomendaría tampoco su uso por defecto.

     

    Aquí algunos por supuesto te interrumpen, y muchos "aficionados" te dirán que ellos son mayorcitos para poner lo que quieran donde quieran. Obviamente, dios me libre que decirle a nadie son solo consejos. Luego te dicen que ellos tienen conocimientos más que de sobra para proteger bien los equipos, que si tienen FW de no se que, que si políticas de no se cuanto... bien, yo me ciño a lo mismo, será verdad o no será verdad, pero cualquier usuario que se tome mínimamente en serio la seguridad de su red, de sus dispositivos, y que encima estos los va a exponer a Internet, te aseguro que lo mínimo que haría y lo primero, sería usar su propio Router, con un control total sobre él, no un Router doméstico de un ISP, que TODOS tienen más agujeros que cualquier otra cosa.

     

    Más aun, ojo, aun teniendo un Router propio, filtrados, controles de acceso, políticas de actualización, políticas de copias de seguridad 3-2-1... aun con todo, a menos que sea un servidor Web de una empresa por ejemplo y que requiera acceso "estándar" o escenarios donde sea realmente imprescindible, cualquier servicio expuesto siempre le cambiaría el puerto a uno alto, SIEMPRE. Sobre todo porque esto no entraña absolutamente nada al que realmente lo necesita. Es decir... si el acceso SSH lo voy a usar solo yo, o yo y dos personas más a lo mejor, que me cuesta decir que en vez del 22 es el 36567. No cuesta absolutamente nada, y en cambio el aumento en seguridad es brutal.

     

    Podría enseñar estadísticas que se le cambiaría la cara a más de uno si supiese a lo que día a día se expone de forma además totalmente innecesaria.

     

    Así que, aunque por motivos diferentes, Movistar inconscientemente está ayudando enormemente a la seguridad de la red, evitando en muchos muchos casos secuestros de NAS, infecciones y otros.

     

    Por supuesto, cada cual que siga haciendo lo que estime.

     

    Saludos.