Seguimos con la categorización de ataques. Entre los ejemplos vistos nos hemos topado con dos nuevas siglas, DoS y DDoS. A esto le podemos añadir otras palabrejas como zombies y botnets. Después de hacer las presentaciones, en http://www.zeltser.com/network-os-security/ddos-incident-cheat-sheet.html tienes una pequeña guía general de respuesta a este tipo de incidentes. Como puedes observar en dicha guía, nuevamente se están tomando decisiones en todo momento. En futuras clases volveremos sobre algunos aspectos incluidos en dicha guía.También hemos analizado un "shell script" orientado a la contención de algunos tipos de ataques DoS. Hemos analizado dicho código y sacado varias conclusiones. Nada es tan fácil como parece a priori.
En muchas situaciones un problema, que puede ser de seguridad, no tiene una solución definitiva, y sí acciones que pueden mitigar los efectos y reducir el impacto. En nuestra profesión, no siempre todo es 0 y 1. Considerando el "shell script" de referencia, se ha dejado constancia de que lo que puede ser una solución aceptable ante un incidente-problema, puede ser nefasto para el mismo incidente-problema, pero en un contexto o entorno distinto.
Nuevamente entramos en la necesidad de tomar decisiones, que requerirán de un amplio conocimiento de los sistemas involucrados, y del entorno en el que actúan. Es aconsejable saber asumir las consecuencias de las decisiones tomadas. El "esto no es mi responsabilidad, no es de mi área", cuando las cosas no salen bien, no es aceptable. O "que listo soy, que bien me ha salido la fotocopia", cuando es un éxito, tampoco es aceptable. Trabajamos en entornos multi-área, en los que la seguridad es un sumatorio de acciones de todas ellas, con independencia de la existencia o no de un responsable-departamento de seguridad que, de existir, debería coordinar acciones en la totalidad de las áreas (pero esto es otra película, que por ejemplo se podría titular tacones lejanos).
Muchas de nuestras máquinas están repletas de "shell scripts". Mira el proceso de arranque de una máquina linux e identificarás en el proceso un buen montón de "scripts". El conocimiento de la programación de "scripts" permite, por un lado, identificar muchos de los procesos que se ejecutan en nuestras máquinas ("shells" de arranque, de estado, etc.) y, por otro, desarrollar distintas herramientas que nos faciliten las tareas de administración, monitorización y control de nuestros sistemas. Por lo tanto, es altamente aconsejable que el alumno se familiarice con la programación de "shell scripts" (no forma parte del temario de PSI, pero cada alumno decide en lo que quiere empelar su tiempo):
* Entre la gran cantidad de enlaces relacionados con "shell scripting" puedes empezar por Writing Shell Scripts, http://linuxcommand.org/writing_shell_scripts.php
* Después de hacer distintas pruebas y algún "shell script", aconsejo que revises alguno de los muchos existentes en cualquier distribución linux. Entre otras posibles curiosidades para hacer pruebas, esta entrada "A web server in a shell script", un servidor web en poco más de 20 líneas http://www.debian-administration.org/articles/371. ¿Qué posibles problemas de seguridad identificas en dicho servidor?
Señalar que existen otras opciones para automatizar tareas de administración, como por ejemplo perl, o directamente con programación C, python, etc., etc.
La seguridad de la información requiere unos ciertos conocimientos en gran cantidad de campos (redes de comunicaciones, protocolos, programación, hardware, electrónica, cacharrería, jardinería, una pizca de pillería, cambio de pañales, fabricación de cafés, etc., etc., etc.).
Otro aspecto de gran importancia introducido en clase está relacionado con el conocimiento que todo profesional debe tener de las infraestructuras de TIC que gestiona-administra. El desconocimiento de lo que se tiene hará imposible su protección. En este sentido, se ha presentado la estructura organizativa de una red de datos, considerando el concepto de "cableado estructurado". En todo momento se ha utilizado el modelo de red de voz y datos de la UDC y la RECETGA, para mostrar ejemplos reales de redes de comunicaciones.
Sobre la Red de Ciencia y Tecnología de Galicia (RECETGA) recomiendo en http://www.cesga.es/index.php?option=com_docman&task=cat_view&gid=14&Itemid=11 la revista dixitos del CESGA. En este enlace están disponibles en pdf los ejemplares anuales de la revista del CESGA. Busca la sección de comunicaciones del último número en el que se haya incluido (por eso de que esté lo más actualizada posible). Podrás encontrar el estado casi actual de dicha red. Para los que tengan sed de conocimientos, recomiendo también las secciones de "Data Storage", de interés para cuando tratemos el tema de dispositivos de almacenamiento y seguridad. Y si después de estos sigues con sed de conocimientos, el apartado sobre el supercomputador finisterrae. Recuerda que el CESGA es uno de los "top ten" de Galicia para desarrollar un futuro profesional en TICs. Para los nostálgicos de las tecnologías, recomiendo la evolución de la RECETGA desde 1993 a 2005 disponible en http://www.cesga.es/content/view/424/21/lang,es/
Por cierto, también aconsejable visitar su sección de ofertas de empleo.
Sobre la red de la UDC no tengo constancia de la existencia en digital de información pública sobre la misma, por lo que tendréis que conformaros con el esquema expuesto en clase.
Como se sale del temario de PSI, no entraré en el estudio de la organización de las redes de comunicaciones, aunque si dejaré algunas referencias de interés. Tiene gracia el nombre de cableado estructurado, con las tanganas de cable que se suelen liar en los "patch panels" de los armarios de comunicaciones. Pero bueno, para esto está la teoría del caos.
Como el tiempo es un bien limitado, en el caso de tener que seleccionar entre las fuentes, en estos temas una imagen es mejor que 666 palabras, por lo que me centraría en los enlaces de los videos que adjunto dentro de 3 o 4 párrafos (realmente muy didácticos). Posteriormente, es aconsejable formalizar los distintos temas.:
- Structured cabling, http://en.wikipedia.org/wiki/Structured_cabling
Preferible este enlace a la entrada de la wikipedia en castellano, más extensa, pero con la que no comparto un par de apreciaciones.
En el caso de que el noble arte del idioma de Shakespeare no te atraiga mucho, recuerda que gran parte de la documentación que manejamos en nuestra profesión, no ha sido escrita por Shakespeare, pero casi. Aportando soluciones, en este caso, http://es.wikipedia.org/wiki/Cableado_estructurado
Para terminar, destacar dos magníficos videos localizados en el portal de los portales del mundo audiovisual, muy recomendables para "ver", en el mejor sentido de la palabra, lo que es un cableado estructurado, y sus elementos. Por cierto, son muy didácticos, y de gran interés.:
- Video cableado estructurado (parte 1)
- Video cableado estructurado (parte 2)
En el aspecto puramente técnico, hemos visto la posibilidad de matar conexiones de red, y la forma en la que los procesos multithread suelen atenderlas. También hemos visto la utilidad y forma de hacer un cierto control del ancho de banda de las conexiones, lo que familiarmente llamamos control del "canuto".
Hemos introducido el término "man in the middle" y "spoofing", apoyados por ejemplos. También hemos introducido el concepto de hash y colisiones. Entre las herramientas que han aparecido en la clase de hoy, señalar hping2, scapy y ADM DNS Spoofing. Las herramientas son libres, utilízalas con cabeza, y toma siempre buenas decisiones.
--
"Los estándares son siempre obsoletos. Eso es lo que los hace estándares" [Alan Bennett]
