Filtros de red para OSPF (Open Shortest Path First)

Si en nuestros routers utilizamos la estrategia de denegar todo por defecto y permitir expresamente lo que deseamos, en el caso de que estos equipos tengan configurado que aprendan sus rutas con OSPF, debemos habilitar dicho protocolo. Para ello, debemos tener en cuenta que OSPF

  • se encapsula en datagramas IP con el número 89 de protocolo (esto implica que NO utiliza UDP ni TCP ni, por tanto, tiene puertos),
  • usa tanto paquetes multicast (los grupos 224.0.0.5 y 224.0.0.6 y lo que nos obliga a configurar, usar y habilitar en nuestros filtros IGMP*) como unicast,
  • el TTL de sus paquetes es 1, por lo que no atravesarán un cortafuegos, salvo que configuremos un túnel (http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml),
  • y por último, dispone de un identificador de tipo de paquete (nos permite mejorar las reglas, aunque dependemos del software de filtrado).

Con iptables, la forma más fácil es ejecutar las siguientes ordenes**:

iptables -A INPUT -p 89 -j ACCEPT
iptables -A OUTPUT -p 89 -j ACCEPT

Si queremos ser más «finos», debemos indicar las IPs de origen, destino y, si lo permite el software de filtrado, el tipo de paquete de OSPF. Las reglas en este caso***:

#hello ospf between rt_ext and rt_int
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#database description, link state request, asking for information about a particular link and request/update link state
iptables -A INPUT -s rt_ext -d rt_int -p 89 -j ACCEPT
iptables -A OUTPUT -d rt_int -s rt_int -p 89 -j ACCEPT
#link state update, flooding all link states from rt_ext router
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
#rt_int router link state update from rt_ext router
iptables -A OUTPUT -s rt_int -d 224.0.0.5 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A OUTPUT -s rt_int -d 224.0.0.6 -p 89 -j ACCEPT
iptables -A INPUT -s rt_ext -d 224.0.0.5 -p 89 -j ACCEPT

Referencias

  1. Building Internet Firewalls, de Elizabeth D. Zwicky, Simon Cooper y D. Brent Chapman

* Es muy sencillo, pero lo dejo para otra entrada 😉

**Estamos considerando que NO queremos reenviar (forward). Si quisiéramos hacerlo, ver el punto 3 de las consideraciones de OSPF que he escrito en la entrada. Además, estas reglas deben ejecutarse en los routers designados.

***Las reglas se deben de ejecutar en los router afectados (en rt_ext cuando ‘-s rt_ext’ o en rt_int si ‘-s rt_int’), salvo que dispongamos de un cortafuegos específico y, en ese caso, se ejecutan todas en él. Recordad que debe disponer de un túnel (ver **)


Timeouts de TCP

En TCP(1) existen 4 tipos de timeouts (tiempos de espera) y cada uno de ellos se aplica en diferentes momentos y con diferente duración. Algunos, incluso, podemos evitarlos si es lo que deseamos…

Conocer estos tiempos es importante tanto para administradores de sistemas como para programadores de aplicaciones distribuidas (¡¡¡pocas no lo son ya!!!)

Leer más


Suckit rootkit… Warning: /sbin/init INFECTED

Si al ejeuctar sudo chkrootkit en tu Ubuntu 13.04 te sale el aviso del título del post, en principio, no debes asustarte (antes, ejecuta rkhunter).

Según se cuenta en http://askubuntu.com/questions/25176/chkrootkit-says-sbin-init-is-infected-what-does-that-mean parece un falso positivo por una búsqueda poco rigurosa:

   ### Suckit
   if [ -f ${ROOTDIR}sbin/init ]; then
      if [ "${QUIET}" != "t" ];then printn "Searching for Suckit rootkit... "; fi
      if [ ${SYSTEM} != "HP-UX" ] && ( ${strings} ${ROOTDIR}sbin/init | ${egrep} HOME  || 
              cat ${ROOTDIR}/proc/1/maps | ${egrep} "init." ) >/dev/null 2>&1
        then
        echo "Warning: ${ROOTDIR}sbin/init INFECTED"
      else
         if [ -d ${ROOTDIR}/dev/.golf ]; then
            echo "Warning: Suspect directory ${ROOTDIR}dev/.golf"
         else
            if [ "${QUIET}" != "t" ]; then echo "nothing found"; fi
         fi
      fi
   fi

Lista de puertos usados por un proceso…

Dado el PID  y sin necesidad de netstat o herramientas similares, podéis saber qué puertos tiene en uso (y su estado y mucha más información) dicho proceso con algo parecido a esto:

ls -la /proc/$proceso/fd | grep socket | cut -d’>’ -f2|cut -d’:’ -f2 | while read id; do grep $id /proc/net/tcp; done;

La información resultante la podéis interpretar con la documentación del Kernel de GNU/Linux (proc_net_tcp.txt), si no os aclara la primera línea del fichero /proc/net/tcp:

sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops

Para el caso que me ocupaba, sobraba con saber que de la línea:

4: 00000000:445C 00000000:0000 0A 00000000:00000000 00:00000000 00000000  1000        0 71298 1 f61904c0 300 0 0 2 -1

el primer campo (4) es un identificador de entrada; el segundo (00000000:445C) son la IP de origen y el puerto de origen; el tercero es la IP y puerto de destino y el cuarto (0A) es el estado (0A= Listen)

Si alguien no se fía de los resultados que le muestran sus herramientas, recordad que siempre está /proc


Interesante curso de administración de sistemas

Según la propia descripción de los organizadores. «Este curso pretende ofrecer una panorámica de las tareas relacionadas con el diseño, la planificación, el despliegue y la administración de servidores con software libre desde un punto de vista profesional.»
El temario parece bastante completo y se puede consultar, esto y más información, en http://formacion.libresoft.es/cursos/sistemas


¿Qué pasa con nuestra conexión de red?

Para comprobar la velocidad efectiva de nuestra conexión de red, tenemos una aplicación como Network Diagnostic Tool (NDT). Se trata de un sofisticado test de diagnóstico y velocidad que no solo mide la velocidad de subida y descarga sino que pretende encontrar la causa de la limitación de la velocidad, diferenciando entre los problemas de infraestructura de red y la configuración del ordenador. Aquí, un servidor cercano. En la misma página que he enlazado en primer lugar tenemos, más abajo, la utilidad NPAD, cuyo objetivo es diagnosticar problemas en el rendimiento de la red.

Por otra parte, si lo que detecto es que determinados protocolos o contenido (como vídeo cuando me conecto a youtube) va «lento», lo que debo hacer es comprobar, y no fiar me de las palabras, si mi proveedor de red está o no realizando filtros, penalizaciones de tráfico,…, e incumpliendo con la neutralidad de red. Para realizar estas comprobaciones, tenemos paquetes software como Glasnost o el Switzerland de la EFF. Gracias a programas como estos, nos ahorramos tener que analizar nosotros los paquetes que circulan por la red para comprobar si están siendo «retocados».

Espero que os sean de utilidad.


Las cookies nos permiten ofrecer nuestros servicios. Al utilizar nuestros servicios, aceptas el uso que hacemos de las cookies. Más información.