21 de octubre de 2010

No cON Name 2010 (2/2)



conjuntoEntradas() {
  No cON Name 2010 (1/2)
  No cON Name 2010 (2/2)
}

Hoy, como era de esperar, he estado en el segundo y último día de asistencia al No cON Name y este es mi resumen de las ponencias del día.

IP Fragmentation Overlapping
Jose Selvi nos ha dado toda una lección sobre IP Fragmentantion Overlaping.
Ha empezado dándonos los conceptos básicos del fingerprinting, mediante el comportamiento de la pila de red del implementador, obtenido a partir de la respuestas de las peticiones IP que quedan fuera de lo especificado en la RFC.

A partir de la técnica de IP Fragmentation Overlaping nos ha demostrado como poder hacer un pentest saltándonos un IDS si la configuración no está afinada a la arquitectura de red que pretende proteger.

Ha sido una muy buena ponencia, ya que parte de ella la ha dedicado a realizar tres demos de los conceptos explicados y de algunas de las casuísticas que te puede encontrar.

Reversing for goods: fixing security vulnerabilities in binaries
Sergi Álvarez (pancake) ha dado un ponencia muy técnica sobre el parcheado de binarios para mitigar 0 day, hacer jailbreak de dispositivos, creación de exploits, etc.

Sinceramente, yo estoy un poco verde en este aspecto, y aunque he podido seguir ciertas partes de la charla, no he podido llegar a comprender todos los aspectos o comprenderlos profundamente.

Ha explicado las distintas técnicas de parchear binarios usando la herramienta, Radare2, co-desarrollada por él mismo. También ha mostrado varios ejemplos simples de como parchear, con las distintas técnicas comentadas.
Y para finalizar ha comentado como se pueden parchear dos vulnerabilidades que han tenido bastante revuelo, sobre todo una de ellas que es la que utiliza el gusano Stuxnet.

Development of security-critical embedded systems
Lamentablemente sobre esta charla solo puedo decir “No comment”.

SMSspoofing: fundamentos, vectores de ataque y salvaguardas
Julían Díaz nos ha hablado, a partir de un estudio que llevan realizando hace tiempo, del SMS Spoofing muy focalizado en los servicios ofrecidos por proveedores de envío masivo de SMS.

Han explicado los conceptos generales y aplicaciones que pueden ser vulnerables y como y con que han realizado las pruebas, además de haber hecho algunas demos con esto.

Para finalizar han indicado sus recomendaciones para protegernos tantos los usuarios como las operadores sobre este tipo de ataques.

Resolución de concursos de la No cON Name 2010
Alejandro Ramos y Francisco Alonso han realizado la resolución de los concursos a los que nos podíamos a presentar como participantes.

Las resoluciones, aunque no he participado, me han parecido muy instructivas, he aprendido conceptos que pueden se aplicables en otros ámbitos, además de tener una visión de como abordar estos retos.

Concretamente me ha gustado mucho la resolución del concurso “Iluminación de Randa”, ya que estaba basado en un problema de carácter real. En él se ha explicado como bloquear el ataque y después como crear un informe detallado de lo sucedido, además para añadir la guinda al pastel, han comentado el el ataque que ellos mismos hiciero sobre la infraestructura de control del spyware, es decir el contraataque a los malos.

Ellos se habían presentado al consurso por hobby, es decir sin formar parte de los participantes que optan al premio, pero como nadie más se ha presentado, la organización ha decidido darles el premio ellos, aunque realmente se lo han bien mercido por el excelente trabajo que han hecho; hay que decir que son unos cracks!

Políticas llevadas a cabo en la Generalitat de Catalunya
Jordi Bosch ha explicado, como el título indica, políticas que llevan a cabo en la Generalitat; realmente no tengo mucho que decir, solo que tienen en cuenta aspectos que no me hubiese pensado que los tienen en cuenta, aunque no pongo la mano en el fuego, si realmente se ponen en práctica o solo se aplican a nivel de discurso.


Antes de terminar el post quier hacer un comentario sobre algo que sucedió ayer. El ppt de la ponencia "Aspectos organizativos ligados a la seguridad de la información", dada por Joan Ayerbe, estaba en catalán algo que me pareció fuera de lugar, ya que a mi parecer, el congreso estaba dirigido a la audiencia en general y no solo a la audiencia catalana, por lo tanto esto, desde mi punto de vista, ya me pareció un FAIL a la audiencia; pero la cosa no quedó en solo esto, luego me enteré que el acto de inauguración, el cual me salté, fue dado en catalán, así que si lo del ppt me pareció un FAIL, esto último me parece una falta de respeto, en toda regla, a la audiencia.

Parece que esto último llegó a oídos de los organizadores, ya que el último ponente, Jordi Bosh, antes de empezar comentó que le habían dicho que hiciera la ponencia en castellano, y que él, como era de esperar, la haría en castellano ya que el objetivo es la comunicación, vamos lo que para mí es, a nivel global, el objetivo principal de la lengua; a parte de esto pidió disculpas, por adelantado, si al darla en castellano pudiese llegar a soltar alguna catalana.

Hasta la próxima enfermos.

Actualización
La organización me ha aclarado como fue concretamente lo que realmente sucedió en la presentación del evento, que cómo ya dije no asistí, llegándome el feedback de terceros, y para la cual he manifestado que me pareció una falta de respeto a la audiencia.

Así que actualizo la entrada con este comentario para dejar claro como dio la situación y quien realmente tomó la iniciativa; la cosa fue así:
“El acto fue presentado y distendido en castellano tanto por presidente de la asociación y patrocinadores. La intervención en catalán fue del colaborador, el director del CESICAT”.

No cON Name 2010 (1/2)



conjuntoEntradas() {
  No cON Name 2010 (1/2)
  No cON Name 2010 (2/2)
}

Hoy he asistido al primer día, de un total de dos, del congreso No cON Name 2010; aquí os dejo mi resumen de las ponencias a las que he asistido.

HTC Nand dumping for forensics purposes
Pau Oliva nos ha dado un lección sobre el dumping de memoria flash del tipo Nand sobre dispositivos HTC.

El detalle dado de los métodos que existen para hacer un análisis forense sobre estos dispositivos ha sido genial, desde los métodos hardware hasta los realizados desde el sistema operativo, pasando por los realizados desde el bootloader, este último es de los que más me ha interesado. A mí parecer, ha comentado los pincelazos clave, para quien tenga un interés sobre este campo, pueda lanzarse y motivarse en empezar ha hacer su propios pinitos.

Aspectos organizativos ligados a la seguridad de la información
Es posible que parte de la audiencia le haya parecido una ponencia palo, pero a mí personalmente, me ha gustado, ya que encaja en lo que pienso a nivel general, que básicamente se reduce a que la organización es factor clave en todos los ámbitos ya sean tecnológicos o no.

Joan Ayerbe ha comentado las implicaciones que tiene tomar la riendas de implantar un modelo organizativo desde el punto de vista de la seguridad de la información.

Como todo proceso los pros y contras están presentes; desde los beneficios hasta los inconvenientes de los recursos (costes económicos directos e indirectos como volumen y dedicación de los recursos humanos necesarios) que hay que emplear; el objetivo, que claramente ha marcado Joan, es el buscar el equilibrio entre el nivel de seguridad y los costes, lo cual se consigue viendo las necesidades reales del negocio.

Joan nos ha comentado los procesos organizativos y qué organismos internos hay que crear para implantar y concienciar a los usuarios, indicando que uno de los aspectos más importantes es el apoyo de la dirección y la gestión del cambio.

La ponencia me ha tocado el corazón, ya que es día a día que vivo, que intentar concienciar a los usuarios y a la dirección, está última la tarea más difícil.

802.1X y 802.11i – La única seguridad real en Red
Yago Fernández nos ha hablado de securizar los accesos a la red en capa 2, utilizando el protocolo 802.1x, para redes cableadas, y 802.11i para redes inalámbricas.

Nos ha hablado de las herramientas que hay, que aplicar y cómo; además también no has comentado como poder hacer un par de ataques al conocido protocolo RADIUS y como mitigarlos si no dejamos de banda los parámetros opcionales y si configuramos todos los parámetros de seguridad.

Una de las cosas que ha comentado y que me ha llamado la atención, por mi ignorancia, ha sido el comentario que ha hecho sobre lo “sencillo” que es montar un appliance, tanto a nivel de hardware como del sistema operativo.
Vamos, es todo un crack!

“Que vienen los Zombis”
Pedro Sánchez de Conexión Inversa nos ha dado un repaso a lo que hacen y las buenas prácticas que aplican.

Nos ha detallado que medidas utilizan y aplican para defenderse y rastrear los nuevos ataques que pueden surgir en la web.

Ya acabando nos ha contado uno de los ataques, el “Ataque Zulú”; les hicieron un DOS además de de echarles a bajo varios de los sensores. Finalmente el ataque era concretamente un DDOS desde una botnet y finalmente les ganaron; pero como no “uno se cae para volverse a levantar” y de ahí aprender de la hostia y estar preparado para un futuro ataque; de ellos han sacado hasta una aplicación.

Nuking and defending SCADA networks
Alexis Porros y Silvia Villanueva nos han expuesto las necesidades de los sistemas SCADA a nivel de seguridad.

Nos han comentado que las preferencias de seguridad en estos sistemas es distinto a la gran mayoría de sistemas que estamos acostumbrados a ver, prevale la disponibilidad frente a la confidencialidad pasando por la integridad.

También nos han hablado de como ha cambiado estos sistemas en poco tiempo, a partir del boom de las comunicaciones, conectando estos sistemas a Internet y a raíz de esto como se ha producido varios estragos; a eso hay que sumarle lo poco actualizados que están estos equipos debido a que los sistemas tienen muy poco soporte por parte del fabricante o directamente están fuera de mantenimiento y su actualización no es para nada fácil, debido a los sistemas que controlan y la disponibilidad que se demanda en estos sistemas.

Finamente nos han comentado un poco acerca del gusano Stuxnet.


En definitiva, ha sido un día interesante ya que muchos de los conceptos explicados me han permitido abrir la mente en cuanto a conocimientos, algo que ya esperaba y espero que mañana vuelva a ser un día tan productivo como el de hoy; las valoraciones individuales sobre cada ponencia me las reservo para comentarlas con los colegas en vivo.

Hasta la próxima enfermos.

10 de octubre de 2010

Gestionando incidencias de manera organizada (3/3)

conjuntoEntradas() {

Planificando la resolución
Asumiendo mi rol, por falta de la persona al cargo y por la poca experiencia de mi compañero, no sin motivos justificados, decidí invertir mi maravillo tiempo dentro de la jornada y fuera de él, a planificar la resolución de la incidencia, que se iba a atender al día siguiente y fuera de la jornada laboral para no entorpecer la actividad diaria de la empresa, después de saber que se tenía que restablecer el sistema por completo.

Como por motivos de productividad y disponibilidad no se podía atender el mismo día, yo tenía más tiempo de realizar una mejor planificación, más detallada, pensada y documentada. Así que pensé y evalué exhaustivamente la situación y de ahí saque un documento donde se detallaba lo sucedido, los sistemas afectados y el tiempo necesario para su restauración completa (debido al volumen de información), las actuaciones a realizar sobre los sistemas afectados indirectamente y la lista de acciones a llevar a cabo de manera correlativa.

Al plasmar todo esto en un documento, me permitió tener un mejor razonamiento de la situación y de sus resolución; además el documento iba a ser a la guía para hacer lo de manera metódica y no olvidarse de nada, dar un soporte a la explicación verbal mi compañero para que lo tuviese más claro y pudiese acudir en caso de duda, teniendo presente que la incidencia era en la oficina donde él estaba y que nos separaban unos 600 km y además tener un informe de la incidencia algo que nunca se ha hecho y que en situaciones futuras se puede llegar agradecer, como los planes de contingencia, que por cierto a falta de recursos, también son inexistentes.

Con todo lo que acabo de mencionar, creo que el tiempo invertido en crear el mencionado documento, ha sido de sobras, rentabilizado, además de la satisfacción de trabajar planificada y organizadamente, y más cuando algún miembro el equipo está desconcertado y con poco control de la situación.

Aquí os dejo un documento modelo del que realicé por si puede servir de algo.

Conclusiones
Las incidencias surgen cuando toca y es bastante complicado o prácticamente imposible predecir cuando van a suceder así que cuando más preparado estés, planes de contingencia, infraestructura de backups, copias de seguridad actualizadas de la información y de los sistemas críticos (configuraciones, parametrizaciones, etc.), sistemas hardware replicados y preparados para soportar posibles fallos, etc., y sobre todo cuando no hay un plan de acción para la situación o una situación que se lo asemeje y hay un margen temporal de reacción entonces piensa, razona y elabora un planning de como vas a abordar la resolución y restauración manteniendo el servicio los más disponible posible mientras actúas y si no eres un lobo solitario y tienes compañía, un equipo o un único compañero, explícale el planning y hazle participe en las situaciones que le implican directamente, si realmente quieres que “te eche un cable” y le ponga ganas al asunto.

Hasta la próxima enfermos.

6 de octubre de 2010

Gestionando incidencias de manera organizada (2/3)

conjuntoEntradas() {

Descripción de la incidencia
Durante la mañana se detecta que el servidor está offline; entonces se procede a verificar el motivo y se detecta que está en la pantalla justo antes de realizar el boot del sistema operativo.

Se revisa lo que sucede y desde la controladora SATA-RAID se detecta que dos discos están en estado offline, por lo que se prueba de forzar su estado a online y se revisa si el sistema operativos es capaz de arrancar. Por ahora aunque el indicativo es que el fallo es de dos disco, al encontrarlos en estado offline y no en estado fail puede que el fallo haya sido, aunque poco probable, por otra causa.

El sistema operativo arranca, por lo que el servicio esta de nuevo disponible. Tras arrancar se decide instalar un aplicación del fabricante que monitorea el estado del hardware, esto ya es un FAIL por no tenerlo instalado desde que el servidor se puso en producción. Con dicha aplicación se pueden lanzar test sobre el hardware, en este caso lo hicimos sobre los discos, y en el test se comprueba que un disco falla, así que se llega a la conclusión que el reinicio pudo ser algo puntual por fallo de un disco algo que siendo un RAID 5 no tendría porque haber sucedido, pero al arrancar sin problemas de nuevo, no da pie a pensar, después del test, que haya dos discos dañados.

Se tramita el cambio de disco con el fabricante y al día siguiente, antes de que empiece la jornada laboral, se reemplaza.

El servicio se levantó en menos de una hora y se mantuvo todo el día, pero al día siguiente después de haber reemplazado el disco, el servicio se vuelve a detener con los mismos síntomas; esta vez el disco que el día anterior había estado offline se encuentra en estado fail, no obstante se puede de nuevo levantar el servidor y con otro aplicación de diagnóstico se obtiene un estado del servidor en un fichero de log que tras el análisis por parte del fabricante se dictamina que el segundo disco también está averiado. Debido a que el fallo, se produjo en dos discos, se nos indica que hay que reinstalar todo el sistema de nuevo, ya que el error puede haberse propagado al resto del RAID y eso puede producir inestabilidades en el sistema.

Aquí es cuando para mí empieza el tratamiento de la incidencia de manera planificada, ya que hasta el momento ha sido acción-reacción ya que el problema estaba ahí y había que resolverlo lo antes posible y las circunstancias han permitido activar y mantener de nuevo el servicio y tener un margen acotado de tiempo para organizar como eliminar el problema definitivamente.

No me voy a alargar más explicando que es lo que se ve afectado por la caída de uno de los servidores de almacenamiento en una de las oficinas, ya que tendría que entrar en bastante detalle en el funcionamiento del sistema y no es el objetivo de esta serie de posts.

Información a los usuarios
Yo soy de los que prefiere estar informado de las cosas y vivir la realidad antes que vivir engañado pensando que todo es un jardín de rosas.

Esta es una de las cosas que yo he echado en falta desde que rondo por la empresa, siempre que pasa algo y en algunas ocasiones, se va hacer algo no se informa ni se advierte de nada a los usuarios. Sé que a veces esto puede ser contraproducente, por la idea que algunos se puedan hacer de la situación, pero creo que eso se soluciona dando un explicación con los mínimos tecnicismos que se pueda pero que te permita explicar de lo que sucede y como se va a solventar la incidencia, esto último es muy importante mencionarlo y como se dice para que no cunda el pánico.

Así que con el rol que tenía desde un primer momento decidí mantener a los usuarios informados para evitar, la sicosis de estos, ya que cuando lo que involucra la incidencia es información y encima la que está generando día día los empleados con su esfuerzo, es lo que le coge a todos, supongo que pensando las N horas extras sin remuneración que tendrán que hacer para restablecer el trabajo ya realizado.

Manteniendo los informados, también te evitas que te suene el teléfono cada 2 minutos, preguntando te que sucede y cuando va a estar solucionado además de escuchar, en algunos casos, despotricaciones varias; por lo que el tiempo que dedicas escribiendo el comunicado, creo que se rentabiliza, de manera lineal al número de usuarios afectados.

Además en este caso, también era necesario información que actividades podían desarrollar con normalidad y cuales no y como hacer un workarround mientras se solventaba la incidencia.

Hasta la próxima enfermos.

3 de octubre de 2010

Mis amigas las ratas

Que a los informáticos nos metan en el sótano ya ha pasado a la historia, o más bien eso yo creía hasta hace dos mese y pico, cunando me comunicaron que me iban a cambiar de sitio de la oficina; como que en la oficina no hay mucho sitio si no se hace algo de obras, que debido a la situación económica mejor las dejamos para otra ocasión, se plantearon la pregunta de ¿dónde vamos a meter al informático? la respuesta clásica sería en el sótano, pero a falta de él lo más fácil es buscar a lo que más se asemeja, en este caso el archivo.

Yo que pensaba ahora que la tecnología convive con todos y es parte de nuestra vida diaria y que todos estamos continuamente manipulando ordenadores, teléfonos móviles, que ya hacen de todo, sistemas de entretenimiento, utensilios de cocina como los que te hacen automáticamente la comida, etc. A raíz de esto yo pensaba que la peña empezaba a cambiar la visión que tienen de nosotros y los tópicos que hay, empezaban a diluirse.
Bueno, sea la realidad o solo lo que yo creía (por una experiencia profesional que viví y por lo que se puede ir leyendo) los informáticos han ido evolucionando, dentro de las organizaciones, de unos bichos raros que están ahí con las máquinas en los sótanos a formar una parte importante del negocio (sin tener en cuenta las empresas cuyo negocio es la tecnología) y donde su papel es fundamental para poder competir dentro en el mercado; ¡¡¡joder si incluso le han cambiado el nombre al departamento!!!

Ahora con mi traslado, tengo dos cosas a pensar, mis creencias eran equivocadas o la empresa donde trabajo está un poco atrasados en cuanto a términos organizativos y competitividad comercial.

Muchos de mis compañeros, no de departamento ya que en la sede donde yo trabajo estoy solo, me decían antes de cambiarme, “¿Ahí te van a meter? ¿no es un poco claustrofóbico?”, y los que habían participado en la decisión de mi cambio me dicen ahora “Es un sitio amplio y tranquilo ¿no? ¿a que estas bien aquí?”.

Y mis respuestas sinceras a todo esto es, que me tengo que aguantar, porque total me van a meter me guste o no  y sin tener en cuenta mi opinión y si tengo claustrofobia ya me acostumbraré y se me pasará, y por lo de si estoy bien, pues realmente tampoco estoy mal si no pienso que me han quitado una de las cosas que más me gusta, la luz natural, pero por lo demás no me puedo quejar, es un lugar tranquilo y tengo espacio necesario para trabajar.

Para ir terminando con el rollo este os voy a dejar un foto de mi nuevo amigo que he hecho después de llevar ahí más de dos meses y el cual sea convertido también en mi compañero del día a día, después de que a ambos se nos quitase el temor que, inicialmente, teníamos uno del otro.

 Mi compañero y colega Ratbit

Hasta la próxima enfermos.

2 de octubre de 2010

Gestionando incidencias de manera organizada (1/3)

conjuntoEntradas() {

De que va esto
En esta serie de posts voy escribir una posible forma de gestionar de una manera más o menos organizada como se debería gestionar una incidencia en empresa de tamaño medio con menos personas en el departamento de TI de lo que realmente sería necesario, teniendo en cuenta que tampoco se contratan recursos externos (outsourcing y/o insourcing).
Antes de continuar con el tema a tratar quiero dejar claro que lo aquí descrito no tiene que ser lo estrictamente correcto y mucho menos la manera perfecta, todo se puede mejorar; ésta, ni de lejos, es la única vía para tratar incidencias, pero si, desde mi punto de vista, una manera ordenada, organizada y metódica de hacerlo, aunque el resto es libre de opinar de otro modo, y por mi parte lo respeto totalmente.
Porque ahora
Si ahora estoy escribiendo este conjunto de posts es porque antes de ir me de vacaciones, tuve que afrontar, en la empresa donde ahora trabajo, una incidencia; esta vez a diferencia de las demás tenía que asumir el rol de gestionar su resolución debido a que el responsable que lo tendría que hacer estaba gozando de sus merecidas vacaciones. En el pasado he participado en muchas otras pero siempre he tenido un papel de técnico que le indican que es lo que tiene que ir haciendo y como se tiene que coordinar con el resto del equipo y siempre he pensado, ya sea por la situación del departamento dentro de la empresa (no hay tiempo material dentro de la jornada laboral, con los recursos que somos para hacer las cosas bien) o por cualquier otro motivo, que, el orden, la coordinación y la metodología han sido inexistentes.

Todo esto quería publicarlo en el momento que pasó pero entre las vacaciones, el volumen de trabajo al regreso en la empresa en la cual trabajo y nuevos retos profesionales en modo freelance me ha obligado a retrasar su publicación.

Escenario organizativo
El escenario en el que se desarrollo la incidencia es el siguiente:
  • Empresa con unos 110 usuarios aproximadamente, de los cuales unos 80 trabajando en las tres oficinas que consta la empresa, el resto de vacaciones, de viaje de negocios o trabajan fuera por la actividad que están desarrollando.
  • Departamento de TI, o podríamos decir de mierdas varias, formado por 4 personas, 2 en la oficina de Madrid, 1 en Bilbao y el otro, yo, en Barcelona. Dadas las fechas, solo eramos dos, yo, y el recién incorporado y recién terminado un CGS de Administración de Sistemas, en Madrid.

Escenario tecnológico
La infraestructura de comunicación, la descrita en este post, pero ahora sin la cuarta oficina, Málaga, que la crisis ha obligado a cepillarse la.
Se utiliza el sistema DFS (Distributed File System), para mantener replicados en las 3 oficinas gran parte de los espacios de almacenamiento de documentos de trabajo, pero sin Share Point, usando un sistema de acceso desarrollado en la empresa para atacar los repositorios evitando accesos simultáneos a mismo fichero, sobre este punto, no hago manifestaciones, ya que no es el objetivo de este conjunto de posts.
Usamos 3 máquinas en cada oficina para el almacenamiento de la información, replicando se en malla por pares, es decir los 3 servidores de una oficina contienen información distinta, por lo que no se replican entre ellos, y se replican con sus 3 homólogos ubicados en las otras dos oficinas; y lo hacen las 24 horas y con todo el ancho de banda que la red les dé.

Sistema afectado
La incidencia fue originada por el fallo de dos discos montados en RAID 5 de uno de los 3 servidores de almacenamiento ubicado en la oficina de Madrid.

Hasta la próxima enfermos.