Como suprimir el router de Telefónica en FTTH
Qué contento que estaba yo cuando me pusieron fibra óptica en casa. Lo rápido que iba a poder descargar "distribuciones de linux", "wikipedias" y demás contenidos libres ahora. Cuando ví llegar a los instaladores de Telefonica con varias cajas blancas, rollos de fibra, cajas de herramientas, etc,… pensé que venían los Cazafantasmas.
Como los chicos parecían majetes (y uno de ellos leía Security By Default -un saludo para Jose desde aquí-) estuve de lo más entretenido viéndoles hacer la instalación, tirar la fibra y ejecutar trabajo de precisión con los conectores necesarios. A mi pregunta, "cuál es el modelo del router para ir buscando por Internet cómo destriparlo?", me abren dos cajas y me explican que cuando tienes FTTH, necesitas dos equipos:
Una unidad ONT Huawei HG 850, que hace bridge entre la conexión de fibra óptica y un cable ethernet; y un router inalámbrico, normal y corriente (de los típicos ADSL de Telefonica pero sin interfaz RJ-11) que tendrá la IP pública y hará "el routing" entre los PCs de dentro de la red e Internet.
Para activar la ONT, el instalador se conectó a uno de los puertos y ejecutó varios parámetros de inicialización según pude ver. Sin embargo, según me comentaron, la ONT no disponía de módulo de routing y era imprescindible disponer del otro dispositivo conectado en serie para poder tener acceso a Internet.
Antiguamente, cuando funcionábamos con módem a través de RTB e incluso con ADSL normal mediante módems, ya era posible establecer una conexión PPPoE o PPPoA (dependiendo si era sobre Ethernet o sobre ATM) desde una máquina con Linux, teniendo la IP Pública un interfaz TCP/IP directamente en la máquina.
Hay que decir que en el caso de una casa "normal" con varios dispositivos conectándose a internet directamente a través del router de forma directa, no es posible eliminar este último dispositivo. En mi caso, que lo que tengo es una máquina con muchas funcionalidades, que además separa entre sí varias redes a las que da el acceso a Internet y entre ellas, podemos intentar eliminar el dispositivo de routing intermedio sin problemas. Además, la configuración de NAT del router blanco tenía configurado como "DMZ host" la IP del servidor, de manera que todo el tráfico de red entraba directamente contra mi "gateway". La idea es eliminar el salto intermedio.
Como bien podéis imaginar, según salieron por la puerta, lo primero que hice fue sentarme a trastear con los dos cacharros y ver si uno de ellos era susceptible de ser eliminado.
Manos a la obra
Al principio pensé que sería cuestión de 10 minutos mediante la instalación de los paquetes rp-pppoe y ppp para CentOS, crear una conexión PPPoE y a correr. La verdad es que no resultó tan sencillo como parece. La conexión PPPoE se resistía y me daba un montón de errores.
La configuración utilizada en el fichero /etc/sysconfig/network-scripts/ifcfg-ppp0 era la que veis bajo estas líneas:
Código PHP:
USERCTL=yes
BOOTPROTO=dialup
NAME=DSLppp0
DEVICE=ppp0
TYPE=xDSL
ONBOOT=YES
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
DEFROUTE=yes
SYNCHRONOUS=no
ETH=eth0
PROVIDER=DSLppp0
USER=porsiacasoloquito@telefonicanetpi
PEERDNS=no
DEMAND=no
Además, en los ficheros /etc/ppp/chap-secrets y /etc/ppp/pap-secrets será necesario añadir una entrada con la contraseña perteneciente al usuario.
En la interfaz web del dispositivo intermedio (un Comtrend), el que hace el routing entre el PC y la ONT de fibra, en un primer vistazo inicial, no vi nada que permitiera ver qué estaba haciendo mal.
Sin embargo, descargando un backup de la configuración de dicho router se pueden observar varias cosas interesantes.
Se trata de un fichero XML que, permite ver que, para empezar, la clave de administración del router se encuentra en claro, para que el que tenga acceso a un fichero de backup, pueda además acceder al router después, además con un tag facilito <AdminPassword$gt; (un bonito detalle oye).
Código PHP:
<X_BROADCOM_COM_LoginCfg>
<AdminPassword>LaPassEnClaroDeMiFraudeRouter</AdminPassword>
</X_BROADCOM_COM_LoginCfg>
Al analizarlo más en profundidad, y ya por pura curiosidad, encontré una sección que me dejó muy mosqueado:
Código PHP:
<url>https://main.acs.telefonica.net:7004/cwmpWeb/WGCPEMgt</url>
<username>XXXXXX-696969R-1234A-aabbccddeeffgg</username>
<password>123456789101112131451617181920</password>
<periodicinformenable>TRUE</periodicinformenable>
<periodicinforminterval>86400</periodicinforminterval>
<periodicinformtime>2000-01-01T00:00:10+00:00</periodicinformtime>
<connectionrequestusername>XXXXXX-696969R-1234A-aabbccddeeffgg</connectionrequestusername>
<connectionrequestpassword>lalalaalalalalalalaalaalalalalalalalalaalalalala</connectionrequestpassword>
Como la curiosidad mató al gato, intenté acceder a esta URL: Si accedo a esta URL https://main.acs.telefonica.net:7004/cwmpWeb/WGCPEMgt, el certificado está firmado por una CA de Telefónica (o eso dice), me pide usuario y contraseña, introduzco obedientemente los valores de los tags <username> y <password> (parecen valores en hexadecimal) y me aparece una página que dice:
CPE Servlet responding
Active session count = 213
Analizando con TamperData, aparece una Cookie llamada "BIGipServerPool_HNM_Walled-garden" que imagino que la inyectará un balanceador F5 para fijar la persistencia de la sesión a través de un nodo de una granja de servidores web. ¿Para qué valdrá esto? Hay otros parámetros que con el mismo usuario tiene una password diferente, que al probarla no funciona. ¿Será que sirven para otorgar gestión remota al Router desde el portal Alejandra de Telefónica? No sé a vosotros, pero cada vez me da más mala espina este tipo de dispositivos que te entregan desde el proveedor con una configuración pre-establecida.
Finalmente, en la sección de la conexión PPPoE, aparte del usuario y la contraseña necesarios, el parámetro VlanMuxID (6) hace sospechar que el tráfico podría ir en formato 802.1Q (o VLAN Tagging) en concreto con el Tag 6. Tendría además sentido el que, tanto en la intefaz web como en el fichero XML, apareciese el nombre del interfaz como ppp0.6.
Código PHP:
<WANPPPConnection instance="2">
<Enable>TRUE</Enable>
<ConnectionType>IP_Routed</ConnectionType>
<Name>pppoe_eth0.6</Name>
<NATEnabled>TRUE</NATEnabled>
<X_BROADCOM_COM_FirewallEnabled>TRUE</X_BROADCOM_COM_FirewallEnabled>
<Username>porsiacasoloquito@telefonicanetpi</Username>
<Password>lapassword</Password>
<X_BROADCOM_COM_IfName>ppp0.6</X_BROADCOM_COM_IfName>
<X_BROADCOM_COM_BcastAddr>255.255.255.255</X_BROADCOM_COM_BcastAddr>
<X_BROADCOM_COM_VlanMux8021p>1</X_BROADCOM_COM_VlanMux8021p>
<X_BROADCOM_COM_VlanMuxID>6</X_BROADCOM_COM_VlanMuxID>
<DNSServers>80.58.61.250,80.58.61.254</DNSServers>
<PortMappingNumberOfEntries>0</PortMappingNumberOfEntries>
<X_BROADCOM_COM_FirewallException>nextInstance="12"
</X_BROADCOM_COM_FirewallException>
</WANPPPConnection>
Me diréis: "Oye Lorenzo, en la imagen que has puesto arriba aparece claramente VlanMuxID 6". Pues sí, tenéis razón, pero yo no me dí cuenta hasta que bajé el backup de la configuración. -Mi cerebro debe procesar mejor los ficheros de configuración XML que las imágenes, no sé-
Así pues, en vez de hacer la conexión PPPoE en modo untagged (el normal para un dispositivo de usuario en una red), habrá que crear primeramente un interfaz virtual "tagged".
Para ello, en CentOS creamos el fichero /etc/sysconfig/network-scripts/ifcfg-eth0.6 con el siguiente contenido:
Código PHP:
DEVICE=eth0.6
ONBOOT=yes
BOOTPROTO=static
VLAN=yes
Haciendo la prueba levantando el interfaz, se ve que se levanta correctamente un interfaz sin IP llamado eth0.6 y que el módulo 8021q se encuentra cargado y utilizado
Código PHP:
[root@Carmen ~]# ifconfig eth0.6
eth0.6 Link encap:Ethernet HWaddr AA:AA:AA:AA:AA:AA
inet6 addr: fe80::fff:fff:ffff:d1fc/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:99292 errors:0 dropped:0 overruns:0 frame:0
TX packets:76372 errors:0 dropped:4 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:122826179 (117.1 MiB) TX bytes:9347498 (8.9 MiB)
[root@Carmen ~]# lsmod | grep -i 802
8021q 24413 0
garp 7310 1 8021q
Ahora sólo queda modificar la configuración del fichero /etc/sysconfig/network-scripts/ifcfg-ppp0 para que el parámetro ETH que antes era "eth0" pase a ser "eth0.6".
Levantando el interfaz se observa cómo se crea correctamente un interfaz nuevo llamado ppp0 con la IP pública que Telefonica me asigna.
Ahora sólo queda modificar la configuración de algunas aplicaciones que se "bindeaban" en el interfaz pública directamente, anteriormente eth0, para que pasen a hacerlo al ppp0. Además hay que modificar la política de firewall/NAT, configuración de herramientas de análisis como Snort, ntop, y demás juguetitos para que monitoricen el nuevo interfaz.
Si anteriormente, teníais configurado el NAT entrante del router para que determinados puertos fuesen redirigidos a puertos de algún PC interno, tened cuidado puesto que actualmente la máquina Linux "está" directamente en Internet. Si tenéis algún servicio mal configurado, que anteriormente no era un riesgo alto por no estar comunicado desde fuera, ahora sí que lo estará, así que revisad las reglas del firewall de la máquina.
He de decir que en CentOS 4.X al levantar el interfaz ppp0 se provocaba un core dump que hacía que se reiniciara el servidor. Escribo ahora este post puesto que he migrado a Centos 6 y en la nueva máquina ya no da crashes como los anteriores. Previamente probé en una Fedora Core 13 y funcionaba también estupendamente.
Publicado por Lorenzo Martínez en http://www.securitybydefault.com/2011/08/como-suprimir-el-router-de-telefonica.html
