Sacándole el jugo a los IDS/IPS (II) - Configuración y afinamiento

En posts anteriores explicamos cómo llevar a cabo un despliegue de sondas IDS/IPS de la forma más óptima posible. Como lo prometido es deuda, en este post detallaremos cómo conviene configurar dichos elementos para que la información generada en forma de eventos de seguridad sea aprovechada por los Departamentos de Seguridad de las organizaciones.

La colección de dispositivos IPS/IDS con la que sembramos nuestra arquitectura de red anteriormente son capaces de enviar alarmas en caso de detectar/bloquear tráfico malicioso. En el momento de la configuración de dichos dispositivos (que traen una base de firmas genérica) se suele poner a registrar toda la actividad de la red durante un tiempo suficiente para obtener una muestra de suficiente calidad (generalmente una semana, aunque este tiempo puede variar). Esto se hace con el fin de evaluar los diferentes eventos detectados por las sondas IDS/IPS. A partir de aquí surgen dos posibles filosofías de afinamiento:

• La primera sugiere afinar la política de alertas de red eliminando todos los falsos positivos, y eventos de severidad baja, de manera que solamente genere alertas en caso de ataques que puedan suponer un impacto importante para la organización. Esta filosofía también es conocida como “anomaly detection”. Así los operadores que reciban las alertas deberán poner en marcha un plan de contingencia para mantener el ataque bajo control.
• La otra posible forma de configurar los IDS/IPS es afinar únicamente los falsos positivos y dejar todos los demás eventos activos, de manera que en caso de una intrusión, a la hora de realizar un análisis forense, contar con mucha más información para poder analizar los prolegómenos del ataque.
  

Ambas filosofías son muy opuestas en cuanto a la funcionalidad práctica (la segunda se hace ingestionable por recursos limitados en redes con mucha actividad), el mantenimiento y los costes de almacenamiento (a mayor verbosidad en el registro de eventos mayores necesidades de espacio en disco y mayor frecuencia de rotado de logs para poder manejar la información). Sin embargo la segunda posee como única ventaja el poder contar con un nivel de detalle excelente en casos post-mortem.

Según el ejemplo con el que contábamos en el posts anterior, teniendo mecanismos diferentes de IDS y de IPS, mi experiencia en estas lides me hace recomendar configurar los IPS de forma abnomally detection y los IDS en modo logging completo. De esta manera los IPS no tendrán que analizar una base de datos de ataques tan grande, priorizando también el rendimiento de los mismos, y los IDS guardarán datos de toda la actividad de red con un primer nivel de filtrado (por los IPS en caso de tráfico entrante/saliente).

En la siguiente entrega, aprovecharé para introducir un "juguete" nuevo en la infraestructura de seguridad de la compañía: los centralizadores/correladores de eventos.

Leer más...

apache-scalp

Ya hemos escrito sobre PHPIDS como solución para la detección de intentos de intrusión, pero hoy queríamos ampliar esta información con una herramienta de Romain Gaucher, llamada scalp, que permite en base a un fichero de registros de un servidor web detectar ataques, usando las propias reglas de PHPIDS.

Su uso es muy sencillo, consiste en un script programando en Python, (aunque está anunciada una futura versión en C++ multithread) que se ha de ejecutar pasándole como argumento el archivo a analizar, como por ejemplo, el archiconocido "access_log" de un Apache. A partir de ahí, generará un informe con las coincidencias detectadas.

Para instalarlo, basta con descargar el script de esta dirección: http://apache-scalp.googlecode.com/files/scalp-0.2.py, así como las reglas en formato XML actualizadas de PHPIDS, de la siguiente URL: https://svn.php-ids.org/svn/trunk/lib/IDS/default_filter.xmly dejarlas en el mismo directorio.

La siguiente imagen muestra la pantalla de ayuda al ejecutar sin argumentos la herramienta.


Mediante el argumento "-l" se indica cual es el fichero de logs, generando la salida en el formato deseado, por defecto en texto.


El siguiente ejemplo muestra un informe del resultado.

Leer más...

Gmail + DNI-E

Recientemente tuve que darme de baja en un servicio que me requería un correo electrónico para confirmar mi baja.

Enviando el correo electrónico, pensaba en que este tipo de procedimientos, en pleno 2008, deberían ser mucho mas fiables y que desde la llegada del DNI-e, no hay demasiadas excusas para no implantar mecanismos mas seguros. Al hilo de eso y dado que soy usuario habitual de Gmail, se me pasó por la cabeza que sería genial poder emplear mi Dni-e directamente en la interface web de Gmail (hasta ahora estaba usando Thunderbird para el firmado digital). Así que me puse a ver "el estado del arte" con respecto a firmado S/MIME en Gmail, al final di con esta extensión que hace justamente lo que yo buscaba.

La extensión aun está en etapas tempranas de desarrollo y no es plenamente funcional, en concreto Si puede hacer:

• Firmar digitalmente un correo electrónico
  
• Cifrar un correo electrónico
  
• Descifrar un correo electrónico que nos haya llegado

Por contra, se echa y mucho de menos la verificación de firmas digitales, es decir, si alguien nos envía un correo firmado digitalmente no sera posible verificar la firma, ni a nivel certificado digital ni mucho menos comprobando CRLs.

Tal vez en este punto algún que otro lector este pensando en jubilar sus vetustas claves GPG y pasarse al apasionante mundo de los certificados digitales, antes de eliminar sus claves ha de saber que, el dni electrónico, provee dos certificados en el chip, Firma y Autenticación ¿que significa esto? básicamente que los certificados digitales NO están preparados par cifrar información, por tanto, con el estándar PKI en la mano, ningún certificado del DNI-e debería ser usado para cifrar correos electrónicos. Para el que se haya perdido y le resulte incongruente la situación, aclarar un par de puntos sobre certificados digitales, todos ellos contienen una clave publica y otra privada RSA plenamente funcional "para cualquier cosa" adicionalmente, cada certificado lleva inscritas sus extensiones que definen su propósito de uso y es ahí donde se define si un certificado sirve para firmar digitalmente, para autenticarse o para cifrar información (entre otras muchas opciones). En el caso del DNI-e, los certificados sirven para autenticación y firma. Obviamente tu eres libre de extraer las claves RSA de los certificados y usarlas "a pelo" para lo que te de la gana, pero estarías violando el estándar PKI

No obstante, si pretendes usar certificados digitales para cifrar y firmar correos electrónicos, Firefox tiene una extensión que te permite crear tus propios certificados a medida que deberían funcionar perfectamente con la extensión S/MIME.

Aclarado este punto, prosigo con un mini how-to usar el dni-e para firmar digitalmente correos en Gmail.

Dando por hecho que ya tienes configurado el dni-e en tu Firefox (existen ya muchos tutoriales escritos sobre el tema) esta guía debería funcionar tanto en Windows como en Linux.

La integración de Gmail S/MIME con Gmail es total, y el uso, de lo mas sencillo, una vez hayamos abierto el editor de correos para enviar un correo, podemos observar que aparece a la derecha, un símbolo de firmado (resaltado con el cuadrito en rojo), y un candado para cifrar. (las imagenes son 'clicables' para verlas completas)

Simplemente hemos de marcar esa opción para activar el firmado digital del correo, como consejo, es recomendable activar el uso de "solo texto" y de esa forma eliminar los tags HTML que pueden provocar warnings durante el procesado del correo. Una vez marcada esa casilla y escrito el texto, simplemente pulsamos enviar.

Al hacer esto, nos aparecerá una ventana indicando con cual de los dos certificados del DNI-e queremos firmar el correo, como hemos dicho antes, PKI en la mano, deberemos seleccionar el certificado de firma y no el de autenticación.

En esta ventana, habremos de introducir el PIN de nuestro DNI-e.

Si todo ha ido bien, nos aparecerá otra ventana que nos pedirá confirmación para el proceso de firmado

Una vez aceptada la ventana, se lanza el proceso de envío, que, en este caso, se hace mediante la interface SMTP de Gmail, por lo que nos pide que introduzcamos nuestra contraseña (la misma que para acceder via web a Gmail)


Si la petición de envío ha ido bien, veremos en la parte superior de Gmail un mensaje indicando que nuestro correo electrónico ha sido firmado y enviado


Espero que el tutorial os haya resultado útil y, si sois usuarios de Gmail, no tenéis excusa para no agregar a nuestro bot

Leer más...

DNS, pasaté al TCP

Mucho se ha hablado ya del famoso bug que afecta al DNS y del que recientemente se han conocido los detalles "mas íntimos" sobre la forma y manera de sacarle partido (con su correspondiente exploit).

De una forma muy resumida y digerible el asunto estriba en dos características del protocolo DNS tal y como está desplegado actualmente :


·La comunicación se realiza con un protocolo NO orientado a conexión (UDP) y por tanto susceptible de ser "spoofeado"
· Las transacciones (peticiones-respuestas) están marcadas con un ID que, si bien se han hecho esfuerzos por dotarlo de aleatoriedad, como se ha podido comprobar, no ha sido suficiente.

El protocolo DNS, tal y como está definido en la RFC 883 debería de ser capaz de atender querys tanto en el puerto 53-UDP como en el 53-TCP. Erróneamente mucha gente asocia únicamente la comunicación del protocolo DNS en formato TCP a las transferencias de zonas entre DNSs primarios <-> secundarios y cuando una petición excede los 512 bits. Incluso no es descabellado encontrar documentos de hardening en el que se propone como medida de seguridad bloquear el acceso al puerto TCP del DNS.

Lo cierto es que un servidor DNS debería de prestar servicio por el puerto 53-TCP de forma "normal" el problema está en que consuetudinariamente la gente ha usado siempre 53-UDP alegando motivos de eficiencia, motivos que, en origen, cuando se diseñó el protocolo DNS tenían mucho peso, el problema es que esos conceptos forman parte de la época del Gopher y la www por texto, donde unos pocos bits eran un lujo. En los tiempos actuales en los que cualquiera puede incluso emplear su ADSL para colgar enormes vídeos en formato flash de varios megas, no tiene demasiado sentido seguir con esas premisas.

A nivel seguridad, ¿que supondría pasar el protocolo DNS a TCP? En pocas palabras: adiós al spoofing de conexiones (parte básica en todos los ataques al protocolo DNS), cuando hablamos de conexiones TCP estamos hablando de un protocolo orientado a conexión, donde interviene en cada conexión lo que se conoce como "TCP Sequence Number" que es un numero aleatorio por cada conexión. Hace años (principio de los 90) el protocolo TCP adoleció de fallos en este sistema que permitía predecir dichos números volviéndolo vulnerable a ataques de tipo IP-Spoof. Actualmente y tras muchos esfuerzos, unánimemente se considera un mecanismo robusto y fiable ya que prácticamente todos los sistemas operativos cuentan con mecanismos muy probados para obtener la suficiente entropia.
Podemos usar Hping para comprobar la aleatoriedad del ISN sobre cualquier host de la siguiente forma:
hping -S -p 80 www.security-projects.com -Q
HPING www.security-projects.com (eth0 208.88.52.63): S set, 40 headers + 0 data
bytes
1144894739 +1144894739
1147953489 +3058750
1136625600 +4283639406
1137798400 +1172800
1150024660 +12226260
1147708505 +4292651140
1138715293 +4285974083

Como se puede observar, la forma en la que se altera el ISN no tiene ningún patrón predecible.
Con el cambio de UDP a TCP, un potencial atacante tendría que deducir el ISN de TCP y el DNS-query-ID para falsear una respuesta, algo prácticamente imposible.

A nivel rendimiento, ¿que supondría pasar el protocolo DNS a TCP? En este punto toca disfrazarse del Sr Solbes y sacar la calculadora para manejar correctamente los datos, Wireshark en mano, una consulta DNS por el protocolo UDP, de www.google.com en un Windows XP sp2 sale en:

4 Paquetes / 461 Bytes

Misma query usando TCP:

22 Paquetes / 1557 Bytes

Evidentemente, bajo UDP, el consumo de ancho de banda es infinitamente menor, y visto porcentualmente, puede que el dato sea demoledor, pero si nos fijamos en las cifras y sobre todo en el orden de magnitud que nos estamos moviendo (Bytes) ¿realmente supone tanta diferencia?
He buscado algún tipo de métrica online con datos fiables a-la-mrtg para tratar de hacerme una idea de lo que puede suponer multiplicar por dos el trafico DNS. Y si, estudios del estilo "El p2p ocupa el 80% del tráfico" hay cientos, pero con datos para ver, pocos. Finalmente he encontrado un proyecto de la organización CAIDA (si, un nombre poco apropiado para los hispanohablantes) que se basa en obtener métricas de "puntos neutros" al estilo de nuestro Espanix.

Ojeando dichos datos me llama la atención que el DNS no está entre los protocolos con mas consumo de ancho de banda, de hecho, ni sale en la lista ordenada por consumo de bytes hay que ir a las listas de flujos de datos (normal, el DNS se supone que ha de generar múltiples hits) para encontrar los datos de consumo que, según esas estadísticas, suponen un 0,18 %

Con esos datos en la mano (que no tienen porque ser ni parecidos a los de, por ejemplo, un ISP como telefónica) queda bastante claro que el cambio TCP por UDP no tiene que resultar especialmente traumatico.

¿Soluciones? A dia de hoy no resulta obvio ni trivial alterar los parámetros del sistema operativo para forzar que las consultas DNS se hagan mediante TCP, en Linux-Unix, el 'resolver' (la base donde se sustenta el mecanismo para resolver direcciones), está preparado para hacer consultas vía TCP empleando la opción RES_USEVC, pero sorprendentemente, esta opción no se puede configurar desde el fichero /etc/resolv.conf (otras muchas, si). Resultaría trivial hacer unas pequeñas modificaciones para soportar esta funcionalidad. En el caso de sistemas Windows no costaría mucho adaptar el sistema y dejar al usuario la opción de añadir una clave en el registro para activar-desactivar esa opción.

A nivel servidores, (Bind, DJB y cía) como ya hemos visto, nativamente soportan querys vía 53-tcp, no costaría demasiado adaptarlos para que empleen un mecanismo al estilo "primero intento TCP, si falla, lo envío por UDP", ajustando muy muy bien los 'timeouts' para identificar con suficiente celeridad que servidor DNS esta dispuesto a resolver por TCP y cuales no.

Queda un ultimo punto: el desempeño en enlaces con poco ancho de banda (PPP, GSM, y similares) obviamente esta claro que ese tipo de conexiones iban a sufrir bastante por la falta de rapidez en realizar las transacciones DNS, por eso, la solución necesariamente tendría que ser como he comentado antes, dejar al usuario los mecanismos para decidir si necesita UDP o TCP.

¿Que se puede hacer ahora? Con todo lo expuesto anteriormente, si se puede hacer algo, al menos, para securizar nuestro entorno (Red local, nuestro PC). Después de investigar bastante el tema, buscar y probar varias implementaciones de DNS Cache e incluso plantearme hacer mi propio DNS-proxy, di con un software que hace justo lo que yo tenia en la cabeza: Admite querys en formato UDP (necesario para la comunicacion PC<->DNS) y re-envía la petición al DNS principal en formato TCP, su nombre: Pdnsd (Para linux).

La configuración que se puede hacer con este programa corresponde a este esquema:


Como se puede ver, la comunicación desde nuestro PC / un equipo de nuestra red, hacia el cache DNS va en formato UDP "atacable" pero la comunicación hacia el servidor DNS principal, en internet, va en formato TCP con lo que restringimos el riesgo de ataque a nuestra propia red, cosa bastante menor ya que si alguien pretende atacarnos desde nuestra intranet o nuestro PC, tendríamos bastantes mas problemas de los que preocuparnos.

Un ejemplo de configuración para Pdnsd de cara a usarlo en local (para tu propio PC, no como DNS cache para toda tu intranet) sería ésta

En este punto solo nos hace falta localizar un servidor DNS recursivo que acepte querys por el puerto TCP, como ya hemos dicho anteriormente, muchos ISPs cierran ese puerto o impiden que se acepten querys por el 53-TCP. Para comprobar si un servidor DNS acepta peticiones al 53-tcp podemos usar la herramienta dig con los parametros +vc

dig +vc www.google.com @dns.ya.com

; <<>> DiG 9.2.3 <<>> +vc www.google.com @dns.ya.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38295 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 7, ADDITIONAL: 7 ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 577445 IN CNAME www.l.google.com. www.l.google.com. 245 IN A 66.102.9.99 www.l.google.com. 245 IN A 66.102.9.104 www.l.google.com. 245 IN A 66.102.9.147

Como se puede ver, el DNS de ya.com acepta y resuelve bien por el puerto 53-TCP

Leer más...

Sacándole el jugo a los IDS/IPS

Conocidos como mecanismos de detección o prevención de intrusiones, los IDS/IPS se han convertido en un "must" en el SIMO de dispositivos que han de tener las organizaciones como mecanismos de seguridad en su infraestructura.

Dependerá del uso que se les vaya dando a estos dispositivos, que se conviertan en herramientas útiles que aporten valor en el proceso de la seguridad de las organizaciones, o se conviertan en unos "cacharros" más, cuyo mantenimiento engrose la lista de tareas de los administradores. Ya que todos los dispositivos que forman parte del stuff de una compañía requieren un mantenimiento (backups, actualizaciones, parches, licencias,...) por lo menos vamos a dar las pautas para que la utilización de sondas de detección/prevención de intrusiones puedan resultar útiles en su funcionalidad.

Antes que nada, quiero dejar claro que las sondas IDS son dispositivos que se posicionan offline del flujo de las redes, de manera que reciben una copia del tráfico de cada VLAN (mediante la utilización de TAPs físicos o con la creación de un port mirroring o port span de una VLAN de un switch capaz de hacerlo). Por un interfaz sin pila TCP/IP reciben el tráfico en formato RAW y lo analizan enfrentándolo contra una base de datos de firmas de ataques conocidos, de manera que, a través de otro interfaz, cuando detectan tráfico malicioso, envían señales de alarmas a una base de datos centralizada. Estos dispositivos solamente son capaces de detectar tráfico y, en ciertas ocasiones, pueden llevar a cabo reacciones activas que eviten males mayores en la infraestructura de producción. En este caso nos referimos a IDS de red, puesto que existen (o existieron hace unos cuantos años) los llamados IDS de host. Estos eran agentes software que se instalaban de forma directa en cada uno de los servidores a monitorizar y que enviaban alertas sobre ataques contra los mismos.

Los IPS sin embargo, funcionan de una forma diferente, puesto que se emplazan en modo inline entre las diferentes redes, de modo que el tráfico que pasa hacia y desde una red los ha de atravesar, pudiendo discriminar si el tráfico es malicioso o no. Al encontrarse en modo transparente e inline, este tipo de dispositivo sí que es capaz de bloquear todo tipo de tráfico que se considere un ataque. En líneas generales (aunque los IPS han evolucionado mucho), el funcionamiento principal de los IPS a la hora de identificar ataques es idéntico al de los IDS. Se basan en firmas de ataques conocidos y envían por un tercer interfaz las alertas a una base de datos centralizada.

Como diferencias principales entre ambos, aparte de las ya comentadas referidas a la capacidad de detectar únicamente o de bloquear los ataques, es la cantidad de tráfico a monitorizar por parte de ambos. En el caso de los IPS, sólo son capaces de identificar ataques dentro del tráfico que los atraviesa en ambos sentidos. Sin embargo, los IDS de red van más allá, puesto que al analizar el tráfico de una VLAN completa, es capaz de clasificar ataques entre máquinas de la VLAN, no sólo la que pasa de una red a otra.

Inicialmente, todo despliegue de una plataforma de sondas IDS/IPS, cómo si del apostamiento de francotiradores se hablase, requiere planificar con cierta inteligencia.

Como tónica habitual en la gestión de proyectos de este tipo lo que manda principalmente es el presupuesto asignado para invertir en el análisis de la seguridad de las redes.

Suponiendo que disponemos de algo de presupuesto para equipos con licencias comerciales, mi recomendación sería diversificar entre software comercial y software libre. Si bien como iniciativas libres disponemos del ultraconocido Snort (que puede funcionar como IDS y como IPS inline). Como soluciones comerciales más recomendables podemos contar con ISS (adquirida por IBM), Tipping Point (adquirida por 3Com), McAfee Intrushield (solución IPS basada en ASIC), Sourcefire (spin-off comercial de Snort que se integra sobre máquinas Nokia, aparte de sus propios appliances),...

No obstante, y dependiendo en mayor medida de si se tiene proyectado efectuar cambios en la estructura de cortafuegos de red principales, existen los llamados UTMs (Unified Threat Management) o MFA (Multi Functional Appliances) que son en realidad cajas que aunan las funcionalidades de cortafuegos de red, gestor de túneles VPN, antivirus, proxy, gestor de contenidos e IDS/IPS (dependiendo si solo registran las alarmas detectadas o si bloquean los ataques), entre otros... por lo que no es nada desechable la idea de implantar como pilar central de la seguridad un dispositivo de estas características que sea capaz de detectar y bloquear los ataques que lo atraviesen en dirección desde/hasta cualquiera de las redes que delimitan. Por poner ejemplos de fabricantes de dispositivos comerciales UTM, podríamos indicar: Fortinet, Juniper, NetASQ, Checkpoint, Radware,... De esta manera es posible evitar la inclusión de dispositivos IPS puros en los segmentos más importantes de la red. Huelga decir que si tenemos presupuesto ilimitado para llevarlo a cabo, lo más recomendable es situar elementos de diferentes fabricantes por lo que utilizar uno o varios UTM con la función de IPS activa para separar diferentes redes, y además la inclusión de IPS puros en los segmentos de red que necesitemos.

Supongamos que no contaremos con un dispositivo de estas características como eje central distribuidor de las redes principales de nuestra organización. Lo más normal en estos casos es dimensionar la cantidad de sondas a desplegar en caso de los IDS. Si contamos con instalar Snort como IDS (opción recomendada por ser gratuito y de gran calidad), de manera que podemos darnos el lujo de tener una sonda por cada red que posea la organización. En caso de tener limitación en el número de sondas por el coste del hardware, habremos de priorizar sobre las redes en las que tengamos elementos más críticos para nuestro negocio. Se suelen seguir criterios como "la red con más servicios expuestos a Internet" o "la red donde más información confidencial haya".

En cuanto al despliegue de IPS, supongamos que hemos destinado el grueso del presupuesto del proyecto a comprar equipos comerciales IPS. Lo más recomendable es situar un dispositivo (o clústers en alta disponibilidad si el presupuesto lo permite) justo en el punto de acceso a la red (puede ser en la salida/entrada de cada interfaz del firewall que delimita esa red).

Con esta disposición lograremos tener monitorizado el tráfico que entra a cada una de las redes que separa el firewall principal (y bloquearlo con los UTM o los IPS) y el tráfico que se intercambian las máquinas de cada red entre ellas (mediante el análisis del tráfico interno entre máquinas de un mismo segmento), pudiendo detectar actividad vírica que pudiera dejar fuera de combate una VLAN completa.

En posteriores entregas intentaré detallar lo mejor posible cómo configurar los diferentes elementos de seguridad que hemos incluido en nuestra arquitectura de red.

Leer más...

Syslog 2 Twitter

Mucho se ha hablado ya sobre Twitter y del fenómeno social que ha supuesto el micro-blogging, fenómeno que cuenta con legion de seguidores y otro inmenso grupo de detractores.

Personalmente, no acabo de encontrarle utilidad a, por ejemplo, saber que Lorenzo se está comiendo una manzana, o que yo, ando en mitad de un atasco en la A-2 (mas allá del hecho que me estaría jugando los puntos suficientes como para tener el Iphone gratis por twittear con el móvil en el coche).

El caso es que sea o no sea una moda pasajera, twitter, indudablemente si tiene una cosa muy favorable y es el hecho de poder "broadcastear" información de una forma muy sencilla desde un único punto hacia múltiples clientes. Existen clientes-twitter (mas allá de la web) de todos los colores y sabores, solo hay que ojear Genbeta para confirmarlo.

Desde SbD no hemos querido dejar pasar la oportunidad para contribuir al ecosistema Twitter y hemos desarrollado una pequeña aplicación que permite exportar los archivos de log que genera syslog a twitter. Syslog, para el que no lo sepa, es el mecanismo de logging que tiene Unix, algo así como el primo hermano mayor, con barba y gafas gruesas del Eventlog de windows.

El programa, en forma de script, hace uso de un par de curiosos módulos Perl que permiten monitorizar ficheros y "hablar" a Twitter. Para usarlo, obviamente, has de haber creado una cuenta en twitter.

Además Twitter permite hacer tus logs privados solo-para-la-gente-que-tu-quieras, cosa bastante útil de cara a publicar ese tipo de logs, ya que a mi me puede interesar que las personas que co-administran una maquina lean los logs, pero no el común de los mortales. Otra cosa que hace de twitter interesante para esta labor, es el hecho de que tiene una potentisima interface de busqueda que hará muy fácil buscar entre los eventos del syslog. Y como bonus, twitter también permite sindicarse vía RSS a un usuario, con lo que para aquellos que se encuentren mas cómodos con un lector RSS, también pueden tener sus logs disponibles desde cualquier parte.

¿Como funciona sys2twit? vayamos por partes, primero, la instalación de los módulos necesarios:

Como root ejecuta :

#perl -MCPAN -e shell

Esto debería llevarte a otra pseudo-shell desde la que poder instalar los módulos de la siguiente forma:

cpan> install File::Tail
cpan> install Net::Twitter

Una vez tengas todo lo necesario, puedes descargarte sys2twit desde aquí

Los parámetros que acepta la aplicación son:

-u (usuario que has creado en twitter)
-p (contraseña)
-f (fichero de log a monitorizar)
-d (daemon)

Un ejemplo para monitorizar /var/log/messages

# perl sys2twit.pl -u twitterlog -p 12345 -f /var/log/messages

De esta forma todo lo que se genere en /var/log/messages sera transmitido a twitter a la cuenta del usuario 'twitterlog'. Si no quieres que el comando sea interactivo y se 'daemonice' simplemente añade -d al final

Leer más...

Boletin Enigma

Con bastante e injustificado retraso por nuestra parte, nos gustaría anunciar que ya está disponible el último boletín Enigma en la calle.

Para el que no lo conozca, el boletín Enigma es, sin duda, el referente nacional sobre documentación técnica en criptografía en lengua castellana. Lleva desde el 2002 siendo editado gracias a la labor del profesor Arturo Quirantes.

En este ultimo numero, Arturo referencia de una forma muy pedagógica nuestro post sobre la FNMT.

Así que ya sabéis, si tenéis inquietud por la criptografía, y todavia no estaís suscritos, no dudéis en daros de alta en su boletín

Leer más...