Escribí mi proyecto final de graduación implementando un wrapper genérico de conexiones que puede ser extendido para comprender y proteger protocolos específicos. Presenté mi proyecto en el YAPC::NA 2001, y publiqué un corto artículo en la revista ;login: de Usenix, en el número de Junio del 2002.

• Proyecto final completo (130 páginas, PDF)
• Proyecto final completo (convertido a HTML)
• Texto publicado en las memorias del YAPC::NA 2001 (PDF)
• Texto publicado en la revista ;login:, Junio de 2002 (PDF)
• Código de ProtoWrap 0.5, instalable como módulo de Perl. Hay pequeñas diferencias entre este código y la versión publicada en el proyecto final.

¿Buscas una solución de respaldos simple de implementar, con bajo uso de recursos, que te permita tener respaldos incrementales disponibles de inmediato? Rsync y las características del sistema de archivos de cualquier Unix pueden ser tu principal aliado - Preparé esta plática para el seminario Admin-UNAM de diciembre del 2005, organizado por el Departamento de Seguridad en Cómputo, DGSCA, UNAM.

• Presentación Magicpoint (fuente de la presentación, formato Magicpoint)
• Presentación Magicpoint (convertido a PDF)
• Script que ejecuta el cliente - Este script corre el cliente; es el que analizamos en el punto de la presentación donde menciono ¡vámonos para Emacs

Texto corto mencionando diversas herramientas que pueden ayudar a un administrador de sistemas implementar prevención de incidentes, monitoreo de red y detección de intrusos en Linux. Presenté esta plática en el seminario interno Admin-UNAM del Departamento de Seguridad en Cómputode la UNAM, en junio de 2005. Fue publicado además en la revista de agosto de 2005 de PC Magazine en español.

• Artículo completo (PDF)

Plática preparada para el IV Congreso Nacional de Software Libre en la Universidad Mayor, Real y Pontificia
de San Francisco Xavier de Chuquisaca, Sucre, Bolivia. Es una continuación a la plática de Seguridad en redes, aterrizando algunos de los conceptos a soluciones más concretas (aunque aún bastante genérico).
Presenté este trabajo en 2005 para el seminario interno Admin-UNAM del ; re-escribí el material como un artículo a texto completo, también disponible aquí.

• Presentación Magicpoint convertida a HTML
• Artículo en PDF, con la misma estructura general de la presentación, pero más apto para su lectura
• Presentación Magicpoint formato fuente Magicpoint, los esquemas en su formato fuente Dia

Presenté este tutorial en el Congreso de Seguridad de Cómputo DGSCA/UNAM 2003, menciono en ella las características básicas del funcionamiento de las redes Ethernet, qué es el sniffing, varios sniffers útiles para un administrador, y algunos consejos para protegernos de sniffers no autorizados en nuestra red.

• Artículo completo (formato PDF), apto para imprimir
• Artículo completo (formatoHTML), para leer en línea
• Artículo completo (documento fuente LyX), Para modificar/editar

Presenté esta propuesta de esquema de respaldo en el Congreso de Seguridad en Cómputo 2001, presenta una propuesta para la implementación de un esquema de respaldo remoto, cifrado, automático.

• Servidor y cliente de SOMBI

SOMBI: Still One More Backup Implementation

Gunnar Wolf
gwolf@campus.iztacala.unam.mx
Congreso de Seguridad en Cómputo 2001
UNAM FES Iztacala

Abstract:

Hay una gran cantidad de implementaciones ya existentes para llevar a cabo de manera automática en sistemas en red -- Por diferentes razones, ninguno de ellos me convenció para las necesidades (nada atípicas, en mi opinión) de mi situación. Lo que aquí presento es un esquema muy simple que permite hacer respaldos de manera automática sobre la red con cifrado y contemplando diferentes tipos de respaldo.

¿Qué hay de malo con los esquemas de respaldo existentes?

Si estoy proponiendo un nuevo esquema de respaldos, esto es porque los ya existentes tienen alguna carencia que no me permite resolver de una manera simple mis necesidades. Entonces pues, ¿qué hay de malo con los esquemas de respaldo que existen hoy?

1.1 Mis necesidades

...Que pueden no ser las de los demás, pero seguramente habrá alguien con necesidades similares

• Hacer los respaldos de manera periódica y automática
• Hacer los respaldos sobre la red
• Cifrar los respaldos conforme son realizados
• Almacenarlos en un medio que me proporcione acceso fácil, rápido y confiable
• Que sea simple y poco intrusivo, para cualquier administrador
• Que sea software libre

1.2 El medio donde se almacena el respaldo

¿Por qué no usar cintas DAT?

• Confiabilidad
• Costo
• Reusabilidad del medio
• Velocidad
• Compatibilidad entre plataformas

1.3 La transmisión de datos sensibles sobre la red

• ¿Hacernos de la vista gorda y pasarlo en claro? ¿''ocultarlo'' con gzip?
• ¿Cifrado en el transporte?
• ¿Cifrado en el archivo?
• Tiempo de procesador que esto ocupa

2 Consideraciones previas a SOMBI

2.1 Lo más común que he visto

• Directo a la cinta, conectada localmente
  • ¿Y si no tengo una cinta en esta computadora?
  • ¿Y si no confío en las cintas?
• Directo a cinta, en un host remoto
  • Típicamente con rsh -- Tremendamente inseguro!
  • ¿Y si no confío en las cintas?
• Respaldo local con tar o equivalente
  • Un respaldo debería ser remoto o desmontable...

2.2 Mi esquema previo - sus fuerzas y debilidades

• tar xf - /etc /home /var/mail | ssh $SERVER 'cat > respaldo'
• Funciona, pero
  • Requiere root tanto en cliente como en servidor
  • No es automatizable (¿pondrías tu contraseña de root en un script?)

3 Esquema operativo de SOMBI

3.1 Soporte a diferentes tipos de respaldo

• Como está en este momento, permite tres tipos de respaldo: Completo, de configuración y de datos de usuario. Ampliarlo, sin embargo, a que acepte otros tipos de respaldo es trivial.
• Las pruebas que he hecho son con tar, pero podemos usar algún otro método para archivar, siempre que permita enviar la salida a un flujo de datos, con modificar bkCmd

3.2 Cifrado del lado del cliente

• El cifrado se hace con un programa externo que nos permita trabajar sobre un flujo de datos
• GPG (versión GNU de PGP) parece ideal
  • Cifrado con llave pública: No es necesario siquiera poder descifrar el respaldo con la información contenida en el cliente ni en el servidor
  • GPG incluye compresión (probablemente gzip)
• Podrían usarse otros métodos -- Basta con modificar cryptCmd

3.3 Doble conexión

El proceso que sigue una conexión es:

1. El cliente se conecta al puerto indicado del servidor
2. El servidor verifica que la conexión venga de una dirección aprobada
3. El cliente abre un puerto aleatorio, e informa al servidor cuál puerto abrió
4. El servidor se conecta de vuelta con el cliente por este puerto
5. El cliente verifica que la conexión venga del servidor
6. El cliente envía el respaldo completo cifrado al servidor a través de este nuevo puerto
7. El servidor almacena los datos en un lugar predeterminado

Proceso a agregar próximamente:

• En el paso 3, enviar el puerto cifrado con una llave secreta que tengan tanto cliente como servidor
• En el paso 5, verificar no sólo por la IP, sino que por una cadena cifrada con la llave secreta, que es realmente el servidor.

3.4 Medio en el que se almacena el respaldo

• Se almacena en el disco duro de un servidor remoto
  • ¿Cuánto cuesta hoy en día un disco duro grande?
  • Velocidad, confiabilidad
• Se puede combinar con crontab para quemar un CD-ROM periódicamente
  • Hacer más granular lo que se graba -- ¿Necesitas grabar en CD TODO el sistema?
  • Los CD-Rs y CD-RWs son ya muy baratos

3.5 Seguridad implementada por el esquema

• Cifrado con GPG
• Spoofing difícil (aunque a estas alturas, aún no imposible)
• El respaldo es almacenado en un medio confiable
• El respaldo puede trasladarse sin mayor problema a un medio removible

3.6 Problemas con este esquema

• Está hecho para resolver mis necesidades, no cualquier necesidad
• Costo de disco duro para respaldos masivos
• No contempla (nativamente) guardar respaldos en medio removible
• Estando cifrado con GPG, un bit corrupto puede hacer inútil al respaldo entero
• Es una idea nueva y, por tanto, no del todo confiable

Esta plática la dí en el Congreso GNU/Linux 2001 en Jalapa, Ver., en septiembre del 2001. En este artículo muestro diferentes características y recomendaciones de seguridad utilizando los diferentes sistemas operativos y herramientas libres.

• PDF (apto para imprimir)
• HTML (apto para consultar en línea)
• Fuente en LyX (apto para editar o modificar)

De nueva cuenta, me invitaron a participar en el Admin-UNAM del Departamento de Seguridad en Cómputo de la UNAM, esta vez en abril del 2001. El tema expuesto en esta ocasión: Recomendaciones de seguridad en una instalación de Linux. Cómo hacer que un Linux recién instalado sea una presa muy
difícil para cualquier atacante.
Este mismo material, aunque bastante ampliado, lo presenté también como tutorial en el Congreso
de Seguridad en Cómputo 2001, organizado también (claro está) por el DSC de la UNAM.

• PDF (apto para imprimir)
• HTML (apto para consultar en línea)
• Fuente en LyX (apto para editar o modificar)

Plática que dí acerca de esta herramienta en el seminario Admin-UNAM del Departamento de Seguridad en Cómputo de la UNAM en septiembre del 2000.
Logcheck es una herramienta encargada de revisar periódicamente las bitácoras del sistema y reportar al administrador lo que sea -según patrones predefinidos por el administrador- importante.

• Versión HTML

Plática que dí acerca de esta herramienta en el seminario Admin-UNAM del Departamento de Seguridad en Cómputo de la UNAM en septiembre del 2000.
PortSentry es una herramienta que permite la fácil detección de barridos de puertos y tiene la capacidad de actuar de inmediato al detectarlos.

• Versión HTML

Presentado el 30 de marzo del 2000 en el CECEC 2000 en la ESIME Culuhacan

• Presentación completa (HTML)

SmbGate es un pequeño programita escrito en Perl (usando el framework Embperl) que permite a los usuarios conectasre a sus directorios raiz de un servidor SMB (sea Samba sobre algún Unixoide o Windows), implementando acceso de sólo lectura, sobre una interfaz Web

Copyright (c) 2003,2005 Gunnar Wolf - gwolf@gwolf.org

RAZONES

Comencé a usar mutt como mi lector de correo hace un par de meses. Una de las características que más me gustaron de mutt es que los mensajes normalmente aparecen ordenados por hilo - esto ayuda realmente a seguir una conversación larga en una lista muy activa!

Para preservar el hilado de los mensajes, decidí archivar todos mis mensajes viejos - claro, tal como acostumbran hacer los usuarios de mutt. Cada lista va para un folder diferente, y la vida es bella.

Sin embargo, la vida no era perfecta. Después de un par de semanas, algunas de mis listas tenían tanto tráfico -con más de 2000 mensajes archivados- que a mutt le tomaba demasiado tiempo ya abrirlos. Y si bien parte de la culpa puedo echársela a que uso buzones en formato mbox, el cambiar a maildir no haría más que posponer este mismo problema por un par de semanas. Y no quería cortar artificialmente el buzón cada cierto tiempo, pues perdería los beneficios de mis queridos hilos.

Me encontré con el maravilloso y tremendamente completo módulo de Perl Mail::Box, y me dí cuenta que mover hilos completos era muy simple, así que escribí este programita que expirara hilos en vez de mensajes individuales.

USO

El uso es muy simple. Antes que nada, como siempre:
eot -h
te dará una lista de las opciones de EOT, todas ellas opcionales (aunque usualmente querrás especificar al menos -f y -F).

Las opciones válidas son:

eot -f <from_mailbox> -t <from_type> -F <to_mailbox> -T <to_type> -p <period>
All arguments are optional.
opt  description                                        default
======================================================================
-f   Which source mailbox to use                        mailbox
-t   What format is this mailbox in (mbox, maildir, mh) mbox
-F   Which destination mailbox to use                   mailbox.arch
-T   What format is this mailbox in (mbox, maildir, mh) mbox
-p   Period of time to declare a thread as old, in days 7
-v   Whether to report work statistics to STDOUT        0

-f and -F se refieren a un buzón -un archvio si es tipo mbox o un directorio si es tipo maildir o MH- en el directorio local, o un path completo o relativo al buzón en cuestión.

-t y -T indican el tipo de buzón a abrir - mbox, maildir or mh.

-p indicates how old (in days) should the last message in a thread be
for the whole thread to be considered inactive.

Si no especificas -v, EOT correrá en silencio. Si especificas -v un
corto resumen de actividad aparecerá después de correr.

LICENCIA

EOT is está cubierto por la GNU GPL versión 2 o superior, a tu discreción.
El texto completo de la GNU GPL puede ser encontrado aquí.

REQUISITOS

EOT fue escrito en Perl, y por tanto requiere Perl (versión 5 o
superior). Además de esto, EOT requiere de los siguientes módulos de
Perl:
Mail::Box (probado con 2.038)
Date::Parse - parte de TimeDate (probado con 1.1400)

Puedes encontrarlos en el CPAN. Si usas un sistema Debian, están respectivamente en los paquetes libmail-box-perl y libtimedate-perl.

AUTOR

EOT fue creado por Gunnar Wolf (gwolf@gwolf.org) en mayo del 2003. Puedes usarlo libremente para el propósito que sea, siempre que te
atengas a la licencia GNU GPL.

BAJARLO

Ok, veo que te interesó ;-)

Puedes bajar la versión 1.1 de EOT aquí.

Un sistema que hice cuando trabajé para la FES Iztacala. Ayuda a los administradores de redes en su ardua labor relacionando direcciones IP y MAC, generando configuraciones para el servidor de DHCP y ARP.
Varios años más tarde, ya trabajando en el IIEc UNAM, prácticamente lo re-escribí completo, más limpio, con una capa orientada a objetos, utilizando Template Toolkit para la presentación, y como módulo de Apache (con mod_perl). Ambas versiones son funcionales y usables - Aquí están ambas. Ambas están, sin embargo, en un estado de "snapshot", con pequeñas omisiones en lo que concierne a funcionalidad y documentación.
IPManage (versión de 2003, orientada a CGI)
IPManage (versión de 2007, OOP, basada en mod_perl)