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.

22 de agosto de 2010

Ocio a bordo, powered by GNU Linux

En el viaje en avión de vista a la costa noreste de USA en motivo de mis vacaciones he experimentado el primer viaje de tanta duración que he hecho en mi vida; no es que haya sido un viaje extremadamente largo, solo unas 8 horas y media, pero supongo que pasado un cierto umbral tiempo, las compañías aéreas tienen que pensar que hacer para mantener a los pasajeros distraídos durante ese tiempo.

Ciertas compañías, principalmente las low cost deciden someterte a una buena dosis de SPAM pero aunque es una manera de hacer negocio, no es que sea un solución para mantener a los pasajeros distraídos, sino más bien lo contrario. En mi caso no ha sido así, me han dado de comer dos veces, de beber unas cinco o seis veces y no me han obligado a ver reflejarme en una pantalla ni una sola peli.

El avión con el que fui, tenía incorporado una pantalla por asiento, que en mi caso y en la mayoría de los asientos, clase turista, estaba pegada en la parte trasera del reposa cabezas del asiento delantero. La pantalla era táctil y en ella aparecía un sistema de entretenimiento a bordo.

El sistema de entretenimiento, por ahora sin saber en que SO estaba basado, tenía un repertorio suficientemente amplio de películas, música y vídeo juegos. Supongo que hasta aquí nada nuevo para los que viajen muy a menudo largas distancias, pero a mí realmente me impacto que los aviones ya viniesen equipados con este tipo de sistemas, no por su complejidad, sino porque pensaba que una aerolínea, con la competencia que hay, no se iba a gastar la pasta en eso, sobre todo si estas hablando de la clase turista.

Aunque para mí era algo nuevo, no pensaba escribir acerca de esto pero lo he escrito porque lo que supongo que ya no es algo tan normal es que el sistema de entretenimiento se reinicie durante el vuelo, con suerte de que no había ningún pasajero como algunos de los usuarios que atiendo que porque se caiga un servidor se piensan que toda la infraestructura se ha ido al traste sino hubiese cundido el pánico.

Al reiniciarse el sistema, pude ver que estaba basado en el sistema del NYU y el pingüino (GNU Linux); aquí os dejo una foto para que veáis.

Reinicio del sistema de entretenimiento

Hasta la próxima enfermos.

23 de julio de 2010

Compra un servidor y llevate un troyano

Llevo poco más de un mes sin meter una entrada y no ha sido por falta de ganas ni falta de ideas, más bien por falta de tiempo, bueno mejor dicho por dar preferencias al tiempo que uno tiene "libre" a otras cosas por encima de escribir en el blog.
Como aún estoy metido en el gran embrollo que me ha estado ocupando este tiempo, ya se sabe que lo primero es lo que da de comer, voy a comentar una noticia que me parecido bastante trascendente y también la voy a aprovechar para dar unas pequeñas señales de vida.

El tema de la entrada e s referente al malware encontrado en el firmware de ciertos servidores DELL.

Es un tema peliagudo para la firma ya que deja por lo suelos la reputación, que no es poca, que tienen como proveedor de hardware para empresas.

Realmente, yo he adquirido, en numerosas ocasiones, hardware a DELL, siempre me ha gustado lo estrictos que son en los plazos que dan, la atención que te dan tanto en preventa como en postventa y los precios que normalmente ofrecen; pero ahora con esta noticia es para plantearse si son tan metódicos en los procesos de fabricación y en las evaluaciones de calidad, que para mí engloba la seguridad de los productos en sus distintas facetas.

Otra de la cosas que me molesta de todo esto es que te avisen y que no te especifiquen nada, como hacen muchos proveedores de esto y otras tantas cosas, y no creo que sea por que realmente no tienen ni idea; ya sé que algunos no quieren ni oír las explicaciones técnicas pero en mi caso es todo lo contrario, que no me las den me provoca que piense que realmente me lo ocultan para que siga viendo les con la cara bonita de siempre cuando de verdad me produce todo lo contrario.

Para terminar solo quería comentar que tiempo atrás escuché que troyanizar un compilador sería la monda, ya que si llegase a ser utilizado por un gran número de desarrolladores, todo ese software programado legítimamente estaría infectado de serie, por lo que podría producirse una propagación de malware  masiva.
Ahora con esta noticia es para plantearse, también, lo desastroso que podría llegar a ser vender hardware troyanizado, y más de un distribuidor con el peso de DELL.


Hasta la próxima enfermos.

P.D. Yo no he recibido la llamada de DELL, mis comentarios se basan absolutamente en las noticias que he leido sobre este asunto.

17 de junio de 2010

Malware con nombres de ficheros sospechosos

Mientras escribía el anterior post me empecé a plantear porque en el nombre de esos troyanos que habíamos recibido por e-mail se habían utilizado un chorro de "_"  justo después del nombre, terminado en .doc, y la extensión del fichero, que era la de un ejecutable de Windows, .exe; el objetivo, como ya mencioné, está claro, es el de confundir al usuario para que llegue a creer que lo que está recibiendo es un fichero de Word de Microsoft Office, es decir un .doc, haciendo énfasis la utilización del icono asociado al ejecutable de Word. Mi planteamiento no era el objetivo en sí, sino de porque utilizar guiones bajos y no utilizar espacios en blanco ya que seguramente es más fácil confundir a la posible víctima debido a su invisibilidad.

Así que, ya que me lo plantee, he decido probarlo y ver si realmente los espacios en blanco cumplirían mejor su objetivo que los guiones bajos utilizados y teniendo en cuenta la vista que estemos utilizando en explorador  de ficheros. Los resultados han sido los siguientes:
  1. Vista detalles



    Como podemos ver en la imagen anterior, los espacios en blanco es la mejor opción para la eficacia del engaño. De los tres ficheros que aparecen, el de en medio no tiene ningún carácter entre el .doc y la extensión y en en el caso de no tener activada la opción de "Ocultar las extensiones de archivo para tipos de archivos conocidos" sería la más eficaz porque entonces no aparecerían los "..." en el extremo derecho de la columna "Nombre", pero teniendo dicha opción desactivada queda delatada la verdadera extensión del fichero, algo que es lo que pretenden evitar los espacios en blanco o lo guiones bajos.
    No obstante esta vista puede ser la que mejor convenga para detectar que realmente es un ejecutable, ya que en la columna "Tipo" aparece lo que realmente son los ficheros, así que si la posible victima ve eso, fácilmente puede detectar que se trata de un engaño.

  2. Vista lista



    En esta vista, si el ancho de la ventana, bueno concretamente el de la zona de listado de ficheros y carpetas, es mayor que el número de caracteres utilizados para ocultar la extensión, y tenemos desactivada la opción de ocultación de extensiones, comentada en el punto anterior, claramente queda delatada la extensión en cualquiera de las tres opciones. En el caso de tener activada opción de ocultar extensiones, en ninguno de los tres casos se detecta la extensión real, aunque en el caso de  utilizar guiones bajos dará indicios a pensar que algo raro sucede; esto mismo también sucede si aún teniendo desactivada dicha opción, la longitud horizontal de la ventana de lista de archivos y carpetas es inferior a la del nombre real del fichero (nombre con los caracteres para ocultar la extensión), tal y como podemos ver en la imagen de a continuación.



  3. Vista iconos



    Este tipo es muy similar a la del punto 1, el resultado sería el mismo, pero el usuario no tendría la posibilidad de ver de manera rápida que el fichero se trata de un ejecutable, ya que en esta vista no tenemos una columna informativa sobre el tipo de fichero.

Aunque hay otras vistas disponibles, no he citado más porque el resultado del resto  no aportaría nada nuevo ya que el comportamiento de cualquiera de estas es igual  a alguna de las 3 mencionadas.

El objetivo de este post no ha sido ni mucho menos generar nuevas ideas a los atacantes, ya que para mí los atacantes maliciosos son mi enemigo del día a día, además la idea es muy simple y de carácter no técnico; si he decido escribir esto es para poner en alerta al usuario del día a día que no duda cuando recibe estos ficheros aunque se vea de lejos que el e-mail no va dirigido a él y/o a su empresa y/o ha su responsabilidad dentro de ella y que si con el truco de los guiones bajos está colando, con el uso de espacios seguro que todavía colaría más.
Este tipo de avisos los tengo que estar dando yo a los usuarios de la empresa para la cual trabajo para concienciar les que la industria del malware es un peligro real y presente hoy en día , aunque la mayoría de las veces me llevo comentarios del tipo "informáticos estáis obsesionados con la seguridad y  sois unos exagerados y lleváis este más allá de la realidad", aunque yo no voy a desistir por escuchar este tipos de gilipolleces. Considero que explicarles este tipo de medidas de como detectar técnicas sencillas de engaño les puede ayudar a que eviten ciertos contagios, tanto en sus equipos personales como en los de la empresa,  quedando claro que los problemas generados en estos últimos  me atañen a mí.

Por último solo quiero mencionar que en el post anterior ya hice mención que los antivirus/antimalware y más concretamente los filtros antispam que también analizan los ficheros adjuntos podrían llevar un mecanismo de alerta, en el caso de los primeros, y de mover el correo al buzón de SPAM, en el caso de los segundos, solo por el simple hecho de que los nombres de los ficheros tuviesen un patrón asociado a la distribución de malware como lo es el citado en este post; sin duda creo que sería de gran ayuda para evitar contagios con técnicas tan técnicamente simples como estas.

Hasta la próxima enfermos.

10 de junio de 2010

Facturas para no olvidar

Ayer en la empresa volvimos a recibir otro de los famosos troyanos, un .exe, camuflados  en un ZIP, con icono de Microsoft Word y con el clásico nombre en cual aparece la palabra "Factura" por algún lugar y ".doc" justo antes de un chorro de guiones bajos que preceden su verdadera extensión (.exe).

Hace no más de un mes, recibimos un fichero de este tipo, menos mal que el usuario receptor fue precabido y me avisó antes de ejecutar nada, ya que el mail con el que llegaba, cantaba un bastante lo que traía con él. En ese momento estábamos probando nuestro nuevo proveedor de correo por lo que en fase de pruebas y que un filtro antispam y antivirus no parase ese mail con un fichero adjunto, que por su nombre y extensión gritaba "Soy un troyano", era para suspender la fase de pruebas y no contratar sus servicios.
Como no me gusta sacar conclusiones a la ligera, lo analicé con el antivirus corporativo que tenemos y al obtener un falso negativo, se me ocurrió subirlo a Virus Total; el resultado fue desolador tan solo 1 de los 41 motores lo detectaba, así que decidí subirlo a varias veces durante unos cuantos días y postear los resultado obtenidos aquí.
El servicio antispam y antimalware se salvaba de que no lo contratásemos, ya que con ese índice inicial de detección no podemos justificar que el servicio no es el correcto. 


Como de nuevo esta vez el motor antispam y antimalware lo ha vuelto a dejar pasar sin ningún tipo de advertencia, lo he subido, como hice con el anterior, a Virus Total y el resultado ha sido:
  • En mi primer análisis por mi parte, ya que ya había sido analizado una vez dos horas antes aproximadamente, un solo motor lo detectaba; podéis ver el informe aquí.
  • En mi segundo análisis, medido día más tarde aproximadamente, lo detectaban cuatro motores; podéis ver el informe aquí.
Así que de nuevo estamos no veo lícito realzar reclamación alguna ya que el índice de detección cuando nos ha entrado es extemadamente bajo.

No obstante si que veo lógico abrir una reclamación por no detectarlo como SPAM, ya que con un mega potente motor antispam y antimalware que está en la nube, así es como lo venden, no dé ningún tipo de advertencia o catalogue el mail como SPAM, solo por el simple hecho de llevar un .exe comprimido en un ZIP y con nombre que obedece el clásico patrón comentado al inicio de este post.

Para finalizar solo me gustaría añadir que los antivirus podrían añadir un sistema de advertencia al usuario al estilo de "Posible fichero malicioso", cuando detectasen ficheros con nombres con patrones sospechosos, no creo que sea tan difícil añadir un sistema de advertencia de este tipo, ¿no?


Hasta la próxima enfermos.

9 de junio de 2010

Physical Broadcast Traffic Attack

Introducción
En esta entrada voy a explicar una incidencia que tuvimos ayer y que provoco una caída en toda regla de la infraestructura de red de la empresa, cuando digo de la empresa, no es de una sede, sino de más de una, en este caso de 3 de 4 que tenemos.

No voy a explicar, nada innovador, aunque el nombre pueda hacer pensar en eso, pero si algo muy estúpido que dejo durante casi un ahora la infraestructura de red y la telefonía fuera de servicio y media hora más funcionando a medias tintas, provocando, como es de suponer, ciertas perdidas económicas en la empresa y horas de trabajo de más sin remunerara de ciertos empleados para recuperar ese tiempo de improductividad.

Arquitectura de interconexión entre sedes
La empresa tiene la siguiente arquitectura de red de interconexión entre sedes:
  • 4 sedes intercomunicadas entre ellas a través un backbone ofrecido por un ISP.
  • 3 de las sedes están interconectadas en un topología en estrella a través de un canal de fibra óptica. Madrid como nodo central y Barcelona y Bilbao como nodos periféricos.
  • Los canales de fibra se interpretan como una conexión directa, es decir que el ISP solo enlaza el tráfico de un extremo al otro, corriendo de parte de la empresa la manera como gestionar el trafico por dicho canal.
  • Las sedes también se encuentra interconectadas por una infraestructura paralela, proporcionada por un router DSL en cada sede; en este caso la infraestructura de red del ISP es quien enruta a el trafico a la sede correspondiente.
  • La cuarta sede que no está conectada con el canal de fibra óptica, Málaga, solo está enlazada a través del router DSL con el resto de las sedes.
  • Distinto rango de red local en cada una de las 4 sedes.
Os dejo un esquema para su mejor compresión.

Esquema de la arquitectura de la interconexión de red entre sedes

Problemas de fondo
Uno de los problemas que detecte hace un mes y medio aproximadamente, snifando la red para analizar otras tareas que no vienen a cuento en este post, y que nunca había verificado antes porque cuando yo empecé a currar aquí la infraestructura de red de interconexión de sedes por fibra óptica ya existía y lo dí por supuesto después de la información que me habían facilitado mis compañeros que estuvieron en el momento de su instalación, es que el broadcast de cada una de las redes interconectadas llega al resto.

El problema que esto provoca es evidente, una inundación de las redes con paquetes que no sirven para nada, no obstante el día a día no provoca grandes estragos. Solo decir que este problema está en la lista de resolución de problemas, pero la prioridad que tiene es baja, ya que las directrices que nos llegan, sin tener ni voz ni voto, nos indican que estos asuntos no tienen relevancia en el negocio, así que mejor nos dediquemos ha hacer las otras que si las tienen.

El "ataque"
Bueno llegado a este punto voy a explicar en que consistió el "ataque", entre comillas ya que no fue intencionado.

El problema vino de un usuario que había venido con su portátil y se había sentado en uno de los lugares donde tenemos un switch de 5 bocas, de esos que no superan los 40 €, ya que es la manera que usamos para ampliar una única boca disponible de un despacho sin la necesidad de tirar nuevo cableado; no obstante esto solo lo tenemos en puntos muy localizados, ya que la oficina de Barcelona, por lo general, los accesos físicos a red están bien distribuidos y cableados. Cuando el usuario abandono su lugar la oficina, se le ocurrió conectar el extremo del cable conectado a su equipo a una de las bocas libres del switch de 5 bocas, creando un bucle físico y directo.

A partir de aquí ya nos podemos imaginar que sucedió, la red empezó a inundarse con los paquetes de broadcast que llegaban a una de esas bocas, ya que entre ellas se iban realimentando.

Las consecuencias
Las consecuencias del "ataque" fueron las siguientes:
  • Denegación de servicios en todo los aparatos conectados en la red de Barcelona. Cuando digo todos, son todos; los switches colapsados con tanto broadcast, a raíz de esto las comunicaciones entre las máquinas (usuarios y servidores) se les denegaba los distintos servicios no de manera total pero si parcialmente, que igualmente impedía trabajar, además el router DSL también estaba colapsado, incluso lo manifestaba con parpadeos de luces inhabituales y para completar el DOS, la centralita telefónica también denegaba su servicio, no funcionaba ni las llamadas internas ni externas, es decir como si se hubiese apagado, esto se debe a que la centralita tiene un interfaz de red ethernet para poder ser administrada y parece que un su fabricación y diseño no se tiene encuentra como una parte no importante de su servicio, es decir que no es capaz de tirar al suelo el servicio ethernet y dejar intacto el servicio de telefonía frente aun problema de este tipo.
  • Debido a la configuración que hay actualmente de interconexión entre sedes, comentado en el apartado anterior, "Problemas de fondo", todo el broadcast llegó a las otras dos sedes, Madrid y Bilbao, produciendo un efecto similar, solo salvando se las centralitas, porque estas no tienen el servicio de administración vía ethernet.
Bien, todo esto fue una gran putada, nos volvimos locos viendo que pasaba y haciendo hipótesis de lo que podía estar sucediendo, viendo si lo que podía fallar era un swith, cual de ellos, si el problema podía venir por parte de la infraestructura de red del ISP, etc.
Finalmente después de varias pruebas, todo parecía que era un switch de Barcelona, uno de conexión de máquinas de usuarios, o eso o algún equipo que estaba enviando paquetes de broadcast o corruptos; así que mientras pasaba las conexiones de ese switch al switch de backup  iba monitoreando la red para ver si las nuevas bocas que iba pinchando provocaban alteraciones, hasta que finalmente, como la Ley de Murphy indica, fue una de las últimas bocas que pinché y al ir visitar la localización de esa boca fue cuando me comenta uno de los usuarios que habían al lado del "atacante", "Cuando se ha ido ha conectado su cable ahí".

Conclusiones
Parece que hackearnos la red, aunque solo sea por un intervalo de tiempo aproximadamente una hora, es bastante más fácil que conectar un proyecto a un portátil, así que para la próxima vez que pueda suceder algo así, ya tenemos algo bastante fácil que mirar, antes de empezar a desmontar parte del rack de comunicaciones.

Por cierto, tener un rack bien organizado con switch de backup y una buena adecuación y organización del cableado del rack me ayudó a trabajar más ágil y eficazmente.

Hasta la próxima enfermos.

2 de junio de 2010

Conectando un disco de un RAID software de Windows 2000

Ayer en el curro tuvimos una incidencia con una de las máquinas que utilizamos como servidor de sistemas, es decir básicamente para almacenar software que instalamos en los equipos, almacenar alguna que otra documentación interna del departamento de TI y rodar ciertos software de tareas de mantenimiento de sistemas con un nivel de criticidad bajo o más bien nulo.

La incidencia básicamente se resumió en que el sistemas se fue colgando desde hacía unos días cada vez con mayor frecuencia hasta el punto que el tiempo de funcionando se redujo a menos de 8 horas, por lo que la prioridad de la incidencia aumentó, ya que con un intervalo de indisponibilidad inferior a 8 horas y en decrecimiento deja de ser operativa en toda regla.

El sistema operativo de esta máquina era un, prehistórico Windows 2000 Server; es lo que hay en un departamento con presupuesto bastante reducido y más aún en tiempos de crisis y con el estatus económico de España; la máquina tenía dos discos duros del mismo tamaño, los cuales en su día se tomó la decisión de crear un RAID 1 software sobre ellos con la propia herramienta integrada en Windows 2000 Server.

Una vez haber soltado el rollo del motivo de la incidencia y cual era el entorno de producción que nos interesa conocer para entender la situación, paso a explicar la fácil y rápida solución a esta historia que llegó a un punto que parecía que no iba a tener ese final feliz que si tuvo.

Para recuperar esa información durante el tiempo en que tardaremos en poner en marcha el nuevo entorno de producción, decidí pinchar ese disco en una de las máquinas, con Windows XP, que tenemos de backup como plan de contingencia de fallo de alguna de las workstation.

Al iniciar la máquina y ver que el disco a recuperar no se mapeao directamente en Mi PC como una unidad más, fui a la consola de "Administrador de discos" (Accesible a través de la consola de administración del equipo) y en ella me aparecía como que me detectaba el disco con "error" y otro disco inexistente que es el  otro que hace de espejo.

 Acceso a la consolad de administración de Windows XP

En este momento ya me estaba imaginando que recuperar el disco no sería tan sencillo, como pinchar lo y ya está, ya que aunque el formato fuera NTFS, es posible que el RAID software tuviese alguna que otra configuración que no siendo un Windows 2000 Server o un Windows Server de versión superior pudiese gestionar, es decir que desde un cliente Windows XP, no iba a poder recuperar lo de manera sencilla.

En ese momento antes de buscar otra máquina o algún software de recuperación, dando le un par de vueltas al asunto y mirando si desde la consola de administración de discos me daba alguna opción de recuperación,  se me ocurrió asignarle una letra a la unidad y ver que aunque lo marcase con error me dejase y después de eso ya veremos si se puede acceder o no.
El resultado fue satisfactorio, al asignarle una letra a la unidad del disco se  ha mapeado sin problema, totalmente accesible desde "Mi PC", como cualquier otro unidad y además el administrador de discos ha pasado de indicar como sistema de archivos "error" a indicar "NTFS"; así que la historia tuvo un final feliz y para otra vez ya sé que un disco que funciona como uno de los espejos de un RAID software de Windows 2000 se puede conectar a una máquina con un cliente Windows XP y siendo accesible como cualquier otra unidad.

 Administrador de discos de Windows XP

Como podemos ver en la imagen anterior el otro disco del espejo del RAID 1 aparece informado como que falta porque físicamente no esta. Podemos hacer que desaparezca de esa lista si no pensamos añadir el otro espejo, dando botón derecho sobre ese disco informado e indicando "Extraer", en el caso de querer activar el espejo sería, una vez conectado físicamente al equipo, la opción "Reactivar", pero esto último no lo he probado y no sé con toda certeza si funcionaría.

Hasta la próxima enfermos.

22 de mayo de 2010

Seguimiento de detección de un fichero sospechoso

Esta semana, en el curro, entró por mail el típico spam con un fichero adjunto sospechoso, muy fácil de detectar, por cualquier técnico, que se trata de un fichero ilícito, pero donde muchos usuarios, sobre todo los que se dedican llevar la facturación, pueden llegar a picar.

El mail, muy clásico, tenía el siguiente contenido:
Asunto: Fwd: New_Factura!!!
Cuerpo:
Buenos dias, xxxxxx@dominiodelaempresa.es.
La factura que debe ser abonada antes de la semana siguiente.
Los detalles estan dentro del archivo.
--
Con los mejores votos,
Departamento              mailto:canduxo@otrodominio.com
Fichero adjunto: 56_Factura.zip

Hasta aquí todo muy claro de detectar, sin ni si quiera tener que abrir el archivo:
  • No saben como nos llamamos, resulta que nuestro nombre es la dirección de mail, sin dignarse a quitar el dominio.
  • Resulta que nos lo envía un tal yyyyy@dominodelspam.com pero que si queremos contactar con alguien que tiene un mail en otro dominio, con un nombre más legítimo canduxo@otrodominio.com y encima nos ponen mailto tal cual, no es el mailto de un enlace.
  • Y, claro esta que lo más normal del mundo en España es despedirse diciendo: "Con los mejores votos".

En esta ocasión el usuario, fue precabido y me acabó llamando para que le asegurará si realmente era un spam; aunque estaba claro, por esas cosas que tiene la curiosidad, decidí jugar un poco, a un juego fácil, que no voy sobrado de tiempo, con el fichero adjunto. 
  1. Analicé el fichero con nuestro antivirus corporativo; el resultado fue un falso negativo, es decir no detecto nada.
  2. Lo abrí con un descompresor desde una maquina virtual, por si acaso. El zip estaba bien formado; en su interior había un fichero .exe con un icono de MS Word y con el mismo nombre que el zip pero en vez de .zip, era .doc y a continuación unos cuantos guiones bajos para que no se viese que el fichero terminaba con la extensión .exe.

      
    Contenido del fichero zip
  3. Bueno visto lo visto en el paso 1 y 2, me decidí a subir a Virus Total (podéis encontrar explicación del servicio ofrecido por Virus Total al principio del siguiente post) y aquí empezó lo que me hizo gracia, porque al subirlo, de los 41 motores de análisis que utiliza Virus Total, solo lo detectaba uno; en vista de esto y que al día siguiente nuestro antivirus corporativo me lo detecto como un troyano me enredé durante los siguientes días a subirlo varias veces de nuevo a Virus Total y hacer un seguimiento de detección.
    El resultado de este seguimiento lo podéis ver en la siguiente tabla y gráfico:

Tabla de valores de la evolución de la detección

Gráfica de evolución de la detección

Pasados más de 4 días, de los 41 motores, solo lo detectan 17; realmente ya no sé si se trata de un troyano o no, porque a raíz de la gran noticia que saltó durante el mes de febrero de este año uno ya no sabe que pensar, la noticia que me refiero es la que se puede ver en el mismo link que he dejado más arriba donde he mencionado que se hace una breve explicación del servició ofrecido por Virus Total.

A continuación os dejo los enlaces a los diez análisis, por orden cronológico, que he realizado de la misma muestra.
  1. http://www.virustotal.com/es/analisis/0818...174895
  2. http://www.virustotal.com/es/analisis/0818...269705
  3. http://www.virustotal.com/es/analisis/0818...285975
  4. http://www.virustotal.com/es/analisis/0818...293558
  5. http://www.virustotal.com/es/analisis/0818...337572
  6. http://www.virustotal.com/es/analisis/0818...355766
  7. http://www.virustotal.com/es/analisis/0818...382462
  8. http://www.virustotal.com/es/analisis/0818...426420
  9. http://www.virustotal.com/es/analisis/0818...473799
  10. http://www.virustotal.com/es/analisis/0818...541009

Hasta la próxima enfermos.

17 de mayo de 2010

Dejando la improvisación para cuando sea necesario (2/2)

################# Conjunto de entradas ###################
# Dejando la improvisación para cuando sea necesario (1/2)
# Dejando la improvisación para cuando sea necesario (2/2)
########################################################

Entrando en acción
Bueno después de planificar y organizar la acción que se quiere llevar a cabo, esta claro que hay que ejecutarla, sino lo anterior no sirve de nada, ya que hasta este punto no hay ninguno objetivo completado.

La previa
Así que empecé creando las plantillas comentadas en el post anterior y luego, entre yo y el becario, pasamos a rellenarlas. Mientras tanto le iba en mi cabeza iba diseñando la arquitectura lógica de la red y a ratos la iba plasmando en el diagrama.
Cuando ya tuve una primera versión del diagrama del diseño de la arquitectura lógica de la red busqué un rato para comentarlo con el becario, con el objetivo que se sintiera más implicado y motivado (dos aspectos que para mí son muy importantes si quieres que los currantes trabajen bien y eficazmente), supiera que es lo que vamos ha hacer y también que valorase esa opción y las otras que yo le había dado vueltas y las cuales le comenté, ya que dos cerebros piensas más que uno de solo
Después de esto él comentó sus puntos de vista y discutió mis argumentos y finalmente acabamos haciendo pequeñas modificaciones sobre mi propuesta inicial por tal de que la red fuese lo más óptima posible (contando solo con los recursos que teníamos) aunque eso implicase un punto crítico, básicamente porque la topología era en estrella; pero era la mejor opción para descartar que la red fuese un cuello de botella cuando te llamen los usuarios para decirte "que todo les va muy lento", una música que escuchamos muchas veces, y  como yo no he sido quien ha montado todo el tinglado y la documentación es inexistente ,si  no optimizo la red cuando he puedo hacerlo, no hay manera de cargarse incógnitas de esta ecuación tan odiada, y  para solucionar el punto crítico, el switch central, se puede solucionar teniendo un switch de backup que nunca viene mal tenerlo.

También elaboré la el diagrama de diseño de la distribución de la energía eléctrica, partiendo de la premisa que no había presupuesto para comprar nuevos UPSs, así que me toco distribuir los distintos dispositivos entre los UPSs existentes garantizando que todo pudiese aguantar el máximo de tiempo posible encendido frente a una caída de tensión y así tener claro a que toma íbamos a conectar cada uno de los dispositivos.

Para terminar con todo esto anoté el orden, de arriba a bajo, con el que iba poner cada uno de los elementos de dentro del rack (centralita, switches, routers, patch panels, etc.) y así completaba como iba se iba materializar todo y no tener que estar improvisando en medio de cables y con la presión  que algo no terminase de funcionar al siguiente día laboral.

El juicio final
Llego el gran día y yo y el becario, estábamos ahí delante del rack y dispuestos a desmontarlo, así que  empezamos a desconectar todo el rack de comunicaciones para posteriormente reorgarnizar los patch panels y todos los dispositivos de red (switches, routers, etc.) y conectar todo como se había planificado.
Sobre ese día no hay mucho más que contar, porque lo único que tuvimos que hacer es seguir las instrucciones que había elaborado y tanto yo como el becario fuimos completando nuestras tareas sin ninguna complicación.

Conclusiones
Es esencial dedicar 5 minutos a valorar si merece la pena o no dedicar un tiempo a planificar las tareas con cierta envergadura que tienes que acometer.
Pensando con antelación y planificando las tareas, por muy chorra que pueda parecer, como en un principio podía parecer la organización de un rack de comunicaciones, te garantizas en un % muy elevado que su ejecución se lleve a cabo sin complicaciones y te da una elevada garantía de cumplir satisfactoriamente con todos los objetivos y a la vez cumplirlos con una calidad más que aceptable.

Para terminar os dejo el antes y el después del rack, ya que aprovechamos y cambiamos el cableado que había hasta el momento por uno de mayor calidad y de adecuada longitud, algo que también fue posible, en parte, a la nueva distribución de los elementos, dejando un rack donde meter la zarpa ya no supone un engorro.

El antes

Y el después


Hasta la próxima enfermos.

13 de mayo de 2010

Taller técnico formativo sobre el DNIe

Hoy he asistido al "Taller técnico formativo sobre el DNIe" que organiza INTECO en Barcelona.
Como valoración general no ha estado mal, ya que ha tenido parte teórica y parte semi-práctica, semi porque las prácticas se basaban en hacer una o varias llamadas en lugar concreto del código, es decir que tampoco es que vayas a practicar mucho, pero con el tiempo que había es más que aceptable, ya que o hacían esto o omites la parte práctica y al menos con esta pequeña intervención de los asistentes todo se hace más ameno.

La verdad es que desde mi punto de vista lo del DNIe puede dar bastante juego, pero estar por ver sus limitaciones, ya que no creo que ahora se trate de que ahora todo el mundo quiera meterte el DNIe por el culo, es decir que se convierta en un boom y todo acabe siendo un desastre, como suele pasar con todo los booms.

Dejando de banda lo que se ha hecho en el taller, básicamente porque se ha seguido el programa, tal cual está publicado paso a comentar cosas que me han parecido graciosas.

La infraestructura
Todos los asistentes teníamos un portátil con acceso a la Internet a través de la wifi del hotel; wifi, que por cierto no era cifrada así que todo lo que ha volado por allí no es que lo estuviese haciendo de manera muy segura.
El acceso al portátil era con el administrador y en un Windows XP, así que la seguridad del equipo a tomar por culo; no obstante al menos tenían un antivirus instalado, al menos lo que predican sobre que todos tenemos que tener un antivirus instalado, ellos mismos se lo han aplicado.
Estos equipos tenían cierto software instalado, uno de ellos era Adobe Acrobat Professional 7.0.0, es decir una versión con cierta antigüedad, pero bueno eso puede ser que no hay presupuesto para actualizar licencias, pero lo que no pasa es que no tenía instalada ninguna actualización y todos sabemos que el año pasado Adobe se llevo la mayor parte del pastel en explotación de vulnerabilidades.

El entorno de desarrollo, desde mi punto de vista era adecuado, se basaba en VMware, es decir una máquina virtual con WindowsXP y con un Visual Studio instalado.

Lo único que yo me pregunto es ¿porque no habían capado las máquinas y que los asistentes utilizasen una máquina virtual para desarrollar toda la jornada? esto les permitiría tener las máquinas un poco más asegurada frente a los juegos que un asistente puede ejecutar en el equipo y una mayor flexibilidad a la hora de restaurar una máquina entre jornada y jornada.

Los ponentes
Los ponentes aceptable, alguno más a menos que otro, pero ya sabemos que esto siempre pasa, ya que cada uno tiene su manera de presentar además de venir condicionado del contenido que presenta.

Quiero resaltar algunas frases que me he descojonado al oírlas por parte de Juan Crespo del CNP, el segundo ponente:

  • Un documento electrónico no es más que un chorizo de bits.

  • La creatividad de los españoles es ¡¡¡ muy grande !!!.

  • La administración es como un elefante desde el punto de vista de innovación tecnológica (Esto lo ha dicho con una expresión no verbal bastante cachonda).
Además este ponente ha mencionado que hasta ahora no han podido evolucionar más el DNIe porque les falta la parte de como un externo puede validar toda la cadena de CAs que validan el certificado digital del DNIe, ya que este necesita obtener la clave pública raíz que ha emitido ese certificado y la empresa que está desarrollando esta parte todavía no ha conseguido hacerlo; ha reconocido parte de la culpa de este incidente, aunque sí que ha mencionado que no acaba de entender cómo es que el proveedor no ha logrado todavía eso y eso que contrataron el que el fabricante recomendó, "¿será porque no le pagamos demasiado?" (Que conste que la pregunta la ha lanzado el mismo).

Agradecimientos
Quiero agradecer a INTECO la organización de estos talleres, ya que son interesantes porque te ofrecen una pincelada a la tecnología del DNIe.
Además se están realizando de manera gratuita y todo y eso el trato y los medios destinados al taller han sido excelentes.
Solo quiero añadir que lo que haya podido comentar en este post no tiene ningún otro objetivo de ser una crítica constructiva y contar ciertos aspectos anecdóticos y/o graciosos.

Hasta la próxima enfermos.

12 de mayo de 2010

Dejando la improvisación para cuando sea necesario (1/2)

################# Conjunto de entradas ###################
# Dejando la improvisación para cuando sea necesario (1/2)
# Dejando la improvisación para cuando sea necesario (2/2)
########################################################

En este post voy a explicar una de las experiencias que he vivido y la cual yo he tenido la posibilidad de "liderar"; si entre " porque no se trata de ninguna gran proeza ni tampoco de ninguna obra maestra pero creo que en ella se refleja claramente que si las cosas se planifican con antelación tienen muchas más probabilidad de que se completen con éxito; y ya sabemos que la planificación no es un plato fuerte de lo "Made in Spain", algo que quiero dejar claro que es un punto de vista personal y al cual he llegado después de estar viviendo lo continuamente tanto en mi vida profesional como personal.

La tarea
  • Descripción: Organizar el rack de comunicaciones de la oficina de Barcelona de la empresa para la cual trabajo.
  • Objetivos:
    1. Mantener la conexión en las rosetas que hasta el momento estaban conectadas.
    2. Mantener las mismas extensiones telefónicas de los usuarios.
    3. Flexibilizar la escalabilidad física, con los medios actualmente disponibles.
    4. Optimizar la red con los medios que  actualmente disponibles.
  • Requerimientos implícitos:
    1. No influir en el trabajo del día a día de la empresa.
    2. No se pueden realizar obras (poner canaletas, poner nuevas rosetas).
El plan
Para llevar a cabo la tarea y cumplir con los requerimientos implícitos realicé lo siguiente:

Analizando el entorno
Basándome en los requerimientos me centré en determinar que es lo que tenía que pensar y organizar para llevar a cabo la labor.
  1. Realizar el trabajo fuera de horas laborales, por lo que se aprovechó un día por la tarde fuera de horario laboral.
  2. Registrar las rosetas conectadas a la centralita por tal de mantener la mismas extensiones en el caso que haga falta desconectar los cables de los patch panels.
  3. Para cumplir con los objetivos 3 y 4 y respetar el requerimiento 2 se tiene que pensar en cambiar la organización física de los switches y como los conectábamos entre ellos.
Detallando las subtareas
  1. Registrar las rosetas con conexión y en el caso de las telefónicas anotar en que boca de la centralita van conectadas.
  2. Determinar  la distribución física de los switches y los patch panels.
  3. Determinar la conexión entre los switches.
  4. Distribuir las conexiones de corriente de todos los dispositivos del rack (no se invierte en nuevos UPSs hay que utilizar los que hay).
  5. Planificar la desconexión de ciertos servidores con la oficina central (Madrid).
  6. Determinar día de realización de la tarea.
Planificando las subtareas
A excepción de la subtarea 6 que es ejecutar la tarea en el mundo físico, consideré que el resto de tareas se tenían que hacer durante los días anteriores, claro está que pare ello mi empresa  no me iba a permitir dejar de atender lo del día a día (incidencias, soporte usuarios, más soporte usuarios, más soporte usuarios, ...).

En esta ocasión tenía una ayuda; estoy hablando de un becario que se acaba de incorporar y el cual me podía ser útil, si lograba transmitirle y explicarle lo que teníamos que hacer, como nos íbamos a organizar y concretamente que iba a hacer él, teniendo en cuenta que no tenía tiempo suficiente, debido a que marqué como día de ejecución el cuarto día después de su incorporación, para ponerle al día al completo sobre la infraestructura tecnológica de la oficina, por lo tanto las tareas en las que podía ayudarme tenían que ser sencillas,

Así que los 3 días antes, de la ejecución y dedicando más horas de las que me pagan ya que el día a día da poco margen para cosas que no son del día a día, me dedique a:
  • Crear una plantilla para registrar las conexiones de la centralita, con el objetivo adicional de que se incorporasen a la documentación interna del departamento de TI, en beneficio de la empresa.
  • Crear una plantilla para registrar las conexiones de cada una de las bocas de los switches. No es necesario saber concretamente en que boca va conectada cada roseta, ya que hasta hora habían sido conectadas todas a la brava y en el caso de las rosetas donde se conectan las máquinas de los usuarios no es importante.
    Lo realmente importante de esta platilla era registrar las bocas que se utilizan para conectar los switches entre ellos y las que se utilizan para conectar dispositivos relevantes de la arquitectura de red, como son los servidores, routers, impresoras, etc.
  • Elaborar un diagrama lógico de la interconexión de los dispositivos relevantes, vamos lo que para mí es diagrama  de la arquitectura lógica de la red,  con el objetivo de plasmar en un diagrama el punto anterior sin entrar en el detalle del número de boca, más bien saber a que switch está conectado cada uno de los dispositivos relevantes y como se conectan los switches entre ellos y de que manera es decir si utilizan un trunk o no.
  • Elaborar diagrama de conexión de los dispositivos de dentro del rack (switces, centralita, routers y firewalls) a la toma de corriente, pensando en los UPSs que teníamos y como distribuir estas conexiones entre ellos para soportar las pequeñas bajadas o caídas de tensión y con el objetivo de que también pasé a ser una documentación interna de TI y ser útil para el futuro.
  • Para el desarrollo de la subtarea 5, anotar y explicar al becario que switch se iba a mantener conectado hasta el último momento y que es lo que iba a tener conectado.

En el próximo post de esta serie explicaré como lo llevamos a cabo y que conclusiones he sacado de esta experiencia.


Hasta la próxima enfermos.