Source: http://enfermodelosbits.blogspot.com/2010/
Timestamp: 2018-07-21 21:15:52+00:00

Document:
Un enfermo de los bits: 2010
Alerta de obligación de contraseña para adjuntar un ID en el Domino
Por esta razón, o la menos esa es mi deducción, ningún servidor registrado en el Domino de la empresa, tiene adjunto su ID.
Publicado por Anónimo en 23:56 2 comentarios: Enlaces a esta entrada
Etiquetas: aplicaciones, e-mail, seguridad
Después de que uno de mis clientes decidiese implantar el uso del Open Source en su empresa, en parte culpa mía, me ha tocado aparear un Thunderbird y un iPhone.
Con lo sencillo que es que MS Outlook y iPhone se juren amor eterno; solo tienes que instalar iTunes, luego conectar el iPhone al ordenador y posteriormente desde iTunes acceder a las preferencias de iPhone, que aparece como dispositivos conectado, para acabar indicando en una de las pestañas de las preferencias que quieres que sincronicen el calendario, los contactos y el correo. En cambio todo esto se convierte en algo bastante más complicado cuando decides que tu iPhone se sincronice con Thunderbird, ya que entre ambos, todavía no hay manera, o al menos de una manera estable y sin tener que hacer juegos de malabares, de que lo hagan a través de la conexión USB, y lo único que te queda es hacerlo on the air usando un "midleware" compatible con los dos.
Uno de los empleados de Mozilla declarando que la sincronización con iPhone y Thunderbird no está planeada
Sincronizando on the air
Maneras de sincronizar el calendario, los contactos y los correos on the air hay varias y entre ellas algunas que se pueden hacer con distintas herramientas.
Después de buscar durante un rato encontré las siguientes:
Funambol - Definido como el Open Source para sincronizar billones de teléfonos.
Sobre iPhone parece que solo sincroniza contactos y aunque explicitamente indica que lo que necesitas es que tengas una cuenta free, luego no parece que sea tan free.
Página de login de myFunambol Portal
NuevaSync - Es de pago y requiere tener un servidor con ciertos servicios activos o usar una cuenta de yahoo, gmail, etc.
Además, en el caso de aprovecharte de los servicios de gmail, no sé que aporta ya que se configura, como veremos posteriormente, de la misma manera que si configuras a iPhone directamente sobre gmail
Gmail - Gmail conectándose a él directamente. El problema de esto, es obvio, que tienes que usar el servicio de Google y eso no gusta siempre.
En mi caso, yo tenía que conseguir sincronizar el calendario y los contactos entre iPhone y Thunderbird. El correo no era necesario ya que mi cliente accede a sus 3 cuentas de correo bajo sus 3 dominios administrados en unos servidores de un proveedor de servicios externo y a los cuales yo no tengo ni acceso, ni tampoco información ni potestad para indicar si activar o desplegar nuevos servicios sobre ellos; además accede al correo bajo demanda manual, aunque tienen un tarifa plana de datos 3G , es decir que no el iPhone no descarga correo hasta que el lo solicita.
Es decir que lo que necesitaba es hacer lo mismo que hacía conectando el iPhone con USB al equipo para sincronizarlo con MS Outlook.
Para conseguirlo lo que he hecho es crear una cuenta de google mail, con el objetivo de tener un calendario y una agenda de contactos en la nube y de esta manera sincronizar todo esto con el iPhone. El caso del correo era indiferente, ya que seguía manteniendo sus cuentas de correo y accediendo a este a través de POP3, y en el caso que descargase correo a la vez desde el equipo y el iPhone y se quisiera mantener una sincronización de las cuentas, entonces se tendrían que configurar con IMAP, también soportados por los servidores del proveedor externo.
Aunque para sincronizar calendarios desde iPhone se podría hacer mediante CalDAV y no haría falta configurar la conexión a gmail en modo Exchange, nos faltaría poder sincronizar los contactos, así que es más apropiado hacer en modo Exchange y dejar la opción de correo desactivada.
Elementos a sincronizar en modo Exchange
Lo que ahora solo faltaba era configurar Thunderbird. Lo de las cuentas de correo, no lo voy a explicar, ya que es tan sencillo como configurar cuentas de correo POP3, además de alejarse del objetivo del post.
Primero, para que Thunderbird tenga calendario hay que utilizar un add-on llamado Lightning, que lo que hace es incorporar Sunbird (aplicación de calendario Open Source de Mozilla) sobre Thunderbird, todo en uno. Lo que tenía que hacer con Thunderbird era, básicamente, acceder a la a esa cuenta de gmail y sincronizar el calendario y los contactos. Sunbird, permite consultar calendarios a través de CalDAV, así que, aunque hay add-ons para acceder a los calendarios de gmail desde el propio Thunderbird, yo no he usé ninguno y configure el calendario de gmail directamente con CalDAV desde propio Sunbird.
Para los contactos no hay mas remedio que sincronizarlos a través de un add-on. Yo probé primeramente el Zindus pero no luego me di cuenta que no sincronizaba las direcciones postales, y vi que si lo hacía pero para ello los distintos campos de la dirección postal tenían que ir taggeados con etiquetas xml porque gmail guarda esa información en un mismo campo y Thunderbird en distintos; así que si no tenía las etiquetas, la información no se sincronizaba desde gmail a Thunderbird y si sincronizabas esa información desde Thunderbird a gmail, entonces te aparecen las etiquetas, que si hubiese sido para mi, tampoco me importa tanto, pero para una persona con casi ningún conocimiento técnico, es un poco dramático.
Debido a esto busque otro add-on, y encontré Google Contacts, el cual si que permite sincronizar las direcciones postales, aunque te mete toda la información (calle, número, código postal) en el campo dirección de la pestaña trabajo y si en Thunderbird lo metes todo allí, entonces también se sincroniza de este a gmail; no he probé que pasaba si en gmail o thunderbird metes varias direcciones, ya que todos los contactos que tenía mi cliente, o no tenía información postal o solo tenía una.
Días más tarde escribiendo este post he encontrado otro add-on, gContactSync; este, aunque no lo he probado, parece que tiene una pestaña más en la ficha del contacto de Thunderbird para meter la información postal que se sincroniza con gmail; así que es posible que hubiese sido mejor solución, así sabes donde hay que poner esa información si realmente quieres que se sincronice con gmail y posteriormente con tu iPhone.
Y de esta manera conseguí que mi cliente pudiese cambiarse de MS Outlook a Thunderbird y continuando manteniendo sus contactos y calendario sincronizado con su iPhone.
A mi cliente, esto ya le ha parecido una buena manera, pero no tiene porque ser buena para otros, ya que es posible que el usuario de iPhone no quiera pagar por tarifa plana de datos o que no quiera meter su información en google, así que en ese caso se tendría que buscar otro de las soluciones que hay o indagar un poco más y con un poco de ingeniería inversa implementar una solución estable de sincronizar estos dos vía cable USB, ya que Mozilla, por ahora, no parece que tenga prioridad alguna (y totalmente lícito, ya que el software es gratis) en implementar este tipo de funcionalidad.
Publicado por Anónimo en 19:14 1 comentario: Enlaces a esta entrada
Etiquetas: cloud computing, dispositivos móviles, open source
Publicado por Anónimo en 11:24 2 comentarios: Enlaces a esta entrada
Etiquetas: aplicaciones, e-mail, incidencias, RAID
Sobre el uso del software Open Source frente al de Closed Source se ha hablado y se continua hablando mucho y mi objetivo aquí no es escribir un post a favor de uno o de otro sino más bien escribir una recomendación sobre pros y contras de la utilización de uno y otro en un entorno empresarial, concretamente en la PYME y más enfocado en la P que en la M, y aunque he mencionado el termino Source, más bien sería el uso de software con licencias que tienen un coste económico en entorno profesional frente a los que no.
Esta entrada tiene que ver con una de mis intervenciones profesionales independientes, en la que hace poco más de un par de meses, tuve que asesorar a uno de mis clientes sobre la inversión económica en software.
El detonante de esta toma decisión, en la que a mí se me pidió el papel de consultor tecnológico, ha sido la rotura con su socio, que ha conllevado que él se quede con una parte del negocio, estando el solo al pié del cañón, como tiempos atrás había sucedido. Con esta rotura, la toma de decisiones dependen única y exclusivamente de él, aunque su nuevo director ejecutivo ejerce una gran influencia.
Las separaciones siempre son duras y no me refiero a nivel de relación sino económico, sobre todo cuando te llevas una parte del negocio, ya que te toca hacer los liquidaciones pertinentes de las acciones y luego asumir los gastos de constitución de una nueva empresa, que muchas veces, y en este caso fue así, conlleva un cambio de oficina, adquisición de nuevos activos, etc., es decir, lo que en tiempo de crisis, a uno le viene muy bien.
Con tanto gasto, y estando en este España, uno ya se puede imaginar que cuando se le dice una cifra aproximada sobre la inversión necesaria en software de uso más extendido, a este se le entra fuertes dolores de barriga. La gran mayoría te dice, “no puede ser, tiene que haber otras soluciones”, y si eres profesional y velas por la seguridad del cliente, sobre todo en un entorno empresarial, no serás su vecino Carlos.
Así que le puedes decir que otras soluciones, legalmente hablando, las hay y aunque tienen la ventaja que las licencias de uso de ese software no tienen ningún coste económico directo, también tiene desventajas, y hay que tenerlas en cuenta antes de decidir si utilizas software con licencias con coste o sin coste, ya que las sin coste no te van a costar un dinero directo pero si otros compromisos, esfuerzos y es posible que también algo de inversión económica.
Así que aquí os dejo la parte de mi informe de consultoría tecnológica que habla de la infraestructura software a utilizar, para que pudiese tomar una decisión en base a este aspecto.
Dejo constancia que intenté ser lo más objetivo posible y la valoración la enfoque desde su situación, no obstante seguro que se puede mejorar y ampliar ciertos aspectos que en ese caso yo no indiqué.
“Se recomienda el uso de software con licencia libre de utilización frente al de licencia con coste de utilización, si las actividades y necesidades del negocio no lo requieren, ya que la diferencia de inversión económica es considerable.
La utilización del software con licencia con coste de utilización es necesaria cuando los elementos externos que interactúan con la actividad de la empresa requieren del uso de estos, ya sea por los formatos de documentos que genera una aplicación concreta y los cuales son intercambiados o porque se necesita un función muy específica que no se encuentra en cualquier otra aplicación con licencia de libre utilización.
Otro caso en el que el uso de software con licencia con coste de utilización es necesario es cuando los costes de parametrización y/o implantación de un software con licencia de libre utilización son elevados tanto en tiempo como económicos en el caso de necesitar soporte externo a los recursos de la organización; este caso es muy poco frecuente y se da en aplicaciones muy concretas y normalmente cuando se da ese caso en aplicaciones con licencia de libre utilización, difícilmente se encuentra una aplicación con licencia con coste de utilización que elimine esos costes, produciendo normalmente un coste económico más elevado ya que es necesario adquirir la licencia y contratar el soporte externo.
Otro impedimento al uso de aplicaciones con licencia de libre utilización es la reacción de los usuarios de estas, los empleados. Normalmente los usuarios son reacios al cambio y más cuando se les exige que el aprendizaje lo hagan manera autodidacta y se les exige el mismo rendimiento desde el primer momento, sin darle un periodo de tiempo de adaptación para alcanzar el rendimiento que tenían anteriormente con las aplicaciones que utilizaban anteriormente. Este caso no solo se da en la implantación de aplicaciones con licencia de libre utilización, también se da cuando se implantan nuevas aplicaciones con licencias con coste por utilización o incluso cuando se actualiza una aplicación que ya utilizan a una nueva versión. Normalmente lo que causa una reacción de oposición al cambio de aplicaciones es la interfaz de interacción con la aplicación, ya que durante el periodo de adaptación se sienten torpes y tardan mucho más tiempo en realizar sus labores, debido a que les cuesta encontrar en la interfaz la manera de ejecutar las acciones deseas; superado el periodo de adaptación las reacciones de oposición desaparecen.”
Publicado por Anónimo en 10:52 No hay comentarios: Enlaces a esta entrada
Etiquetas: closed source, consultoría, licencias, open source
El jueves pasado recibí un e-mail de un colega muy especial, JavierLloret; un colega muy especial porque, aún habiendo lo conocido a los 18 años, pasamos muchas horas trabajando juntos a lo largo de 4 años que estuvimos juntos en la universidad.
Aún recuerdo esos tiempo, que nos pasábamos horas y horas currando en las prácticas de las asignaturas, unas totalmente por obligación de aprobar las asignaturas y otras prácticamente más por motivación que por el simple hecho de sacar las asignaturas.
En una de las prácticas que más curramos, fueron en un par de asignaturas optativas que coincidimos en el segundo trimestre de cuarto curso. Habíamos pasado trimestres con mucho overbooking de asignaturas, porque así lo marcaba el apretado temario de 4 años, de la Universidad Pompeu Fabra, para realizar una Ingeniería Informática; pero en el trimestre de estas dos asignaturas no era un trimestre muy apretado, ya que si no recuerdo mal, solo había una asignatura obligatoria y el resto era para realizar créditos de asignaturas optativas y libre elección y dedicarle tiempo al desarrollo del proyecto de fin de carrera. Es decir que fue un trimestre que curramos un motón, pero no por el hecho de sacar las asignaturas, sino prácticamente por pura motivación e interés.
El trimestre empezó como cualquier otro; parecía que se iba a presentar relajado, pero cuando empezamos a asistir a las primeras clases de prácticas y poco después se expuso lo que finalmente se tenía que hacer como proyecto de asignatura, el estado de relajamiento paso a ser todo lo contrario, un estado de euforia constante.
Empezamos pensando que hacer como proyecto de cada una de las asignaturas y acabamos entrando en un estado de delirio marcando metas por encima de nuestras posibilidades, tanto en recursos humanos como temporales. Fuimos demasiado optimistas pero finalmente aunque uno de los proyectos no se terminó, completamente, el otro en cambio se terminó en cuanto a funcionalidades, es el que recibió el nombre de “The Maze”.
Recuerdo que prácticamente la última semana nos encerramos en su habitación (15 m2 incluyendo el baño y cocina integrada), saliendo para lo estrictamente necesario, en mi caso incluía aparecer por el curro, llegando a estar las 48 últimas horas antes de la entrega sin salir apenas de allí, durmiendo 4 horas, antes de enlazar con las últimas, aproximadamente 27 horas delante del ordenador, programando, testeando, pegándonos de ostias con los problemas de compilación, de linkaje, … ya sabéis de que estoy hablando.
Bueno finalmente, después de todo esto nació la primera release de “The Maze”; un juego interactivo para dos jugadores; uno con el rol de construir un laberinto con unos recortes de cartulina sobre una mesa, en esa primera versión “muy alpha”, construida con una caja de cartón y un pedazo de plástico traslucido, de esos que se utilizan como portadas en las encuadernaciones de las papelerías y el otro jugador básicamente utilizaba un ordenador, como en cualquier juego que ves el personaje en primera persona, que tenía que salir del laberinto en un tiempo determinado, con el agravante que el laberinto podía ser alterado por el otro jugador.
No me voy a extender mucho sobre todos los matices técnicos, porque la nueva versión, seguramente, ha cambiado mucho de la primera, que es en la que yo participé como co-developer. El concepto era el mencionado, dos jugadores, cada uno con su rol; la mesa se conectaba a un ordenador que captaba el laberinto construido sobre la mesa y lo enviaba por red a otro equipo que era donde el otro jugador tenía que conseguir salir de él.
Para la captación de las paredes (cartulinas) puestas sobre la mesa de cartón se utilizaba una Webcam, de estar por casa, junto con un pequeño framework que nos cedieron para realizar las prácticas que permitía captar ciertas figurillas y reconocerlas, que se estaba desarrollando en uno departamento de la facultad y ha llegado a ser lo que se conoce como Reactable Live; pero nosotros nosotros desechamos todas esas funcionalidades, ya que no lo necesitábamos para nada reconocer figuras y, básicamente, solo utilizamos el framework para captar la presencia de más o menos luz, y así identificar las paredes.
Ahora todo esto ha evolucionado a una release mucho mejor, gracias a Javi, que desde que terminó con esa asignatura siempre ha dicho que tenía pendiente mejorarlo para obtener una versión mucho más decente, en cuanto a material físico empleado, como a tecnología de desarrollo utilizaba y el resultado has sido el que podéis ver en el siguiente vídeo:
The Maze EV from Javier Lloret
Ya terminando, solo quiero reflejar, el mal sabor que nos dejó de boca, que después de tanto curro, el profesor de la asignatura ni si quiera se digno a pasarse por el aula, el día de la presentación, mandó al becario que hacía las sesiones de prácticas, el cual iba un poco perdido, ya que era extranjero y acababa de aterrizar por la facultad, ese mismo trimestre. Todo fue “muy motivador” por su parte, enzarzar a la gente a realizar cosas de interactivos para luego acabar valorando mucho más una mierda de presentación sobre un tema del ámbito de la interacción que se tenía que presentar en las sesiones de teoría, las cuales el no podía aludir, y que con todo el curro que tuvimos no le dedicamos prácticamente tiempo; vamos el pan del día a día, explicar cosas que ya existen en un formato PPT (bueno ahora PPTX) bien bonito, muchas de las cuales el que expone sabe de que coño está hablando, pero eso es indiferente, hay demasiado humanos que solo ven hasta donde los ojos alcanzan, sin traspasar a la actividad neuronal.
Publicado por Anónimo en 11:40 No hay comentarios: Enlaces a esta entrada
Etiquetas: games, interacción, interactive art
No cON Name 2010 (2/2)
No cON Name 2010 (1/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”.
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.
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”.
Publicado por Anónimo en 21:17 2 comentarios: Enlaces a esta entrada
Etiquetas: congresos, ponencias, seguridad
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.
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.
Publicado por Anónimo en 0:33 2 comentarios: Enlaces a esta entrada
Gestionando incidencias de manera organizada (3/3)
Gestionando incidencias de manera organizada (1/3)
Gestionando incidencias de manera organizada (2/3)
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.
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.
Publicado por Anónimo en 17:35 No hay comentarios: Enlaces a esta entrada
Etiquetas: incidencias, organizacion, RAID
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.
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.
Publicado por Anónimo en 21:40 No hay comentarios: Enlaces a esta entrada
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
Publicado por Anónimo en 23:35 No hay comentarios: Enlaces a esta entrada
Etiquetas: crítica, informáticos
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.
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.
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é.
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.
Publicado por Anónimo en 20:48 No hay comentarios: Enlaces a esta entrada
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
Publicado por Anónimo en 4:39 No hay comentarios: Enlaces a esta entrada
Etiquetas: entretenimiento, experiencias, Linux
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.
P.D. Yo no he recibido la llamada de DELL, mis comentarios se basan absolutamente en las noticias que he leido sobre este asunto.
Publicado por Anónimo en 21:51 No hay comentarios: Enlaces a esta entrada
Etiquetas: harware, malware
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:
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.
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.
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.
Publicado por Anónimo en 0:31 No hay comentarios: Enlaces a esta entrada
Etiquetas: e-mail, malware, spam
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?
Publicado por Anónimo en 7:58 No hay comentarios: Enlaces a esta entrada
Etiquetas: cloud computing, e-mail, malware, spam
Physical Broadcast Traffic Attack
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
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 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í".
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.
Publicado por Anónimo en 23:22 No hay comentarios: Enlaces a esta entrada
Etiquetas: dispositivos red, DOS, redes, seguridad, switch
Gestionando incidencias de manera organizada (3/3)...
Gestionando incidencias de manera organizada (2/3)...
Gestionando incidencias de manera organizada (1/3)...

References: Resolución 
 resolución 
 resolución 
 resolución

 resolución 
 resolución 
 resolución 
 resolución