Entrevista a la organización de Navaja Negra.#nn3ed 3 al 5 de Octubre.

En la entrada de hoy vamos a conocer un poco más a la organización de Navaja Negra (#nn3ed), una de las mejores conferencias nacionales de seguridad informática,que se celebra en una ciudad del sur de España, Albacete.

Mi vínculo con ellos no es otro que el de la amistad y la admiración, porque son un grupo de jóvenes, y con esto amplio no solo a los organizadores de Navaja Negra, sino a lo que yo llamo "el colectivo Navaja Negra" que trabajan en el mundo de la seguridad informática en varias vertientes, que tienen en común sus ganas por compartir. Hoy en día esto es difícil.

En la primera Navaja Negra Con me acogieron entre ellos por venir desde fuera.
En la segunda Navaja Negra me dejaron contar mi introducción al Pentesting. Descarga presentaciones.
En la tercera Navaja Negra, me alegra que AUN ME DEJEN ENTRAR :-).

Aquí os paso la pequeña conversación. Espero que os guste.

- ¿Qué es Navaja Negra? ¿Por qué este nombre?

NAVAJA NEGRA es sinónimo de “seguridad informática con sabor albaceteño” y es el nombre del Congreso anual de Seguridad Informática que hacemos en Albacete, una pequeña ciudad en el sudeste de España.

El nombre surge de una mezcla manchega de black “HAT” y lo típico de nuestra tierra que son las navajas. Como no estamos en Estados Unidos ("black hat") ni en Madrid ("boinas negras") sino en Albacete, pues de ahí el particular nombre con el que bautizamos el nombre del Congreso.

Es nuestra pequeña devolución a la tierra de unos cuantos que nos hizo ser lo que ahora somos y que muchos lamentablemente tuvimos que abandonar por cuestiones laborales. La idea surgió de un par de “locos” (@ggdaniel y @nn2ed_s4ur0n) en un bar donde se dijo: “… y porqué no intentamos hacer un evento de seguridad en nuestra tierra?” Muchos de los que formamos parte de ésta gran familia, hemos viajado numerosas veces a otras conferencias en España e incluso en el extranjero… y pensamos que sería genial poder hacer lo mismo, compartiendo nuestras experiencias en seguridad informática con todo aquel que le apetezca escucharlas.

Servilleta de papel en mano, nos pusimos a trabajar en las primeras charlas “CRASH” (Conferencia Reunión Albacete Seguridad y Hacking) y de ahí salió la idea de montar el Congreso de Seguridad Informática “NAVAJA NEGRA”. Todo empezó en la academia privada MADESYP y con el patrocinio incondicional de BUGUROO OFFENSIVE SECURITY, -que hasta la fecha nos siguen apoyando-, donde asistieron unas 60 personas. Todo un logro el reunir a tanta gente con un mismo denominador. Recordamos con humor y cariño que pusimos en el catering “cervezas” y… quedaron!!! Increíble en una primera reunión de “hackers". Fue sorprendente que viniera gente de Murcia (como tú), Alicante, Valencia, Cuenca, Toledo, Ciudad Real, Madrid...

Con las segundas navajas, logramos ampliar el número de personas. Entre todos (organización, muchos voluntarios y amigos ayudando) logramos reunir a 165 personas y un buen número de ponentes. Un auténtico honor.

Para esta tercera edición nuestro mayor deseo es tener, al menos, la misma aceptación de años anteriores, y una ilusión: Que Navaja Negra pueda llegar algún día a la sombra de las mejores: Rooted, No cON Name, LaCON o Conecta. Todas ellas referencias nacionales.

- ¿Qué tiene Navaja Negra que a la gente tanto le gusta, para que llenéis las salas en donde ha tenido lugar?

Que las salas son pequeñas… jajaja… Bueno, broma aparte, creemos que el éxito no es nuestro sino de todos aquellos que hacéis posible que sea un éxito. Nuestra filosofía desde el primer momento es que sean unas conferencias de todos y para todos. Aunque los "ideadores" del congreso fuimos dos personas, hemos podido hacerlo gracias a muchos amigos y colaboradores desinteresados. No hay roles. Los asistentes se mezclan con los ponentes. La máxima: “el buen rollo”. No se limitan tan solo a la ponencia, sino que hacemos una pequeña convivencia durante el tiempo que duran.

Tratamos que las charlas sean lo más novedosas posibles, actuales y con una temática principalmente técnica. Tampoco “nos casamos” con nadie (puede leerse sin "tapujos" fabricantes, proveedores, etc.) por lo que se puede contar “todo” siempre y cuando sea legal.

Este año intentamos que fuera el público el que votase las charlas que quería que ver. Al final, haciendo un gran esfuerzo, pudimos dar cabida a todas ellas. Una fantástica noticia.

El año que viene esperamos poder ofrecer unas charlas "a la carta" aunque… para eso aún queda mucho, verdad? :)

- ¿Que tipo de público se espera para este 3º Congreso?

Todo aquel que le apetezca aprender y conocer sobre el mundo de la seguridad. Las charlas serán bastante técnicas, pero... nadie nacimos aprendidos, no?

- ¿Por qué gratis?

Creemos firmemente que deben ser gratuitas ya que no todo el mundo puede costearse una entrada para una conferencia, además de tener que pagar el desplazamiento, alojamiento y como no, la cena que solemos hacer y esas “cañitas con tapa” por los lugares típicos…

Sin embargo, seguramente éste año nos veamos obligados a “cobrar” un mínimo (10 euritos) para que la gente que va no deje ningún hueco vacío. Hay un gran problema cuando es gratuito y es que la gente se apunta y luego no asiste. Siempre se prevee y se hace overbooking, pero éste año con los costes que tiene el congreso (y que nos está costando muchísimo poder costear), no podemos permitirnos ni un solo sitio vacío. A cambio, esperamos poder dar alguna sorpresa….

Fieles a nuestra filosofía, publicaremos todos los gastos e ingresos que ha tenido la Organización del Congreso con una total transparencia, para que se vea claramente que no hay "trampa ni cartón".

También hemos negociado con Renfe, hoteles, restaurantes, bares, etc. importantes descuentos para los asistentes. Informaremos de todo ello en la web para que podáis beneficiaros de ello. E incluso tendremos una aplicación para "hostelería" y que nadie se pierda ninguna oferta que nos hagan en tiempo real.

- Seguro que no se puede, pero somos hackers !!! A ver, contarme, que ponentes/ponencias tenéis preparadas para este año.

Un montón de ponencias… Ya las hemos publicado en la página http://www.navajanegra.com/ponentes.aspx para que se puedan ver. Lo que podemos adelantarte es que comenzarán a media mañana el Jueves y finalizarán el sábado al mediodía… más no podemos...

kino dice:Felicito en este espacio a mi amigo @winsock  de Mi equipo está loco, por la fantástica presentación que tiene preparada y por su nueva aventura laboral.

- ¿Que apoyos estáis teniendo de la comunidad Hacker? ¿De las empresas y organismos públicos?

Por parte de la comunidad, nacional e incluso internacional, el apoyo es muy alto. Constantemente están siguiendo el evento desde hace mucho tiempo y pendientes para cuando se abra el proceso de inscripción. Será en la primera o segunda semana de septiembre.

Las empresas tenemos algunas que anunciaremos en la página completamente volcadas y que gracias a ellas, podemos celebrar el Congreso. Sin su ayuda económica sería imposible poder hacerlo. Otras, han colaborado en forma de descuentos en sus materiales, etc.

Las instituciones, como estamos entre “hackers”, si quieres te contamos la verdad… ¿Te la imaginas ya? Las únicas que han apoyado el evento han sido: el CEEI el año pasado y éste año la Universidad, que nos subvencionará SOLO una parte de los gastos del salón.

- Que actividades se van a realizar durante el congreso aparte de las charlas, algún reto?

La verdad es que tres días dan para mucho, aunque por el gran número de ponencias que tenemos previstas, queda muy poco tiempo para poder realizar un reto, hacklabs o showcases de forma paralela. De momento no hay nada previsto, aunque no se sabe de última hora qué podrá ocurrir… de hecho, ya hay algo y nadie "se ha dado cuenta todavía"… xD

El reto éste año sera asistir a la “cena manchega” y resistirse a degustar los productos típicos de nuestra tierra incluyendo el “miguelito” de postre… ;-D

Muchos de los que leen este blog ya han asistido a anteriores Navajas Negras. Seguro que tenéis mucho feedback de los asistentes, estáis trabajando para mejorar algún aspecto mejorable de anteriores ediciones? ser críticos amigos, que fue lo que menos os gusto de anteriores Navajas Negras.

La verdad es que en general, el feedback ha sido muy positivo pero hemos aprendido de los errores y esperamos que no se repitan éste año. Esperamos poder tener un mayor control en los accesos, en las acreditaciones personales e intentaremos que si finalmente realizamos streaming, no se sature como el año pasado. Pero tampoco esperábamos que hubiera tanta gente siguiéndonos online!!!

- Algo más que queráis comentar para el público de Inseguros? ( Recordar que la mayoría son féminas xD)

Pues animar a tus lector@s para que asistan éste año y podamos compartir unos días hablando de esas cosas que no puedes hablar con tus colegas o tu novia porque "te miran raro" :)

Desde aquí darte las gracias Joaquín por haber participado en nuestro Congreso y brindarte todo nuestro apoyo para tu blog que sabes que seguimos fielmente.

Gracias a vosotros por vuestro tiempo. 

Podéis seguir las novedades del congreso en la web principal y en el Hashtag #nn3ed.

Espero que os guste la entrevista, y nos vemos en Navaja Negra tercera edición los días 3, 4 y 5 de Octubre.

Gracias por leerme.

Server 2012 iSCSI Target SAN & SQLServer 2012 FailOver Cluster.

El objetivo del post de hoy es implementar una estructura base de almacenamiento redundante a fallos para una instalación de Sql Server 2012. En la primera parte vamos a configurar el almacenamiento virtual para dos nodos del cluster mediante iSCSI Target. Esta función está disponible en la instalación base de Windows Server 2012, y no es necesario descargar ningún software como hacía falta en Windows 2008 R2. En la segunda parte del artículo configuraremos el cluster de los servidores que van a alojar los Sql Server 2012.

Para preparar este laboratorio tengo un controlador de dominio, con dos discos duros. Uno de ellos lo usaré para crear el iSCSI.
Dos servidores miembros unidos al dominio, en los que instalaremos los servidores SQL Server.

Lo primero que vamos a hacer es instalar el complemento de iSCSI Target  San desde el DashBoard en el DC. Si cuentas con una unidad SAN para hacer las pruebas, puedes obviar este paso.

Una vez instalado, entramos en el complemento de administración de Ficheros y Almacenamiento, y sobre la parte iSCSI, creamos un nuevo disco duro virtual SCSI.

Lo más importante del proceso de instalación es identificar que servidores van a tener acceso a la SAN. Como en mi caso ya lo tengo documentado y preparado, introduzco las ip´s.

Si todo ha ido bien, ya tenemos disponible nuestro "sistema SAN" de andar por casa.

Si prefieres realizar este paso sobre algún nodo montado en FreeNas, puedes consultar este artículo.

Si quieres montar FreeNas desde cero, te aconsejo que sigas la serie de artículos en el blog de 1GBdeinformacion. 1, 2 y 3

Ahora es el turno de configurar uno de los servidores SQL Server 2012.

Lo primero que hacemos es dar a conocer la unidad SAN al servidor.

El siguiente paso será instalar en el servidor los complementos .Net Framework 3.5 y el cluster por conmutación de error.

Repetimos los mismos pasos para el segundo servidor que formará parte del Cluster.

Una vez tenemos instalados los sistemas base, en el primer nodo, en mi caso SqlServer1 (x.x.x.200) entramos en el complemento de administración del Cluster.

Imagino que si habéis seguido el proceso os habrán salido algunas advertencias, según vuestras configuraciones. Podemos obviarlas de momento, pero debemos tenerlas en cuenta ya que las advertencias suelen ser sobre el rendimiento y sobre todo disponibilidad. Disco de Quorum, tarjetas de red para el HeartBeat, etc. Más adelante podemos modificar estas configuraciones.

El último paso es añadir un disco al cluster. Seleccionamos el disco y listo.

De momento, tenemos los dos servidores trabajando en modo Cluster por conmutación de error.

Ahora pasamos a instalar Sql Server 2012. 

Seleccionamos las opciones avanzadas, y entramos en Preparación para Cluster.

Proseguimos con la instalación habitual de SQLServer y realizamos la misma operación en el segundo nodo.

Una vez instalados los dos SqlServer 2012, seguimos en el menú de instalación y pulsamos Finalización avanzada del Cluster.

Indicamos el nombre del Cluster.

Introducimos una ip para el Cluster.

Siguiente siguiente siguiente y tenemos instalado nuestro Cluster de conmutación por error de Sql Server 2012. Si quieres profundizar un poco más en la ubicación de los ficheros de la BBDD debes consultar aquí.

Como siempre, gracias por leerme, espero que os guste.

Tips & Tricks. Crear imagen actual de nuestro sistema Windows 8.

Al igual que anteriormente disponíamos de la opcion Restaurar Sistema. Ahora tenemos la posibilidad de crear una imagen WIM personalizada con nuestra instalación de Windows 8 y programas. La ventaja sobre la anterior tecnología es que nosotros decidimos el momento de crear la imagen, y no al realizar un Update como con la opción de Windows Restore. Otra ventaja es que en todo momento controlamos la ubicación de la imagen WIM, por lo que podemos usarla en caso de perdida total del sistema.
Para realizar la imagen de nuestro sistema, basta con iniciar una consola CMD con permisos de administrador local, y ejecutar: recimg.exe /createimage "directorio donde guardar".

La manera más sencilla y directa de comprobarlo es borrar una aplicación después de crear una imagen, y restaurarla desde las opciones de configuración, Uso General, Restaurar tu PC sin afectar los archivos.

Sin duda, una alternativa útil para recuperar un PC de un problema de una manera sencilla.

Si ejecutamos este comando una vez al més en pc´s instalados sin virtualización, podemos tener una Copia de Seguridad funcional del estado total del sistema.

Como siempre, espero que os guste, y gracias por leerme.

Auditando tu política de actualizaciones con terceras partes. Nessus Home

En este artículo vamos a hablar de la auditoría de las actualizaciones de productos administrados bajo WSUS con una herramienta, Nessus.

La idea es sencilla. Si administras una infraestructura en la que dispones de sistemas operativos Windows, y algún que otro servidor... tendrás instalado WSUS, el servicio de actualizaciones para los productos Microsoft, como puedan ser el propio sistema operativo, Office, Sql Server, Sharepoint etc etc.
Constantemente hablamos de la necesidad de controlar los sistemas en profundidad Como halábamos en otra entrada, debemos considerar implementar una política de escaneo de vulnerabilidades continua, que nos permita tener una visión global del estado de nuestros sistemas, en lo que a nivel de parcheo, configuraciones por defecto y obtención de información se refiere, que es lo que considero que aporta un test de vulnerabilidades.

Vamos a usar Nessus en versión home para auditar un equipo, en cuanto a nivel de parcheo se refiere. No vamos a escanear el equipo en cuestión, sino que vamos a consultar al servidor WSUS el estado del equipo.
Si realizamos una auditoría autorizada a un equipo, y le pasamos las credenciales válidas para conectarse, Nessus trata de obtener la versión de la librería implicada en la actualización que trata de comprobar. Esta acción es directa contra el equipo, y puede que no sea 100% efectiva.

El por qué realizar una auditoría de este tipo? Se me ocurren muchas razones. Imaginemos el caso de una empresa en la que la administración de los servidores la lleva a cabo una empresa contratada. Imaginemos el caso de que tienen un acuerdo de nivel de servicio. Imaginemos que fallan las actualizaciones en un segmento de equipos y que por este motivo se produce una infección y se acaba el mundo... Contar con unos informes en los que se almacene el estado de las actualizaciones puede sernos útil.
Una razón sería usar esta información en un proceso de post-explotación en un test de intrusión en el que tenemos acceso a una cuenta local, en un servidor corriendo WSUS, y en el que sin duda obtendremos mucha información útil del estado de los equipos sin tener que actuar directamente contra ellos.
Otra razón simplemente sería la de tener un indicador más de rendimiento del servicio.

Lo primero que debemos hacer es configurar una Política o Policies. Como el propósito de este test no es saber los puertos abiertos, vulnerabilidades, etc desmarco todas esta opciones. En preferencias seleccionamos Patch Management: WSUS Server Settings y configuramos los datos del servidor WSUS. En Plugins, los que muestro. Un consejo, desmarcar todos los plugins, y mediante un filtro, buscar por "contiene la palabra Wsus".

Podemos incorporar el Plugin Bulletins. Este Plugin identifica el KB concreto de la actualización con toda su descripción. Sería el que usaríamos en un test normal, contra el equipo directamente, y proporcionándole credenciales. No es el caso. La única diferencia entre activarlo o no sería que en el resultado del Report, si lo incluimos, nos aparecerá una vulnerabilidad por cada actualización que no se encuentre aprobada pero no instalada, mientras que si no usamos el Plugin Bulletins, en el Report nos aparecerá solo una "vulnerabilidad" del tipo Info. con el resumen de actualizaciones no instaladas.
Es decir, veríamos esto con Bulletins:

Y esto como resumen si no añadimos ese plugin.

Como podéis ver, muestra en el resumen para ese equipo 58 Parches no instalados. Lo mismo que me dice WSUS.

Si está acostumbrado a usar WSUS sabrás que su fuerte no es el Reporting. Puede que en determinadas ocasiones saber si un grupo de equipos tiene instalada una actualización concreta puede ser ardua tarea.

A eso le sumamos la facilidad de usar Nessus para almacenar el estado de actualizaciones para un determinado momento.

Lo que no he podido hacer es configurar una programación para este escaneo, paralela a la política de Microsoft de segundos martes del mes...

Sin duda me parece necesario el control de parches de nuestros sistemas, y de esta manera, podemos controlar si lo estamos haciendo bien o tenemos algún problema con el servicio.

Como siempre, gracias por leerme y espero que te guste el artículo.

Test de vulnerabilidades As a CONTINOUS Services. Nessus Home.

Este concepto no me lo he inventado yo ni mucho menos, pero es algo sobre lo que llevo pensando desde hace tiempo. He visto varios artículos dándole vueltas al asunto, por lo que imagino que ya será una realidad en muchas organizaciones.

Como todos sabemos en el mundo de la seguridad, el ciclo de vida de los incidentes es muy corto. Pueden pasar horas, minutos, desde que un tipo en Kazajastan crea un exploit para un zero Day en un producto popular, y lo tenemos en la puerta de nuestra empresa probando infectar o atacar la vulnerabilidad. Los días que pasan desde que se publica la vulnerabilidad, hasta que el fabricante desarrolla la corrección pueden marcar la diferencia en el éxito o no de los ataques.

Desde el punto de vista clásico de un director TI, el contar con un informe de una empresa que le realiza un test de vulnerabilidades dos veces al año, sería una buena gestión. Pero entonces, confiamos en que nuestros sistemas están correctamente parcheados/configurados durante los 6 meses de diferencia entre auditoría y auditoría?.
 En el mundo de la calle, en el que los empleados apuntan claves en Post-it, en los que aún hay empresas que no se adaptan a una simple LOPD por no tener ni una infraestructura de directorio, en ese mundo no hay auditorías de seguridad.

Como siempre reivindico en Inseguros, existe el término medio. No todos podemos administrar sistemas/seguridad en MegaCorp. S.L. con recursos para hardware/software. Ni tampoco tenemos que ser participes con nuestra falta de profesionalidad de administrar una empresa con la clave "1234".

Vamos a intentar proporcionar a nuestra organización, o por qué no, red de ordenadores domésticos ( por eso de las licencias) de una aproximación a lo que entiendo como un servicio continuo de Test de Vulnerabilidades.

La idea es muy sencilla. Definimos una plantilla con la configuración de una auditoría para nuestros sistemas. Programamos la realización de este test en un horario que no deteriore mucho el rendimiento de los sistemas.
Monitorizamos el resultado de los informes y monitorizamos los informes de resultados obtenidos entre auditorías realizadas entre fechas.

La palabra continuo aquí tiene sentido cuando hablamos del problema de tener informes de resultados cada 6 meses, pero no tiene sentido si lo comparamos por ejemplo con la continuidad que ofrece lo que hace un IDP en tiempo real. Programar una auditoría "ligera" diariamente y otra un poco más completa mensualmente lo considero aceptable para una PYME que le preocupe la seguridad, pero que no tiene los medios para adquirir un producto específico.

Para realizar este laboratorio necesitamos tener instalado Nessus 5.2 o superior, que en la versión Home posibilita la programación de test y la notificación por correo. Si queréis revisar los artículos sobre Nessus en Inseguros podéis pinchar aquí, aquí y aquí.

Lo primero que vamos a hacer es en Configuration, introducir los datos de nuestro servidor SMTP que realizará el envío.

Para crear una plantilla de Test nos vamos a Scan Templates y creamos una nueva del tipo programada. Introducimos la política de Test que queremos realizar. Debemos configurar una seria de Plugins acorde con el sistema que vamos a auditar, y tenemos que tener en cuenta la perdida de rendimiento en el equipo a auditar. Yo para esta demo ya tengo mi Policie llamada "kino" :-) .
Configuramos la periodicidad del Test.
 Introducimos la lista de equipos que queremos auditar y configuramos una cuenta de correo de destino. En los filtros podemos indicar que resultados mostrar en el informe que enviaremos al correo. Considero oportuno filtrar algún tipo de información, por ejemplo, si estás de vacaciones y te llega el Report del Test no creo que te sea de utilidad saber que ha detectado " Windows Devices" o que hay un puerto 80 activo. En este informe no vamos a ver las diferencias entre el último Test, pero a mi me gusta ver estos informes en el correo en mi tiempo libre, por si detecto alguna anomalía. Para esta prueba he configurado que envíe los resultados en caso de encontrar algún resultado denominado Critical y por filtrar algún detalle más, que me muestre los que tienen algún tipo de exploit disponible.

Con esto lanzamos la programación para nuestro Test diario a las 21:30.
Este es un ejemplo de un Report enviado al correo.

Una vez tenemos generados suficientes informes como para poder comparar,  solo tenemos que seleccionar los informes en el panel de resultados y pinchar en Options. Diff Result.

El informe de resultados que nos presenta no se almacena, es labor del responsable el realizar la comparación y detectar variaciones no deseadas en los resultados.

Como podéis ver, podemos tener un sistemas más o menos continuo para realizar test de vulnerabilidades programados, dentro de las posibilidades de una herramienta como Nessus.
Profesionalmente hay sistemas que se encargan de esto, del fabricante de Nessus, pero para controlar un poco más este aspecto, nos puede servir este procedimiento.

Como siempre, espero que os guste el artículo, y gracias por leerme !!!.



Google +