Planeta RedIRIS

Algunos piensan que con esto de la crisis económica todo vale y que ya que recibimos spam todos los días el buscar de forma masiva direcciones de correo y emplear los servidor de listas de las organizaciones para la difusión de convocatorias de congresos, revistas, cursos y demás formas de conseguir financiación adicional o prestigio, yo personalmente creo que hay que hace hincapié en los responsables de las listas de correo internas de cada organización para evitar este tipo de comportamientos.

No se ve todos  los días , pero como mínimo una vez al mes se recibe  información desde listas de correo sobre masters, cursos, congresos y demás organizados por departamentos o centros de instituciones afiliadas, donde sin haberlo pedido en ningún momento me han incorporado a una lista de distribución.

Mención aparte merecen algunas organizaciones afiliadas a RedIRIS con difusión internacional que añaden de forma masiva a los usuarios extranjeros que acceden a una de sus cursos/conferencias y charlas y de los que recibimos diariamente quejas de algunos ISP estadounidenses.

Aparte de la mala imagen para la organización, generación de spam a los destinatarios, etc,  están los problemas de listas negras.  por lo que un uso irresponsable de los recursos que proporciona la organización pueden provocar perjuicios a otros usuarios  en un momento determinado.

Por favor. recordarle a los administradores de las listas de correo las normas de buen uso , gran parte de vosotros las tiene ya publicadas y aprobadas , por ejemplo en :https://www.google.es/search?q=rediris.es+listas+de+correo+normas&rlz=1C5CHFA_enUS503ES505&oq=rediris.es+listas+de+correo+normas&aqs=chrome.0.69i57j69i62l2.6272j0&sourceid=chrome&ie=UTF-8

Y explicitamente en RedIRIS en http://www.rediris.es/mail/abuso/ace.es.html  (perdonar por los tipos mime sin actualizar 😉  se indica claramente que este tipo de contenido viola varios de los puntos que desde RedIRIS se consideran contenido abusivo.

un saludo a todos

En  una reunión paralela al IETF 87 en Berlin , de un grupo de «hackers» interesados en la seguridad informática hubo una comparativa entre el rendimiento de algunos dispositivos de seguridad en IPv4 e IPv6, bastante completa y con varios sistemas de pruebas que se están haciendo ya.

En http://www.insinuator.net/2013/08/ipv6-hackers-meeting-ietf-87-in-berlin-slides/ están las presentaciones que se hicieron con varias pruebas.

Hay que indicar que se trata por lo general de equipamiento para redes pequeñas y no de equipamiento de backbone pero es interesante a la hora de saber como se comportan estos fabricantes a nivel de IPv6.

En los últimos años los ataques de  Denegación de Servicio Distribuido (DDOS) son cada vez más frecuentes y se basan en la falsificación de tráfico IP y la amplificación de este (Usar protocolos cuyos paquetes de respuesta sean de mayor tamaño que la petición enviada).

La falsificación de tráfico es debido sobre todo a redes mal configuradas que permiten que se genere tráfico que no pertenece a su rango de direcciones , a pesar de que el Documento de Buenas Prácticas (BCP 38) , indica que no se debe permitir, sin embargo todavía muchas redes lo permiten y esto permite que los equipos infectados de una botnet puedan falsificar el tráfico indicando que el origen es otro equipo (la víctima) el que genera el tráfico .

De esta forma el tráfico le llega a equipos en Internet que al responder le responden a la dirección de la víctima que se satura por el número de paquetes y volumen que les llega.

La amplificación de tráfico lo que permite es que los atacantes consigan que por un 1k de trafico los equipos al responder le reenvíen una cantidad mayor de datos a la víctima , en algunos protocolos se puede conseguir una amplificación de hasta 1:1000 o superior.

Cuando se falsifica el tráfico el atacante no espera respuesta , por lo que se deben emplear paquetes de datos UDP, que no requieren un establecimiento de conexión , esto descarta inicialmente ya bastantes protocolos comunes, como HTTP, correo, etc que van por TCP, sin embargo hay varios protocolos UDP que se usan bastante:

• DNS, fue el primero en ser usado,  más información en esta entrada del blog.
• SNMP (puerto 161) se emplea sobre todo para la monitorización de red, se esta usando bastante ya que hay muchos equipos que llevan una configuración «vulnerable» por defecto,  en http://www.bitag.org/report-snmp-ddos-attacks.php hay un documento que explica bastante bien los problemas.
• Chargen (puerto 19) , es un protocolo antiguo que se usaba para comprobar que un equipo respondía en Internet,  no tiene mucho sentido desde hace mucho tiempo, pero muchos equipos lo tienen configurado , en  el diario del ISC de SANS,  comentan que se esta también usando para la generación de ataques DDOS , ya que permite una generación algo más reducida (un máximo de 512 caracteres )

SNMP es el caso más problematico , junto al DNS  ya que es un protocolo que se puede emplear para monitorizar y configurar el equipamiento, además:

1.  Es posible amplificar el tráfico , es decir que enviando un paquete de tamaño reducido conseguir que se generan una respuesta mucho mayor (se habla muchas veces de 1:100  para algunas consultas, pero al parecer es posible llegar a una amplificación cercana a 1:10000 , (por un byte recibido el equipo genera 10000
2. ) La seguridad del protocolo en su versión 1.0 se basa en una clave (community» ) que muchas veces es «publica» para consultas .
3.  En muchos dispositivos de red el demonio SNMP escucha en todos los interfaces IP que tiene el equipo, lo que puede dificultar su filtro.
4. Al ser un protocolo de monitorizacion en muchos dispositivos esta habilitado por defecto , no solamente en dispositivos de red sino también en equipos Linux, SunOS, ADSL, etc.
5. Muchos equipos llevan configurado el servicio con los valores por defecto, que son públicos.

¿Qué se puede  hacer en vuestras instituciones ?.

1. Por defecto filtrar las consultas SNMP desde el exterior, de forma que salvo las excepciones que necesitéis por monitorización externa este filtrado todas las consultas SNMP desde el exterior.
2. Permitir solamente el acceso SNMP a las redes externas que os hagan monitorización y solamente como único recurso
3.  Emplear en lo posible una VPN o un túnel GRE a la hora de las monitorización  externas, de forma que no haga falta hacer lo contemplado en el punto 2.
4.  Cambiar las claves (comunidades ) de acceso de forma que no sean los nombres por defecto y realizar estos cambios de forma periódica.
5. Limitar en los equipos no perimetrales lo indicado en los puntos 1 y 2 y 4 , de forma que solamente los equipos que tengan que hacer consultas SNMP pueden hacerlas y no cualquier equipo dentro de vuestra institución.
6.  Monitorizar los equipos para ver cuando se producen este tipo de conexiones de forma insistente y cuando estas conexiones son ataques de fuerza bruta  (recordar que por SNMP no solo se puede monitorizar sino también cambiar configuraciones en los equipos).