SysAdmin

Monitoreo de PostgreSQL con Munin

Submitted by gwolf on Thu, 02/02/2012 - 14:54
Wolf G.  2011.  Monitoreo de PostgreSQL con Munin. Revista Cubana de Ciencias Informáticas. 5:1-8.

Los muchos significados del «cómputo en la nube»: Desmitificando el concepto

Submitted by gwolf on Fri, 01/14/2011 - 11:15
Wolf G.  2010.  Los muchos significados del «cómputo en la nube»: Desmitificando el concepto. Software Gurú. :48-49.

Uno de los términos ampliamente en boga en nuestro campo hoy en día es el cómputo en la nube. Tan en boga que me parece que se ha convertido en una palabra mágica, bastante hueca y sintomática de querer parecer en sintonía con los últimos desarrollos tecnológicos, sin comprenderlos en realidad. Además, al ser una frase que de golpe comenzó a escucharse con tanta insistencia, asumimos que es una estrategia nueva, una idea posibilitada por los nuevos avances tecnológicos — Y esto dista de ser el caso. En esta columna busco clarificar los conceptos y tipos básicos de cómputo en la nube, sus principales ventjas y desventajas, y brevemente encontrar paralelos con casos documentados de estos ”novedosos” conceptos

No critico, ojo, a las estrategias que están detrás de este sonoro término — Muy por el contrario, resultan muy convenientes a la hora de implementar, y como profesionales del desarrollo de software tenemos la obligación de estar familiarizados con ellas. Lo que critico es el abuso de un término ambíguo, que suele poner en problemas a los implementadores, al no estar claramente comprendido.

La mayor parte de las referencias que consulté mencionan a tres capas o niveles principales: El software –o la aplicación– como un servicio (Software as a Service, SaaS), la plataforma como un servicio (Platform as a Service, PaaS) y la infraestructura o el hardware como un servicio (Infrastructure as a Service, IaaS). Mi punto de vista, es que más que un nivel distinto, IaaS es un conjunto de cualidades adicionales que dan valor agregado a una oferta de PaaS.

SaaS: Bloques de construcción

Cuando uno de nuestros sistemas utiliza un API público remoto, o cuando para nuestro flujo de trabajo empleamos a una aplicación que reside y es administrada fuera de nuestra organización, estamos empleando SaaS. Nuestro proveedor puede cobrar su servicio de diversas maneras: A través de una renta directa, requiriendo del despliegue de publicidad, recibiendo autorización para recolectar nuestra información y hacer minería de datos sobre de ella — Hay una enorme variedad de esquemas, que refleja la gran variedad de niveles de integración que se puede dar a los servicios.

Notarán que la principal diferencia con los esquemas tradicionales cliente-servidor con que hemos trabajado desde hace décadas es el uso explícito de un proveedor externo — Sin embargo, técnicamente, nuestros sistemas no seguirán una lógica o un proceso de desarrollo diferente de como lo vienen haciendo por décadas.

Al mismo tiempo, sí hay una importante diferencia: Al no controlar nosotros el proceso que ocurre dentro de uno de nuestros subsistemas, nos vemos forzados a hacer bien lo que ya deberíamos estar haciendo: Implementar una separación limpia de responsabilidades entre los componentes, utiilzar exclusivamente las interfaces publicadas explícitamente — No brincarnos las capas de abstracción, como muchas veces estaríamos tentados a hacerlo en un proyecto meramente interno.

Hay un punto que no podemos perder de vista cuando empleamos un servicio de aplicaciones como parte de nuestra infraestructura en sistemas: Al depender de un tercero, ponemos en sus manos parte importante de nuestras promesas (y, por tanto, requerimientos), en tanto a disponibilidad, protección de datos y continuidad de la operación. Tocando el primer punto, resulta natural: Una falla en el servicio de cualquiera de nuestros proveedores de aplicaciones llevará a que nuestro sistema presente información incompleta o errónea a sus usuarios.

Respecto al segundo, no sólo debemos tener en cuenta las implicaciones directas (el proveedor tendrá acceso a todos los datos específicos que le enviemos para operar), sino que las indirectas: Todo ataque por medio del cual un agente hostil pueda llevar a cabo recolección de información sobre de nuestros proveedores resultará en la probable divulgación de información interna nuestra, e incluso el mismo proveedor puede estar realizando un seguimiento estadístico de nuestros patrones de uso, revelando mucho más de lo que podríamos querer darle.

En tanto a la continuidad de operación, si el proveedor del servicio decide cambiar los términos bajo los cuales brinda sus recursos, o si sencillamente deja de operar, podemos quedar sin una alternativa disponible para parte importante de nuestro flujo de trabajo.

Como corolario de la dependencia de terceros, al depender de aplicaciones como servicio perdemos la capacidad de planear las actualizaciones de nuestra infraestructura — Al depender de proveedores externos, en el momento en que cualquiera de sus APIs cambia, nos vemos forzados a actualizar de inmediato. Nuestros servicios en producción pueden fallar, y el mero concepto de rama estable pierde buena parte de su atractivo1.

PaaS+IaaS: Flexibilidad en el uso de recursos

Mientras que en el apartado anterior partíamos de que –desde el punto de vista del usuario– hay una aplicación central que corre en sus instalaciones y consume procesamiento realizado por componentes distribuídos por el mundo (”en la nube”), aquí la aplicación completa será desplegada en el proveedor de servicios. El usuario deja de emplear un servidor –o una granja de servidores– para consumir sólo los recursos. Y, consecuentemente, el esquema de utilidad para un proveedor de servicios bajo esta modalidad puede ir desde la renta a costo fijo hasta un cobro por uso de recursos, típicamente permitiendo reconfiguraciones dinámicas del paquete (del conjunto máximo de recursos) como respuesta a la demanda del sistema.

La justificación detrás de este concepto es que los servidores ”en casa” representan un gasto demasiado grande — Compra y actualización periódica de equipo, consumo eléctrico, uso de espacio físico y de ancho de banda, siendo que las instalaciones de la mayor parte de los usuarios no cuentan siquiera con un centro de datos. Además, todo servidor debe ser adquirido contemplando la carga estimada que sostendrá, pero contemplando un espacio para sobreconsumo en picos de actividad no planificable. En cambio, un proveedor masivo de servicios balancea el exceso de demanda de un usuario con la reducción de demanda de otro, permitiendo un menor sobredimensionamiento — Y una reducción neta de precios.

Nuevamente, apreciarán que la idea no es nueva — Los proveedores de presencia o de hosting existen desde hace muchos años en Internet. Más allá aún, precisamente este esquema fue planteado a mediados de los 1960, cuando fue desarrollado el sistema MULTICS2.

La principal diferencia con el esquema tradicional de renta de servidores es que bajo este esquema, el usuario deja de ser responsable de la administración incluso del servidor en el que se ejecutarán sus aplicaciones; el proveedor de servicios ofrece una cartera de plataformas administradas. Las plataformas pueden ser desde aplicaciones medianamente complejas, como plataformas Web que llevan un grado no trivial de configuración y representan una solución completa e integrada, hasta marcos para el desarrollo de sistemas (como Rails, Struts, Django, GWT), para los cuales los clientes sólo proveen el código específico de su aplicación, y aprovechan todo el andamiaje común que ya existe para una amplia base de clientes.

Respecto a consideraciones de seguridad y confiabilidad: Si bien al emplear PaaS no caemos ya en la trampa descrita en el primer apartado respecto a emplear código del cual no tenemos más conocimiento que el API, éste esquema sigue depositando todos nuestros datos en control del proveedor, en infraestructura compartida, con lo cual la probabilidad de que un ataque a un sistema sin relación aparente con el nuestro puede dar a un intruso acceso pleno a nuestra información.

El riesgo de que el proveedor cambie sus políticas de cobro a un esquema que no nos convenga se reduce también fuertemente, dado que en principio tenemos todo lo necesario para replicar la instalación con cualquier otro proveedor, o incluso migrar a una solución ”en casa”. Sin embargo, seguiremos sujetos a los días bandera de actualización forzada, dado que el proveedor típicamente ofrecerá la misma versión base a todos sus clientes — Y este factor puede dificultarnos una migración entre proveedores.

Hablando meramente de la conveniencia: Podemos enviar a uno de nuestros sistemas a la nube dados sus requisitos de almacenamiento de información, o de ancho de banda. Ahora bien, ¿cómo estamos realizando nuestros respaldos? Para poder hacer frente a contingencias, contar con una estrategia de respaldos buena y probada es mucho más importante aún que cuando hablamos de despliegues en infraestructura propia.

Por último, respecto al IaaS: Este resulta el más nebuloso y ambiguo — Ya no se trata de sistemas o entornos para que éstos se ejecuten, sino que de recursos de cómputo que están a nuestra disposición: Espacio en disco o en memoria, ”ticks” de procesador, ajuste de ancho de banda, como componentes discretos y ajustables en vivo — Atributos que se apoyan fuertemente en la virtualización para poder ser desplegados y controlados.

Hay quien incluye la virtualización de escritorios dentro de la definición de IaaS, pero si mucho, eso debe ser visto como consolidación de recursos y mejoría en el aprovechamiento de recursos, pero por calidad en el servicio debe hacerse utilizando recursos internos a la organización — Y por tanto, se aleja de las definiciones básicas de en la nube.

Llevamos años haciendo cómputo en la nube de un tipo o de otro. Al desmitificarlo un poco, espero abonar a una mejor utilización. Y al hablar acerca de los nada ignorables riesgos que conlleva, apunto a la cautela que debemos tener al adoptarlo, no entrar de lleno sólo porque es la moda.

  • 1. Podemos ver un buen ejemplo de esto cuando Twitter cambió su esquema de autenticación en agosto de este año, obligando a cientos de aplicaciones a impulsar la migración a nuevas versiones — http://blog.twitter.com/2010/08/twitter-applications-and-oauth.html
  • 2. El sistema operativo MULTICS partía del planteamiento de que el cómputo se convertiría en un servicio provisto centralmente, como la electricidad o el teléfono. http://www.multicians.org/
( categories: )

Arquitecturas de paquetes al rescate

Submitted by gwolf on Fri, 06/18/2010 - 07:35
Wolf G.  2010.  Arquitecturas de paquetes al rescate. Software Gurú.

Modularización: Arquitecturas de paquetes al rescate

Convirtiendo a la hidra en nuestra aliada

En el número 27 de Software Gurú, Agustín Ramos presentó un artículo acerca de estrategias para lograr una modularización efectiva en Java. Varios de los puntos de su artículo me llevaron a dedicar la presente columna a explicar a qué llamamos una distribución de Linux, y cuál es su relación –y la solución que ofrece– a los problemas derivados de la complejidad derivada de la modularización, que bien describió Agustín.

Como deben ya saberlo, a diferencia de otros sistemas operativos, el entorno operativo completo al que normalmente nos referimos como Linux no es desarrollado por un sólo grupo, ni sigue un roadmap, criterios o visión en común. Mucho se ha argumentado acerca de las características que diferencían a los proyectos desarrollados desde planteamientos libres de aquellos desarrollados siguiendo metodologías tradicionales — No abordaré dicha discusión en este momento. Sin embargo, no quiero dejar de aprovechar la oportunidad de tener un artículo escrito por un colega en esta revista para ilustrar cómo abordamos la relación entre proyectos independientes –que logran una complejidad de miras mucho mayor que cualquier instancia de conjuntos de módulos desarrollados en casa– en el Software Libre, por qué enfatizamos tanto en lo prevalente que resulta dicha modularización, y cómo nos enfrentamos a su inherente complejidad.

Los sistemas basados en Linux son estructurados, pues, en distribuciones. Una distribución es un conjunto de programas –típicamente del órden de miles– que, entre todos, presentan la funcionalidad que un usuario espera ya no sólo de un sistema operativo sino que de todo un entorno operativo integrado. Además, se encargan de gestionar las relaciones de dependencia entre dichos programas, y resolver dichas dependencias, para facilitar al usuario la instalación, remoción y actualización de software.

Una instalación mínima de cualquier distribución de Linux no tiene menos de un par de centenares de paquetes individuales. El núcleo Linux, por sí mismo, no representa más que la interfaz más básica para presentar una abstracción del hardware ante los programas que corren sobre él. Formalmente, al mencionar Linux ni siquiera nos referimos a la interfaz de línea de comandos (misma que generalmente es provista por los paquetes bash, dash o sash, dependiendo de las necesidades del administrador). Son en realidad contados los paquetes que no dependen más que de paquetes esenciales. Toda distribución define un pequeño conjunto (decenas) de programas que es fundamental tener instalados como base para cualquier otro, conjunto mínimo que asumimos que siempre estará ahí para asegurarnos la funcionalidad mínima.

Si bien las primeras distribuciones tuvieron por objetivo facilitar la instalación de un sistema basado en Linux a usuarios con menor involucramiento técnico, y fueron instrumentales en la primer ola expansiva de usuarios que fuimos adoptando Linux hacia mediados de los 1990, han trascendido ya a éste rol para dar respuesta al infierno de dependencias al que se refiere en su texto Agustín Ramos: Hacia fines de los 1990, aproximadamente cuando todas las distribuciones comenzaban a contar en miles los paquetes independientes que ofrecían, comenzó a hacerse obvio que no bastaba con que cada paquete indicara de qué otros paquetes dependía (incluyendo, claro está, la información de versiones pertinente), sino que era necesario contar con una arquitectura de paquetes: Un esquema orientado a depósitos y no a paquetes individuales, que se encargara de resolver las dependencias cada que el administrador instalara o eliminara un paquete. La primera arquitectura fue introducida por la distribución Debian, bajo el nombre de apt: A Package Tool. Es definitivamente gracias a apt que, al día de hoy, la versión de desarrollo de Debian cuenta con 15640 paquetes fuente independientes, que resultan en 27886 paquetes binarios, cubriendo prácticamente todas las áreas de necesidad en cómputo, tanto a nivel de aplicaciones como de bibliotecas.

A diferencia de otras arquitecturas previas, como los ports de los Unixes BSD, Apt está además construido basado en el manejo de depósitos múltiples. Esto significa que, además de servirme para instalar los paquetes oficiales de la distribución, nos permite definir depósitos adicionales con el software que desarrollemos localmente, así como de paquetes adicionales que preparemos localmente para uso en nuestra organización.

Con esto como introducción, veamos cómo ésto se aplica al texto de Agustín. Por razones de espacio, me enfoco a cómo éste esquema reduce fuertemente los efectos negativos de la modularización, permitiendo a los desarrolladores crear software más robusto y temer menos a esta tan dificil de conciliar fuente de dolores de cabeza.

Demasiadas dependencias
El argumento principal mencionado en el texto al que hago referencia en contra de tener demasiadas dependencias es la posterior dificultad de instalación de nuestros sistemas. Sin embargo, al crear paquetes con la información de las dependencias, convertimos el fastidioso proceso de instalación (y todo el tiempo que requiere documentarlo) en una sóla instrucción al sistema.
Dependencias cíclicas
Coordinar el trabajo de cientos de voluntarios en todo el mundo, sin más factores de cohesión que su voluntad por crear un sistema de calidad trae como resultado natural el que parte importante de sus esfuerzos estén encaminados a la creación de documentos de políticas comprehensivos — y a que su comunidad de desarrolladores comprenda la importancia de dichos documentos.
Claro está, si la unidad atómica de trabajo en una distribución es el paquete, problemas tan claros como las dependencias cíclicas fueron de los primeros puntos en ser prohibidos por política. Sin embargo, conforme la complejidad de cada uno de los paquetes aumenta, se vuelve posible que aparezcan dependencias cíclicas de indirectas. Para evitar problemas como este, y otros destinados del control de calidad en sistemas complejos, se hacen revisiones periódicas de todos los procesos imaginables.
En este aspecto, si bien no hay balas de plata para evitar las dependencias cíclicas, contamos con una comunidad de desarrolladores verificando que estos problemas se mantengan al mínimo. No estamos sólos en el manejo de nuestros proyectos.

Largas cadenas de dependencias
Este fue precisamente el punto que motivó al desarrollo de las arquitecturas de paquetes. Podemos confiar en que la arquitectura que elijamos, empleando los depósitos del sistema y de nuestra organización, sepan resolver este punto sin que represente problemática alguna. Además, no tenemos por qué limitarnos al uso de este esquema para las dependencias de los componentes externos que empleemos. Si dentro de nuestra organización nos acostumbramos a empaquetar nuestro código en componentes, la reutilización de código que podamos hacer será muchísimo más simple y más natural.
Dependencias en conflicto
Nuevamente, aquí acudimos a la sabiduría de las masas, a la fuerza de la multitud. Una distribución basada en Linux no es sólo un conjunto de programas disponibles a través de un mismo depósito — La mayor parte del trabajo de sus creadores es asegurarse que todos los componentes sean mutuamente compatibles, y asegurar a los usuarios un producto de calidad, con todas las actualizaciones necesarias para asegurar su seguridad (cuidando no compormeter su estabilidad) durante su ciclo de vida.
Este puede ser un punto fundamental al elegir qué distribución vamos a usasr para determinado proyecto: Hay distribuciones principalmente orientadas al perfil de usuario de escritorio, para el cual es fundamental tener siempre soporte completo para el último hardware, aceleración gráfica compelta y demás bondades. Sin embargo, para basar nuestros desarrollos empresariales, típicamente preferiremos las distribuciones con ciclos de vida más largos, con un mayor soporte a largo plazo.

Como pueden ver, manejar una arquitectura de paquetes simplifica algunas de las tareas más complicadas (y más ingratas) del desarrollo de software, el manejo de toda la talacha creada por los componentes que, a fin de cuentas, incluimos para ahorrarnos trabajo.

Cuando veo los instaladores típicos, que crean enormes amasijos (típicamente en forma de enormes instaladores .msi o archivos .jar que incluyen copia de todas las dependencias para evitar estos problemas), no exagero: Me dan ganas de llorar. Porque además, al tener varias copias de una misma biblioteca en el sistema, tengo la certeza de que en caso de aparecer algún defecto en alguna de ellas, habrá componentes de mi sistema que reciban la corrección en cuestión — pero habrá otros que no. Acostumbrarse al manejo de dependencias externas nos reduce la tentación de acudir al tan temido ligado estático, reduce el peso de nuestras imágenes de instalación (y de nuestros sistemas ya instalados), y ayuda fuertemente a mantener un mayor control de calidad en nuestros procesos como un todo.

Mucha gente evita aprovechar la modularización como medida preventiva para no perder la razón resolviendo dependencias y bugs creados por compatibilidad incompleta entre versiones. Sin embargo, dejar de usar buen software, ya existente y probado por terceros, sólo por no contar con las herramientas de seguimiento correctas es un triste error en el que debemos evitar caer. La hidra de la modularización a la que se refiere Agustín puede ser un mounstro mortal, pero si aprendemos a hablar con ella puede ser nuestro mayor aliado. Porque si dos cabezas piensan mejor que una, ¿qué decir de decenas de cabezas?

( categories: )

Estrategias de virtualización en Linux

Submitted by gwolf on Fri, 10/24/2008 - 17:26
Written in...: 
2008

Virtualization is the technique (or rather, the set of techniques) that allow to share a single computer's resources so that, for the user, it appears as several independent computers. There are several motivations to virtualize our systems, such as:
- Ease of administration (keeping our installations as simple as possible)
- Isolation/security (limiting the damage a potential attacker can achieve to the smallest possible domain)
- Resource control (avoiding a system failure to consume too many resources in others, leading to a denial of service - Or selling our computer resources by volume)
- High availability (transparent service migration between servers for maintenance tasks)

And a very long etcetera.

Virtualization is not a new technique in computer science, not even in the personal computer world - But there are several factors that have led to its rapid popularization in Linux. Now, there are several techniques through which we can get virtualization.

In this talk, I go over the main virtualization technologies currently available (in Linux and in other operating systems), comparing the strongest and weakest points between several of the available methods, and I present some cases, showing how to resolve several needs.

Resumen: 

La virtualización es la técnica (o más bien, el conjunto de técnicas) que permiten repartir los recursos de una sóla computadora para que, ante el usuario, aparezca como varias computadoras independientes. Virtualizar nuestros sistemas puede hacerse por diversas razones, como:

- Facilidad de administración (mantener nuestras instalaciones tan sencillas como sea posible)
- Aislamiento/seguridad (limitar el daño de un atacante potencial al dominio más reducido posible)
- Control de uso de recursos (evitar que un fallo en un sistema consuma demasiados recursos en otros, llevando a negación de servicio - O venta de servicios de cómputo por volumen de recursos)
- Alta disponibilidad (migración transparente de servicios entre servidores para tareas de mantenimiento

Y, claro, un largo etcétera.

La virtualización no es una técnica nueva en el cómputo, ni siquiera en el mundo de las computadoras personales - Pero hay varios factores que han llevado a que en los últimos años se haya popularizado rápidamente en Linux. Ahora bien, hay varias técnicas que nos brindan virtualización.

En mi plática revisaré las principales metodologías de virtualización actualmente disponibles (en Linux y en otros sistemas operativos), comparando los puntos más fuertes y más débiles entre los métodos comparables, y presento brevemente algunos casos, mostrando cómo resolver diversas necesidades.

Monitoreo de redes con Munin

Submitted by gwolf on Fri, 05/30/2008 - 10:58
Written in...: 
2008

Munin is an easy, rich, configurable, extensible, autodiscovering system- and network- monitoring framework. I explain what it is, how to deploy it and how to implement custom plugins.

Here you will find two presentations, one as a wider Munin introduction (munin.pdf and its source, written in 2008) and one more (munin_pg.pdf and its source, updated, extended but with many bits shortened, written in 2011) focused on PostgreSQL monitoring, as well as the accompanying article (munin-pg.pdf and its source) for the PostgreSQL presentation.

Resumen: 

Munin es un sistema de monitoreo de redes y de sistemas sencillo, rico, configurable, extensible, capaz de autodescubrimiento. Explico qué es, cómo desplegarlo, y cómo implementar plugins a la medida.

Encontrarás dos presentaciones: Una es una introducción más general a Munin (munin.pdf y su fuente, escrita en 2008) y una más (munin_pg.pdf y su fuente, actualizada, extendida pero con varios recortes, presentada en 2011) enfocada en el monitoreo de PostgreSQL, así como el artículo que la acompaña (munin-pg.pdf y su fuente).

ProtoWrap: Using wrappers to protect specific network services

Submitted by gwolf on Sun, 02/10/2008 - 14:20
Written in...: 
2001

I wrote my final paper for graduation on implementing a generic connection wrapper that can be extended to understand and protect specific protocols. I presented this project at YAPC::NA 2001, and published a short article on Usenix's ;login: magazine (published in the June 2002 number).

Resumen: 

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.

Respaldos multinivel robustos y simples utilizando rsync

Submitted by gwolf on Sun, 02/10/2008 - 13:05
Written in...: 
2005

Are you looking for an easy to implement backup solution that allows you to have incremental backups, with low resources consumption, and allowing for immediate retrieval of your data? Rsync and the basic characteristics of any Unix filesystem can be your greatest allies. I prepared this talk for the Admin-UNAM December 2005 seminary, organized by the Computer Security Department, DGSCA, UNAM.

Resumen: 

¿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.

Asegurando tu red con Linux

Submitted by gwolf on Sun, 02/10/2008 - 10:25
Written in...: 
2005

Short text going over several tools that can help a system administrator work on incident prevention, network monitoring and intrusion detection in Linux. I presented this talk in UNAM's Departamento de Seguridad en Cómputo internal admin-unam seminar, in June 2005. It was also published in the August 2005 issue of PC Magazine en español.

Resumen: 

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.

Principios para mantener la seguridad en redes TCP/IP

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

This talk was prepared for IV National Free Software Conference in Universidad Mayor, Real y Pontificia
de San Francisco Xavier de Chuquisaca
, Sucre, Bolivia. This is more or less the second part for my Network security talk, bringing down to earth some of the concepts to more concrete solutions (although still fairly generic).
I presented it in 2005 for UNAM's Computer Security Department's Admin-unam internal seminar; I re-wrote it as a full-text article, also available here.

Resumen: 

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í.

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.

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.

Syndicate content