security

warning: Creating default object from empty value in /home/gwolf/drupal6/modules/taxonomy/taxonomy.pages.inc on line 33.

Seguridad en Redes: ¿Qué es? ¿Cómo lograrla?

Submitted by gwolf on Sun, 02/10/2008 - 09:01
Written in...: 
2002

I presented this talk ath the II Computer Systems Engineering Conference at Nuevo León Technological Institute. Here I review general security concepts, explaining to a non-expert audience various important factors that as security experts -and as conscious users in general- we must take into account.

Resumen: 

Presenté esta plática en el II Congreso de Ingeniería en Sistemas Computacionales del Instituto Tecnológico de Nuevo León. Reviso conceptos generales de seguridad, explicando a un público no iniciado en el tema los diversos factores que como profesionales en la seguridad -y como usuarios conscientes en general- debemos tener en cuenta.

Los sniffers y las redes Ethernet

Submitted by gwolf on Sun, 02/10/2008 - 08:10
Written in...: 
2003

I presented this tutorial at Computer Security DGSCA/UNAM 2003 Conference. I talk about the basic characteristics for an Ethernet network, what is sniffing, some sniffers useful for a network administrator, and some advices for protecting against unauthorized sniffers in our network.

Resumen: 

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.

Security in Perl scripts / Seguridad en scripts de Perl

Submitted by gwolf on Sun, 02/10/2008 - 00:16
Written in...: 
2002

I presented this tutorial at Congreso de Seguridad en Cómputo 2000, and later rewrote it (and moved it to a free, portable format) for Días de Software Libre at Guadalajara, May 2002. In this tutorial, I review some important key points not to fall in security errors while programming with Perl. I later adapted it together with a coworker, Alex Juárez, and we presented it in English at YAPC::Europe 2002. Here you will find this text both in Spanish and in English.

Resumen: 

Un tutorial que presenté para el Congreso de Seguridad en Cómputo en noviembre del 2000, y tras reescribirlo en un formato libre y portable, lo presenté de nuevo en los Días de Software Libre en Guadalajara, mayo del 2002. Lo adapté y traduje junto con mi compañero de trabajo Alex Juárez, y lo presentamos en el YAPC::Europe::2002. Reviso aquí una serie de puntos importantes para no caer en importantes errores de seguridad al programar con Perl. Está tanto en inglés como en español.

SOMBI - Still One More Backup Implementation

Submitted by gwolf on Sat, 02/09/2008 - 21:09
Written in...: 
2001

I presented this proposal about a backup system in the Computer Security 2001 Conference. Here I present a proposal for the implementation of a cyphered, automatic remote backup scheme.

Resumen: 

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.

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

Implementación de seguridad con sistemas operativos y herramientas libres

Submitted by gwolf on Sat, 02/09/2008 - 20:56
Written in...: 
2001

I gave this talk at the GNU/Linux 2001 conference in Jalapa, Veracruz, in September 2001. In this article I show different characteristics and security reccomendations using free operating systems and tools.

  • PDF (fit for printing)
  • HTML (fit for online viewing)
  • LyX sources (for editing or modifying)
Resumen: 

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)

Recomendaciones de seguridad en Linux

Submitted by gwolf on Sat, 02/09/2008 - 16:44
Written in...: 
2001

Once again, I was invited to the seminar, with Computer Security Department of UNAM, this time in April 2001. The topic this time: Security guidelines in a Linux installation. How you can make a newly made Linux installation a difficult target for an attacker.
This same material, although updated and enhanced, was also presented as a tutorial at Congreso de Seguridad en Cómputo 2001, also organized (of course) by DSC, UNAM.

  • PDF (fit for printing)
  • HTML (for online viewing)
  • LyX sources (if you want to edit or modify it)
Resumen: 

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)

Logcheck

Submitted by gwolf on Sat, 02/09/2008 - 16:33
Written in...: 
2000

Talk I gave at the Admin-UNAM seminar, with Computer Security Department of UNAM, in September 2000.
Logcheck is a tool that checks periodically the system's log files, reporting to the administrator whatever is -according to operator-defined patterns- important.

Resumen: 

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.

Portsentry

Submitted by gwolf on Sat, 02/09/2008 - 16:18
Written in...: 
2000

Talk I gave at the Admin-UNAM seminar, with Computer Security Department of UNAM, in September 2000.
PortSentry is a tool that permits easy detection of port scanning, and has the ability to act immediately upon detection.

Resumen: 

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.

Scripts de seguridad en Perl

Submitted by gwolf on Tue, 02/05/2008 - 21:59
Written in...: 
2000

Tutorial I presented at Computer Security conference 2000, giving many examples of small Perl scripts that can help improve security at a site.

Resumen: 

Tutorial que presenté en el congreso Seguridad en Cómputo 2000, dando varios ejemplos de pequeños scripts en Perl que pueden ayudar a la seguridad de un sitio.

Infraestructura de llave pública

Submitted by gwolf on Tue, 02/05/2008 - 21:42
Written in...: 
2000

The full text for the lecture I gave for the GASU seminar organized by Computer Security
Department
at UNAM in july, 2000.

Resumen: 

El texto completo de la conferencia que dí para el Seminario GASU del Departamento de Seguridad en Cómputo de la UNAM en julio del 2000.

El arte de la administración de sistemas

Submitted by gwolf on Mon, 02/04/2008 - 15:01
Written in...: 
2000

Presented on March 30, 2000, at CECEC 2000, ESIME Culuhacan

Resumen: 

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

Security / Seguridad

Submitted by gwolf on Mon, 02/04/2008 - 14:52

An important note

Although I am interested and work in different computer security-related projects, I am not affiliated to any kind of underground movement.
I know that there are many underground groups which have made important contributions to computer security, I don't think that attacking from the shadows to vulnerabilities is not the way to go - The correct way is, instead, to raise conciousness in users, administrators and programmers on how things should be done. To whoever can contribute in further ways, with their own research and development, please go ahead. But everything, everything in an open and public way, and respecting above all other things other people's rights.

Resumen: 

Nota importante

Si bien yo me intereso y trabajo en diferentes proyectos de seguridad en cómputo, no estoy afiliado a ningún tipo de movimiento underground.
Si bien hay muchos grupos underground que han hecho importantes contribuciones a la seguridad en cómputo, el camino a seguir en mi opinión no es el del ataque oculto a las vulnerabilidades, sino que el de conicentizar a usuarios, administradores y programadores de cómo debemos hacer las cosas. Para quien tenga la capacidad de contribuir no sólo con concientización sino que con desarrollo propio, adelante. Pero todo, todo de manera abierta, pública, y respetando por sobre de todas las cosas los derechos de los demás.

( categories: )

Aprovechando a Debian para la administración de sistemas

Submitted by gwolf on Mon, 02/04/2008 - 00:09
Written in...: 
2006

Beyond what the Debian policy gives us, a highly coherent system in which everything is in its place and works as it should (for what we the system administrators are really thankful for), we can find a great amount of tools for easing the homogeneity in the administration both in the planning of its package management system as in many packages we have at our disposition. We will go through this, as well as the process of creating .deb packages, beyond the basic instructions. This talk was originally prepared for CICOL, June 2006

Resumen: 

Más allá de lo que ya nos dan las políticas de Debian, un sistema altamente coherente en el cual todo está en su sitio (lo cual bendecimos los administradores de sistemas), tanto en la planeación de su sistema de paquetes como en varios paquetes que tenemos a nuestra disposición encontraremos una gran cantidad de herramientas para facilitar la homogeneidad en la administración de sistemas. Revisamos algunas de ellas, así como el proceso de creación de paquetes .deb, más allá de las instrucciones básicas. Preparado originalmente para el CICOL, junio 2006

TEPATCHE - OpenBSD automatic system patcher / Parchador Automático de sistema OpenBSD

Submitted by gwolf on Sun, 02/03/2008 - 12:57
Written in...: 
2003

RATIONALE

OpenBSD is a stable, robust and secure operating system. Systems administrators running OpenBSD tend to be also more security conscious than administrators running other operating systems. Nevertheless, patching an OpenBSD system can be a tedious process for many people. If a person manages multiple OpenBSD servers, patching each of them can be a long and repetitive task, ideal for automatization.

Resumen: 

RAZONES

OpenBSD es un sistema operativo estable, robusto y seguro. Los administradores de sistemas que corren OpenBSD tienden a ser mas conscientes de la seguridad que los administradores corriendo otros sistemas operativos. En ocasiones, parchar un sistema OpenBSD puede volverse un proceso tedioso para muchas personas. Si una persona se encarga de muchos servidores OpenBSD, el parchar cada uno de ellos puede ser una tarea larga y repetitiva, ideal para automatizarla.
Tepatche revisará periódicamente el sitio FTP que se le indique, y si hay un nuevo parche que pueda ser aplicado, lo descarga, aplica, compila e instala. Tepatche mantiene una pequeña base de datos de estado para saber en que estado se encuentra cada uno de los parches del sistema.

REQUISITOS

  • Una instalación completa de OpenBSD (incluyendo el código fuente en /usr/src y los fuentes del kernel en /usr/src/sys). Tepatche fue probado con OpenBSD versión 3.1, pero mientras se diseñaba, los parches para el 2.9 y 3.0 también fueron estudiados y, como el formato es el mismo, deben de funcionar. Es importante mencionar que la versión 2.9 y versiones mas viejas ya NO SON MANTENIDAS, no hay nuevos parches que sean liberados para ellos. Es importante que se haga una actualización en caso de que estes corriendo una versión vieja.
  • Tepatche usa el módulo de Perl Net::FTP. Puedes instalarlo desde los ports (p5-libnet) ó desde CPAN. Tepatche fue diseñado y probado con p5-libnet-1.0901, la versión de los puertos 3.1.

NOTAS

  • Tepatche esta liberado bajo la licencia BSD - Leer el archivo COPYING
  • Este es código EXPERIMENTAL. A mi me funciona. Sin embargo, es código hecho para ser corrido como root y para modificar binarios vitales del sistema, y un error de programación puede llevar a consecuencias desastrosas.
  • Tepatche asume que los parches publicados en el ftphost especificado son confiables. Si el ftphost (normalmente ftp.openbsd.org o uno de sus espejos) fueran comprometidos, cualquier cosa pudiera pasar. Si Tepatche instala un parche comprometido, puees revertirlo con la opción de parche -R (ver man patch(1)). Hay que notar que Tepatche no correrá cualquier comando que encuentre en un parche, solo los que reconozca... pero hay mucho espacio ahí.
  • Si el aplicar un parche requiere una compilación del kernel, el administrador del sistema DEBE HACERLO MANUALMENTE. Tepatche parchará los fuentes, pero compilar el kernel involucra muchos pasos que requieren que se opere manualmente.
  • Tepatche SOLAMENTE parchará el sistema base - Si usas ports extra, estos NO serán parchados. Por favor véase las notas referentes a los ports y a la auditoría de seguridad en: http://www.openbsd.org/ports.html

USO

Tepatche consiste en un archivo de programa (/usr/local/sbin/tepatche), un archivo de configuración (/etc/tepatche.conf) y un directorio de datos (/var/db/tepatche). El archivo de configuración contiene los siguientes campos:

  • ftphost: Servidor FTP a conectarse (ej: ftp.openbsd.org)
  • ftpdir: La base del directorio FTP para los parches (ej: /pub/OpenBSD/patches/3.1)
  • ftppasv: Donde el modo pasivo FTP es requerido (1) o no (0)
  • ftplogin: usuario y password para ingresar (separado por una coma, ej: anonymous, gwolf@gwolf.cx)
  • archs: Lista separada por comas de arquitecturas a descargar (ej: i386, common) Por favor, recuerda incluir common!
  • patchdir: Donde los parches serán almacenados en nuestra computadora (ej: /var/db/tepatche)
  • statusfile: Localización del archivo de estado (ej: /var/db/tepatche/statusfile)

Con este archivo en su lugar, Tepatche corre simplemente sin argumentos, solo /usr/local/sbin/tepatche. Sugiero que lo corras desde tu crontab (ver man crontab(5)). Sugiero correrlo una vez al día, cuando mucho una vez por cada hora - por favor no inundes ftp.openbsd.org con peticiones cada minuto ;-)

ARCHIVO DE ESTADO

Tepatche mantiene la información que necesita acerca del estado del sistema en el 'statusfile' (por default, en /var/db/tepatche/statusfile). Este es un archivo de texto plano con el siguiente formato:
<descriptor>::<status>
Donde 'descriptor' es una cadena alfanumérica, y 'status' es un número de estado válido. Los números válidos son:

  • 1: nuevo - El parche acaba de ser bajado.
  • 2: aplicado - El parche ya fue aplicado al árbol de fuentes
  • 3: construído - Los binarios relevantes ya fueron generados en el árbol fuente
  • 4: instalado - Los binarios fueron ya instalados en su lugar. El parche ya fue completamente instalado.
  • 5: kernel - El parche requiere recompilar el kernel. Cuando tepatche llega a este estado, el parche fue aplicado, pero aún no ha sido construído..
  • 10: error - Ocurrió un error en algún punto del proceso de parche

El descriptor usualmente llevará el formato <arch>/<num>_<description>.patch - Indica la arquitectura para la cual fue creado, el número consecutivo de parche, una muy corta descripción acerca de su función, y el sufijo '.patch'. Esta es la nomenclatura estándar que sigue el equipo de Open:BSD. Un nombre ejemplo podría ser:
common/001_sshafs.patch
Esto indica que el parche será aplicado a todas las arquitecturas (common), que es el primer parche producido para esta versión del sistema (001), y que corrige problemas relacionados con 'sshafs'.
Si quieres modificar este archivo (claro está, BAJO TU PROPIO RIESGO), puedes seguir estas convenciones para indicar a Tepatche el nuevo estado del parche. Por ejemplo, en la versión 3.1 de OpenBSD apareció un bug muy peligroso en OpenSSH. El equipo de OpenBSD sugirió actualizar de inmediato a OpenSSH 3.4. Posteriormente, para la gente que no actualizó, publicaron un parche (common/006_sshpreauth.patch). Mucha gente ya instaló el árbol de 3.4, con lo que modificaron manualmente el directorio /usr/src/usr.bin/ssh lo cual hace necesario editar /var/db/tepatche/statusfile y reemplazar
common/006_sshpreauth.patch::10
por
common/006_sshpreauth.patch::4

POR HACER

Al menos:

  • Hacer la salida mas amigable (a medio-hacer)
  • Manejo mas confiable de errores (a medio-hacer)
  • (tal vez) incluir un mecanismo de compilación del kernel
  • Probar, probar, probar

DESCARGAS

Puedes obtener Tepatche (actualmente version 0.85) Justo aqui.
Si te interesa leer el artículo publicado en la edición de diciembre del 2003 de SysAdmin, aquí lo tienes.

¿POR QUE TEPATCHE?

Tepatche es una bebida ligeramente alcohólica en México, en donde yo vivo y donde el programa fué concebido. Tepache es el resultado de
fermentar piña en agua. Tomado de http://www.fao.org/docrep/x0560e/x0560e09.htm :
Tepache es una bebida ligera, refrescante preparada y consumida en todo México. En el pasado, el tepache era preparado con maíz, pero en la actualidad varias frutas como la piña, manzana y naranja son usados. La pulpa y el jugo de la fruta son puestos a fermentar por uno o dos días en agua con algo de azucar morena. La mezcla es puesta en barriles de madera sin tapa llamados "tepacheras", que se cubren con trapos queseros. Después de uno o dos días, el tepache es una dulce y refrescante bebida. Si se deja fermentar por mas tiempo, se convierte en una bebida alcohólica y después en vinagre. Los microorganismos asociados con el producto incluyen al Bacilo Sutbtilis, Torulopsis insconspicna, Saccharomyces cerevisiae y Candida queretana (Aidoo, 1986).
Si eres curioso, puedes encontrar recetas de como preparar tepache (en español) en http://www.chi.itesm.mx/chihuahua/arte_cultura/cocina/bebidas/tepache.html o http://mexico.udg.mx/cocina/bebidas/tepache.html

AGRADECIMIENTOS

Primero y sobre todo, quiero agradecer al equipo de OpenBSD por la increíble cantidad de trabajo que hay puesto en este proyecto.
En menor escala, Tepatche no hubiera sido posible sin la ayuda de OpenBSD México. En este proyecto específico, recibí una gran ayuda de Alex Juárez, César Yáñez y Karl Heinz Holtschmit.
Por supuesto, quiero agradecer a mi lugar de trabajo, UNAM FES Iztacala, por permitirme en trabajar en seguridad y software libre por casi 3 años - Y espero sean muchos mas.

Syndicate content