Mostrando entradas con la etiqueta iptables. Mostrar todas las entradas
Mostrando entradas con la etiqueta iptables. Mostrar todas las entradas

martes, 14 de octubre de 2014

La mala idea de bloquear Internet

Toda mi vida lo que siempre he querido es un Internet libre, sin bloqueos, rápido que ayude al mundo a comunicarse, a educarse, a estar informado. En mi humilde opinión el internauta tiene acceso a visitar la pagina que quiera y cuando quiera, sin importar el contenido lo que diga, lo que vea, lo
que escuche. No se nada de leyes pero creo que debe verse como un derecho del ciudadano a leer, ver y escuchar en Internet lo que la persona desee.

Bloquear paginas no es una solución, es mas un problema, no se llega a nada, la solución a los problemas esta en otra dirección muy lejana a bloquear las paginas y contenidos.

Supongamos un caso donde alguien realiza una publicación indicando que el cielo es rojo, las nubes anaranjadas o que esta lloviendo para arriba, ¿van a bloquear ese contenido?. ¿Tú no tienes derecho a poner esa información en una pagina Web?.

Ahora bien, imaginemos otro caso donde en la esquina de tu urbanización esta ocurriendo algo ilegal (y tu lo ves desde tu apartamento) ¿puedes o no publicar lo que esta ocurriendo en Internet?, ¿tomar fotos?, ¿realizar un artículo al respecto?. ¿Puedes ponerlas en Internet?, ¿te lo bloquean?, ¿tu pierdes la libertad de expresión y yo pierdo el acceso a tu informacion?. Peor aún, en segundos un familiar tuyo va a pasar por esa esquina..... gracias a la NO libertad de expresión y al NO acceso a
la información algo indeseado ocurrió que honestamente no quiero describir.

En los últimos meses (en realidad años) he visto como algunos países han decidido bloquear su acceso a Internet imposibilitando a sus habitantes a acceder a contenido legitimo a la información, pero peor aun dañando poco a poco la super autopista de la información.

Solo por mencionar algunos países con historial por bloquear -al menos un poco- su acceso a Internet (tomado de http://www.usatoday.com/story/news/world/2014/02/05/top-ten-internet-censors/5222385/  y http://en.wikipedia.org/wiki/Internet_censorship: ):
- Irán
- Egipto
- Coreo del Norte
- Venezuela
- Cuba
- China
- Turquía
Arabia Saudita
- Siria
- Vietman

Antes de proseguir, quiero indicar que por más de un año me he tomado la libertad de averiguar que manera utilizan para bloquear paginas Web u otros servicios a los usuarios, he recibido básicamente dos respuestas:

- Bloqueos por DNS
- Bloqueos por dirección IP destino

(claro, por detrás puede haber un montón de cosas que complican el escenario como firewalls, IDS, IDP, etc, etc)

Muchas personas, principalmente los técnicos dirán que ambos métodos son ineficientes y que se pueden evitar utilizando una VPN y/o cambiando los servidores DNS que utilizan los usuarios. Es muy cierto este pensamiento sin embargo en la realidad y en la practica son MUY pocas personas las que tienen conocimiento de DNS, muchos menos de VPN y a su vez este ultimo en algunas situaciones hay opciones pagas ($$) lo que reduce aun mas la poblacion dispuesta a realizar estos cambios. Por lo anterior pienso que bloquear contenido por DNS e/o IP destino es BASTANTE eficiente.

El objetivo de este post es indicar porque pienso que es mala idea bloquear Internet para un país:

1) Rompemos el Internet poco a poco y luego armarlo puede ser muy complicado
Esta razón es fatal para Internet y el país. Al estar constantemente creando y modificando rutas en los routers va a ir creando una especie de "agujeros parciales" a ciertas direcciones IP destino. Pero el problema no es solo este, sino la persecución de bloquear sitios trae consigo el bloqueo "actual" del destino sin nuevamente "permitir" el anterior. Esto ultimo conlleva a ir rompiendo poco a poco muchas direcciones IP legítimas en Internet que no pueden ser accedidas.
Multiplicando el efecto anterior, un caso similar ocurre en el mundo DNS.

2) Los inocentes pagan como pecadores
Siguiendo un poco con lo anterior supongamos el siguiente escenario de ejemplo: Un ciudadano común tiene un blog de cocina. Por cosas del destino su página web esta alojada en un virtualhosting bajo la misma dirección IP que una pagina que quiere ser bloqueada. ¿Qué va a ocurrir?. No puede ser accedida la pagina del blog de cocina. Para el ciudadano común y para el proveedor del virtualhosting identificar esta situación y solventar el caso seria muy complicado.

3) Teletrabajo
Hoy en día es normal trabajar, compartir y jugar de manera remota con diferentes personas en el mundo. Lamentablemente el bloqueo de IPs y de nombres DNSs obstaculiza el Teletrabajo; un ejemplo es que la persona con la que nos encontramos laborando remotamente quisiera compartir información/contenido utilizando medios que se encuentren bloqueados en uno de los países. Lo anterior es un entorpecimiento explícito que siendo antagónico me atrevo a decir que convierte al ciudadano en una persona menos productiva.

4) Dudas a los ciudadanos
Caso a) En el supuesto que una persona en el país bloqueado no pueda acceder a un sitio ¿qué va a pasa?: Quizás llame a su proveedor de servicio (perdiendo tiempo, dinero, creando molestias). Es muy probable que la persona que atienda el teléfono sencillamente no sepa revisar los DNS y rutas en los enrutadores, haya que escalar el caso y mucho mas. Para los proveedores esto es un costo que tiene que ser trasladado a alguien, por supuesto que al cliente. Es decir, el servicio de Internet se encarece.
Caso b) El ciudadano probablemente llame directamente a un amigo con conocimientos en informática, una vez mas: perdiendo tiempo, dinero y creando molestias
Caso c) Las dos anteriores

5) Perspectiva ante un bloqueo _nuevo_ del ciudadano:
Cuando un ciudadano no puede entrar a un sitio Web (o servicio) no sabe si fue bloqueado por el gobierno, por el ISP, el sitio web caído o si es algo temporal. Esto conlleva a una serie de molestias directas e indirectas que a su vez más trae problemas colaterales.

6) El error humano
Los administradores de red son personas como cualquiera, son propensos a cometer errores al igual que todos nosotros.
Es bien sabido que ____ % de errores en red son causados por errores humanos, ahora traslademos esta estadística a los administradores red que deben estar manipulando los servidores DNS y los routers creando rutas frecuentemente con el objetivo de bloquear algunos sitios y contenidos. Lastimosamente el resultado es un peor Internet para el ciudadano.

7) Históricos + falsos positivos (negativos?)
Este punto lo describiré con un ejemplo: Un proveedor de Internet contrata a un nuevo administrador de red; este último observa gran cantidad de direcciones IPs bloqueadas en los routers, es muy complicado que el nuevo administrador NO sepa si estos IPs fueron bloqueados momentáneamente por defenderse de un ataque de red anterior o corresponde a un bloqueo solicitado por el regulador del país (o el ente respectivo)

8) Daños colaterales:
Es común que muchas organizaciones realicen eventos 1,2 ó 3 veces al año y roten su sede en diferentes países. Es bien sabido que estas organizaciones evitaran los países con bloqueos a Internet.



9) Se rompe el acceso a sitios legítimos:
Un caso que he visto en varias oportunidades es el bloqueo por DNS apuntando a direcciones IP, quizás www.example.com a 1.1.1.1. Luego: supongamos que por asegurar el bloqueo a nivel de routing se enruta 1.1.1.1 a un hoyo negro (null 0) el ciudadano no podrá entrar ni al sitio que se bloqueo ni al sitio legítimo que se encuentre en la dirección IP bloqueada


Iba a colocar otras razones y puntos negativos de pasar a través de una VPN y cambiar los DNS en las máquinas tales como enlentecimiento de Internet, lentitud en la VPN y problemas de geolocalizacion  pero lo dejaré para otra oportunidad.


Mi conclusión:
Si existe algo que yo quisiera y pudiera bloquear en Internet seria: pornografía infantil y ventas ilegales de armas (algo realizado por un pais en Latino América). He llegado a ver países que bloquean contenido de sus propios ciudadanos, esto a mi parecer deja mucho que desear.

Lo he dicho mil veces, un Internet 100% libre tendrá unas MUY pocas cosas malas pero tiene MUCHAS mas ventajas que desventajas. Ir bloqueando poco a poco Internet en los países a la larga trae desventajas competitivas, subdesarrollo, imagen ante el mundo poco amigable y muchas otras cosas. Lo anterior repercute entre otros en los ámbitos económico y social. Internet debe ser utilizado como una herramienta para el desarrollo.

Antes de terminar; un Internet debe ser sin bloqueos, Internet debe ser con banda ancha de buena velocidad, acceso a nivel nacional, decirle NO al throttling y lógicamente seguro y con privacidad.


Reciban un saludo,


zcodesystemexclusive

miércoles, 23 de julio de 2014

NAT66 en Linux

Hola,
  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.
  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:
  El equipo a realizar el NAT66 debe tener:
  - Kernel > 3.9 
  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:
  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48




Configuraciones:

En DEVICE 1:
#ifconfig eth0 inet6 add 2001:db8:12::2/48
#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo
#ifconfig eth1 inet6 add 2001:db8:12::1/48
#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:
#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:
#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:
#ifconfig eth1 inet6 add 2001:db8:23::2/48
#route -A inet6 add default gw 2001:db8:23::1


  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad



domingo, 2 de septiembre de 2012

Linux iptables, solucion al error: Warning: wierd character in interface

Introducción:
  En Linux cuando intentamos realizar un NAT con alguna interfaz que posea el caracter ":" recibimos el error:  Warning: wierd character in interface `eth0:0' (No aliases, :, ! or *).
  Por ejemplo en el siguiente escenario:

   #iptables -t nat -A POSTROUTING -o venet0:0 -j MASQUERADE  
   Warning: wierd character in interface `eth0:0' (No aliases, :, ! or *).

Explicación:
  Luego de una investigación en muchas páginas en Internet llegué a la conclusión que no es posible realizar el NAT con una "subinterfaz" (interfaz secundaria, IP secundario, etc) con Linux que posea ":" , durante mi busqueda conseguí que es un problema del manejo de los ARP en dicha interfaz, sin embargo no hay que preocuparse, existe una alternativa y es la que voy a plantear en este post. 

Solución:
  La solución es bastante sencilla y al menos funciona en todos los escenarios donde la dirección IP con la que deseamos natear es estática. La misma se conoce como SNAT (Source NAT) y se utiliza como IP saliente el IP secundario de la interfaza utilizar (ej. eth0:0). La diferencia principal es que hay que indicar cual es la red a la cual deseamos hacer NAT, esto no debe ser ningún inconveniente porque seguramente sabremos esta información.
  En definitiva la solución es realizar el NAT con el IP "saliente" en vez de la interfaz saliente e indicando la red a la cual deseamos realizar el NAT.

Comandos:

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -A POSTROUTING -t nat -s 192.168.56.0/24 -j SNAT --to 123.4.5.6

  Con  lo anterior estaremos nateando la red 192.168.56.0/24 con la dirección IP 123.4.5.6, es decir, cualquier equipo con dirección IP fuente en el rango 192.168.56.0/24 se verá en Internet con 123.4.5.6. En ningún momento hace referencia a "eth0:0"

Espero les sea útil,

Saludos,

miércoles, 7 de septiembre de 2011

Utizando Netem. Simulando escenarios de red. Ejemplos de tc/netem

Problema:
  Deseo simular algunos escenarios de red.
    a) Simular en un salto satelital
    b) Simular perdida de paquetes

  Lo anterior es de mucha utilidad porque permite probar escenarios -casi reales-. Se pueden probar aplicaciones y conocer como se comportan ante una alta tasa de pérdida de paquetes y/o ante altos tiempos de respuesta. Otra opción es conocer el comportamiento ante pérdidad y/o RTT aleatorios y muchas otras cosas.


Solución:
  Netem (Network Emulacion) que permite simular escenarios de red muy tipicos en redes WAN, MAN y Satelitales.
   Netem es controlado con el comando tc que es parte de iproute2

Ejemplos:

a)  Simular el Round Trip Time de un salto satelital (550 ms):

# tc qdisc add dev eth0 root netem delay 550ms

Fijense del tiempo del ping antes y durante el comando (salto del 10 al 11):

[root@localhost ~]# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=53 time=51.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=53 time=48.6 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=53 time=50.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=53 time=49.8 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=53 time=51.8 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=53 time=50.4 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=53 time=49.9 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=53 time=51.1 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=53 time=50.6 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=53 time=601 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=53 time=600 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=53 time=600 ms


b) Simular una red WAN con tiempos de mayor variación (de 100 ms - 10 ms) de manera aleatoria:

# tc qdisc change dev eth0 root netem delay 100ms 10ms

64 bytes from 8.8.8.8: icmp_seq=60 ttl=53 time=49.3 ms
64 bytes from 8.8.8.8: icmp_seq=61 ttl=53 time=50.5 ms
64 bytes from 8.8.8.8: icmp_seq=62 ttl=53 time=59.6 ms
64 bytes from 8.8.8.8: icmp_seq=63 ttl=53 time=50.7 ms
64 bytes from 8.8.8.8: icmp_seq=64 ttl=53 time=49.6 ms
64 bytes from 8.8.8.8: icmp_seq=65 ttl=53 time=143 ms
64 bytes from 8.8.8.8: icmp_seq=66 ttl=53 time=152 ms
64 bytes from 8.8.8.8: icmp_seq=67 ttl=53 time=157 ms
64 bytes from 8.8.8.8: icmp_seq=68 ttl=53 time=153 ms
64 bytes from 8.8.8.8: icmp_seq=69 ttl=53 time=159 ms
64 bytes from 8.8.8.8: icmp_seq=70 ttl=53 time=155 ms


c) Simular perdida % de paquetes:


 # tc qdisc change dev eth0 root netem loss 0.1%

El comando anterior ocasiona una pérdida de 1/1000 paquetes descartados de manera aleatoria

Más opciones:
Existen muchas otras opciones como:
  a) Duplicar paquetes
     # tc qdisc change dev eth0 root netem duplicate 9%


  b) Corromper (dañar) un paquete:
     # tc qdisc change dev eth0 root netem corrupt 0.1%

Mas información:
http://www.linuxfoundation.org/collaborate/workgroups/networking/netem
http://www.cyberciti.biz/faq/linux-traffic-shaping-using-tc-to-control-http-traffic/

sábado, 1 de enero de 2011

Deshabilitar IPtables en Ubuntu

Situacion:
IPtables y UFW estan dando dolores de cabeza.
Deseo permitir todo el trafico con IPtables

Solucion:
Ejecuta los siguientes comandos como root:

iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -L -n

Suerte, espero haya sido util,

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta Introducción y planteamiento del problema En el presente documento queremos discutir sobre un draft (bor...