Abril 23rd, 2008
Estos días he estado programando un modem GSM para un concurso que ha sacado el Cabildo de Gran Canaria con motivo del día del libro, éste consiste básicamente en enviar relatos cortos vía SMS, estos relatos son publicados en una web y lo más votados serán premiados. Antes que nada quiero aplaudir desde aquí tan novedosa iniciativa, podéis informaros del concurso en la web www.relatoscortosxsms.com/.
Y ahora a lo que iba, el terminal que he estado usando es el TC35i de Siemems y la verdad es que me ha sorprendido el mundo de posibilidades que se abre ante nosotros gracias a este pequeño dispositivo. Basta conectarlo al ordenador e insertarle una tarjeta SIM (yo trabajé con una prepago) y ya podemos dar rienda suelta a nuestra imaginación: recibir un sms cada vez que tengamos un correo nuevo o se active un nuevo evento en nuestra agenda, enviar comandos a nuestro equipo vía SMS (activar/desactivar servicios, ejecutar reglas iptables, incluso hacer redirecciones en nuestro router)… y si tenemos la casa domotizada ya ni te cuento. En definitiva, control total vía SMS… y eso por no hablar de los concursos que nos podemos montar en nuestra propia casa.
El modem se controla a través de un puerto serie vía comandos AT. Dicho así puede parecer complicado, pero lo cierto es que si tienes conocimientos de programación te resultará bastante sencillo.
Ya sabes, por un módico precio tienes un mundo de posibilidades vía SMS.
Categorías: interesante |
2 comentarios
Febrero 25th, 2008
Todos habréis oído que las claves WEP que Teléfonica coloca a sus routers no son totalmente arbitrarias. Hace tiempo que pensaba escribir un artículo sobre el tema y cómo conseguir de forma sencilla acceso a las redes así protegidas. Pues bien, ya no lo voy a escribir. El otro día me encontré con un blogger que se me había adelantado… quizás cuando tenga un rato libre haga una revisión de su artículo, hay cosas que creo se podrían mejorar en el método que él expone, pero sin duda lo encontraréis interesante: Romper claves wep de teléfonica
Categorías: interesante, seguridad |
2 comentarios
Febrero 2nd, 2008
Me alegra anunciar que después de infinidad de papeleo y tiempos de espera, por fin ha salido a la luz el libro que escribí junto a José A. Muñoz: Seguridad de Sistemas en Red. Un libro técnico en el que hemos hecho un largo recorrido a través de las diferentes formas en las que se puede vulnerar un sistema conectado en una red TCP/IP y las contramedidas necesarias para evitar tales ataques. Aunque es un libro en el que se describe de forma teórica los ataques y sus fundamentos (así como las defensas a los mismos), siempre hemos intentando darle un enfoque más práctico añadiendo ejemplos y referencia a utilidades que permitan al lector comprobar por si mismo la fuerza demoledora de tales ataques, así como la efectividad de los mecanismos defensivos que tenemos a nuestra disposición.
De momento el libro no se puede encontrar en librerías, pero me han comunicado que en breve estará disponible en la tienda de la ULPGC. Mi intención inicial era liberar una publicación electrónica a la vez que la publicación impresa, sin embargo, el contrato que he firmado me impide liberar el documento en la red hasta dentro de unos años.
Os dejo el índice del documento, la numeración de las páginas no se corresponde con la de la obra publicada, sino con la del borrador que enviamos a maquetación.
Descargar Índice de Seguridad de Sistemas en Red
Categorías: interesante |
4 comentarios
Enero 25th, 2008
Todos alguna vez nos hemos (o nos han) preguntado: ¿Por qué la batería me dura más en Windows que en Linux? Pues simplemente porque los fabricantes de portátiles se encargan de hacer buenos programas para gestionar la energía bajo Windows. Estas pequeñas joyas que cada compañía hace a medida para su equipo, son capaces de controlar y desactivar todo aquello que no se usa, suspenden el bluetooth, ponen el wifi en modo ahorro, bajan el brillo a medida que se consume la batería, suspenden la energía de los puertos usb que no se están usando, etc, etc. En conjunto todas estos pequeños ahorros de energía producen un ahorro significativo que expande considerablemente la duración de la batería.
En Linux hemos ido siempre un paso por detrás en este sentido, es cierto que existen algunos programas que son capaces de reaccionar a ciertos eventos ACPI, haciendo, por ejemplo, que el portátil se comporte de manera diferente según la batería que nos quede. Pero nunca habíamos tenido una herramienta que nos permitiera identificar con claridad los ‘agujeros negros’ de nuestro equipo, es decir, esos procesos que consumen más de lo que estamos dispuestos a permitir o esas carencias de configuración que hacen que el portátil gaste energía en algo que es innecesario.
Pero estamos de enhorabuena, Intel ha desarrollado y liberado una pequeña herramienta que nos permitirá identificar cuales son los procesos que más energía consumen, además esta pequeña utilidad nos dará consejos sobre como configurar nuestro equipo para hacer un mejor uso de la batería, es más, muchas veces bastará pulsar una tecla para que la aplicación aplique el consejo (eso sí, para hacerlo persistente tendremos que crear un script que ejecute las medidas recomendadas durante el arranque del sistema).
La utilidad se llama PowerTop y si tienes un portátil Intel ya deberías estarla usando (si usas una distribución Debian o similar también puedes descargarla vía apt-get).
Categorías: interesante, linux |
11 comentarios
Enero 14th, 2008
Hoy estaba revisando algunos logs y pensé: ojalá pudiera resaltar con colores algunos patrones, me ayudaría mucho. Por supuesto, la primera idea que se me vino a la cabeza fue usar el grep:
# grep –colour PATRON /var/log/messages
Pero el grep elimina todas las líneas que no contienen el patrón y eso tampoco me interesaba. Busqué en la web un rato y encontré varias utilidades que coloreaban ficheros de logs completos, pero tampoco era lo que quería.
Lo que necesitaba era una utilidad que me resaltara sólo ciertos patrones y que me devolviera el contenido íntegro del fichero de logs. Eso sí que estaría bien. Y diría que hace tiempo me encontré con una utilidad que hacía exactamente eso… pero como no daba con ella y tampoco quería pasarme toda la mañana buscándola, escribí un pequeño script en perl que hacía todo lo que yo necesitaba. No soporta expresiones regulares (de momento) pero es suficiente para lo que yo lo quiero. Os pongo un par de ejemplos de uso:
1. Si lo ejecutamos sin parámetros nos sale una ayuda muy cutre. Básicamente nos dice que necesita al menos un patrón que colorear. El script sólo admite cuatro patrones como máximo (pero es muy sencillo modificarlo para que admita más). Cada patrón será resaltado con un color distinto.
# highlight
ERROR: Necesito al menos un patrón que sobresaltar
Uso: /usr/local/bin/highlight patron [patron2] [patron3] [patron4]
2. Coloreamos el log del iptables para que resalte los patrones ‘SPT=’, ‘DPT=’ y ‘Output’.
# cat iptables.log | highlight SPT= DPT= Output
3. Similar al anterior pero usanto un tail:
# tail -f iptables.log | highlight Input SPT= DPT= src= DST=
Descargar Highlight Script
Categorías: descargas, interesante, linux |
No hay comentarios
Enero 5th, 2008
El año nuevo me trajo un bonito regalo: una máquina comprometida. Me pidieron lo que se suele pedir en estos casos, buscar como lograron acceso y que medidas tomar para evitar intrusiones futuras. La máquina en cuestión ofrecía servicios de webhosting y no podía desconectarse bajo ningún concepto, tampoco existía una máquina de respaldo para casos como estos. Las copias de seguridad se hacían rigurosamente, pero no es suficiente en esta situación, es necesario que exista una máquina de respaldo lista para entrar en funcionamiento con la última copia de seguridad limpia.
Pero esto es lo que te enseña la experiencia, las cosas no son como dicen en los manuales… ahí estaba mi máquina con signos evidentes de compromiso y yo no podía desconectarla para analizarla con calma. Tampoco podía obtener un volcado del disco para su posterior análisis, se trataba de una máquina remota y, además, la carga adicional del volcado a un medio externo afectaría notablemente al desempeño del sistema.
Bueno, hay que jugar la mano con las cartas que te tocan, así que me puse manos a la obra. Tras un primer vistazo al sistema descubrí un bouncer y varias instancias del eggdrop campando a sus anchas, además todo ejecutado por el usuario ‘www-data’. Aquello olía a script kiddie. Era evidente que la máquina había sido comprometido por el fallo de algún CMS, pero en aquel momento sentía más curiosidad por la personalidad del atacante que por el fallo que le permitió entrar. Escribí unas cuantas reglas IPTables para asegurar mínimamente la máquina y fui a la caza del intruso. Tras tracearle un poco la pista lo encontré en un IRC dejado de la mano de Dios, estaba en un canal rodeado de todos sus eggdrops. Os aseguro que había muchos y cada uno de ellos era señal inequívoca de que una máquina había sido comprometida en algún lado. El servidor IRC no ocultaba la IP, así que tenía todas las direcciones de todas las máquinas comprometidas, supongo que debería haber notificado a los afectados… pero lo que hice fue hablar con mi pequeño intruso. Era un chaval chino con ganas de impresionar a sus amigos y obtener privilegios de operador en algún canal hacker. Estaba conectado a través de un bouncer, así que localizar su IP real me iba a costar mucho trabajo y tiempo… y tediosas negociaciones con administradores negligentes.
Ya conocía al intruso, así que volví a la máquina. Primero había que ver el alcance del ataque. No había indicios de que hubiera conseguido privilegios de root, aunque claro, siendo root nada te impide borrar tus huellas. De todas formas no parecía probable (y sin desconectar la máquina no podía hacer análisis más concienzudos). Había varios bouncers instalados en el sistema, por su fecha y ubicación era más que posible que fueran creados por distintos scripts, así pues podríamos estar hablando de varias webs vulnerables. Eliminé bouncers, eggdrops y una bonita puerta trasera colocada en el cron y fui a por el fallo que permitió entrar al intruso. Identifiqué varias vulnerabilidades que presentaba el sistema y estudié con detenimiento los logs del servidor web. Vi muchos rastreos automáticos de bots bien conocidos y alguno que otro sin precedentes, no me extrañaba nada que la máquina hubiera sido comprometida. Lo que me sigue extrañando es no haber encontrado más malware.
Informé sobre los problemas y di por acabado el trabajo. Pero aún tengo al sistema bajo vigilancia, estoy seguro de que en esa máquina hay más de lo que veo (también es posible que esté paranoico, esa es una de las consecuencias de este trabajo).
Para acabar un dilema, debería lanzarme en una cruzada contra el chaval que ejecutó el bot o debería dejarlo pasar sin una colleja… ninguna de las dos opciones me parece adecuada, pero haré lo que se suele hacer en estos casos (así va el mundo), tomaré la alternativa fácil… lo dejaré pasar.
Felices Fiestas
Categorías: interesante, reflexiones |
3 comentarios
Diciembre 28th, 2007
Hace unos días tuve la desgracia de presenciar como unos datos de importante valor eran sobreescritos por una mala copia de seguridad, perdiéndose para siempre. Esto me llevó a investigar sobre como recuperar la información y lo cierto es que en un sistema de archivos EXT3 esto es una tarea bastante complicada.
Para los sistemas EXT2 existían varias utilidades capaces de recuperar la información (debugfs era una bastante buena), sin embargo, la forma de trabajar de los sitemas EXT3 (rellena con ceros el puntero hacia el archivo borrado) hace que este tipo de utilidades sean inservibles.
Una vez borrado un archivo la información sigue estando ahí, el problema es que no hay forma de localizarla, no podemos saber donde está, ni como está repartida entre los bloques. Simplemente sabemos que sigue estando en alguna(s) parte(s) del disco duro. Esto es un problema mucho mayor de lo que pudiera parecer ya que no sabemos cuando empieza un fichero y acaba otro, o mucho peor, no podemos saber si el fichero está en un grupo de bloques consecutivos o no. Recuperar archivos binarios en estas condiciones es impensable, sin embargo, recuperar archivos de texto es algo un poco más factible. Quizás no podamos recuperar el archivo como tal, pero sí que podemos leer su contenido y ya que los archivos de texto no suelen ser demasiado grandes, es posible que todo esté contenido en el mismo bloque (es decir, no lo encontraríamos disperso por el disco duro).
La estrategia para conseguir esto es volcar todo el texto de la partición afectada en un fichero y luego examinarlo en busca de las partes que nos interesen. Esto lo podemos conseguir con strings:
# strings /dev/sda7 > /ruta/hacia/archivo
Es recomendable almacenar el volcado en una partición distinta a la que queramos recuperar, ya que si no corremos el riesgo de sobreescribir los datos que estamos intentando salvar antes de haberlos leído.
Espero que esto os sea útil, pero lo mejor es tener las copias de seguridad siempre actualizadas.
Categorías: interesante, linux |
4 comentarios
