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:

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).

<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:

<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. 

<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:

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

[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.

Leer más...

Operadoras ADSL y Slamming: Usuarios desprotegidos by default

Con toda seguridad, casi todo el mundo que tenga contratada una línea ADSL en casa desde hace unos 4 ó 5 años, habrá tenido la experiencia de haber cambiado de uno a otro operador. Lo mismo suele suceder con los servicios de telefonía móvil, que ya sea buscando la oferta o un terminal mejor, hacen que efectuemos la portabilidad de un número a otro sin "apenas" molestias.

Para ello, el cliente que lo desee simplemente debe dar sus datos a la nueva operadora y grabar una locución en la que les autoriza a que se medie por él para cambiar de operadora la línea. De esta forma, las operadoras como ya.com, jazztel, etc,... le piden a Telefónica hacer una portabilidad.

El tema está en que Telefónica no pide generalmente a la nueva operadora ningún comprobante de que es el titular quiere cambiar el ADSL y por ley antimonopolio de la Comisión del Mercado de las Telecomunicaciones, se ve obligada a permitir el cambio. Esto que puede parecer una comodidad tremenda para los usuarios (al fin y al cabo hablamos con una sola operadora y ellos gestionan los trámites con la operadora antigua) puede resultar peligroso y molesto.

Se están llevando a cabo (y hablo por experiencia propia, como víctima y no como ejecutor) una serie de altas indebidas fraudulentas por parte de comerciales de determinadas operadoras que necesitan cubrir su cuota a fin de mes. De esta manera, si en alguna ocasión has estado interesado en alguna oferta de ADSL, o incluso si has dado un alta y una baja en un periodo de tiempo corto, los comerciales de las operadoras generan un alta nueva de un usuario que en su día estuvo interesado. Como el tiempo de realización de la portabilidad es de un mes más o menos, entre que se pide a Telefónica, te quedas sin ADSL por parte de un operador y se hace efectiva, el comercial de la nueva operadora ya ha cobrado y tú te quedas sin un servicio que tenías y con uno nuevo que no quieres. Esto se conoce como Slamming.

Lo más impactante del caso es que aunque llames al 1004 siendo el titular de la línea e indicando que quieres cancelar los trámites de la portabilidad de la otra compañía (lógicamente cuando te quedas sin ADSL llamas a Telefónica para ver qué ha sucedido) se te indica que para ellos es imposible hacer la marcha atrás puesto que la mencionada ley antimonopolio les obliga a ceder la línea a quien se lo pida.

Las únicas contramedidas que Telefónica te ofrece son que mandes un FAX al número 918841771 (la búsqueda en google de este número no dice apenas nada) con tus datos personales indicando que quieres seguir teniendo el servicio con Telefónica y que se trata de un alta indebida: misión imposible, el número suministrado o está todo el rato comunicando o cuando da tono, no suena el pitido de FAX... La otra opción proporcionada por Telefónica es enviar el mismo comunicado a una dirección de correo digitalizacion01.ssee@zeleris.com (lo cual me genera una desconfianza tremenda... la búsqueda en google tampoco genera muchas esperanzas) aún así lo hice y no hubo contestación de ningún tipo por su parte

Después de estos despropósitos y esta impotencia, los siguientes pasos son esperar a que el nuevo alta sea efectiva en la nueva operadora y efectuar una reclamación comercial a Telefónica, en la que por fin exigen algún tipo de prueba a la operadora indebida en la que el titular pide el alta con ellos.

Mientras tanto, sólo hay problemas, pérdida de servicio y molestias. Más allá de una bonita reclamación en la OCU y posiblemente a la Secretaría del Estado de Telecomunicaciones, poco más podemos hacer. Pienso que, siendo Telefónica de España conocedora de que este tipo de fraude existe y es posible, debería dar al menos la última palabra al cliente final (incluso grabando la conversación para evitar las contra-ofertas por su parte) de manera que ante un fraude de estas características, sus usuarios, sus CLIENTES, no fueran robados tan impunemente por parte de otras operadoras. ¿Por qué no implantan el DNI-E como una forma unívoca de autenticar a un usuario para este tipo de gestiones (tanto altas fidedignas como las reclamaciones ante altas fraudulentas)?

Leer más...

Telefónica y sus automatismos

Me ha llegado la factura de mi línea fija de teléfono a casa, y entre otras comunicaciones, me encuentro con un formulario en el que se indica el número de teléfono móvil que tengo asociado a mi ficha de línea fija.

Mentando a la LOPD, se me da la oportunidad de decidir si quiero permitir que Telefónica haga uso de este número de teléfono móvil para promocionar sus productos y servicios (así como de otras empresas) por SMS/MMS.

Para evitar esto se te insta a enviar este formulario con las cruces marcadas sobre aquello que no quieres permitir vía correo postal, vía internet o finalmente al número de teléfono 900502020 (que es lo que creo que harán la mayoría de los usuarios).

En este teléfono, una grabación te indica que marques el número de teléfono al que quieres denegar/permitir su utilización para envío de publicidad mediante SMS/MMS. Después de pulsar los 9 dígitos la misma voz enlatada te hace 3 preguntas sobre si deseas permitir o no este tipo de publicidad. Se te indica que si quieres permitirlo pulses 1 y si quieres denegarlo pulses 2.

Evidentemente he pulsado 2 a las tres preguntas. Posteriormente a esto se te indica que se ha tramitado correctamente tu solicitud y ya está.

Con este sistema en mano, si alguien se sabe mi número de móvil directamente puede llamar tranquilamente, pulsar los 9 dígitos de mi teléfono y marcar 1 a las 3 preguntas. De esta manera me enviarán publicidad de forma indiscriminada al móvil sin haberla pedido. Mis dudas ante esto son: ¿por qué no utilizan algún otro mecanismo de autenticación previo? Pedir que marques tu DNI o una One Time Password que venga en la carta personalizada sería más acorde que únicamente el móvil al que quieres permitir/denegar spam y el decir Sí o No.

He probado por si acaso a llamar desde un móvil diferente para ver si a lo mejor era debido a que sólo se pudiera hacer desde el número de teléfono fijo de casa, pero efectivamente he podido modificarlo para que me envíen morralla al móvil.

Ya aprovechando he modificado los datos para que a mis padres no les envíen publicidad de Imagenios y etcéteras al móvil,... pero lo mismo que he dicho que no lo quería para otra persona, podía haber marcado que sí a todo.

Leer más...