Mejorando la experiencia Nauta: garantizar que no se gaste más de lo necesario
Vamos a tratar un poco el tema del ahorro al usar el servicio Nauta. En este artículo no voy a hacer otra cosa que aplicar lo que publiqué en un artículo anterior sobre iptables y el ahorro de cuota de internet en dar continuidad al que publiqué la semana pasada sobre como mejorar la experiencia Nauta, esta vez orientado a garantizar que el trasiego de datos desde nuestra PC hacia la red de ETECSA y viceversa sea justo el necesario para que el servicio funcione correctamente y nada más, evitando que algún que otro kilobyte extraviado nos cueste dinero extra.
Lo primero que hay que garantizar es que el teléfono Android tenga desactivada la sincronización de cualquier tipo de cuenta que se tenga creada. Esto se puede lograr en dos pasos muy sencillos, a través del menú de Android en el apartado Ajustes del Sistema:
Una vez que se tenga funcionando el servicio de correo en la PC como vimos la semana pasada, podemos añadir algunas reglas al cortafuegos utilizando el método del que ya les comenté en un artículo anterior, o utilizando alguna de las tantas interfaces que existen para configurar el cortafuegos como ufw o firestarter. Yo me voy por la variante más genérica. Las reglas que a continuación expongo deben ponerse después de las reglas básicas que explico en aquel artículo, es decir, las que establece las políticas por defecto de cerrar todo y solo permitir conexiones de respuesta a las peticiones, etc.
Si la conexión con el teléfono la estableciste con el cable del teléfono por USB, se puede poner este conjunto de reglas que restringe las peticiones que salen por la interfaz de red usb0 a los servicios específicos de ETECSA y a ninguno más. Aquí sólo se deja que se realicen peticiones al puerto TCP/UDP 53 del servidor de DNS de ETECSA (200.55.128.3) y puesto que los servidores de correo y webmail están en la subred 190.6.81.0/24, solo se dejan salir peticiones que se dirijan a los puertos TCP 25 (SMTP), 110 (POP3), 143 (IMAP), 80 (HTTP), 443 (HTTPS). Cualquier otra petición saliente por esa interfaz se rechaza.
# Using USB connection -A OUTPUT -o usb0 -d 200.55.128.3 -p tcp -m tcp --dport 53 -j ACCEPT -A OUTPUT -o usb0 -d 200.55.128.3 -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -o usb0 -d 190.6.81.0/24 -p tcp -m multiport --dports 25,110,143,80,443 -j ACCEPT -A OUTPUT -o usb0 -p tcp -j REJECT --reject-with tcp-reset -A OUTPUT -o usb0 -p udp -j REJECT
En caso de que la conexión con el teléfono se esté haciendo por Wi-Fi, entonces hay que tener en cuenta algunas otras cuestiones. Las reglas se establecen para la interfaz wlan0, pero si se dejan solo así, entonces cuando se esté usando la Wi-Fi en otra red se va a tener restringido el acceso, por eso hay que especificar que solo aplique estas reglas cuando la dirección IP de orígen (la nuestra) se encuentre en el rango que el teléfono entrega a través de DHCP (el teléfono crea un NAT donde establece una red interna a la que le reparte direcciones IP por DHCP, utilizando dnsmasq para eso), en este caso 192.168.43.0/24. De ahí la opción -s que se muestra a continuación:
# Using wifi connection -A OUTPUT -o wlan0 -s 192.168.43.0/24 -d 200.55.128.3 -p tcp -m tcp --dport 53 -j ACCEPT -A OUTPUT -o wlan0 -s 192.168.43.0/24 -d 200.55.128.3 -p udp -m udp --dport 53 -j ACCEPT -A OUTPUT -o wlan0 -s 192.168.43.0/24 -d 190.6.81.0/24 -p tcp -m multiport --dports 25,110,143,80,443 -j ACCEPT -A OUTPUT -o wlan0 -s 192.168.43.0/24 -p tcp -j REJECT --reject-with tcp-reset -A OUTPUT -o wlan0 -s 192.168.43.0/24 -p udp -j REJECT
Alguno de ustedes pensarán que poner estas reglas en el cortafuego de la laptop y no en el del teléfono no protege totalmente contra el escape de posibles peticiones indeseables que partan del teléfono. Pues sí, existe esa posibilidad, pero es algo incómodo trastear el cortafuegos del teléfono y realmente la ganancia no es mucha. Hasta el momento con estas reglas he comprobado que la cantidad de bytes que se gastan es la justa, pero igual, ustedes son libres de dejar sus opiniones en los comentarios.
fuente:humanos.uci.cu







