Archivo

Archivo para la categoría ‘Seguridad’

Ataques de amplificación de tráfico: NTP

Viernes, 21 de Febrero de 2014 Comentarios desactivados

Durante el año 2013 se ha generalizado el uso de protocolos distintos al tradicional DNS a la hora de realizar ataques de denegación de tráfico, el ultimo protocolo que se esta usando es Network Time Protocol (NTP), empleado para que los equipos estén sincronizados a nivel horario.

Ya se comentó anteriormente est tipo de ataques, que se basan en dos situaciones bastante frecuentes,  una normal y otra debida sobre todo a malas configuraciones.

Es habitual y normal que haya muchas peticiones de tráfico que no sean balanceadas (se reciba más información que la que se solicita),esto ocurre en la mayoria de las situaciones (ver un video por internet, acceder a una página WWW, etc), por lo general somos “consumidores” de información y recibimos más información de internet que la que enviamos hacia fuera.

Para la mayoría de los protocolos esta situación no genera problemas de amplificación de tráfico ya que emplean un protocolo orientado a conexión como es TCP, en el cual se establece una negociación entre los equipos antes de enviar información, pero hay otros protocolos como ICMP o UDP que no son orientados a conexión .

Aquí interviene después la segunda situación que es la posibilidad de que un equipo genere tráfico con una dirección IP que no le corresponde (falsificación de direcciones, Spoofing, etc), y que este tráfico llegue hasta Internet.

Como comentábamos el documento de buenas prácticas BCP 38 , http://tools.ietf.org/html/bcp38  comentaba hace casí 15 años la necesidad de que las organizaciones filtraran el tráfico en origen , de forma que este  trafico no deseado no llegue a internet. Este  filtrado fue evolucionando de las tradicionales listas de acceso en los routers a técnicas como el “Reverse Path Forwarding”, (RPF),  implementado en los routers de la mayoria de los fabricantes, como Cisco,  o Juniper  , así en la mayoría de los sistemas operativos   (Linux, *BSD*,etC) , cortafuegos (Fortinet, Paloalto, …).

Por lo general las instituciones conectadas a RedIRIS ya tienen aplicados estos filtros y además en el backbone se realizan comprobaciones adicionales pero se puede colaborar con proyectos como spoofer  para comprobar si una red es susceptible de ser utilizada en ataques DDOS.

Estos ataques de denegación de servicio seguirán existiendo mientras haya redes que permitan la falsificación de tráfico ,aunque en el caso de NTP es algo más complicado y peligroso por diversos factores :

  • NTP es usado por muchos sistemas a la hora de mantener una sincronización horaria, necesaria para diversos protocolos  de enrutamiento , verificación de tiempos de espera y de vida de una conexión, etc. Por eso es crítico en muchos entornos.
  • Muchos servidores de NTP, sobre todo los empleados en enrutadores y commutadores no tienen la posibilidad de filtrar las peticiones de consulta “privilegiadas” en la versión del sistema operativo que están corriendo, por lo que hay que aplicar filtros para impedir su uso desde el exterior.
  • En muchas organizaciones como hardware para correr el servicio de NTP se utilizan enrutadores que disponen de varias direcciones IP (por los distintos interfaces) por lo que es necesario aplicar los filtros en todos los interfaces del equipo .

En el caso de NTP el problema es debido a que los servidores que permiten los paquetes en modo 7  (administrativo) desde otros hosts pueden recibir consultas para obtener una lista de los ultimos 600 servidores/clientes que han obtenido tiempo del servidor en cuestión. Esto puede realizarse mediante el comando monlist de la ultilidad ntpdc.

De esta forma un paquete comando de unos pocos bytes obtiene una respuesta de varios miles de bytes que pueden llegar a saturar el servidor y la red.

Existen 3 soluciones recomendadas a nivel de equipo que es servidor de NTP:

  1.   Actualizar el servicio ntp a versiones posteriores a la 4.2.7p26.
  2.   Deshabilitar el monitor. En el fichero de configuración añadir una linea “disable monitor”
  3.  Añadir “noquery” en la lista de restricciones por defecto y despues permitirla a las maquinas que interese             que reciban esa informacion.
      restrict -4 default noquery
      restrict -6 default noquery

Estas dos lineas anteriores evitaran que se ignoren los paquetes en modo 6 y 7 tanto para IPv4 como IPv6.

Referencias:

Por otro lado es aconsejable que aplique a nivel de red los filtros apropiados para evitar que se acceda desde el exterior de la organización a los servidores NTP que no sean públicos para evitar su uso en los ataques de denegación de servicio

 

La importancia de la seguridad ofrecida por eduroam

Viernes, 22 de Marzo de 2013 Comentarios desactivados
Network unlocked by CyberHades @ flickr

Network unlocked by CyberHades

Habitualmente nos paramos poco a pensar en la seguridad a la hora de conectarnos y, cada vez más, asumimos que la red simplemente está ahí, como la luz, o el agua del grifo, y que estamos tan seguros al conectarnos en cualquier sitio como lo estamos bebiendo un vaso de agua del grifo.  Puede que accediendo mediante cable nos sintamos seguros, y que, con el advenimiento de las tecnologías que permiten el acceso móvil (no ya sólo Wi-Fi, aunque en este artículo nos centraremos en eduroam) hayamos asumido que el nivel de seguridad es equivalente al de usar cable. Pero esto no es así, o mejor dicho, no siempre debemos confiar que va a ser así. De hecho, incluso el acceso mediante una conexión cableada tiene sus implicaciones de seguridad: por ejemplo, si tenemos una roseta de red a la que nos conectamos habitualmente, es posible que alguien en nuestra ausencia pueda usarla si el acceso a esta no está protegido.

eduroam se ha definido siempre como una red segura, sin pararnos muchas veces a explicar qué significa esta afirmación. Este artículo pretende clarificar una serie de aspectos relativos a la seguridad en eduroam. No entraremos, aunque lo menciono aquí de paso, en el hecho de que eduroam no sólo puede ser usada para conexiones inalámbricas: también puede usarse en redes cableadas.

Seguridad en el cifrado de la red inalámbrica

El cifrado de la red inalámbrica sirve para que la comunicación entre nuestro dispositivo móvil y el punto de acceso al que nos conectamos no pueda ser interceptada por otro usuario malintencionado que pueda leer lo que transmitimos.

Habitualmente en las redes inalámbricas de nuestros hogares conviven el acceso usando WEP (una muy mala opción en la actualidad), y WPA (o WPA2) Personal, ambos basados en esquemas de clave compartida. El primero de estos se considera ya bastante inseguro y fácil de romper, mientras que WPA2 también tienen ataques conocidos cuando implementan el estándar WPS.

En eduroam se utiliza el modo Enterprise de WPA, la ventaja con respecto a los modos Personal es que no hay una clave única que pueda ser descifrada: las claves se generan después de que se ha verificado que el usuario se ha autenticado correctamente.

Por otro lado, el estándar mínimo de cifrado en eduroam hasta ahora era WPA/TKIP, si bien desde comienzos de este año, por obligación en la política europea de eduroam, es WPA2/AES… ¿el motivo?, aun siendo generadas las claves a partir de la autenticación (y por tanto únicas para un usuario y conexión), ya existen ataques a WPA/TKIP que podrían dar con la clave que se utiliza para cifrar la comunicación entre el usuario (su dispositivo inalámbrico), y el punto de acceso al que se conecta. Por otro lado, a partir de esta fecha desaparece también en el proceso de certificación de la Wireless Alliance el soporte obligatorio de WPA/TKIP por parte de los fabricantes (es decir, ya es posible certificar productos que no incluyan WPA/TKIP).

Seguridad en la entrega de las credenciales a nuestra institución

Quiero dejar claro primero de todo, que mientras el usuario no se ha autenticado -y para ello se usa el cifrado del que hablaremos a continuación-, no se obtendrán las claves de cifrado que nuestro cliente utilizará para cifrar la comunicación con el punto de acceso… ¿qué quiere decir esto? ¿significa que pueden interceptarse las credenciales del usuario en una fase previa a la asociación con el punto de acceso?

Precisamente no. Y precisamente en ello radica la importancia del uso de certificados en eduroam y la comprobación del emisor de los mismos.

La conexión entre el cliente y el servidor que autenticará a la red hace uso también de criptografía, generalmente utilizando algún método tunelado como EAP-TTLS o PEAP, y es muy importante que el cliente verifique que está hablando con el servidor de su organización y no con cualquier otro servidor que intentara suplantarlo. En concreto, no sólo es importante que el cliente conozca quién firma el certificado de su servidor, sino también que valide el asunto del certificado de su servidor (generalmente el nombre del servidor, p. ej.: radius.rediris.es), sobre todo si la autoridad de certificación es “conocida” (nos referimos a una autoridad que esté reconocida por la mayoría de clientes). De no hacerlo de esta manera podríamos estar creando un túnel entre el cliente y cualquier otro servidor cuyo certificado esté firmado por la misma raíz de confianza que el nuestro; es decir, estaríamos estableciendo un túnel seguro, sí, pero podríamos estar entregando las credenciales a cualquier otro servidor que no es el de nuestra institución.

Problemas asociados con la validación del certificado

Todo lo anteriormente dicho es muy bonito, pero no siempre podremos hacerlo… ¿el motivo? implementaciones deficientes por parte de los clientes. Para muestra dos botones:

  • Android. Incluso en versiones recientes no incluye la posibilidad de validar el asunto del servidor: sólo podremos validar la autoridad de certificación, es decir, nos protege a medias.
  • Linux/NetworkManager. Mismo caso que Android. Hasta versiones recientes de los interfaces gráficos que hacen uso de NetworkManager no se ha incorporado la validación del asunto.

En ambos casos resulta paradójico que en realidad lo que falla es cierta funcionalidad en la interfaz gráfica de usuario. Curiosamente en los dos casos mencionados las plataformas (ambas con kernel Linux) hacen uso de la herramienta wpa_supplicant, que sí soporta la validación del asunto del certificado de servidor.

¿es mejor un certificado autofirmado o uno firmado por una autoridad conocida?

Un certificado autofirmado (o firmado por una autoridad de certificación propia) presenta el problema de su distribución; habrá que distribuirlo a todos los clientes; como ventaja, si se controla la autoridad de certificación, podría llegar a prescindirse de la validación del asunto del certificado. Por el contrario, una autoridad de certificación conocida ofrece la ventaja de que ya está distribuida “de serie” en muchos clientes, mientras que como pega, nos obliga a realizar una validación del asunto del certificado del servidor.

En RedIRIS opinamos que es mejor la segunda opción, pues la tarea de instalar certificados suele ser más difícil para el usuario en algunas plataformas. Por otro lado, si la institución proporciona un kit de instalación, tanto la instalación del certificado como su verificación se pueden realizar perfectamente desde dicho kit de instalación. Muchas organizaciones que han optado por esta opción usan los certificados emitidos a través del servicio SCS de RedIRIS, que utiliza una raíz de certificación conocida como es Addtrust External CA Root.

¿merece la pena tanta seguridad?

Queremos pensar que sí. Hay partidarios de la facilidad de uso en contraposición a la seguridad, pero creemos que el nivel de seguridad aportado por eduroam es una cualidad que los usuarios apreciarán, pues protege sus comunicaciones. Por otro lado el administrador de la red también necesita de esa seguridad para saber que quien se conecta a la misma lo hace con legitimidad.

¿y que hay de los tipos de autenticación?

Los dos métodos más usados en eduroam, PEAP (generalmente utilizado en combinación con MSCHAPv2), y EAP-TTLS (usado habitualmente junto con PAP), protegen las credenciales, pues crean un túnel entre el cliente y el servidor, de la manera mencionada anteriormente. La principal ventaja de estos métodos es la privacidad que puede ofrecer al usuario, puesto que en la denominada identidad externa no es necesario consignar el nombre real del usuario, sólo la institución a la que pertenece.

EAP-TLS es usado también por algunas instituciones en eduroam. Tiene la ventaja de estar soportado en muchas plataformas, pero tiene el inconveniente de que hay que generar certificados para todos los clientes, y se pierde en privacidad, salvo si el certificado de cliente ya la incorpora. Por otro lado, EAP TLS es más susceptible de verse afectado por problemas de fragmentación de paquetes.

¿no se prevee en el horizonte algo más sencillo que esto para el usuario final?

Respuesta corta, sí. Respuesta larga:

  • En lo que respecta al cifrado en la red, la desaparición gradual de cualquier tipo de cifrado anterior a WPA2/AES, tanto en equipamiento de red como en hardware cliente, supondrá también la eliminación del problema que teníamos hasta ahora con la convivencia de WPA/TKIP y WPA2/AES (¡y de las minoritarias combinaciones WPA/AES y WPA2/TKIP!).
  • Algunos estándares como EAP-PWD parecen bastante prometedores. Se utiliza criptografía fuerte para proteger las comunicaciones entre cliente y servidor, pero en ningún momento las credenciales viajan entre el equipo que se autentica y el de su institución.
  • Por otro lado, cada vez podemos ver más esfuerzos de los fabricantes de software/hardware por soportar más esquemas de autenticación. Como ejemplo citamos a Microsoft, que en Windows 8 ha introducido el soporte de EAP-TTLS.
¿la complejidad viene por dar soporte a estas características de seguridad?

No es lo único que influye. Determinados sistemas operativos ofrecen una API de provisioning, permitiendo que la institución pueda ofrecer una instalación sencilla para el usuario, donde éste sólo tendrá que introducir su usuario y contraseña. Otras plataformas sin embargo no lo hacen, y es necesario crear instaladores o proporcionar instrucciones de configuración que, lo sabemos, pueden llegar a ser difíciles de seguir .

Desde eduroam en Europa se ha estado desarrollando en los últimos años eduroam CAT, herramienta de la que hablaremos en nuestro próximo artículo, y que permite a los administradores de eduroam generar facilmente perfiles de configuración e instaladores de eduroam que facilitan la labor de configuración a los usuarios.

Categories: Información general, Seguridad Tags: