IT Freek Zone

Puppet Types y Providers

noreply@blogger.com (V3kt0r) — Sun, 23 Sep 2018 13:29:00 -0300

Todos los que utilizamos puppet en algún momento nos encontraremos con la necesidad de crear un módulo que no se puede implementar sólo utilizando los recursos existentes. Es en ese momento donde surge la necesidad de crear nuestro propio tipo.

Puppet provee la posibilidad de crear nuestros propios tipos, desarrollados en ruby. Contar con la posibilidad de programar expande muchísimo nuestro horizonte de cosas que se pueden hacer con puppet.

Desde mi punto de vista, ruby es horrible para programar, pero es la única opción que existe actualmente en puppet, así que no nos quedará otra que aprender aunque sea las bases de este lenguaje.

Puppet separa la definición de un recurso en dos partes: types y providers

El archivo type define todas las propiedades y parámetros que se pueden usar en nuestro recurso. Es decir, define la estructura del recurso y como interactuaremos desde un manifest con él.
Por otra parte, el provider se encarga de implementar el type que definimos.

Algo interesante es que podemos tener múltiples providers para el mismo type. El ejemplo más claro de esto es la implementación del type package. Existen varios providers para este tipo: apt, yum, pacman, etc. La forma en que interactuamos con el type es independiente de cómo luego se implemente.

Como todo en puppet, es importante la estructura y los nombres de nuestros directorios y archivos. Para definir nuestro type y provider, hay que seguir el siguiente árbol:

module
  |-- metadata.json
  |-- README.md
  |-- manifests
  |-- lib
       |-- puppet
             |-- provider
             |     |-- configjs
             |           |-- configjs.rb
             |-- type
                   |-- configjs.rb

La idea es que la explicación sea bastante dinámica, así que plantearé un ejemplo que seguiremos a lo largo del artículo.

Crear nuestro type

Como mencioné, los types deben ubicarse en el path <module name>/lib/puppet/type/<nombre del tipo>.rb para satisfacer la nomenclatura de puppet.

Por ejemplo, voy a definir un tipo para administrar configuraciones en formato JSON. Llamaré al tipo configjs:

  #configjs/lib/puppet/type/configjs.rb
  Puppet::Type.newtype(:configjs) do
    @doc = "Manage json configs"

    ensurable

    newparam(:path, :namevar => true) do
      desc "Path to the JSON File"

      newvalues(/\A\/\w+/)
    end

    newparam(:showdiff) do
      desc "Show a diff when changing values"

      defaultto :true
      newvalues(:true, :false)
    end

    newproperty(:config) do
      desc "The configuration to set"

      isrequired

      def insync?(is)
        is.sort == should.sort
      end
    end
  end

La forma de invocar un tipo es la misma que cuando lo definimos con define en un .pp. Este tipo se utilizaría de la siguiente manera en un manifest:

  $myconfig = {
    'name' => 'itfreek',
    'url' => 'http://itfreekzone.blogspot.com'
  }
  configjs {'/etc/myconfig.js':
    config => $myconfig
  }

Veamos un poco qué significa cada parte del tipo configjs.

Propiedades y parámetros

Para empezar declaramos un parámetro (path) y una propiedad (config). Si bien lucen similares, la diferencia entre ambos es muy importante:

El parámetro se utitliza para designar un valor desde puppet. En el ejemplo, path define la ubicación del archivo en el servidor.
Una propiedad es algo que se puede inspeccionar y cambiar. La misma cuenta con dos valores. Por un lado, tenemos el valor que se indica desde puppet, denominado "should", y por otro el valor que tiene actualmente en el sistema, denominado "is". En el ejemplo, una config en el sistema será el JSON contenido en el file, que pudo haber sido modificado manualmente (esto es el "is"). Si puppet setea un JSON, este es el valor que esa propiedad debe tener, y por eso se denomina "should". La diferencia entre ambos valores es lo que puppet muestra al momento de ejecutar una corrida.

Namevar

Otro punto destacable es el uso de ":namevar => true" en el parámetro path. Como saben puppet usa el concepto namevar para distinguir un recurso en el sistema, y es el valor que asignamos al crear el recurso. En nuestro caso, el path es el nombre que nos permite distinguir un file de otro, lo mismo que sucede con el recurso file. En dicho ejemplo, el valor que tendrá el path es /etc/myconfig.js y será el nombre de nuestro recurso.

Otras opciones

Finalmente también encontramos "isrequired" y "defaultsto". Con el primero indicamos que la propiedad es requerida, es decir, si no se setea puppet dará error. El segundo indica cuál es el valor default que tomará el parámetro si no se especifica ninguno.

Validación y munging

Veamos el uso de newvalues. Con este método podemos restringir qué valores son aceptables para el parámetro. Podríamos incluir una lista de valores (newvalues(:true, :false)), o, como hice yo, una expresión regular a matchear. Más adelante veremos cómo invocar funciones a partir de valores con ensurable. Si el valor otorgado no cumple con esta restricción, puppet dará error.

Las otras opciones que tenemos son validar el input (validate) y transformar (o sanitizar) el valor (munge).

Por ejemplo, si queremos validar que el path sea un path absoluto, podemos agregar lo siguiente:

  newparam(:path, :namevar => true) do
    ...
    validate do |value|
      unless Puppet::Util.absolute_path? value
        raise ArgumentError, "archive path must be absolute: #{value}"
      end
    end
  end

Por otra parte, si quisieramos setear los permisos del file, podríamos agregar un parámetro mode. Mode debería ser un string en la definición del recurso, pero nosotros necesitamos que sea un integer en notación octal para poder setearlo en el filesystem (ej: 0644). Podríamos hacer esto con munge:

  newparam(:mode) do
    munge do |value|
      value.to_i(8)
    end
  end

Providers

Ahora que contamos con la definición del tipo, pasemos al provider. El mismo debe ubicarse en /lib/puppet/provider//.rb. Un tipo puede tener varios providers (como package, o vcsrepo).

En nuestro ejemplo, el provider se llamará igual al tipo (aunque podría llamarse diferente) y lo definimos así:

  #configjs/lib/puppet/provider/configjs/configjs.rb
  Puppet::Type.type(:configjs).provide(:configjs) do
    def config
      if File.exists?(resource[:path])
        content = File.read(resource[:path])
        PSON.load(content)
      else
        {}
      end
    end

    def config=(value)
      create
    end

    def exists?
      File.exists?(resource[:path])
    end

    def create
      config_file = File.new(resource[:path], 'w+')
      config_file.write(JSON.pretty_generate(resource[:config]))
      config_file.close
    end

    def destroy
      FileUtils.rm(resource[:path])
    end
  end

Acá aparece el hash 'resource'. Este hash contiene los valores para cada uno de los parámetros y las propiedades que se setearon. Dentro del type también se puede acceder a este hash, pero como self (ejemplo: self[:path]).

Definiendo la funcionalidad

Ensurable

Si prestaron atención, el tipo configjs invoca el método ensurable. Un recurso se considera 'ensurable' cuando su presencia se puede verificar. Esto es, si no existe y debería existir (ensure => present), hay que crearlo, mientras que si existe y no debería existir (ensure => absent), eliminarlo. Al realizar esta invocación, deberemos definir tres funciones:

exists? debe retornar true si nuestro recurso existe en el sistema y falso sino.
create: crear el recurso si no existe y debería existir.
destroy: destruir el recurso si existe y no debería.

En el ejemplo anterior, exists? nos dice si el file existe o no. Si no existe, creamos el archivo con el contenido indicado en la propiedad config. Si queremos destruirlo, simplemente hacemos un rm del file.

Es posible redefinir los métodos invocados al utilizar "ensure => present/absent", e incluso agregar más valores. La forma de hacerlo es la siguiente:

  #configjs/lib/puppet/type/configjs.rb
  Puppet::Type.newtype(:configjs) do
    ...

    ensurable do
      newvalue(:present) do
        provider.generate
      end

      newvalue(:absent) do
        provider.remove
      end

      newvalue(:empty) do
        provider.empty
      end
    end
  end

Esto es, indicamos que si ensure es present invoque la función generate en lugar de create, mientras que si es absent invoque remove en lugar de destroy. Además, agregamos el valor emtpy que nos permite invocar la función emtpy en el provider.

Como habrán notado, es posible invocar funciones del provider desde la definición del type.

Refresheable

Ahora, qué pasa si realizamos un cambio en el file desde fuera del resource, como por ejemplo, un exec en un manifest? La simple lógica anterior nos indica que si el file existe en el filesystem, entonces no hay que realizar ninguna acción, no verifica si el contenido del file es el correcto.

Este comportamiento lo cambiaremos con los setters y getters (explicado a continuación), pero hay otra forma si no queremos utilizar propiedades, podemos hacerlo indicando que el recurso es refresheable.

Que nuestro tipo sea refresheable significa que se ejecutará algo con un cambio en la propiedad, o si tenemos una relación notify/subscribe. En el ejemplo podríamos realizar estos cambios:

  #configjs/lib/puppet/type/configjs.rb
  Puppet::Type.newtype(:configjs, :self_refresh => true)) do
    ...
    ...
    def refresh
      provider.create
    end
  end

Lo que hicimos es, primero indicar que nuestro tipo es refresheable con ":self_refresh => true". Luego definimos la función refresh, donde indicamos qué se debe ejecutar en un refresh. En nuestro caso lo que hacemos es invocar el método create del provider.

Con esta nueva funcionalidad, además de crearse el file si no existe en el filesystem, también se pisará el contenido si por alguna razón cambia una propiedad o algún otro recurso le notifica que debe hacer un refresh (notify).

Setters y Getters

Siempre que definamos una propiedad, puppet utilizará distintas funciones para determinar si el valor de la propiedad difiere de la que está actualmente en el host. Si este es el caso, seteará el valor que corresponda. Esto es, /etc/myconfig.js tiene el contenido que se indicó por puppet?

Para saber cuál es el valor actual de la propiedad y setear el que corresponde, puppet invoca métodos cuyos nombres son igual a la propiedad. Estos métodos se definen en el provider.

Para el ejemplo anterior, la propiedad se llama config, entonces las funciones get y set se definen de la siguiente manera:

  #Getter: decime qué valor tiene la config ahora en el server
  def config
  end

  #Setter: setea este value como contenido de la config
  def config=(value)
  end

Puppet determina si el valor actual es el que debería tener invocando el método "insync?", es decir, esta propiedad está sincronizada? Por defecto esta función realiza una comparación entre el valor actual y el que debería mediante el operador "==". Para comparar strgins va genial, pero si, por ejemplo, estamos comparando hashes, la comparación podría no resultar como esperamos. Para estos casos, podemos redefinir el método insync? en la definición de la propiedad (en el type).

Siguiendo nuestro ejemplo, vemos esta definición:

  #configjs/lib/puppet/type/configjs.rb
  Puppet::Type.newtype(:configjs) do
    ...
    newproperty(:config) do
      ...

      def insync?
        is.sort == should.sort
      end
    end
    ...
  end

Prefetch y flush

En ciertos casos no queremos definir setters y getters para todas las propiedades de nuestro tipo. Si estamos en esa situación, nuestro approach debería ser utilizar un esquema prefetch/flush.

Un provider prefetch/flush implementa sólo dos métodos:

prefetch: dada una lista de recursos, retornará y seteará las instancias con los valores obtenidos.
flush: se invoca luego de que todos los valores se setearon.

Dado que puppet intentará invocar los setter/getters para cada una de las propiedades, podemos evitar la definición de todos estos métodos invocando mkresource_method, que define setter/getters default para todas las propiedades.

Luego definimos el método prefetch para realizar todas las tareas que haríamos con los getters, y flush para todos los setters.

No utilicé este esquema aún, pero el formato básico es:

  #configjs/lib/puppet/provider/configjs/configjs.rb
  Puppet::Type.type(:configjs).provide(:configjs) do
    mkresource_method

    def prefetch
      ...
    end

    def flush
      ...
    end
  end

Initialize

Otra opción útil para la definición de types y providers es el uso del método initialize. Este método se ejecuta cuando ruby crea un objeto, por lo que podremos realizar algunas inicializaciones ahí si lo necesitamos.

Ejecutar Comandos

En el ejemplo sólo utilizamos files y no necesitamos ejecutar ningún comando. Pero qué pasa si queremos tener un recurso que utilice comandos? Tomando nuestro ejemplo de referencia, tal vez utilicemos el config json generado como input de un comando.

Sólo para ejemplificar el uso de comandos, redefiniré el método create del provider agregando la creación de un container lxd a partir del json. No probé este comando, por lo que puede tener algún error, pero sirve para ejemplificar.

  #configjs/lib/puppet/provider/configjs/configjs.rb
  Puppet::Type.type(:configjs).provide(:configjs) do
    commands :curl => 'curl'

    def create
      config_file = File.new(resource[:path], 'w+')
      config_file.write(JSON.pretty_generate(resource[:config]))
      config_file.close

      curl("-k", "-L", "--cert", ""~/.config/lxc/client.crt", "--key", ~/.config/lxc/client.key", "-H", "Content-Type: application/json", "-X", "POST", "-d", "@#{resource[:path]}", "https://127.0.0.1:8443/1.0/containers)
    end

    ...
  end

Cambiar el output

Cuando puppet cambia un recurso, se registra un evento. Vemos la notificación de que algo cambió de la siguiente forma:

Notice: /Stage[main]/<resource>/Config_js[/etc/myconfig.js]/Configjs[/etc/myconfig.js]/config: config changed <IS VALUE> to <SHOULD VALUE>

La forma en que puppet crea el mensaje es convirtiendo el valor actual y el que debería tener en strings (usando el método to_s de ruby). Dependiendo el valor de la propiedad, la conversión a string puede no ser la deseada y el cambio no resulta claro.

Por suerte podemos customizar tanto la forma en que dichos valores se convierten a string, como el mensaje de lo que va a cambiar. Para ello debemos definir los métodos is_to_s, should_to_s y change_to_s dentro de la propiedad o parámetro:

is_to_s: se ejecuta para convertir a string el valor que actualmente tiene el server.
should_to_s: debe convertir el valor a aplicar a string.
change_to_s: se invoca para mostrar lo que va a cambiar. Si no redefinimos esta función puppet mostrará el valor actual devuelto por is_to_s y el aplicable retornado por should_to_s.

En general nos alcanzará con redefinir is_to_s y should_to_s, o sólamente change_to_s, es muy raro que utilicemos las tres, ya que si definimos change_to_s no tiene mucho sentido definir también las otras dos.

Siguiendo el ejemplo anterior, la propiedad config es un hash. La función to_s no nos retorna un string muy lindo de los hashes, así que en su lugar, podríamos usar inspect en is_to_s y should_to_s:

  #configjs/lib/puppet/type/configjs.rb
  Puppet::Type.newtype(:configjs) do
    ...

    newproperty(:config) do
      ...

      def is_to_s(value)
        value.inspect
      end

      def should_to_s(value)
        value.inspect
      end
    end
  end

En lugar de lo anterior, podríamos simplemente redefinir change_to_s:

  #configjs/lib/puppet/type/configjs.rb
  Puppet::Type.newtype(:configjs) do
    ...

    newproperty(:config) do
      ...

      def change_to_s(is, should)
        "old value #{(is).inspect},
        new #{(should).inspect}"
    end
  end

Update 1: descubrí que cuando ejecutamos puppet con --noop, no se ejecuta change_to_s, sino una función noop que no podemos redefinir y tiene un output predefinido de "current value %s, should be %s (noop), param.is_to_s(current_value), param.should_to_s(param.should)". Ver reporte.

Como no podemos cambiar esta funcionalidad, encontré un workaround en el tipo file. Lo que hace file es imprimir las diferencias entre los files en la función issync? y hacer que is_to_s y should_to_s devuelvan checksums en lugar de printear ambos files.

La forma de implementar esto sería:

  Puppet::Type.newtype(:configjs) do
    ...
    def is_to_s(is)
      '{md5}' + Digest::MD5.hexdigest(is.to_s)
    end

    def should_to_s(should)
      '{md5}' + Digest::MD5.hexdigest(should.to_s)
    end

    def insync?(is)
      return @is_insync unless @is_insync.nil?

      @is_insync = super(is)
      if ! @is_insync && Puppet[:show_diff]
        send @resource[:loglevel], "old value #{(is).inspect},
        new #{(should).inspect}"
      end
      @is_insync
    end
  end

Con esto logramos hacer nuestro propio print de los cambios tanto con --noop como si se van a aplicar de verdad.

Tuve que reescribir las funciones is_to_s y should_to_s para que no retornen el contenido, sino un md5. Ese cambio es necesario porque el método noop de puppet llama estas funciones siempre. Si no modifico su output, obtendremos un print de los cambios dos veces.

También tuve que agregar una variable a la clase para detectar si ya ejecuté insync anteriormente. La clase property llama el método insync? dos veces, así que si no determinamos que ya se ejecutó terminaremos imprimiendo el mismo diff dos veces.

Update 2: Utilizar gems externos en nuestro provider

Algo interesante que me surgió durante la creación de un módulo fue la necesidad de utilizar un gem externo. En mi caso, el gem era inifile.

Ej:

  Puppet::Type.type(:mytype).provide(:mytype) do
    ...
    require 'inifile'
    ini_file = IniFile.load('/etc/config.ini')
    ...
  end

Como muchas cosas en puppet, un poco de magia negra es necesaria, dado que puppet no provee una forma de definir dependencias de librerías ruby en la definición del módulo, así que debemos utilizar un workaround.

Luego de leer en comentarios en reportes de bugs y foros, llegué a esta solución.
Básicamente, lo que podemos hacer es:

Instalar la dependencia gem con puppet.
Hacer que nuestro recurso dependa de la instalación de este paquete.
Agregar una feature y un confine para que el provider no se ejecute si la librería no está instalada.

Vamos por partes, primero instalemos el gem necesario:

  package {'inifile':
    ensure   => 'installed',
    provider => 'puppet_gem',
  }

Agregamos la dependencia a la definición de nuestro tipo:

  mytype { 'nombre':
    ...
    require => Package['inifile'],
  }

Ahora, creemos una feature (lib/puppet/feature/inifilelib.rb) con el siguiente contenido:

  Puppet.features.add(:inifilelib, :libs => ["inifile"])

Por último agreguemos el confine en nuestro provider:

  require 'inifile' if Puppet.features.inifilelib?
  Puppet::Type.type(:mytype).provide(:mytype) do
    confine :feature => :inifilelib
    ...
    require 'inifile'
    ini_file = IniFile.load('/etc/config.ini')
    ...
  end

Esto hará que el provider no se evalúe hasta que el gem inifile no esté instalado. Pueden encontrar una explicación un poco más detallada en el link.

Final, pero hay más para aprender

Si bien este artículo debería cubrir un buen porcentaje de lo que podemos necesitar al crear un type, surgiran cosas que no están acá. Una de ellas es la herencia de providers para crear nuevos providers, el uso de autorequire, features, etc. Recomiendo dar un vistaso a las referencias para más info.

Me decidí a escribir sobre types porque no encontré información muy buena. Si bien hay artículos interesantes que te introducen a la creación de tipos, a medida que avanzas y necesitas entender cómo funcionan ciertas cosas me costó bastante. La info está muy desparramada y se asumen muchas cosas que cuesta entender de dónde salen. Reconozco que no leí completamente el libro Puppet Types and Providers by Nan Liu, Dan Bode que supuestamente es la referencia más completa al respecto.

Referencias

Puppet Types and Providers

Puppet Custom Types

Puppet Provider Development

Puppet Complete Resource Example

Fun With Puppet Providers - Part 1 of Whatever

Who Abstracted My Ruby?

Seriously, What Is This Provider Doing?

Puppet Extension Points - Part 2

Chapter 4. Advanced Types and Providers

Writing Custom Puppet Types and Providers to Manage Web-Based Applications (slides)

Configurar slaves OpenLDAP para aplicar lock de usuarios por logins fallidos (ppolicy)

noreply@blogger.com (V3kt0r) — Thu, 5 Jan 2017 19:31:00 -0300

Quienes utilicen LDAP para autenticación de servidores/workstations, seguramente se han topado o se toparan con el overlay ppolicy, el cual permite configurar policies de password como largo mínimo, complegidad, history, lock por cantidad de intentos, etc. Cómo habilitar y configurar ppolicy está bastante bien explicado en diversos sites como este, por lo que no lo incluiré acá. El problema es que ninguno explica bien qué hacer si tenes servidores slave que se utilizan para autenticación.

Cuando tenés una configuración master -> slaves, los slaves son read-only, por lo que no guardarán ningún atributo por si mismos, sino que replican lo que tiene el master. Esto es, si por ejemplo están utilizando un slave como ldap server, varios intentos fallidos de login nunca bloquearán la cuenta, porque el tipo no guardará el atributo pwdAccountLockedTime en ningún lado. Esto es lo mismo que sucede cuando intentan hacer un change password y están usando un slave, el pass no se puede cambiar.

Para solucionar este problema, OpenLDAP provee la alternativa de que los slave redirijan los updates al master. Esto es, si alguien quiere actualizar un valor en el slave, el slave redirigirá el update al ldap master, y lo obtendrá por replicación. La solución comprende utilizar updateref, enconjunto con el overlay chain y la opción ppolicy_forward_updates, donde:

updateref "<master ldap server>" indica a qué servidor LDAP enviar los updates (se utiliza sólo en slaves). Esta opción por sí sola retorna al cliente la URL del master ldap, y es el cliente quien se debe encargar de tomar esa URL y hacer el update allí.
El overlay chain facilita lo anterior, haciendo que el update lo haga el mismo slave, en lugar de retornar la URL del master al cliente. Con chain podemos configurar que si alguna acción dispara un update, el slave se conecte al master y lo aplique. Para ello, hay que configurar un usuario de binding que en el master tenga permisos de escritura para los atributos que deberá actualizar. Este overlay también se usa para resolver DNs que no están replicados en el slave, ya que sin él, OpenLDAP retornará un redirect que el cliente final deberá seguir.
ppolicy_forward_updates es la opción del overlay ppolicy que le indica que debe forwardear los password failures, ya que sino asume que es un master y no dispara el hook de redirect.

Veamos todo junto en un ejemplo, donde el ldap master se llama masterserver.dvpem.org. Esta config es para el slave y va en slapd.conf. Incluí sólo las líneas relevantes de la configuración, no es una configuración slapd.conf completa.

IMPORTANTE:

La configuración del overlay chain debe ir lo más arriba posible, antes de la configuración de cualquier base de datos y de la configuración de replicación.
updateref debe ir luego de la configuración de replicación (syncrelp).
El usuario que utilicen para el overlay chain debe tener permiso manage sobre los atributos de password. Por ejemplo, este es el permiso necesario para un user SlaveUpdater:

{0}to dn.subtree="ou=people,dc=dvpem,dc=org" attrs=pwdChangedTime,pwdAccountLockedTime,pwdFailureTime,pwdHistory,pwdGraceUseTime,pwdReset by dn.base="cn=SlaveUpdater,dc=dvpem,dc=org" manage by * +0 break

...
#importamos el módulo que contiene el overlay chain
moduleload back_ldap.la

#cargamos el overlay
overlay chain
#definimos cuál es la URL del master y con qué usuario bindear. Recuerden que el user debe tener permiso manage.
chain-uri "ldap://masterserver.dvpem.org"
chain-idassert-bind     bindmethod="simple"
                        binddn="cn=SlaveUpdater,dc=dvpem,dc=org"
                        credentials="elpassdeSlaveUpdater"
                        mode="self"
                        #starttls=yes        #necesario si usamos ldaps como protocolo
                        #tls_reqcert=allow   #necesario si usamos ldaps como protocolo
chain-return-error TRUE

...
...

#cargamos el overlay ppolicy
moduleload ppolicy.la
overlay ppolicy

#indicamos dónde está la pólicy default de password (largo, cantidad de intentos, etc). Misma config que en el master.
ppolicy_default "cn=default,ou=Policies,dc=dvpem,dc=org"

#indicamos que se deben forwardear los updates al master
ppolicy_forward_updates

...
...

#configuración estándar syncrelp
syncrelp rid=001
    provider=ldap://masterserver.dvpem.org
    type=refreshAndPersist
    interval=00:00:02:00
    retry="30 10 120 +"
    searchbase="dc=dvpem,dc=org"
    attrs="*,+"
    bindmethod=simple
    binddn="cn=replicator,dc=dvpem,dc=org"
    credentials=elpassdelreplicator
    tls_reqcert=allow

#especificamos a dónde redirigir los updates
updateref "ldap://masterserver.dvpem.org"

Si tienen configurado el slave para utilizar la base cn=config, deberán ejecutar el diguiente ldif (aquí lo llamo enable-ppolicy-forward.ldif):

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_ldap

dn: olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcChainConfig
olcOverlay: {0}chain
olcChainCacheURI: FALSE
olcChainMaxReferralDepth: 1
olcChainReturnError: TRUE

dn: olcDatabase=ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config
changetype: add
objectClass: olcLDAPConfig
objectClass: olcChainDatabase
olcDatabase: ldap
olcDbURI: "ldaps://masterserver.dvpem.org"
olcDbStartTLS: none  starttls=no
olcDbIDAssertBind: mode=self
  flags=prescriptive,proxy-authz-non-critical 
  bindmethod=simple
  timeout=0
  network-timeout=0
  binddn="cn=SlaveUpdater,dc=dvpem,dc=org"
  credentials="elpassdeSlaveUpdater"
  keepalive=0:0:0
  starttls=yes
  tls_cert="/etc/ldap/ssl/certificado.pem"
  tls_key="/etc/ldap/ssl/certificado.pem"
  tls_cacert="/etc/ldap/ssl/certificado.pem"
  tls_reqcert=allow
  tls_cipher_suite=NORMAL
olcDbRebindAsUser: FALSE
olcDbChaseReferrals: TRUE
olcDbTFSupport: no
olcDbProxyWhoAmI: FALSE
olcDbProtocolVersion: 3
olcDbSingleConn: FALSE
olcDbCancel: abandon
olcDbUseTemporaryConn: FALSE
olcDbConnectionPoolMax: 16
olcDbSessionTrackingRequest: FALSE
olcDbNoRefs: FALSE
olcDbNoUndefFilter: FALSE

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcUpdateRef
olcUpdateRef: ldaps://masterserver.dvpem.org

dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcPPolicyForwardUpdates
olcPPolicyForwardUpdates: TRUE

Ejecutamos el ldif con ldapmodify (cambien el usuario admin por el que corresponda a ustedes):

ldapmodify -D "cn=admin,cn=config" -W -f enable-ppolicy-forward.ldif

Como siempre, espero que les haya resultado útil. Yo perdí un buen rato hasta entender cómo funciona esta lógica.

Reverse Proxy con Apache en 4 pasos

noreply@blogger.com (V3kt0r) — Mon, 11 Apr 2016 03:00:00 -0300

Los reverse proxy son muy útiles para poder proteger nuestros servers, ya que podemos colocar el server que realiza el procesamiento en la red interna y publicar todo a través del proxy, el cual puede filtrar y actuar de application firewall, balancear carga, etc. La idea del post no es explicar qué es ni qué ventajas tiene un Reverse Proxy, sino cómo crear uno usando apache. Para entender qué son, pueden arrancar por la wiki.
Existen módulos para Apache que nos permiten convertirlo en un Reverse Proxy, denominados mod_proxy_*. Los que interesan para esta explicación son mod_proxy y mod_proxy_http.

Supongamos que tenemos la siguiente configuración:

Internet ----> | www.dvpem.org / proxy.dvpem.org |<---> | background-man1.dvpem.org |

Donde www.dvpem.org tiene IP pública accesible desde Internet y es atendida por el server proxy.dvpem.org, y background-man1.dvpem.org tiene una IP privada. El web server background-man1 es el encargado de procesar todos los pedidos, pero no queremos exponerlo, por lo que levantamos un Reverse Proxy (proxy.dvpem.org), que es quien atiende los request a la página www.dvpem.org y los reenvía a background-man1 para su procesamiento. Una vez que background-man1 termina, retorna los resultados a proxy.dvpem.org que es quien responde finalmente al cliente.

Para lograr esto, sólo necesitamos realizar los siguientes 4 pasos:

1. Instalar apache.
2. Habilitar mod_proxy y mod_proxy_http:
a2enmod proxy proxy_http
3. Crear un Virtual Host que atienda los pedidos www.dvpem.org y los reenvíe a background-man1:


    <VirtualHost *:80>

        ServerName   www.dvpem.org:80

        ServerAlias  www.dvpem.org

        

        Alias /about.html /var/www/about.html   #about.html lo procesa el proxy

        ProxyPassMatch ^/about.html !           #Indicamos que no proxee los requests del file about.html

        

        ProxyPass / http://background-man1.dvpem.org/           #Mapeamos los request www.dvpem.org para que vayan a background-man1

        ProxyPassReverse / http://background-man1.dvpem.org/    #Reescribe los headers retornados por background-man1 (ej: Location, Content-Location, URI) para que hagan referencia a www.dvpem.org

    </VirtualHost>

En la configuración agregué una yapa, y es que los request de about.html sean retornados por el mismo proxy, utilizando el file que está en su filesystem local. Esto es, no irá a background-man1, sino que lo retornará de un file en el mismo server. Esto puede ser muy útil si queremos que además de proxy sirva algunas cosas.
4. Reloadear la configuración de apache:
service apache2 reload

El módulo es muchísimo más polenta que esto, expliqué un uso muy básico. Algo interesante es que podríamos resolver diferentes paths a diferentes servers, como por ejemplo usando:


    ProxyPass /main http://background-man1.dvpem.org/       

    ProxyPassReverse /main http://background-man1.dvpem.org/

    

    ProxyPass /images http://images.dvpem.org/

    ProxyPassReverse /images http://images.dvpem.org/

Pueden leer más sobre mod_proxy en su página oficial.

Obtener SSL/TLS Ciphers Soportados

noreply@blogger.com (V3kt0r) — Wed, 2 Mar 2016 18:12:00 -0300

Ufff casi un año sin postear nada, desde que cambié de trabajo estoy extremadamente ocupado y no he tenido tiempo para postear, a pesar de que estuve viendo muchas cosas interesntes. Espero poder retomar un ritmo de post más seguido :)

Con el auge de las vulnerabilidades en TLS/SSL este último tiempo, tuvimos que ir ajustando el listado de ciphers varias veces, ya que los requerimientos son cada vez más exigentes. El problema es la compatibilidad con sistemas operativos/browsers más antiguos, que no soportan las versiones más nuevas de TLS (TLS 1.2) o ciphers más seguros.

Hoy les traigo algo que me sirvió mucho, que es listar los ciphers soportados por un servidor usando un simple script en bash que se basa en openssl. Si bien hay varias tools que hacen esta tarea, siendo la que más uso TestSSLServer, quería algo que pudiera ejecutar desde cualquier lugar, sin depender de tools externas o la instalación de java. OpensSSL está presente en toda las distribuciones, así que no necesitamos nada extra para correr este script.

El core del script lo encontré en este post de superuser, al cual le hice modificaciones para que OpenSSL use SNI, tenga un check básico de parámetros, permita pasar port por parámetro y reporte sólo los ciphers con resultado positivo. Sería un equivalente de TestSSLServer más básico, pero portable :D

#!/bin/bash -e

if [ "$1" == "" ]; then
    echo "usage: $0  [port]"
    exit
fi

if [ "$2" == "" ]; then
    PORT=443
else
    PORT=$2
fi

# OpenSSL requires the port number.
SERVER=$1:$PORT
DELAY=1
ciphers=$(openssl ciphers 'ALL:eNULL' | sed -e 's/:/ /g')

echo -n "Checking if server is up... "
result=$(echo -n | openssl s_client -connect $SERVER 2>&1)
if [[ "$result" =~ "Connection timed out" ]]; then
    echo "FAIL - connection time out"
    exit 1
fi
echo "OK"

echo "Obtaining cipher list from $(openssl version)."
for cipher in ${ciphers[@]}; do
    result=$(echo -n | openssl s_client -cipher "$cipher" -servername $SERVER -connect $SERVER 2>&1 || echo "")
    if [[ "$result" =~ "Cipher is ${cipher}" || "$result" =~ "Cipher    :" ]] ; then
        echo $cipher
    fi
    sleep $DELAY
done

Ejecutar como servicio un programa que no es demonizable

noreply@blogger.com (V3kt0r) — Tue, 2 Jun 2015 19:02:00 -0300

Hoy estuve lidiando con una aplicación que se ejecuta desde consola y queda escuchando en un puerto, pero que no provee la posibilidad de correr como demonio (tipo Apache, sshd, etc). Para no tener que loguear un usuario y dejar la aplicación en ejecución en alguna consola colgada, mejor es convertirla en un servicio. Mi caso en particular se dió con la aplicación CherryMusic, que permite compartir musica a través de una interfaz web.

Como primer paso, vamos a crear un directorio donde alojar la aplicación, y para un caso como el que describo, creo que el mejor lugar es /opt:

# mkdir /opt/cherrymusic

Para cherrymusic, si hacen un clone del proyecto, el directorio se crea sólo, lo mismo si descomprimen un tar.gz.

A continuación creemos el usuario con el que se ejecutará la aplicación:

# useradd cherrymusic -d /opt/cherrymusic -s /bin/false

El comando anterior indica que el home del usuario será /opt/cherrymusic y que utilice /bin/false como shell... es decir, que no tenga shell.

Para ver qué sucede con nuestra aplicación, estaría bueno ver algún log, así que creemos uno, con los permisos necesarios para que la aplicación pueda escribir:

# touch /var/log/cherrymusic
# chown cherrymusic /var/log/cherrymusic

La ejecución del programa la haremos de la siguiente forma:

# sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic --port 8080 &>>/var/log/cherrymusic

Esto es, le decimos que ejecute la aplicación con el usuario cherrymusic (-u), usando el home de dicho usuario (-H), y redirigimos la salida a /var/log/cherrymusic

Como último paso, creamos un init script. Si usamos el viejo estándar, podemos meter un script como el siguiente en /etc/init.d/cherrymusic

#!/bin/bash
### BEGIN INIT INFO
# Provides: cherrymusic
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
### END INIT INFO
case "$1" in
start)
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic --port 8080 &>>/var/log/cherrymusic
;;
stop)
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
killall -u cherrymusic
;;
*)
echo "usage: $0 <start | stop>"
;;
esac

Ok, tal vez un killall no es lo mejor, pero sirve para mostrar un script muy simple.

Al script le agregué un "plus" que es levantar una regla iptables que redirija lo que llegue por el puerto 80, al 8080. Esto se debe a que, al ejecutar el script con un usuario no privilegiado, el mismo no se puede hookear al puerto 80.

Faltaría sólo agregarlo para que se ejecute al inicio:

# update-rc.d cherrymusic defaults

Si quisieramos hacer lo mismo, pero utilizando upstart, podemos crear el siguiente archivo en /etc/init/cherrymusic.conf:

# Cherry Music
#
start on runlevel [2345]
stop on runlevel [!2345]
script
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic --port 8080 &>>/var/log/cherrymusic
end script
post-stop script
iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 8080
end script

Eso es todo, ya pueden utilizar "service cherrymusic start" y "service cherrymusic stop", y además la aplicación se ejecutará cada vez que se encienda el equipo. Los pasos serían los mismos si ejecutaran cualquier otra aplicación =)

ejabberd LDAP, certificados y clustering

noreply@blogger.com (V3kt0r) — Wed, 28 Jan 2015 04:05:00 -0300

Después de pelear durante un par de días con ejabberd, me pareció interesante compartir la experiencia ganada en el proceso, ya que no todo es tan directo como parece. La documentación oficial está buena, pero la encontré un poco escueta, por lo que si no usas una configuración similar a la de los ejemplos, no sabes bien qué poner en cada parámetro.
Ejabberd está escrito en lenguaje Erlang, y utiliza el formato de este lenguaje para su archivo de configuración. Si bien no es complicado, no es a lo que uno está acostumbrado.

Comenzaré con lo básico de todos los tutoriales, pero con la idea de que el servidor autenticará con LDAP en lugar de la autenticación interna. Luego pasaré a los topics más interesantes como autopopular rosters con grupos de usuarios LDAP y armar un servicio de alta disponibilidad con dos servidores ejabberd.

Instalación

En debian, Ubuntu y supongo que otros derivados también, ejabberd se encuentra en los repositorios oficiales, por lo que instalarlo es tan fácil como ejecutar lo siguiente:
# apt-get install ejabberd

Configuración básica

Toda la configuración se realiza desde el archivo /etc/ejabberd/ejabberd.cfg. De base, tendremos que editar lo siguiente:

{hosts, ["dvpem.org"]}.
{acl, admin, {user, "vektor", "dvpem.org"}}.

donde:

hosts especifica los dominios que ejabberd manejará.
acl Indica cuál es el usuario admin. Si utilizan LDAP (ver a continuación) este usuario debe ser uno que exista en el servidor de LDAP.

Como ven, muy poco es necesario para tener ejabberd funcionando. Si no utiliza LDAP deberán cambiar el nombre de usuario por uno local, y luego agregarlo con el comando ejabberctl. Por ejemplo:

# ejabberdctl register vektor dvpem.org superPASS

Es posible acceder a una interfaz web de administración apuntando a la siguiente URL:

http://<host-o-IP>:5280/admin

Habilitar LDAP

Para habilitar autenticación por LDAP veamos un ejemplo de configuración y qué significa cada valor:

%%{auth_method, internal}.
{auth_method, ldap}.
{ldap_servers, ["ldap.dvpem.org"]}.
{ldap_base, "ou=People,dc=dvpem,dc=org"}.
{ldap_rootdn, "cn=Usuario,dc=dvpem,dc=org"}.
{ldap_password, "PASSusuario"}.
{ldap_port, 636}.
{ldap_encrypt, tls}.
{ldap_uids, [{"uid", "%u"}]}.

Vamos por línea:

Deshabilita (comenta) autenticación interna.
Habilita autenticación por LDAP.
ldap_servers: indica cuáles son los servidores LDAP a los que se conectará ejabberd.
ldap_base: especifica el DN base a partir del cual buscar los usuarios. Esto dependerá si se utiliza AD, OpenLDAP, u schemas propios.
ldap_rootdn: especifica el usuario utilizado para conectar ejabberd con LDAP. El usuario utilizado debe poder listar usuarios y grupos, como mínimo.
ldap_password: password del usuario utilizado en la conexión con LDAP.
ldap_port: puerto del servidor LDAP.
ldap_encrypt: indica que utilice TLS en la conexión.
ldap_uids: indica qué atributo contiene el identificador del usuario. Esto también variará según el schema. En AD podría utilizarse samAccountName.

Reiniciar servidor ejabberd:

# server ejabberd restart

Nota 1: si iniciar ejabberd falla, probar de ejecutarlo en modo debug:

# ejabberd --debug

Nota 2: cuando la configuración está mal (o algo falla), puede que igualmente ejabberd deje un procesos corriendo y que ello les traiga problemas al intentar iniciar ejabberd nuevamente. Es un problema que queda medio oculto porque al iniciar ejabberd no arroja error, pero al mirar la lista de procesos escuchando, vemos que ninguno espera conexiones en el puerto default 5222 o 5280. En este caso, buscar y matar los procesos colgados antes de iniciar ejabberd nuevamente:

# killall -u ejabberd

Usar grupos de LDAP como grupos en los rosters

Es posible tomar los grupos de LDAP y utilizarlos en el roster, de forma que cada cliente que se conecte vea los grupos y los usuarios incluidos. Para ello, se puede utilizar el módulo mod_shared_roster_ldap, que por defecto no viene habilitado. Editar el archivo ejabberd.cfg, y en la sección de módulos agregar mod_shared_roster_ldap:

...
{modules,
[
....
{mod_shared_roster_ldap, [
{ldap_base, "ou=Group,dc=dvpem,dc=org"},
{ldap_rfilter, "(objectClass=posixGroup)"},
{ldap_ufilter, "(&(objectClass=posixAccount)(uid=%u))},
{ldap_gfilter, "(&(objectClass=posixGroup)(cn=%g))"},
{ldap_groupattr, "cn"},
{ldap_groupdesc, "cn"},
{ldap_memberattr,"memberUid"},
{ldap_memberattr_format, "cn=%u,ou=People,dc=dvpem,dc=org"},
{ldap_useruid, "uid"},
{ldap_userdesc, "cn"}
]},
]}.

El ejemplo está armado pensando en un servidor OpenLDAP, pero es fácilmente adaptable a AD, sólo hay que cambiar los nombres de los atributos.
Veamos cada uno de los atributos:

ldap_base: indica a partir de donde buscar los grupos para popular el roster.
ldap_rfilter: filtro que utilizará para popular el roster, y como los grupos del roster son los mismos de LDAP, pues ahí va. Dado que el base ya apunta a los grupos, no sería estrictamente necesario ya que no debería haber otra cosa que grupos en esa OU, pero por las dudas... En este caso se asume que los grupos son Posix, si usan AD tendrán que cambiar por el fitro que mejor les quede.
ldap_ufilter: filtro para obtener el atributo que contiene el nombre "humano" del usuario. Préstese atención que con este filtro obtenemos el nombre del atributo, no el valor del atributo, para esto último está ldap_user_desc.
ldap_gfilter: filtro para obtener el nombre "humano" de los grupos. Misma idea que con ldap_ufilter.
ldap_groupattr: nombre del atributo LDAP que tiene el nombre del grupo.
ldap_groupdesc: nombre del atributo que tiene el nombre "humano" del grupo. Se usa en conjunto con ldap_gfilter, obteniendo del resultado de este filtro su valor.
ldap_memberattr: nombre del atributo LDAP que apunta a los miembros del grupo (member también es común).
ldap_memberattr_format: especifica el formato en que se guardan los miembros de un grupo. Por ejemplo, pueden tener cn=vektor,ou=People,dc=dvpem,dc=org. El %u le indica cuál es el nombre del usuario.
ldap_useruid: nombre del atributo que contiene el ID de usuario (en AD samAccountName).
ldap_user_desc: nombre del atributo que contiene el nombre "humano" del usuario. Se utiliza en conjunto con ldap_ufilter, obteniendo del resultado de este filtro su valor.

Instalar certificado propio

Para habilitar TLS/SSL ejabberd utiliza un sólo archivo que contiene clave privada, certificado y cadena de certificados. Por defecto, se genera uno al instalar ejabberd, denominado ejabberd.pem. Para no tener que editar el archivo de configuración, lo más simple es reemplazar este archivo con uno generado por nosotros a partir de nuestros certificados y clave. Este super archivo debe contener los datos en el siguiente orden:

Clave privada
Certificado
Cadena certificante

De modo que, si por ejemplo tenemos los archivos private.key, certificado.crt y CA.crt, podemos unirlos fácilmente utilizando cat de la siguiente manera:

# cat private.key certificado.key CA.crt > /etc/ejabberd/ejabberd.pem

Timeouts

Un problema que surgió en uno de los servers que instalé, es que después de un rato de inactividad, las conexiones TCP de ejabberd con LDAP mueren. Buscando encontré que si no hay actividad durante un dado período de tiempo, algunos equipos de red pueden "desconectar" las sesiones TCP sin notificar al software que las está usando. En este caso, desde ejabberd se sigue viendo como que la conexión está activa, y al ver la conexión activa la utiliza pero sin obtener resultados. Desde mi punto de vista, esto es un bug en ejabberd, ya que si al realizar consultas no se obtiene respuesta, debería cerrar esa conexión e intentar conectarse nuevamente al servidor LDAP. En lugar de hacer eso, sólo da un authentication failure, sin loguear siquiera un timeout en los logs :S

Lo importánte aquí es la solución a este problema. El kernel de Linux soporta el envío de paquetes keepalive, para mantener activas conexiones TCP o marcar una conexión como "muerta". Esto lo realiza enviando paquetes keepalive a intervalos definidos de tiempo, esperando respuesta del servidor para decidir si la conexión está muerta. Es decir, cumple dos funciones, por un lado envía paquetes generando tráfico de red para que la conexión no se muera, y en el caso de que la conexión ya esté muerta, lo detecta y le avisa a la aplicación que la está usando.
La configuración se realiza a través de tres variables que se encuentran en /proc/sys/net/ipv4/

tcp_keepalive_time: default 7200 segundos, es decir, 2 horas. Especifica el intervalo en segundos entre el primer paquete de una secuencia de pruebas keepalive y el primer paquete de la próxima.
tcp_keepalive_intvl: default 75 segundos. Indica cada cuántos segundos enviar paquetes keepalive en una secuencia.
tcp_keepalive_probes: default 9. Valor numérico que especifica cuántos paquetes enviar en una secuencia.

El mecanismo es el siguiente: el kernel envía un paquete keepalive, espera el tiempo especificado en tcp_keepalive_intvl y envía otro, espera de nuevo y luego envía otro, así hasta alcanzar la cantidad de pruebas indicadas en tcp_keepalive_probes. Es decir, por defecto enviará 9 paquetes con una diferencia de 75 entre sí. Si no hay respuesta del otro lado, marca la conexión como muerta. Mientras tanto, una vez que se envió el primer paquete de esta secuencia, comienzan a contarse los segundos, y cuando se llega al valor de tcp_keepalive_time, comienza de nuevo con la secuencia mencionada.

Para no tener el problema de conexiones muertas podemo acomodar estos valores, ya que 2hs de espera puede ser demasiado. Según este post (http://start.nwt.fhstp.ac.at/blog/?p=307), los valores que mejores resultado les dieron son los siguientes:

tcp_keepalive_time = 600
tcp_keepalive_intvl = 30
tcp_keepalive_probes = 5

Lo cual se puede setear ejecutando:

# echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
# echo 30 > /proc/sys/net/ipv4/tcp_keepalive_intvl
# echo 5 > /proc/sys/net/ipv4/tcp_keepalive_probes

Al reiniciar el servidor, estos valores se perderán, pero pueden generar un script en bash que se ejecute al inicio.

Así que ya saben, si ven que las conexiones con el servidor LDAP figuran activas (lsof -Pni), pero los clientes dan authentication failure sin razón, prueben esta solución.

Clustering

La configuración de un cluster ejabberd, es decir, tener más de un servidor ejabberd sirviendo el mismo dominio, es medio críptica, pero no compleja. Digo críptica porque hay que ejecutar comandos Erlang para que funcione. Básicamente configurar un cluster ejabberd es igual a configurar un cluster mnesia. Erlang utiliza mnesia, un manejador de base de datos distribuido, y lo que hay que hacer es configurar mnesia para que funcione en modo replicación.

Si bien la configuración puede ser multimaster, llamaré Master al primer nodo que damos de alta y Slave al segundo.

Configuración Master

Copiar cookie mágica de Erlang que se encuentra en /var/lib/ejabberd/.erlang.cookie al nodo slave. Esta cookie debe ser igual en todos los nodos.

# scp /var/lib/ejabberd/.erlang.cookie vektor@chat2.dvpem.org:~

O bien hacer un cat de .erlang.cookie y pegar el contenido en el nodo destino.

Editar archivo /etc/default/ejabberd y agregar las líneas:

ERLANG_NODE=ejabberd@chat1
INET_DIST_INTERFACE={192,168,1,1}

donde:

ERLANG_NODE especifica el nombre completo del nodo.
INET_DIST_INTERFACE es la IP en la cual esperará conexiones. Utilizar comas para separar los octetos, es decir, en lugar de utilizar los convencionales puntos, separar con comas.

Reiniciar el master:

# service ejabberd restart

Configuración Slave

Detener el servicio de ejabberd:

# service ejabberd stop
# killall -u ejabberd

Editar archivo /etc/default/ejabberd y agregar las líneas:

ERLANG_NODE=ejabberd@chat2
INET_DIST_INTERFACE={192,168,1,2}

Mover la cookie al directorio de ejabberd y cambiar los permisos para que el usuario ejabberd la pueda acceder:

# mv .erlang.cookie /var/lib/ejabberd/
# chown ejabberd:ejabberd /var/lib/ejabberd/.erlang.cookie
# chmod 400 /var/lib/ejabberd/.erlang.cookie

Iniciar ejabberd:

# service ejabberd start

Asegurarse que ejabberd se está ejecutando:

# ejabberctl status

Abrir una consola Erlang para conectar al nodo 1 y realizar una copia de la base de datos:

# ejabberctl debug

En la consola Erlang, ejecutar lo siguiente:

(ejabberd@chat2)1> mnesia:stop(),
(ejabberd@chat2)1> mnesia:delete_schema([node()]),
(ejabberd@chat2)1> mnesia:start(),
(ejabberd@chat2)1> mnesia:change_config(extra_db_nodes, ['ejabberd@chat1']),
(ejabberd@chat2)1> mnesia:change_table_copy_type(schema, node(), disc_copies).
(ejabberd@chat2)1> mnesia:info().

Cerrar la sesión precionando Ctrl+c Ctrl+c

donde:

mnesia:stop() detiene la ejecución de la BD mnesia,
mnesia:delete_schema([node()]) elimina el schema actual del nodo,
mnesia:start() inicia nuevamente la BD,
mnesia:change_config(extra_db_nodes, ['ejabberd@chat1']) apunta la base de datos al nodo 1
mnesia:change_table_copy_type(schema, node(), disc_copies) crea una copia local del schema.
mnesia:info() imprime información del nodo. Al ejecutar este comando deberían ver ambos nodos en ejecución:
...
running db nodes = ['ejabberd@chat1','ejabberd@chat2']
...

Esto sólo copia el esquema de la base de datos en el slave. Si bien todo funciona correctamente así, si el master cae, el sistema en teoría deja de funcionar, ya que el slave no tiene copia de las tablas.
Ahora, para tener un entorno multi-master hay que realizar una copia de todas las tablas en el nodo slave... que ya no sería más slave, sino otro master. En este caso los writes serán más lentos, pero tendremos un entorno de alta disponibilidad.
El comando para copiar tablas de otro nodo es mnesia:add_table_copy... pero hacerlo tabla por tabla es tedioso. Encontré en un comentario de StackOverflow como hacer una copia de todas las tablas en un comando:

(ejabberd@chat2)1> [{Tb, mnesia:add_table_copy(Tb, node(), Type)} || {Tb, [{'ejabberd@chat1', Type}]} <- [{T, mnesia:table_info(T, where_to_commit)} || T <- mnesia:system_info(tables)]].

Hay que ejecutarlo en una consola Erlang con "ejabberdctl debug".

Referencias

Crear una CA con OpenSSL y firmar/revocar certificados con ella

noreply@blogger.com (V3kt0r) — Tue, 6 Jan 2015 04:30:00 -0300

Ya es el 4to artículo (o fueron más?) que escribo sobre certificados digitales, y sin embargo siempre me encuentro con algún requerimiento nuevo. Esta vez necesitaba crear una CA propia para firmar mis certificados, y como siempre, decidí utilizar OpenSSL.

En los siguientes pasos describiré cómo crear la susodicha CA y cómo firmar certificados con la misma.

Si les interesa, pueden dar un repaso a los otro artículos del tema:
- Certificados Digitales
- Firmando una CA propia
- Shortcuts: comandos OpenSSL para generar claves, certificados y testear conexiones

1. Configurar OpenSSL

El primero paso es copiar o editar la información en /etc/ssl/openssl.cnf. Son pocos los campos que es importante/requerido editar. El resto pueden modificarlos también, pero la idea acá es mostrar los requerimientos mínimos.

En el archivo openssl.cnf buscar y editar los siguientes valores:

[ CA_default ]
dir = /ca
...
new_certs_dir = $dir/newcerts
certificate = $dir/ca.crt
...
private_key = $dir/ca.key
...
default_days = 365

donde:

dir: directorio que alojará la información de la CA, como certificados firmados, base de datos, número de serie, etc.
new_certs_dir: donde se alojarán los certificados firmados.
certificate: ubicación del certificado de la CA.
private_key: la clave de la CA.
default_days: cantidad de días de validez de un certificado por default.

También será de mucha utilidad pegarle una mirada y editar lo siguiente:

[ req_distinguished_name ]
countryName = Country Name (2 letter code)
countryName_default = AR
countryName_min = 2
countryName_max = 2
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Buenos Aires
localityName = Locality Name (eg, city)
0.organizationName = Organization Name (eg, company)
0.organizationName_default = Super CA

Estos datos facilitan la vida al generar certificados, ya que se tomarán por default y no habrá que cargarlos cada vez que se genere un nuevo request.

Una vez finalizada la edición, realizar lo siguiente en el directorio default (ver variable dir de la configuración):

crear los archivos de texto index.txt y serial:
# touch /ca/index.txt /ca/serial
donde:
index.txt es la base de datos de certificados firmados por la CA.
serial cotiene el número de serie que debe colocarle al próximo certificado que firme.
al archivo serial, agregarle un valor. Este será el número de serie que imprima al primer certificado que genere, luego lo actualizará solo. El valor debe ser de dos dígitos:
echo "01" > /ca/serial
crear el directorio para los certificados nuevos, si es que todavía no existe. Para el ejemplo dado:
# mkdir /ca/newcerts

2. Generar clave y certificado de CA

Claramente la CA debe contar con su propia clave y certificado. Estos se utilizarán para firmar los certificados que se requieran luego. La forma más rápida es utilizando un sólo comando:

# openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /ca/ca.key -out /ca/ca.crt -config /ca/openssl.cnf
Generating a 2048 bit RSA private key
...+++
..........................................+++
writing new private key to 'ca.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AR]:
State or Province Name (full name) [Buenos Aires]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Super CA]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:super-ca.com
Email Address []:

Como verán, el archivo de configuración hace que los valores de "Country Name", "State or Province Name", etc se tomen de ahí.

3. Firmar certificados

En los anteriores artículos expliqué cómo generar un request de certificado, por lo que no me explayaré en eso. Les dejo el siguiente comando que crea una clave y CSR, y además utiliza como template el archivo de configuración:

# openssl req -new -newkey rsa:2048 -keyout prueba.key -out prueba.csr -config /ca/openssl.cnf
Generating a 2048 bit RSA private key
......................................+++
....+++
writing new private key to 'prueba.key'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AR]:
State or Province Name (full name) [Buenos Aires]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Super CA]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:superprueba.com
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Ok, ahora si a lo bueno, con este simple comando podremos firmar los request de certificados que deseemos:

# openssl ca -cert /ca/ca.crt -keyfile /ca/ca.key -in prueba.csr -out prueba.crt -config /ca/openssl.cnf
Using configuration from /ca/openssl.cnf
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number: 2 (0x2)
Validity
Not Before: Jan 5 15:40:56 2015 GMT
Not After : Jan 5 15:40:56 2016 GMT
Subject:
countryName = AR
stateOrProvinceName = Buenos Aires
organizationName = Super CA
commonName = superprueba.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
EE:9C:75:57:66:F6:3E:FA:D9:CF:6F:06:60:E0:97:D1:EE:EC:14:EA
X509v3 Authority Key Identifier:
keyid:98:7A:32:95:93:72:24:37:B0:16:61:10:8D:E7:51:5F:54:95:C7:62
Certificate is to be certified until Jan 5 15:40:56 2016 GMT (365 days)
Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated

4. Revocar certificados

Finalmente, y porque seguro les sucederá en algún momento, veamos cómo revocar un certificado. Es tan simple como ejecutar el siguiente comando:

# openssl ca -revoke prueba.crt -config /ca/openssl.cnf
Using configuration from /ca/openssl.cnf
Revoking Certificate 01.
Data Base Updated

Si miran el archivo index.txt, podrán observar una R al principio de la línea del certificado.

Un tip interesante, es qué pasa si no tenemos el certificado que queremos revocar. En este post de stackoverflow explican una forma de hacerlo.
OpenSSL guarda una copia de los certificados que firma en el directorio "newcerts" (o donde lo hayan configurado en openssl.cnf). Los certificados se guardan con el número de serie como nombre, por lo que primero hay que hayar el número de serie del certificado que queremos revocar. Un simple grep puede ayudarnos en este caso:

# grep "prueba" /ca/index.txt
V 160105143331Z 01 unknown /C=AR/ST=Buenos Aires/O=Super CA/CN=prueba

donde vemos que el ID es 01.
Con esta info, ejecutamos el comando anterior de la siguiente manera:

# openssl ca -revoke newcerts/01.pem -config /ca/openssl.cnf

Referencias

- How To Setup a CA

FirefoxOS en tu PC

noreply@blogger.com (V3kt0r) — Mon, 10 Nov 2014 05:00:00 -0300

Buscando emuladores de Android, se me ocurrió que sería bueno también probar FirefoxOS, el sistema operativo de la gente de Mozilla para dispositivos móviles. Hacía rato que tenía ganas de probar este sistema, ya que Android me parece extremadamente invasivo, dándo acceso a Google y sus partnets a todo lo que haces con tus dispositivos. Tal vez la gente de Mozilla haga lo mismo, pero es bueno darle una chance y probar. Además en el sentido de la privacidad, confío más en Mozilla que en Google... aunque vale decir que no se puede confiar en nadie jejeje.

Sé que en España y algunos países de Latinoamérica, Telefónica está vendiendo celulares con FirefoxOS instalado. Desgraciadamente estos equipos todavía no llegaron a Argentina, así que no había tenido la oportunidad de probar el sistema.

Por suerte encontré que ejecutar FirefoxOS en una PC es extremadamente simple! tan sólo hay que instalar el add-on del simulador.

Veamos los pasos:

Descargar el add-on para Firefox desde App manager add-ons.
La versión 2.0 pesa más de 120MB, así que a esperar un poco.

Una vez instalado, es posible acceder al simulador desde el App Manager. Al mismo se llega dando click "botón de menú -> Developer -> App Manager", o bien escribiendo en la barra de navegación la URL about:app-manager

En el App Manager damos "Start Simulator" y aparecerán en la misma barra los simuladores que tengamos instalados.

Clickear el simulador que queramos ejecutar y listo!

Increíblemente simple.

Cabe aclarar que estos pasos funcionan en GNU/Linux, Windows y Mac.

Ahora, si no queremos abrir el firefox para ejecutar el simulador, encontré (mirando la lista de procesos), que se puede acceder ejecutando el siguiente comando (en GNU/Linux) desde la línea de comandos:

$HOME/.mozilla/firefox//extensions/fxos_2_0_simulator@mozilla.org/b2g/b2g-bin -profile $HOME/.mozilla/firefox//extensions/fxos_2_0_simulator@mozilla.org/profile -start-debugger-server 56807 -no-remote

En el comando anterior, reemplazar <perfil> por el nombre del directorio del perfil donde el simulador está instalado.

El simulador me demostró ser muy eficiente. Tan sólo consume 128MB de memoria (residente) y funciona muy fluido. Además la integración con el sistema es espectacular.

A probar FirefoxOS y ver que tal se comporta. Hasta donde ví, me gustó. Obviamente la lista de aplicaciones todavía es limitada, pero a medida que vaya ganando popularidad habrá más y más.

Referencia: Using the App Manager

Check Network Device: plugin Nagios para chequear recursos en dispositivos de red

noreply@blogger.com (V3kt0r) — Thu, 30 Oct 2014 16:28:00 -0300

Desde hace un tiempo vengo trabajando en un plugin para Nagios que me permita chequear recursos básicos de dispositivos de red. Me focalicé en el monitoreo de dispositivos Cisco, con los cuales trabajo a diario y es mi principal interés, pero la idea es que soporte diversos dispositivos en el futuro.

El plugin permite chequear los siguientes recursos:

Carga de CPU
Temperaturas
Estados de los FANs
Uso de Memoria
Estado de interfaces de red (up/down)
Ancho de banda (input y output) en interfaces de red

Además de chequear el estado (con umbrales warning y critical), también retorna información contabilizable para poder graficar los resultados con PNP4Nagios u otros plugins. Los valores posibles de graficar son carga de CPU, memoria, temperatura y ancho de banda de las interfaces.

El monitoreo se realiza por SNMP, por lo cual este protocolo debe estar activo en los dispositivos y aceptar conexiones desde el servidor Nagios. Además, el script utiliza la versión en python de la librería Net-SNMP, la cual se encuentra en los siguientes paquetes:

python-netsnmp // debian
net-snmp-python // Red Hat

Actualmente el proyecto se encuentra en Launchpad y pueden descargar la última versión desde la siguiente dirección: https://launchpad.net/check-net-device/+download

Opciones

Se proveen varias opciones que pueden resultar abrumantes al principio, pero una vez que se entienden, no son complicadas..

El uso de check_net_device es el siguiente:

check_net_device -H <ip_address> -C <community> <-t -t device_type | -i interface_ID> [-o check_option] [-w warning] [-c critical] [-P log_path]

donde las opciones obligatorias son:

-H; --host <ip_address>: es la IP del host a chequear.
-C; --community <community>: comunidad SNMP definida en el dispositivo.
-t; --type <device_type>: tipo de dipositivo a chequear. Los valores permitidos en la versión 0.4 son cisco y bc (de BlueCoat), pero sólo cisco está implementado.
-i; --interface <interface_id>: se utiliza para chequear estado de interfaces y anchos de banda. El ID dado por el fabricante a la interfaz que se desea chequear. El ID de la interfaz se puede encontrar consultando el OID 1.3.6.1.2.1.31.1.1.1.1 (ifName) con snmpwalk, y sólo la última parte del OID se necesita como parámetro. Ejemplo: snmpwalk -v2c -c <community> <host ip> 1.3.6.1.2.1.31.1.1.1.1
-o; --option <check_option>: especifica el recurso a chequear.

env: check environmental status. On Cisco it includes temperatures and fan status.
cpu: check status and return CPU load.
memory: check memory status, and return percentage usage.

ifstatus: check the interface status, returning OK or DOWN.
ifbw: check input/output bandwidth and return usage.

-w; --warning <value>: umbral para reportar un warning. Dependiendo del tipo de chequeo, puede ser un porcentaje o un número.
-c; --critical <value>: umbral para reportar un estado crítico. Dependiendo del tipo de chequeo, puede ser un porcentaje o un número.
-P; --log-path <path to dir>: necesario para utilizar la opción "-i <interface id> -o ifbw", dado que esta opción necesita un directorio donde guardar los valores de ancho de banda leídos. El usuario que ejecute este comando (usualmente llamado nagios) necesita permiso de escritura en el directorio especificado.

Nota:

-t y -i no se usan al mismo tiempo, dado que los chequeos de interfaces son independientes del tipo de dispositivo. Esta opción se puede utililizar para chequear cualquier tipo de dispositivo.
-w y -c son opcionales, dado que el script posee valores ya definidos para estados de warning y critical.

Ejemplos

Uso de CPU:

$ ./check_net_device.py -C public -H 192.168.0.1 -t cisco -o cpu
OK - CPU Load: 1% | 'CPU Load'=1%;60;80

Ancho de banda:

$ ./check_net_device.py -C public -H 192.168.0.1 -i 2 -o ifbw -P /tmp/
OK - In: 1.08 Mb/s, Out: 1.49 Mb/s | 'In'=1129850B;629145600;83886080 'Out'=1561893B;629145600;83886080

Estado de interfaces:

$ ./check_net_device.py -C public -H 192.168.0.1 -i 2,3,4,6
OK - All Interfaces UP | Gi1/1: Up, Gi1/2: Up, Fa2/1: Up, Fa2/3: Up

Ejemplos de gráficos con PNP4Nagios, a partir de valores retornados por check_net_device:

Ancho de banda:

Carga de CPU:

Otro Plugin?

Alguno seguramente dirá, ya existen plugins para monitorear equipos de red. Pues si, pero desarrollé este script por tres grandes razones:

No encontré ningún plugin que realice todo esto junto:

Chequeo de estado de CPU, memoria, interfaces, ancho de banda, temperatura y fans.
Entrega de información de performance para poder graficar los valores obtenidos.
Sirva para múltiples dispositivos. Los que chequean múltiples tipos de dispositivos, no permiten muchos tipos de chequeos (por ejemplo check_snmp_environment).

Los plugins que vi están todos escritos en perl, y si bien perl me parece un lenguaje fantástico, se me hace difícil de seguir, con lo cual, me dificulta la posibilidad de agregar funcionalidad a scripts existentes. Creo que un script en python facilitará que muchos lo extiendan, ya que python es más fácil de aprender.
Me gusta programar =)

Espero que les sea útil. Si encuentran errores, por favor reportar, trataré de solucionarlos lo más rápido posible.

POODLE Attack (die SSLv3!)

noreply@blogger.com (V3kt0r) — Wed, 15 Oct 2014 13:41:00 -0300

Leyendo noticias de seguridad, me topé con este interesante ataque que afecta la versión SSLv3 y permite a un atacante desencriptar porciones de tráfico HTTPS, como por ejemplo cookies.

Últimamente al pobre protocolo no le ha ido muy bien, basta recordar el mortal Heartbleed descubierto hace unos meses, y otros ataques como BEAST y CRIME descubiertos hace un par de años, o Lucky-13, por citar algunos.

Una de las personas que participó en el descubrimiento de esta vulnerabilidad es Thai Duong, quien también participó (junto a Juliano Rizzo) en el descubrimiento de BEAST y CRIME. En este caso, Thai trabajó con otros empleados de Google (Bodo Möller y Krzysztof Kotowicz) para el descubrimiento.

Como mencioné al principio, el ataque afecta sólo a SSLv3, el cual está obsoleto desde hace unos años, pero que todavía es soportado por muchos servidores y browsers por compatibilidad. La versión más actual del protocolo es TLSv1.2, pero los clientes pueden negociar con el servidor una versión inferior del protocolo, en caso de no soportar esta última.

El ataque no es tan directo como Heartbleed, ya que es necesario realizar previamente un ataque Man-in-the-Middle (MiTM). Pero un ataque MiTM no es tan complejo si tenemos acceso a la red de la víctima, o si accedemos a una red WiFi pública (hoteles, bares, etc).

Los detalles del ataque los pueden leer en el paper original, pero básicamente explota la encripción CBC utilizada en SSLv3, debido a la forma en que este algoritmo utiliza los paddings para completar bloques.

Según comentan en el paper, la única forma de evitar este ataque es eliminando el uso de SSLv3. En el mismo, proponen utilizar el mecanismo TLS_FALLBACK_SCSV para la negociación, en clientes y servidores. Utilizando TLS_FALLBACK_SCSV, el servidor siempre utilizará la versión más actual del protocolo habilitada en el mismo, rechazando cualquier intento de conexión con una versión inferior. Obviamente, si el servidor no soporta una versión superior a SSLv3, entonces será vulnerable igual.

Existen varios mecanismos para averiguar qué versiones de SSL/TLS soporta un servidor. Les dejo un par para que verifiquen sus servidores.

Una forma simple, es utilizar la capacidad de ejecución de scripts de NMAP, el cual todo administrador de seguridad tiene instalado:

$ nmap --script ssl-enum-ciphers -p 443 <IP Servidor>

Algo más avanzado es utilizar una herramienta dedicada a chequear conexiones SSL, denominada SSLyze, la cual pueden descargar aquí. Esta herramienta está escrita en python y se puede ejecutar sin instalarse:

$ python sslyze.py --regular <IP Servidor>:443

Finalmente y también muy interesante, es la herramienta web provista por Qualys, la cual chequea múltiples vulnerabilidades SSL, así como lista los protocolos soportados y genera un reporte. La misma se accede aquí.

Nagios: generar gráficos con PNP4Nagios

noreply@blogger.com (V3kt0r) — Wed, 8 Oct 2014 12:07:00 -0300

Hace tiempo que estoy trabajando con Nagios y MRTG, como pudieron observar en Nagios: monitoreo remoto de dispositivos + agentes Linux + agentes Windows, y Monitoreo de ancho de banda en routers/switches/etc usando MRTG. Ambas herramientas me resultaron excelentes y me ayudan mucho en el monitoreo diario de la infraestructura de red.
Desde hace un tiempo vengo buscando la forma de integrar más gráficos en Nagios, y me pareció interesante utilizar MRTG para hacerlo. Esto es perfectamente posible y hasta comencé a trabajar en ello, pero luego descubrí PNP4Nagios y cambié la perspectiva.

Tal como cita la página oficinal:

PNP es un addon para Nagios que analiza datos de performance (performance data) provistos por los plugins y los almacena en bases de datos RRD.

Oye, eso suena similar a lo que MRTG hace. Pues claro, el acercamiento es similar, almacenar datos en bases de datos RRD y luego graficar a partir de ellos utilizando rrdtool. De forma similar trabajan Ntop y otras herramientas.

PNP4Nagios tiene una interfaz web muy atractiva y simple de usar, permitiendo seleccionar intervalos de tiempo de forma dinámica, navegar fácilmente entre servicios de hosts, y generar reportes en PDF. Tal vez una de las características más interesantes es la posibilidad de definir templates propios para indicarle la forma de evaluar y generar los gráficos. Dado que trabaja directamente con RRDTool, brinda todas las facilidades de graficación que esta herramienta provee.

Cabe destacar que para poder graficar datos, los plugins deben retornar información en el campo performance_data, y no todos los plugins lo hacen. Por suerte, quienes diseñan buenos plugins si entregan datos de performance. Estos datos deben tener un formato especial para que PNP pueda parsearlos y almacenarlos, pero esa discusión la dejaré para algún artículo sobre creación de plugins.
Para saber fácilmente si un plugin entrega datos de performance, pueden ejecutarlo desde la consola y ver si incluye el caracter pipe "|" en el resultado impreso. Todo lo que venga luego del pipe son datos de performance. Por ejemplo:

$./check_icmp -H 10.6.143.101
OK - 10.6.143.101: rta 1,593ms, lost 0%|rta=1,593ms;200,000;500,000;0; pl=0%;40;80;; rtmax=4,541ms;;;; rtmin=0,832ms;;;;

Este plugin entrega 4 datos de performance:
- rta: tiempo de respuesta,
- pl: porcentaje de pérdida de paquetes,
- rtmax: tiempo máximo de respuesta,
- rtmin: tiempo mínimo de respuesta.

Integración con Nagios

PNP4Nagios provee varios modos de integrarse con Nagios, cada uno con sus ventajas y desventajas:

Synchronous: cada vez que Nagios ejecuta un plugin, luego llama el script process_perfdata.pl para actualizar los valores de la base de datos RRD y el archivo XML correspondiente. La mayor desventaja de esta forma de integración es que Nagios ejecuta process_perfdata.pl cada vez que realiza un check de host o servicio.
Bulk: este modo permite realizar múltiples actualizaciones de datos de performance juntos. Nagios escribe en un archivo temporal los datos obtenidos en cada check, y a intervalos definidos, Nagios ejecuta el script process_perfdata.pl.
Bulk with NPCD: desde el punto de vista de Nagios, es la mejor opción, dado que se independiza de la ejecución del script process_perfdata.pl. La ejecución de script queda a cargo del demonio NPCD (Nagios Performance C Daemon), el cual monitorea un directorio, donde deben ubicarse los datos de performance, a la espera de que un archivo sea creado. De esta forma, Nagios se encarga de guardar los datos de la ejecución de los plugins en archivos y luego mover los archivos al directorio donde los tomará NPCD.
Bulk with NPCD and npcdmod: el flujo de datos es igual a Bulk with NPCD, con la diferencia que simplifica la configuración de Nagios, ya que las definiciones de cómo procesar los datos se dejan al módulo npcdmod. El uso de este módulo se realiza definiendo un broker en la configuración de Nagios. Debe tenerse en cuenta que este modo no funciona con Nagios 4.
Gearman: se utiliza el módulo Gearman como agente intermediario entre Nagios y el procesamiento de los datos. Nagios se encarga de generar los datos y mod_gearman (broker para Nagios) se encarga de encolarlos para su procesamiento, utilizando el demonio gearmand. Luego el script process_perfdata.pl escanea esta cola en busca de datos. La mayor ventaja de este modo es que Nagios y PNP4Nagios pueden ejecutarse en máquinas distintas, ya que la conexión de Nagios con Gearman es a través de sockets. Además Gearman funciona con workers y puede tener múltiples workers trabajando a la vez. Este modo es el ideal para instalaciones de Nagios con hosts y servicios.

De las opciones listadas, elegí utilizar el modo Bulk with NPCD y npcdmod, dado lo fácil que es ponerlo en funcionamiento, y las ventajas que provee sobre el modo Synchronous. Si algún día utilizan Nagios 4, deberían utilizar otra opción como Bulk with NPCD o Gearman.

Instalación y Configuración

Instalar PNP4Nagios en debian y derivados es tan simple como ejecutar:
# apt-get install pnp4nagios rrdtool
Existen paquetes para otras distribuciones como CentOS.

Luego de instalarlo, para integrarlo con Nagios utilizando el modo Bulk with NPCD y npcdmod, debe realizarse los siguientes pasos.

Setear la variable RUN en yes, en el archivo /etc/default/npcd, para habilitar en demonio NPCD.

RUN=yes

Editar el archivo /etc/nagios3/nagios.cfg de la siguiente manera:

# Habilita el procesamiento de datos de performance entregados por los plugins de chequeo
process_performance_data=1
# Hacer que Nagios comparta su información con la librería npcdmod
broker_module=/usr/lib/pnp4nagios/npcdmod.o config_file=/etc/pnp4nagios/npcd.cfg

Recargar Nagios:

/etc/init.d/nagios3 reload

Gualá, ya está la integración, eso fue fácil.

Por defecto, PNP4Nagios se habilita en un directorio web distinto al de Nagios. Los gráficos se acceden apuntando a las siguientes direcciones:

http://<nombre servidor>/pnp4nagios/pnp4nagios/graph?host=<nombre del host>
http://<nombre servidor>/pnp4nagios/pnp4nagios/graph?host=<nombre del host>&srv=<descripción del servicio>

Como nombre de host debe utilizarse el nombre que se utilizó para definirlo en Nagios.

Una forma más directa de acceder a los gráficos, es agregar el link como un action_url en la definición de hosts en Nagios. El camino fácil es definir nuevos templates para hosts y servicios, de la siguiente manera:

define host {
use generic-host
name pnp-host
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=_HOST_
register 0
}
define service {
name pnp-service
action_url /pnp4nagios/index.php/graph?host=$HOSTNAME$&srv=$SERVICEDESC$
register 0
}

Luego, para cada host o servicio que se desee ver gráficos, simplemente agregar pnp-host y pnp-service en la definición de hosts.

Pensamientos Finales

A diferencia de MRTG que utiliza consultas SNMP para obtener sus datos, PNP4Nagios utiliza los datos entregados por los plugins de Nagios... los cuales pueden sacar datos por SNMP o de muchas otras maneras. Esta funcionalidad me resultó mucho más abarcativa, y ya que igualmente necesito Nagios y estoy obteniendo datos con sus plugins, por qué no aprovecharlos para generar los gráficos.
Claro que es posible obtener con MRTG datos de otras fuentes que no sea SNMP, MRTG es muy flexible. Sería posible llegar a resultados similares a los obtenidos con Nagios y PNP, pero de una forma más laboriosa. No estoy diciendo que esta solución reemplace MRTG, sino que me parece mucho más completa. La elección de utilizar una u otra es de cada administrador.

Referencias

- PNP4Nagios Documentation
- Archivo /usr/share/doc/pnp4nagios/README.Debian

Obtener uso de CPU y memoria, temperatura y estado de interfaces de dispositivos Cisco, utilizando SNMP

noreply@blogger.com (V3kt0r) — Thu, 18 Sep 2014 16:56:00 -0300

Continuando con la labor de monitorear el estado de dispositivos conectados a la red, decidí profundizar en el control de equipamiento Cisco. Para ello, recurrí al viejo pero muy vigente y útil protocolo SNMP. Los dispositivos Cisco, como la gran mayoría de los dispositivos de red, proveen información detallada a través de SNMP. El problema es que entre tanta información provista, uno se puede marear y perder lo que le interesa conocer.

Dado que no encontré mucha información que detalle cómo monitorear e interpretar la información de los recursos más importantes (si encontré pedazos de información por separado), decidí investigar y armar documentación propia. Distintas páginas de Cisco proveen información, pero dan por asumido que conocemos relativamente bien la información provista. Lo único que me resultó realmente útil es el navegador de objetos SNMP (http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en). En base a este último pude recopilar y armar las consultas que yo requería.

Yendo al grano, con la información provista en este artículo podrán no sólo saber cómo obtener por SNMP información del estado de los recursos del dispositivo, sino también entender los valores obtenidos.

Me centraré en obtener la información listada a continuación, la cual abarca todo lo necesario para conocer el estado de un dispositivo:

- Estado de las interfaces de red del dispositivo.
- Uso de CPU.
- Temperatura del chasis, y/u otra información provista por los sensores que el equipo posea.
- Uso de memoria.

En el artículo me centraré en describir los OIDs necesarios para obtener la información listada. Los ejemplos los haré utilizando snmpwalk como herramienta de consulta. Esta misma información se puede obtener con distintos clientes snmp, snmpwalk es sólo uno de ellos, muy versátil y completo. Una vez que se conocen los OIDs y la información provista, es muy fácil automatizar el monitoreo con herramientas como Nagios, o scripts propios. Dejaré la integración con Nagios para otro artículo :D

Si les interesa el monitoreo de redes, pueden encontrar más información al respecto en mis anteriores artículos:

- Nagios: monitoreo remoto de dispositivos + agentes Linux + agentes Windows
- Monitoreo de ancho de banda en routers/switches/etc usando MRTG
- Armar servidor de logging con rsyslog y configurar dispositivos para logging remoto
- Instalar Zabbix en Debian GNU/Linux

Estado de Interfaces

Hay ciertas interfaces que son muy interesantes para monitorear, dado que ello nos permitirá saber si un equipo importante perdió la conexión. Interfaces de este tipo pueden ser uplinks entre edificios, conexiones a servidores, enlaces a la WAN, etc.

El OID utilizado para ver el estado de las interfaces es el 1.3.6.1.2.1.2.2.1.8 (objeto ifOperStatus), descripto como "The current operational state of the interface". Este OID contiene una entrada por cada interfaz presente en el switch.
Por ejemplo, al realizar un walk en un 2950, obtenemos la siguiente información:

$ snmpwalk -v2c -c public 192.168.1.100 -On 1.3.6.1.2.1.2.2.1.8
.1.3.6.1.2.1.2.2.1.8.1 = INTEGER: up(1)
.1.3.6.1.2.1.2.2.1.8.2 = INTEGER: down(2)
.1.3.6.1.2.1.2.2.1.8.3 = INTEGER: down(2)
...
...

Ok, esto nos da el estado de las interfaces... pero cómo sabemos cuál interfaz es cada una? Para esto existe el OID 1.3.6.1.2.1.2.2.1.2 (objeto ifDescr), que contiene información de la interfaz. En el ejemplo anterior, la consulta de este OID nos dará lo siguiente:

$ snmpwalk -v2c -c public 192.168.1.100 -On 1.3.6.1.2.1.2.2.1.2
.1.3.6.1.2.1.2.2.1.2.1 = STRING: FastEthernet0/1
.1.3.6.1.2.1.2.2.1.2.2 = STRING: FastEthernet0/2
.1.3.6.1.2.1.2.2.1.2.3 = STRING: FastEthernet0/3
...

Ahora si, ya sabemos que el OID 1.3.6.1.2.1.2.2.1.8.1 representa el estado de la interfaz FastEthernet0/1, el 1.3.6.1.2.1.2.2.1.2.3 la Fa0/3, etc. Para cada interfaz que se desee monitorear, deberá consultarse primero la descripción de la misma, así sabemos con cuál OID se relaciona.

Uso de CPU

Cisco almacena distintos valores para el uso de CPU, utilizando distintos períodos de tiempo. Los OIDs son:

1.3.6.1.4.1.9.9.109.1.1.1.1.10 (cpmCPUTotalMonIntervalValue): uso de CPU en el intervalo especificado por 1.3.6.1.4.1.9.9.109.1.1.1.1.9 (cpmCPUMonInterval). El intervalo suele ser 5 segundos, y este OID es el que debe utilizarse en lugar de cpmCPUTotal5sec y cpmCPUTotal5secRev, ya en desuso.
1.3.6.1.4.1.9.9.109.1.1.1.1.7 (cpmCPUTotal1minRev): uso en el último minuto. Anteriormente se utilizaba cpmCPUTotal1min.
1.3.6.1.4.1.9.9.109.1.1.1.1.8 (cpmCPUTotal5minRev): uso en los últimos cinco minutos. Debe utilizarse en lugar de cpmCPUTotal5min.

La empresa recomienda utilizar cpmCPUTotal5minRev, dado que representa la mejor estimación de uso.
Todos estos valores representan porcentaje de uso y van de 0 a 100.

Ejemplo de consulta del valor de carga de CPU en los últimos 5 minutos es el siguiente:

$ snmpwalk -v2c -c public 192.168.1.100 -On 1.3.6.1.4.1.9.9.109.1.1.1.1.8
.1.3.6.1.4.1.9.9.109.1.1.1.1.8.1 = Gauge32: 6

es decir, la carga es de 6%.

En la página How to Collect CPU Utilization on Cisco IOS Devices Using SNMP se explica bien como obtener información del uso de CPU.

Sensores (midiendo temperatura y estado de fans)

Existen varios sensores en los dispositivos que permiten medir diferentes valores, como la temperatura del chasis y el funcionamiento de los fans. Los valores de los sensores se almacenan en el objeto 1.3.6.1.4.1.9.9.91.1.1.1.1.4 (entSensorValue).
Por ejemplo, accediendo los valores de los sensores en un 4500 obtendremos algo así:

$ snmpwalk -v2c -c public 192.168.1.200 -On 1.3.6.1.4.1.9.9.91.1.1.1.1.4
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.9 = INTEGER: 35
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.15 = INTEGER: 1
.1.3.6.1.4.1.9.9.91.1.1.1.1.4.18 = INTEGER: 2

Este objeto contiene entradas indexadas según el índice físico de cada entidad (en este caso, el sensor es la entidad). Para saber a qué entidad refiere cada índice, se puede consultar el objeto 1.3.6.1.2.1.47.1.1.1.1.2 (entPhysicalDescr), el cual describe cada entidad física.
En el ejemplo anterior, podemos ver lo siguiente al consultar este objeto:

$ snmpwalk -v2c -c public 192.168.1.200 -On 1.3.6.1.2.1.47.1.1.1.1.2
...
.1.3.6.1.2.1.47.1.1.1.1.2.9 = STRING: "Chassis Temperature Sensor"
...
.1.3.6.1.2.1.47.1.1.1.1.2.15 = STRING: "Power Supply Fan Sensor"
...
.1.3.6.1.2.1.47.1.1.1.1.2.18 = STRING: "Power Supply Fan Sensor"

Es decir, los valores obtenidos anteriormente son la temperatura del chasis y el estado de los fans de las fuentes.
Ahora, qué significan esos valores? en qué unidades están representados? Bueno, para esto necesitamos consultar ooootro objeto, el 1.3.6.1.4.1.9.9.91.1.1.1.1.1 (entSensorType), que nos indica de qué tipo es cada sensor:

.1.3.6.1.4.1.9.9.91.1.1.1.1.1.9 = INTEGER: 8
.1.3.6.1.4.1.9.9.91.1.1.1.1.1.15 = INTEGER: 12
.1.3.6.1.4.1.9.9.91.1.1.1.1.1.18 = INTEGER: 12

Cisco tiene predefinidos estos valores en una tabla, la cual se puede encontrar en su página. La tabla indica lo siguiente:

1:other
2:unknown
3:voltsAC
4:voltsDC
5:amperes
6:watts
7:hertz
8:celsius
9:percentRH
10:rpm
11:cmm
12:truthvalue
13:specialEnum
14:dBm

Con esto sabemos que el primer sensor mide grados celsius (valor 8), y los otros dos otorgan un valor booleano (12). Pero qué significan los valores 1 y 2? cuál es verdadero y cuál es falso? Consultando la página de Cisco, encontramos lo siguiente:

other(1): a measure other than those listed below
unknown(2): unknown measurement, or
arbitrary, relative numbers
voltsAC(3): electric potential
voltsDC(4): electric potential
amperes(5): electric current
watts(6): power
hertz(7): frequency
celsius(8): temperature
percentRH(9): percent relative humidity
rpm(10): shaft revolutions per minute
cmm(11),: cubic meters per minute (airflow)
truthvalue(12): value takes { true(1), false(2) }
specialEnum(13): value takes user defined enumerated values
dBm(14): dB relative to 1mW of power

Gracias a esta última información, ahora sabemos que 1 es verdadero, y 2 es falso. Es decir, el Fan 1 funciona bien, mientras que el 2 no.

Juntando todo este meollo de consultas, ahora sabemos lo siguiente:

El switch posee 3 sensores.
El primero mide la temperatura del chasis, la cual en este momento es de 35º
Los otros dos sensores chequean el estado de los fans de las fuentes, estando el primer fan funcionando bien y el segundo no.

Uso de Memoria

Es posible ver el uso de memoria de los dispositivos, así como la cantidad de memoria libre, accediendo al objeto 1.3.6.1.4.1.9.9.48 (ciscoMemoryPoolMIB). Cisco divide la memoria en pools, según su uso. Los tipos de pools predefinidos son:

1: processor memory
2: i/o memory
3: pci memory
4: fast memory
5: multibus memory

Además, los pools pueden ser categorizados en dinámicos o predefinidos. De los listados anteriormente, sólo el tipo processor debe ser soportado por todos los dispositivos.
Ejemplo de valores obtenidos en un 2950:

$ snmpwalk -v2c -c public 192.168.1.100 -On 1.3.6.1.4.1.9.9.48
.1.3.6.1.4.1.9.9.48.1.1.1.2.1 = STRING: "Processor"
.1.3.6.1.4.1.9.9.48.1.1.1.2.2 = STRING: "I/O"
.1.3.6.1.4.1.9.9.48.1.1.1.3.1 = INTEGER: 2
.1.3.6.1.4.1.9.9.48.1.1.1.3.2 = INTEGER: 0
.1.3.6.1.4.1.9.9.48.1.1.1.4.1 = INTEGER: 1
.1.3.6.1.4.1.9.9.48.1.1.1.4.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.48.1.1.1.5.1 = Gauge32: 2417476
.1.3.6.1.4.1.9.9.48.1.1.1.5.2 = Gauge32: 687872
.1.3.6.1.4.1.9.9.48.1.1.1.6.1 = Gauge32: 1467696
.1.3.6.1.4.1.9.9.48.1.1.1.6.2 = Gauge32: 1492064
.1.3.6.1.4.1.9.9.48.1.1.1.7.1 = Gauge32: 1274620
.1.3.6.1.4.1.9.9.48.1.1.1.7.2 = Gauge32: 1492060

De los valores obtenidos, tenemos que:

1.3.6.1.4.1.9.9.48.1.1.1.2 (ciscoMemoryPoolName) define el nombre del pool. En el ejemplo hay dos pools, Processor e I/O.
1.3.6.1.4.1.9.9.48.1.1.1.5 (ciscoMemoryPoolUsed) muestra el uso de memoria actual de cada pool, expresado en bytes.
1.3.6.1.4.1.9.9.48.1.1.1.6 (ciscoMemoryPoolFree) representa la memoria libre en cada pool, también en bytes.

La memoria total del equipo se puede obtener sumando los bytes libres con los utilizados.

Tips: Montar carpeta compartida VirtualBox en Guests debian y derivados

noreply@blogger.com (V3kt0r) — Thu, 28 Aug 2014 14:02:00 -0300

Hoy me topé con un problema extraño, pero que por lo que encontré googleando, es común. Hasta ahora no se me había dado por montar shares en una máquina virtual debian (virtualizada usando VirtualBox), así que no me había pasado. Usando guests Windows siempre me funcionó correctamente.
Dado que requiere algunos pasos, decidí armar un mini instructivo de cómo hacerlo, ya que seguramente alguien más se encuentre con el mismo problema. Veamos los pasos:

Como todo manual de VBox indica, primero hay que instalar las Guest Additions antes de poder compartir carpetas entre el host y el guest. Previo a esto, hay que contar con los headers del kernel (paquete linux-headers-), y make. Una vez que cuentan con estos paquetes (make instala los compiladores y demás), realizar lo siguiente:

Ir a la ventana de la máquina virtual, elegir la opción "Dispositivos" -> Insertar imagen de CD de las «Guest Additions»". Esto habilitará la imagen en la lectora virtual del guest.
Montar el cd virtual ejecutando: mount /dev/cdrom -o exec
Ejecutar el script correspondiente a Linux: /media/cdrom/VBoxLinuxAdditions.run

Con lo anterior debería bastar para montar los shares según el manual oficial, ejecutando:

mount -t vboxsf share /lugar-a-montar

Sin embargo esto no es así en debian (y derivados también, no se en otras distros), al menos al utilizar VBox 4.3.10. Por alguna razón cambiaron de lugar el path donde se instalan las Guest Additions, o bien apuntaron mal el enlace de mount.vboxsf... sea cual sea la razón, al intentar montar una partición, mount dará error y syslog dirá:

sf_read_super_aux err=-22

Para evitar esto, tenemos dos alternativas:
1. Linkear el directorio desde donde debería estar a donde realmente está:

ln -s /opt/VBoxGuestAdditions-4.3.10/lib/VBoxGuestAdditions /usr/lib/

2. O linkear el ejecutable mount.vboxsf a donde está el ejecutable realmente:

rm /sbin/mount.vboxsf
ln -s /opt/VBoxGuestAdditions-4.3.10/lib/VBoxGuestAdditions/mount.vboxsf /sbin/mount.vboxsf

Bien, esto debería alcanzar... salvo en algunos casos. Increíblemente si dejamos el mismo nombre de share que el del directorio al que apunta el share (por ejemplo usar el share "datos" para apuntar al directorio /datos), mount fallará horriblemente diciendo:

/sbin/mount.vboxsf: mounting failed with the error: Protocol error

Mientras que syslog indicará lo siguiente:

sf_read_super_aux err=-71

WTF?! si, increíble. Así que recuerden llamar distinto al share que a la carpeta a la que apunta. Por ejemplo, ponerle vdatos al share que apunta a /datos en el host (siguiendo el ejemplo anterior).

Ahora si, a montar felizmente (?!).

Referencias

Shared folders will not mount after 3.10 update
Mounting share directory on Linux host result in Protocol error if default share name is used

Instalar Zabbix en Debian GNU/Linux

noreply@blogger.com (V3kt0r) — Fri, 6 Jun 2014 16:20:00 -0300

Después de haber leído muchas buenas críticas acerca de Zabbix, decidí instalarlo sobre un debian para probarlo. Dado que no fue una tarea trivial, decidí documentarla para facilitarle la vida a alguien más. Para empezar, salvo un artículo específico, no encontré documentación que explique bien cómo utilizar los paquetes provistos en debian. Debian trae Zabbix en sus repositorios, pero instalar el servicio no es tan directo como instalar los paquetes, requiere varios pasos adicionales. Esto me molestó bastante, dado que se podría automatizar todo este proceso en la misma instalación del paquete. Igualmente, conociendo los pasos, no es una tarea compleja, sólo algo tediosa :P El artículo en el que me basé para la instalación es How To Install Zabbix on Ubuntu & Configure it to Monitor Multiple VPS Servers.

Instalar los paquetes necesarios
Para instalar Zabbix, ejecutar lo siguiente:

# apt-get install apache2 php5-mysql mysql-server zabbix-server-mysql zabbix-frontend-php

Los paquetes de Apache, PHP5 y MySQL sólo son necesarios si aún no los instalaron, se agregan por completitud. Los paquetes de Zabbix crean los archivos del servidor zabbix, y copian los archivos del front-end en /usr/share, pero sólo eso... restan varios pasos. Es posible instalar Zabbix sobre PostgreSQL.

Configuración base de datos

Los paquetes instalados no crean la base de datos, ni el usuario, por lo que hay que hacerlo manualmente. Los siguientes pasos explican cómo hacer este proceso:

Desde MySQL (i.e. logueados con $mysql -u root -p), crear la base de datos, el usuario y asignarle permisos:

mysql> create database zabbix_db;
mysql> create user 'zabbix_usr'@'localhost' identified by 'ELpassword';
mysql> grant all privileges on zabbix_db.* to 'zabbix_usr'@'localhost';
mysql> flush privileges;

Crear las tablas y asignar los valores default provistos por Zabbix. Para esto existen los archivos /usr/share/zabbix-server-mysql/{schema.sql.gz, images.sql.gz, data.sql.gz}. Descomprimirlos y ejecutarlos con MySQL, con destino la base de datos recién creada.

/usr/share/zabbix-server-mysql$ gunzip schema.sql.gz images.sql.gz data.sql.gz
$ mysql -u root -p zabbix_db < schema.sql
$ mysql -u root -p zabbix_db < images.sql
$ mysql -u root -p zabbix_db < data.sql

Servidor Zabbix

Según la definición de la base de datos, hay que adaptar el archivo de configuración del serivicio Zabbix. Debe editarse el archivo /etc/zabbix/zabbix_server.conf y ajustar los siguientes valores:

DBName=zabbix_db
DBUser=zabbix_usr
DBPassword=ELpassword

Además, dado que por defecto el servicio Zabbix no inicia automáticamente, debe editarse el archivo /etc/default/zabbix-server y dejar la siguiente sentencia:

START=yes

Luego si podremos iniciar el servicio:

# /etc/init.d/zabbix-server start

Front-End Web

Para habilitar el front end web, deben realizarse los siguientes pasos:

Copiar el archivo de configuración de Apache, provisto en el paquete Zabbix, a su lugar correspondiente, para habilitar el acceso web:
# cp /usr/share/doc/zabbix-frontend-php/examples/apache.conf /etc/apache2/conf-enabled/zabbix.conf
En versiones anteriores de debian, los archivos de configuración se copian en /etc/apache2/conf.d

Editar el archivo /etc/php5/apache2/php.ini y asignar los siguientes valores a las variables correspondientes, para adaptar la configuración de PHP a los requerimientos de Zabbix

post_max_size = 16M
max_execution_time = 300
max_input_time = 300
date.timezone = America/Argentina/Buenos_Aires
donde el timezone dependerá de su ubicación (ver List of Supported Timezones).
Reiniciar el servidor Apache:

# service apache2 restart
Abrir, desde el navegador, la página de Zabbix. La misma se encuentra en http://<IP del servidor>/zabbix. Esto redirige al wizzard de configuración inicial, donde:

2- Se chequea que los requisitos para correr Zabbix se cumplan. Si alguno no se cumple, mostrará un fail y no permitirá seguir hasta tanto se corrija.
3- Solicita se configuren los datos de la base de datos. Si MySQL no aparece entre las opciones, es que les falta el paquete php5-mysql
4- Permite asignar los valores del servidor Zabbix. Si no cambiaron nada en la configuración del server, dejar los que están por defecto.
5- Muestra el resultado de la configuración y permite revisar los valores antes de terminar.
6- Intenta crear el archivo /etc/zabbix/zabbix.conf.php. Si el servicio no tiene permiso para hacerlo (lo cual será así), descargar el archivo y copiarlo manualmente en el directorio correspondiente.
Una vez creado el archivo, clickear "Retry" y mostrará un mensaje OK. Clickear "Finish" para ir a la página principal.
Ingresar al sistema con el usuario admin y contraseña zabbix.

Fin

AirWatch MDM Review

noreply@blogger.com (V3kt0r) — Wed, 21 May 2014 16:50:00 -0300

Hace un tiempo comenzamos a utilizar dispositivos Android en la empresa y se hizo evidente que necesitaríamos un software para administrarlos. Desde hace varios años utilizamos BlackBerry, para lo cual contamos con BlackBerry Enterprise Server (BES). Personalmente BES siempre me pareció una cagada, tiene sus cosas buenas y fue uno de los pioneros del rubro, pero las cosas no andan bien. Los servicios de BB en general siempre me parecieron una bosta. Que algún administrador de BES me diga si al menos una vez al mes (o a la semana) algún BB deja de sincronizar los mails y encuentra otro remedio más que desvincular el equipo y volver a vincurlarlo? si, a veces se soluciona con una reiniciada, pero muchas veces no! y lo peor es que es imposible saber la causa.

Bueno, dejando mi resentimiento hacia BES, volvemos a Android. Android es una plataforma muy buena, pero creo que no tan orientada a las empresas todavía. De a poco va queriendo, pero todavía le falta bastante. El tema es que los dispositivos Android parecen estar pensados solamente para el usuario hogareño. Para poder utilizar este sistema a nivel corporativo, necesitamos una herramienta que nos brinde ciertas funcionalidades.

Veamos primero qué es lo que se necesita para poder administrar dispositivos móviles en general, y luego nos adentraremos en AirWatch en particular.

Introducción MDM para Android

Mi experiencia me permite distinguir las siguientes necesidades, a la hora de administrar dispositivos móviles Android (u otros) corporativos:

Uso de mail corporativo: Android soporta ActiveSync para poder utilizar un servidor de correo Exchange. La necesidad que identifico es poder administrar esta conexión desde un software centralizado.
Políticas de seguridad: muy pero muy importante es poder aplicar restricciones a los equipos. Como la mayoría sabe, existen miles de aplicaciones maliciosas para Android. Si permitimos a cualquier usuario instalar cualquier cosa, vamos a tener un grave problema. Las políticas de seguridad deben permitir:

Forzar uso de PIN o patrón para bloquear el dispositivo.
Bloquear la instalación y desinstalación de aplicaciones. Así como no queremos que instalen nada, también queremos que no desinstalen software básico.
Bloquear "reset to factory" del equipo. Si borran la configuración, después pueden hacer cualquier cosa.
Bloquear el cambio de ciertas capacidades estéticas, como cambio de wallpaper.

Instalación remota de aplicaciones: bien, no permitimos instalar aplicaciones al usuario, pero si el mismo necesita algo para sus tareas, debemos poder instalarselo. Estos usuarios puede que no estén físicamente en las instalaciones de la empresa, así que poder instalar aplicaciones desde el administrador, es un requisito.
Uso de encripción: dado que los equipos pueden transportar información sensible, es necesario poder activar la encripción de la tarjeta de memoria y/o memoria del equipo.
Bloqueo / Wipe remoto: si un dispositivo es robado o perdido, el administrador debe poder bloquearlo e incluso borrarlo para que no se accedan a los datos de la empresa.
Configuración centralizada: tener que configurar muchos dispositivos de a uno, no solo estresa a cualquiera, sino que es una pérdida de tiempo. La mejor alternativa es realizar la configuración una vez, y que todos los dispositivos la apliquen al conectarse.

Los programas que proveen estas funcionalidades se denominan Mobile Device Management (MDM), y hay varios dando vueltas. El mismo BES es un MDM que implementa las funcionalidades descriptas. Uno de estos MDMs es AirWatch y en él me enfocaré el resto del artículo. AirWatch, según sus propias palabras, es el MDM líder a nivel empresarial.

AirWatch

Estuve utilizándo AirWatch durante un par de semanas, haciendo varias pruebas, y quería compartir mi experiencia con esta herramienta, por si alguno de ustedes está buscando algún MDM y está indeciso. Les comentaré tanto las cosas buenas, como las cosas malas que encontré al utilizarlo.

Para empezar, me pareció muy útil que soporte múltiples sistemas operativos (Android, iOS, BlackBerry, Symbian, Windows Phone, Mac OS X, entre otros). Si el parque de dispositivos no es homogéneo, como en nuestro caso, esto es una característica importante. Es importante observar aquí que no es la panacea. Si bien el soporte de sistemas operativos existe, en muchos casos el soporte es muy limitado. Por ejemplo, no podrán reemplazar BES por AirWatch para administrar los BlackBerry, ya que las características que AirWatch soporta para BB son muy (MUY) limitadas.
En cada opción de configuración de AirWatch, podrán observar al costado, qué sistemas operativos la soportan. Incluso dependiendo la versión del sistema operativo, puede que la opción esté disponible o no (por ejemplo, algunas cosas disponibles para Android 3, no están disponibles para Android 2). A favor de AirWatch hay que decir que en muchos casos la limitación la pone el sistema operativo. Si el sistema operativo no provee una forma de evitar el uso de la cámara, el software no podrá hacerlo.
Otro punto a tener en cuenta, es que la mayoría de las opciones de configuración para Android, sólo están disponibles para dispositivos SAFE (Samsung For Enterprises). Si no adquirieron dispositivos Android que sean SAFE, casi que ni les conviene utilizar AirWatch.

AirWatch implementa todos los puntos listados en la introducción, aunque no todos para todos los sistemas operativos. Para equipos SAFE, todas las opciones están disponibles, teniendo algunas limitaciones en cuanto a la granularidad.
Algo interesante es que AirWatch permite organizar los dispositivos en unidades organizativas (por ejemplo, departamento), y a los usuarios por grupos. Luego es posible definir perfiles (que incluyen políticas de uso, certificados, bookmarks, VPN, WiFi, etc) por unidad organizativa y por grupo de usuario. Esto brinda la flexibilidad de poder definir, por ejemplo, que ciertas restricciones se apliquen a los usuarios de comercial, que se encuentren en el grupo de usuarios atención al cliente. La organización de los grupos resulta un poco confusa al principio, pero luego del uso se va afinando.

La instalación remota de aplicaciones existe, pero no es del todo directa. Es posible distribuir tanto aplicaciones públicas, como adquiridas por la empresa (llámese APK). Es posible instalar las APK sin intervención del usuario, pero si es una aplicación de la Play Store, requerirá la intervención del usuario, algo para nada conveniente. Tal vez sea algo que me falló a mi, pero luego de varias pruebas, no logré que se instale algo directamente.

Dado que muchos dispositivos incluyen aplicaciones que tal vez no deseamos (Google trae algunas que en modo usuario son imposible desinstalar... llámese Gmail, G+, etc), es posible desinstalarlas/desactivarlas mediante AirWatch. Este es un punto muy a favor del software, dado que sin rootear el dispositivo no es posible eliminar ciertas aplicaciones. Además es posible restringir la instalación de aplicaciones y no permitir que el usuario desinstale las importantes. Esto se logra con los grupos de aplicaciones Blacklisted, Whitelisted y Required. Todas las listas se arman con los IDs de las aplicaciones. Cada aplicación tiene un ID único, como com.google.android.gm para GMail.

Blacklisted permite listar las aplicaciones explícitamente prohibidas. Si una aplicación está en esta lista, no se podrá instalar.
Whitelisted, si está activa, restringe que no se instale ninguna aplicación que no se encuentre en la lista.
Required no permite que el usuario desinstale ninguna de las aplicaciones listadas.

Me parece importante remarcar que las aplicaciones que vienen "de fábrica" como GMail, seguirán instaladas incluso si utilizamos la Whitelist y no la incluímos. La única forma que logré de remover estas aplicaciones es listándolas explícitamente en la Blacklist.
El único aspecto negativo que encontré en esta funcionalidad, es que el sistema permite al usuario llegar hasta el último paso de la instalación antes de decirle "está prohibido instalar la aplicación". Estaría bueno que no lo permitiera de entrada.

Otro aspecto que en nuestro caso era importante, es dónde está instalado el servidor. Para empezar, AirWatch vende el servicio en la nube, es decir, está el servidor instalado en algún lugar del ciberespacio, y nosotros lo administramos remotamente. Consultando con un agente oficial, me indicaron que también es posible instalar el sistema on-site, es decir, tener nuestro propio servidor AirWatch. El requerimiento para hacerlo es contratar por lo menos 100 licencias, donde las licencias son por dispositivos... para hacer una prueba inicial no resulta muy atractivo tener que contratar 100 licencias. Como dato extra, cada licencia cuesta entre 5 y 6 dólares mensuales. No estoy para nada a favor de colocar datos de la empresa en la nube, mucho menos información de dispositivos, que incluye localización, registro de llamadas, mensajes, etc, pero en este caso, no tuvimos opción.

Algo que todavía no mencioné es que la interfaz de administración es Web. La interfaz es, a mi gusto, poco intuitiva y confusa. No es fácil familiarizarse con ella, e incluso luego de utilizarla un par de semanas, a veces no encuentro las cosas. Tal vez sea una mera impresión mia, pero conversando con mis compañeros de trabajo, les dio la misma sensación. La primer gran confución es la diferencia entre los usuarios. Existen dos tipos de usuarios, los administradores, y los "dueños" de dispositivos. Los primeros tienen permiso de administrar la aplicación, y mediante roles se puede restringir lo que pueden hacer. Los segundos se utilizan para registrar equipos. Es decir, cuando damos de alta un equipo, éste debe pertenecer a algún usuario, por lo que antes habrá que dar de alta el usuario. Cada uno de estos usuarios puede tener asignado uno o más equipos.
Otra confusión es dónde estamos parados. Como cada dispositivo pertenece a una unidad organizativa, si estamos en una de ellas, no podremos ver los dispositivos en otras (salvo que estemos en la OU raíz, donde podemos ver todos). Lo mismo sucede con los usuarios.
Un problema que encontré aquí es mover dispositivos o usuarios entre unidades organizativas... simplemente, no pude. Si el usuario tiene asignado un dispositivo que se encuentra en una dada OU, no se puede mover el usuario, y lo mismo pasa con los dispositivos.
Más allá de ser confusa, tengo para decir a favor de la interfaz que genera interesantes gráficos. El dashboard es muy visual y La información sobre los dispositivos es muy completa.

Un aspecto muy negativo, es la falta de documentación. Googlear cómo hacer algo en AirWatch es prácticamente inútil. Sólo se encuentran broshures de propaganda. Incluso en la página de AirWatch no encontrás los manuales! Tienen una sección de whitepapers que no me resultó muy útil. Por suerte, nuestro proveedor de AirWatch en la nube brindó un buen soporte a nuestras consultas, y nos entregaron un manual oficial... aunque este manual oficial no era muy completo tampoco. En fin, punto negativo en cuanto a documentación.

Agente AirWatch

La administración de los dispositivos se logra instalando un agente AirWatch en cada uno de ellos. Este agente se instala desde la Play Store de Google (en el caso de Android), y se registra en el servidor utilizando una URL de enrollment (que no es la misma que la de administración), el ID de la unidad organizativa, y un usuario del tipo "dispositivo" (no uno de administración).

Para la instalación encuentro como punto negativo que no se provea una APK. El uso de la Play Store de Google fuerza registrar una cuenta Google. Para un dispositivo corporativo, por qué la empresa debería tener cuentas Google? Parte del monopolio encubierto de Google.

Una vez que se registra el dispositivo, se aplica la configuración indicada por el servidor, la cual incluye el perfil del usuario. Acá encontré otro problema. Si bien el agente provee una forma de forzar la sincronización, la aplicación del perfil no siempre funciona. Tuve muchísimos problemas creando bookmarks desde el servidor. A veces el agente los borra, no se actualizan...

Encontré riesgoso el echo de no poder prohibir la desactivación del agente. Si bien encontré la forma de que el usuario no desinstale el agente (Required list, descripta anteriormente), no encontré la forma de que el usuario no desactive el agente. Una vez que se desactiva el agente, el usuario sigue teniendo las restricciones, pero el servidor pierde el contacto con el dispositivo.

Conclusión

AirWatch es un muy buen comienzo en la administración centralizada de dispositivos móviles. Sin embargo, creo que odavía tienen mucho camino por delante. Tal vez dependa mucho de la evolución de los sistemas operativos como Android, que seguramente tomarán un approuch cada vez más empresarial, como BB.
No utilizaría AirWatch como reemplazo de BES. Si tienen dispositivos BB, debido al limitado soporte, recomiendo seguir utilizando BES por más feo que sea :P

Como puntos a favor encuentro que:

Implementa las características más importantes de un MDM.
Brinda muy buena información sobre los dispositivos.
Permite una buena restricción de las aplicaciones instaladas y que no se pueden desinstalar.
Soporte de múltiples sistemas operativos.
Aplicación de políticas por grupos de usuarios y/o dispositivos. Facilidad de generar perfiles y aplicar uno o más a cada dispositivo.

En contra, encuentro que:

La interfaz web de administración no es muy intuitiva.
La documentación casi inexistente, ya que una vez que nos vamos adentrando en el software y queremos hilar más fino, no se encuentra información al respecto.
El soporte de Android es principalmente para equipos SAFE, y salvo iOS, las características disponibles para el resto de los SOs es muy limitada.
El agente falla cada tanto y no aplica correctamente los perfiles.
Se requieren demasiadas licencias (al menos 100) para poder instalar el servicio on-site.

Thunderbird/Icedove como cliente de Mails, Calendario y Libreta de direcciones de Exchange

noreply@blogger.com (V3kt0r) — Thu, 8 May 2014 14:33:00 -0300

El conjunto de herramientas de Exchange utilizado en entornos Windows, es muy importante en la mayoría de las empresas. Para tener una Workstation GNU/Linux totalmente funcional con respecto a sus pares Windows, necesitamos integrar tanto mails, como calendario y libreta de direcciones, provistos por Exchange.

Por suerte, existe una excelente herramienta denominada DavMail que nos facilita la vida. Esta herramienta actúa de proxy entre el cliente de mails que utilicemos (Thunderbird/Icedoe, Evolution, etc) y el servidor Exchange. Para ello, transforma protocolos estándar (IMAP, SMTP, LDAP, etc) en solicitudes WebDav (extensión del protocolo HTTP) reconocidas por el servicio OWA de Exchange.

A continuación explicaré cómo utilizar Thunderbird/Icedove como cliente de mails, calendario y libreta de direcciones provistos por Exchange, a través de DavMail. La explicación está basada en los tutoriales provistos en la propia página de DavMail: IMAP Thunderbird mail setup, Thunderbird calendar setup y Thunderbird directory setup. Además, la explicación está basada sobre debian GNU/Linux, pero la configuración es igual para otras distribuciones e incluso Windows.

Instalación y configuración de DavMail

Descargar DavMail desde su página en sourceforge. Dirigirse al directorio de instalación y ejecutar:
#dpkg -i davmail.deb # ver nombre real del paquete descargado, o renombrarlo
#apt-get -f install # instala todas las dependencias necesarias para davmail

DavMail también está disponible para Windows y Mac, dado que está programado en Java.

Una vez instalado DavMail, debe ejecutarse. Lo recomendable es linkearlo para que se ejecute al inicio de sesión del usuario, así no tenemos que ejecutarlo a mano cada vez que queramos usarlo. En la primera ejecución hay que configurarlo para que apunte al servidor Exchange.
Los campos requeridos, como base, se encuentran en la pestaña Main, y son los siguientes:
- Exchange Protocol: elegir EWS para Exchange 2010, o WebDav para Exchange 2007.
- OWA (Exchange URL): la URL del servidor Exchange, por ejemplo: https://miserver.com/OWA
- Elejir los puertos locales en los que DavMail debe esperar conexiones POP, IMAP, SMTP, Caldav y LDAP. El cliente que configuremos, se conectará a estos puertos. Pueden dejar los puertos default y desactivar alguno de los protocolos si no son necesarios (POP por ejemplo).

Configuración de la cuenta de mail en Thunderbird/Icedove

Los pasos para configurar la cuenta de dominio en el cliente Thunderbird, son los siguientes:
1- Elegir Crear una nueva cuenta de e-mail. Dependiendo de si ya tienen configurada alguna cuenta o no, los pasos pueden variar un poco al principio.
- Si no tienen una cuenta definida, el wizzard busca para crear una cuenta con alguno de sus partners. Si este es el caso, clickear el botón "Saltear esto y usar mi correo existente".
- Si ya tienen otra cuenta en Thunderbird, ir a "Editar -> Configuración de Cuentas...", elegir "Acciones de cuenta -> Agregar una cuenta de correo".
2- Completar el campo de Nombre y dirección de mail en la configuración de la cuenta. Aconsejo destildar la opción recordar contraseña. Dar continuar.

3- Al dar continuar, Thunderbird fallará en la comprobación del dominio y les solicitará que ingresen los datos manualmente. En la configuración, utilizar los siguientes valores:

Entrante/Incoming:
IMAP (pueden elegir POP, pero IMAP es más completo)
Nombre del servidor: localhost
Puerto: el puerto que configuraron en DavMail. Por defecto es 1143.
SSL: Ninguno.
Autenticación: Contraseña normal.
Saliente/Outgoing:
Nombre del servidor: localhost
Puerto: el puerto que configuraron en DavMail para SMTP. Por defecto 1025.
SSL: Ninguno.
Autenticación: Contraseña normal.
Nombre de usuario: su nombre de usuario en el dominio, agregando el nombre del dominio: DOMINIO\usuario

Tal vez DavMail indique que el servidor Exchange provee un certificado no confiable. Esto sucede si el servidor utiliza un certificado autofirmado, o firmado por una CA local. Dar aceptar.

Calendario

Para configurar el calendario, debemos instalar la extensión iceowl-extension (extensión Lightning):
# apt-get install iceowl-extension

Luego, desde Thunderbird/Icedove abrimos el calendario "Events and Tasks -> Calendar", y realizamos los siguientes pasos:
1- Click derecho en el panel izquierdo (deben tener el predefinido calendario "Home") y clickeamos "New Calendar".
2- En la ventana que aparece, elegimos "On the Network", luego "Siguiente".

3- En la siguiente opción elegimos "CalDAV" en el formato, y utilizamos la siguiente dirección para el "Location": http://localhost:1080/users/usuario@dominio.com/calendar, donde deberán reemplazar usuario@dominio.com por su usuario y dominio.

4- Una vez que terminen, les solicitará un nombre de calendario, color, si desean recibir recordatorios. Configurar a gusto.
5- Para finalizar, les solicitará las credenciales de dominio. Hay que colocarlas como en el caso de los mails, utilizando el formato DOMINIO\usuario para el nombre de usuario.

Libreta global de direcciones

La libreta global de direcciones de Exchange se habilita de la siguiente manera:

1- Ir a "Herramientas -> Libreta de direcciones".
2- En la ventana emergente, seleccionar "Archivo -> Nuevo -> Directorio LDAP".
3- Abre una nueva ventana, donde se nos solicitan los siguientes datos:
Nombre: el que ustedes elijan (ej: Exchange)
Servidor: localhost
DN base: ou=people
Número de puerto: 1389 (ver la configuración de DavMail para saber qué puerto usar con LDAP, por defecto es 1389)
DN para inicio de sesión: DOMINIO\usuario

Para que Icedove autocomplete con las direcciones de la libreta global, hay que ir a "Editar -> Preferencias -> solapa Redacción". Allí tildar la opción "Servidor de directorios" y elegir la libreta recién creada.

Cuando vayan a redactar un e-mail, Thunderbird/Icedove les solicitará la contraseña del usuario de dominio.

Ejecutar e Instalar Android en VirtualBox

noreply@blogger.com (V3kt0r) — Tue, 8 Apr 2014 12:04:00 -0300

El otro día leí el interesante artículo de linuxito, Cómo instalar Android en una máquina virtual QEMU/KVM y me alentó a probarlo. Para hacerlo, preferí utilizar VirtualBox, ya que tengo todas mis máquinas virtuales ahí, y me pareció bueno publicar mi experiencia, como complemento a la de linuxito.

No conocía la versión x86 de Android. Hasta ahora había utilizado Android desde el SDK, mediante Android Virtual Devices (AVD). Este emulador es muy completo, pero también muy pesado, y la ejecución no es muy fluida que digamos (salvo que tengas una máquina muy potente). No me pasó lo mismo con la virtualización mediante VirtualBox.

Creación de la máquina virtual

Para empezar, descarguemos la última imagen de Android para x86 desde la página del proyecto. Algo a tener en cuenta es que esta versión de Android es para tablets, por lo que algunas aplicaciones para celulares como WhatsApp no funcionarán.

La máquina virtual que creemos en VirtualBox debe tener ciertas características, dado que Android aparentemente no trae todos los drivers y tiene requerimientos mínimos. Para la configuración base de la virtual, me basé en la información de Android x86 - VirtualBoxHowTo.
Utilicemos la siguiente definición:

- Tipo: Linux
- Versión: 2.6
- Disco: 10GB deberían ser suficientes.
- Memoria: 256MB como mínimo, 512MB recomendado. Yo le pondría 1GB para que funcione bien fluído.
- Memoria de video (Pantalla -> Vídeo): 8MB
- Controlador de audio (Audio): SoundBlaster 16
- Red: Utilizar NAT o bridge. En modo bridge es necesario un servidor DHCP.
- Tipo de adaptador: PCnet-FAST III
- Montar la imagen ISO de Android en la lectora virtual (Almacenamiento -> Controller: IDE)

Ejecución de prueba

Al iniciar la máquina virtual, vemos que existen varias opciones de booteo. Si quieren hacer una prueba antes de instalar, pueden ejecutar Android en modo live (primer opción).

En modo live, solamente nos solicitará que configuremos el idioma, la red WiFi, y nos preguntará sobre la localización. Como estamos en una virtual, y sólo queremos probar el sistema, dar skip a la configuración del WiFi y no tildar ninguna de las opciones de localización.

El sistema inicia en cuestión de segundos y vemos el escritorio de Android. Acá me topé con un problema. Si están utilizando la integración del mouse de VirtualBox, probablemente les suceda que no ven el puntero dentro de la máquina virtual. Esto hace casi imposible su uso. Para solucionarlo, simplemente hay que deshabilitar la integración desde VirtualBox:

Máquina -> Inhabilitar integración del ratón (Ctrl + I)

Instalación de Android

Para instalar Android en el disco virtual, debemos iniciar desde el cd y realizar los siguientes pasos:

Seleccionar el modo instalación en GRUB.
Una vez que se carga el sistema de instalación, aparece el gestor de particiones.
En el mismo seleccionar "Create/Modify partitions", con lo cual se abre cfdisk
Aquí seleccionar New -> Primary y dejar el tamaño completo del disco. Cuando la partición aparece, marcarla como booteable (opción Bootable).
Luego dar a la opción Write para que se guarden los cambios. Esta opción preguntará si estamos seguros de lo que vamos a hacer, pues decir que yes!
Una vez terminado esto, seleccionar Quit para salir. Esto nos retorna a la pantalla anterior, en la cual ahora podemos seleccionar la partición para instalar el sistema.
Seleccionarla y formatearla con ext3.
Al formatear el sistema consultará de nuevo si estamos seguros de lo que deseamos hacer, responder nuevamente que yes!
Luego se nos consulta si deseamos instalar grub como boot loader. Seleccionar que si.
Para finalizar, el sistema nos pregunta si deseamos hacer que /system sea un directorio de lectura+escritura. Esto permitirá mejor debugging, pero ocupará más espacio y la instalación demorará más. Dar que si, tampoco es tanto lo que pesa (ni lo que tarda).
Cuando termina la copia de archivos, seleccionar reiniciar para ejecutar el nuevo sistema.

Como podrán observar, la instalación completa no demora más de 10 minutos (en mi caso no demoró ni 5).

Primer ejecución

La primer ejecución solicitará que configuremos algunas cosas:

Idioma: seleccionar el que más les guste.
Configuración de WiFi: seleccionar skip, usaremos la conexión física.
Cuenta de Google: sin una cuenta de Google configurada no se puede hacer mucho en Android, pero pueden pasar este paso sin configurar una.
Enviar información de localización a Google: en este paso se nos consulta si deseamos información de localización "anonimamente" a Google. Al no tener GPS en la máquina virtual, no hace diferencia dejar tildadas o no las opciones.
Nombre: la tablet necesita un nombre para personalizar aplicaciones. Pongan lo que gusten.

Configuraciones básicas

Al usar un rato Android en la virtual, encontré algunos problemas. El primero que encontré es que al abrir alguna aplicación, se rota la pantalla y no puedo retornar a la posición original. Como se imaginarán, usar el sistema rotado 90º no es nada cómodo! Esto se puede solucionar fácilmente deshabilitando el auto-rotate:

Aplicaciones -> Settings -> Accessibility -> Destildar Auto-rotate scree

Otro problema es que cuando se apaga la pantalla para ahorrar energía, no puedo recuperar el control. Para evitar esto deshabilité el modo sleep:

Aplicaciones -> Settings -> Display -> Sleep -> Never Timeout

Comentarios finales

Usar la versión de Android x86 en VirtualBox u otras máquinas virtuales es muy simple y anda mucho mejor que usar AVD. Sin embargo AVD es mucho más completo que esta versión, dado que trae múltiples versiones de Android para múltiples dispositivos.
Hay que tener en cuenta que si no configuran una cuenta Google, no podrán instalar nada... prácticas monopólicas? naaaa

Probar aplicaciones en el ambiente virtualizado es mucho mejor que andar instalando porquerías en una tablet o un celular directamente. Esto nos permitirá conocer Android más a fondo, dado que no tendremos miedo de romper un caro aparato. También nos servirá para testear como se ven y ejecutan aplicaciones web.

En resumen, jueguen con este Android, que para eso está :)

Monitoreo de ancho de banda en routers/switches/etc usando MRTG

noreply@blogger.com (V3kt0r) — Thu, 13 Mar 2014 15:39:00 -0300

Luego de tener algunos problemas de saturación de ancho de banda, me volqué a la búsqueda de una herramienta que pueda graficar el uso de los links.
Comencé la búsqueda con herramientas que puedan graficar datos almacenados en archivos pcap, creados con tcpdump o wireshark, para lo cual encontré tcptrace. Si bien tcptrace es una herramienta interesante, me resultó bastante anticuada para lo que yo necesitaba, que era una visualización simple del uso de los links.

Continuando la búsqueda, me orienté a herramientas que obtengan resultados por SNMP, en lugar de archivos pcap. De esta manera fui a dar con Multi Router Traffic Grapher (MRTG). Descubrí que esta herramienta es muy utilizada, e incluso en la propia página de Cisco proveen información sobre cómo usar MRTG (una búsqueda en google "mrtg site:www.cisco.com" mostrará muchos resultados).

Según la descripción en la página oficial:

MRTG monitorea dispositivos de red por SNMP y dibuja lindas imágenes mostrando cuánto tráfico ha pasado a través de cada interfaz.

Si bien la idea parece ser monitorear routers, la herramienta permite ir más allá y monitorear cualquier dispositivo de red que envíe información de uso de interfaces a través de SNMP. Y no sólo eso, también permite monitorear uso de CPU, disco y memoria.
MRTG está escrito en perl y funciona tanto en GNU/Linux como en Windows (además de NetWare... por si a alguien le interesa), y es libre, licenciado mediante GPL.

Si bien llevo un par de días probándolo, MRTG me parece la solución ideal para la tarea de monitoreo de links, y es un adicional muy interesante poder monitorear CPU, memoria y disco. Lo estoy probando con un switch Cisco Catalyst de más de 200 ports y va de lujo.
Este es un ejemplo de los gráficos que muestra:

Bueno, básta de cháchara y pasemos a lo importante, cómo instalar y configurarlo.

Instalación

La instalación es muy simple, dado que el paquete se encuentra en los repositorios de las distribuciones más importantes. Hay que tener en cuenta que se necesita tener un servidor web instalado, como ser Apache.

En debian, MRTG se instala simplemente ejecutando:
# apt-get install mrtg

Mientras que en derivados de Red Hat (CentOS, Fedora) es:
# yum -y install mrtg

La instalación crea un archivo de configuración básico que no tiene prácticamente nada. En debian el archivo de configuración es /etc/mrtg.cfg, mientras que en derivados Red Hat es /etc/mrtg/mrtg.cfg. Además se crea un archivo cron en /etc/cron.d/mrtg.
El resto de la explicación la haré basándome en debian, que es donde lo probé, pero para los derivados de Red Hat sólo cambian los paths a los archivos.

En debian hay que crear el directorio que hospede los archivos web. Dependiendo de su configuración del servidor web, el path puede variar, pero por defecto, el directorio se crearía en /var/www:
# mkdir /var/www/mrtg

Cambiamos el grupo owner para que Apache tenga más permisos sobre los archivos:
# chown root:www-data /var/www/mrtg

Configuración

La configuración básica de MRTG es muy simple. La forma más rápida y fácil de tener una configuración que realice pull de un dispositivo para ver el uso de ancho de banda, es usando la herramienta cfgmaker (instalada por el paquete mrtg) de la siguiente manera:

# cfgmaker --global 'WorkDir: /var/www/mrtg' --output /etc/mrtg.cfg public@192.168.1.10

donde:

--global 'WorkDir: /var/www/mrtg' especifica el directorio donde se pondrán los datos recaudados, es decir, el del server web,
--output /etc/mrtg.cfg especifica el archivo de configuración a crear,
public@192.168.1.10 indica que se use la comunidad SNMP "public" y que la IP del dispositivo es 192.168.1.10.

La comunidad "public" es la default en muchos dispositivos y por seguridad debe cambiarse, dado que es la "contraseña" de acceso a los datos SNMP. Obviamente el dispositivo que estemos consultando debe tener habilitadas las consultas SNMP con la comunidad utilizada.

cfgmaker generará un nuevo archivo mrtg.cfg que contiene configuraciones globales, así como definiciones para cada interfaz que el dispositivo reporte en el pull SNMP. Lo más destacable de la configuración global es la sentencia "WorkDir:" que especifica el directorio pasado por parámetro.

El siguiente paso es generar los archivos web para la configuración recién creada. Para ello, se utiliza la herramienta indexmaker, que también viene con mrtg. La generación de dichos archivos se realiza de la siguiente manera:

# indexmaker /etc/mrtg.cfg --output /var/www/mrtg/index.html

donde:

/etc/mrtg.cfg es el archivo de configuración,
--output /var/www/mrtg/index.html es la ubicación y nombre del archivo index principal.

Ejecución de MRTG

Con todo en su lugar, ahora debemos ejecutar mrtg. La instalación genera un archivo cron que ejecutará MRTG cada 5 minutos. Cada vez que se ejecuta, obtiene los valores de las interfaces para los dispositivos configurados, los almacena en su base de datos RRD, y crea los gráficos.

Para ver si todo está bien, lo mejor es ejecutar al menos una vez el programa por consola, de la siguiente manera:

# env LANG=C /usr/bin/mrtg

env LANG=C se utiliza para setear la variable de entorno LANG, dado que si utilizan otro valor como UTF-8, arrojará un error.

La primera vez que ejecuten mrtg arrojará varios errores del tipo "no encuentro tal archivo". Esto es normal, dado que los archivos que busca todavía no existen y se crean con la primer ejecución. Ejecuciones sucesivas no deberían arrojar estos errores.

Una vez que se prueba que todo está bien, ya no hace falta ejecutarlo a mano, dado que de eso se encargará cron.

Acceder a las gráficas es tan simple como apuntar con el navegador a la dirección del servidor donde se encuentra instalado MRTG. Por ejemplo:

http://192.168.1.100/mrtg

Configuración avanzada

Vimos como realizar una configuración de forma casi automática. Ahora, dependiendo lo que deseen monitorear y cómo, deberán editar el archivo de configuración creado con cfgmaker, o bien crearlo de cero.
Para esto hace falta conocer un poco más la estructura del archivo de configuración. El mismo se divide básicamente en tres secciones: opciones globales, configuración de targets y definición de thresholds. Listaré las opciones que me parecen más importantes de cada una, para poder tunear la herramienta un poco.
Es interesante tener en cuenta que se pueden incluir otros archivos de configuración en el de la configuración global, utilizando el keyword "Include". Por ejemplo: Inlude: switches.inc.

Global

Entre las opciones globales, destaco:

WorkDir: establece el directorio de trabajo, donde se ubican los archivos de log y web. En el ejemplo básico, el directorio se estableció a /var/www/mrtg, pero se puede cambiar al que se desee.
Es posible cambiar el directorio donde se ubican los html (HtmlDir), logs (LogDir) e imagenes (ImageDir). Si se utilizan estas opciones, no debe establecerse el WorkDir, dado que sobreescribe estas opciones.
Forks: permite definir cuántos procesos disparar para realizar consultas SNMP. Si se tienen que consultar muchos dispositivos, utilizar más de un proceso a la vez puede optimizar considerablemente la tarea.
Interval: tiempo, en minutos, que transcurre entre ejecuciones de mrtg (por defecto es 5 minutos). Esto se refleja en los gráficos web, y se utilizar en modo daemon.
Language: permite setear el lenguaje en el cual se muestran los datos web. MTRG soporta múltiples lenguajes, y tranquilamente podríamos elegir "spanish" como valor.
RunAsDaemon: muy interesante opción que permite independizarnos de cron y optimizar la ejeción. Si se setea en yes, no hace falta llamar el programa mrtg desde cron cada cierto intervalo de tiempo, sino que el programa se ejecuta una vez y luego queda en ejecución, realizando actualizaciones al intervalo seteado.
En este caso es importante setear la opción "Interval" citada anteriormente, y eliminar la entrada de cron, dado que cada ejecución de mrtg iniciará un demonio nuevo.
Esta opción debería utilizarse siempre, dado que ejecutar el programa con cron conlleva la creación del proceso y tener que releer los archivos de configuración cada vez.

Ejemplo de configuración global:
WorkDir: /var/www/mrtg
Forks: 3
Language: spanish
RunAsDaemon: yes
Interval: 5

Targets

La definición de targets tiene una cantidad de opciones abrumadora, por lo que listaré algunas que me parecen las principales. Cada target debe tener un nombre único, y el nombre debe agregarse a cada parámetro que pertenezca al mismo target (entre corchetes). Este nombre se usa también para el nombre de los archivos web, log e imágenes.

Target: es la principal sentencia al definir un dispositivo a monitorear. Acepta muchos formatos (y cuando digo muchos, es MUCHOS) para definir el target. Las formas más comunes son las siguientes:
- Basica: "puerto:comunidad@router"
  donde:
  - puerto: es el número de la interfaz en el router a monitorear. La documentación no dice mucho al respecto, pero al menos en los Cisco, los puertos se numeran de forma consecutiva desde la primer placa, y arrancan desde el valor 2. Por ejemplo, la Fa0/37 pasa a ser el puerto 38, mientras que la Gi1/1 es el puerto 50 (es la interfaz 49 - por los 48 de la primer placa-, más 1 porque arranca en 2 la numeración).
  - comunidad: es la comunidad SNMP que asignaron en el dispositivo.
  - router: es el nombre DNS o la dirección IP del router/switch/etc a monitorear.
  Ejemplo: definición para graficar la interfaz 38 de un switch 3560.
  Target[switch3560_2]: 39:public@192.168.1.10
- OIDs explícitos: "OID_1&OID_2:comunidad@router". Los OIDs son los identificadores SNMP que determinan los valores a obtener. Los OIDs están en cierta forma estandarizados, pero cada fabricante puede definir los que quiera. MTRG necesita al menos dos OIDs para realizar sus gráficos (uno lo dibuja en verde y el otro en azul). Esto no necesariamente necesita tener dos OIDs distintos, tranquilamente se puede especificar el mismo OID dos veces.
  Ejemplo: graficar el uso de CPU.
  Target[switch3560_1]: 1.3.6.1.4.1.9.2.1.57.0&1.3.6.1.4.1.9.2.1.57.0:public@192.168.1.10
Hay muchas otras formas de definir targets, así que si necesitan otra, busquen en el manual que están bien descriptas.
MaxBytes: especifica los valores máximos que cualquiera de los dos valores medidos puede tomar. En el caso de interfaces, los tamaños máximos serían la velocidad soportada. Tener en cuenta que el valor es en bytes, no bits se especifica en las interfaces: 100 MB Ethernet = 12500000.
Ejemplo:
MaxBytes[switch3560_2]: 12500000
Title: el string que se muestra en la barra del título de la página Web.
Ejemplo:
Title[switch3560_2]: Analisis de trafico Switch 3560
PageTop: texto a agregar al tope de la página HTML definida para el target. Hay que tener en cuenta que se pueden usar varias líneas, siempre que la primer columna esté vacío.
Ejemplo:
PageTop[switch3560]: <h1>Analisis de trafico Switch 3560</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>Switch 3560 in </td>
</tr>
<tr>
<td>Max Speed:</td>
<td>125.0 MBytes/s</td>
</tr>
</table>
</div>
Directory: si se especifica, los archivos web, para ese target, se ubicarán allí en lugar del WorkDir (o HtmlDir, LogDir, ImageDir). El directorio debe ser creado manualmente, dado que mrtg no lo creará.
Ejemplo: colocar los archivos del switch3560 en el directorio /var/www/mrtg/switches
Directory[switch3560]: /var/www/mrtg/switches
XSize e YSize: permiten especificar el tamaño del gráfico. Por defecto, los gráficos son de 400x100 pixels. Xsize debe estar comprendido entre 20 y 600, mientras que YSize debe ser mayor a 20.
Ejemplo:
XSize[switch3560_2]: 600
YSize[switch3560_2]: 150
XZoom e YZoom: permiten hacer zoom en el gráfico.
Ejemplo:
XZoom[switch3560_2]: 2.0
YSize[switch3560_2]: 2.0
Options: permite setear algunos valores booleanos. Por ejemplo, por defecto los gráficos son en bytes y el tiempo se grafica de derecha a izquierda. Es posible cambiar este valor a algo más intuitivo, como valores en bits y que el gráfico crezca de izquierda a derecha:
Options[switch3560]: growright, bits
Existen muchas otras opciones para setear por gráfico, y se pueden encontrar en la documentación.

Un dato interesante es que, dado que muchas definiciones de targets comparten la misma configuración, o configuraciones similares, mtrg permite utilizar valores default. Los datos default se configuran de la misma manera que se especifico para los targets, pero usando los caracteres _ ^ y $
En todos los casos, un valor en blanco, borra la configuración default. Cada una de las configuraciones default pueden ser sobre-escritas más abajo, con otra configuración default. Esto permite usar valores default distintos para distintos targets.
Veamos las opciones de configuración:

Valores default se especifican con el underscore "_". Las definiciones en targets sobreescriben este valor.
Ejemplo: Especificar que todos los gráficos sean en bps, y crezcan hacia la derecha
Options[_]: growright, bits
El signo "^" permite pre-agregar texto a valores definidos en los targets.
Ejemplo: poner en el título de todos los targets el valor "Analisis MRTG -"
Title[^]: Analisis MRTG -
Ahora, si por ejemplo se define el target switch3560:
Title[switch3560_2]: Switch 3560 Fa0/2
El resultado será una página con el título "Analisis MRTG - Switch 3560 Fa0/2".
Finalmente, el signo peso "$" permite agregar texto al final de valores definidos en los targets.
Ejemplo: agregar el texto "- Laboratorio" a todos los títulos.
Title[$]: - Laboratorio

Ejemplo completo de configuración de Target (interfaz FastEthernet0/1 en switch 3560):

Options[_]: growright, bits
XSize[_]: 600
YSize[_]: 150
XZoom[_]: 2.0
YSize[_]: 2.0
Title[^]: Analisis MRTG -
Target[switch3560_2]: 39:public@192.168.1.10
MaxBytes[switch3560_2]: 12500000
Title[switch3560_2]: Switch 3560 Fa0/2
PageTop[switch3560]: <h1>Analisis de trafico Switch 3560</h1>
<div id="sysdetails">
<table>
<tr>
<td>System:</td>
<td>Switch 3560 in </td>
</tr>
<tr>
<td>Max Speed:</td>
<td>125.0 MBytes/s</td>
</tr>
</table>
</div>

Thresholds

La definición de thresholds permite realizar alguna acción cuando los valores sobrepasen un límite pre-establecido. Las acciones posibles son llamar un script externo o mandar un mail. Si se define llamar a un script externo, puede utilizarse la variable SetEnv para enviar parámetros extra.

Como ejemplo de uso de thresholds, veamos la configuración para mandar un mail cuando la interfaz 2 del switch 3560 supera los 90Mb/s:

# Directorio donde colocar los valores de threshold almacenados
ThreshDir: /var/www/mrtg/thresh
# Servidor de mail a utilizar
ThreshMailServer: mail.midominio.com
# Dirección a poner en el from del mail
ThreshMailSender: mtrg@midominio.com
# Definir a quienes mandar e-mail cuando se supere un límite. Se puede definir por host
ThreshMailAddress[_]: admin@midominio.com
# Definicion de limite maximo de uso de una interfaz (90Mb/s = 11.25MB/s = 11796480 Bytes/s)
ThreshMaxI[switch3560_2]: 11796480

Tener en cuenta el uso de "ThreshDir", dado que sin él, mrtg no tiene donde almacenar los datos de mediciones de límites, causando que cada detección sea independiente y mandando muchos mails. Es decir, estamos interesados que nos informe si superamos los 90Mb/s una vez, y hasta que no baje de 90Mb/s, no vuelva a mandar otro mail.

Monitoreo Cisco

Para poder monitorear dispositivos Cisco, primero hay que habilitar una comunidad SNMP para ser accedida en modo lectura. El nombre de la comunidad es el "password" para acceder a la información, por lo que debe mantenerse secreta.
Adicionalmente se puede setear una access-list que brinde acceso al servidor SNMP sólo a la IP elegida.
La configuración es la siguiente:

(config)# snmp-server community ro 50 (config)# access-list 50 permit

Referencias

- MRTG 2.17.4 configuration reference
- MRTG (Multi Router Traffic Grapher) en Debian-Ubuntu
- Network Monitoring Using Free Linux Tools
- MRTG Configuration in Debian
- Quick HOWTO : Ch23 : Advanced MRTG for Linux
- Use MRTG to monitor bandwidth
- Cisco Task 3--Using MRTG to Monitor and Graph Traffic Loads

Cargar scripts JavaScript una sola vez + llamar función cuando la carga termina

noreply@blogger.com (V3kt0r) — Sat, 28 Dec 2013 07:56:00 -0300

Programando interfaces con JavaScript me topé con un problema al que no encontré una solución concreta. Cuando tenemos una página dinámica que carga scripts JS usando AJAX a medida que los va necesitando, podemos caer en el problema de cargar el mismo script más de una vez. Esto se debe a que de antemano no sabemos si el script se cargó o no y lo necesitamos para cumplir alguna función. Un ejemplo rápido de ver es el caso de asignar un evento a un componente. Supongamos que tenemos una página con el siguiente componente: <DIV ID="contenedor">contenido</DIV> y tenemos una sección que cambia según el accionar del usuario, pero carga un script jQuery de la siguiente forma:

$.getScript('/js/bind.js');

cuyo contenido es el siguiente:

$('#contenedor').click(function(event){ $("#contenedor").append("hola"); });

Si llamamos la misma sección más de una vez, lo que sucederá es que el evento click se enlaza más de una vez al componente "contenedor", haciendo que la palabra "hola" se agregue varias veces, en lugar de una sola vez como se esperaría. Van entendiendo por dónde va el problema? De alguna forma, la sección que carga el script debería saber que el script ya se cargó y no debería cargarlo de nuevo. El tema es cómo saber esto... En internet encontré algunas alternativas (sobre todo en StackOverflow) que explican cómo escapar este problema, pero al parecer ni JavaScript, ni jQuery implementan una solución directa, el programador debe encargarse de diseñar una función a tal fin. Otro problema con el que me topé relacionado a esto es cómo saber en qué momento se terminaron de cargar varios scripts. Si usas jQuery, ellos recomiendan usar la función $(document).ready() para esperar a que la página se cargue. La realidad es que cuando se cargan scripts con $.getScript, el evento ready no espera a que estos scripts se carguen. No obstante $.getScript permite definir una función como parámetro que será llamada cuando el script se termine de cargar... pero y si queremos esperar a que un conjunto de scripts se carguen? Para matar dos pájaros de un tiro (los problemas citados), diseñé una función jQuery denominada load_script, la cual decidí compartir con el mundo porque ninguna de las soluciones que encontré me pareció completa. Esta función está basada en distintas propuestas de distintos usuarios de StackOverflow. La función utiliza dos variables globales: loaded_scripts y loading_scripts. loaded_scripts mantiene la lista de scripts que ya se cargaron, así no se los vuelve a cargar nuevamente, mientras que loading_scripts mantiene la lista de scripts que se están cargando actualmente, para saber en qué momento se terminó de cargar todo. Los parámetros de la función son: script_list y callback. script_list es un arreglo con la lista de scripts que se deben cargar y por los cuales debe esperarse a que carguen, mientras que callback es una función definida por el programador que se llamará cuando todos los scripts se terminen de cargar.

/**
 * Load the given JavaScript scripts and call the callback function when all of them are fully loaded.
 * Each script is loaded only once, meanning that if this function is called two times with the same script name
 * it will be loaded the first time. This avoids problems like redeclared functions or variables, event binded more than
 * once, and every other error produced by a script loaded multiple times.
 * The function uses two global array variables:
 *  loaded_scripts: scripts that has been already loaded. Used to know which scripts should not be loaded again.
 *  loaded_scripts: scripts that are in loading process. Used to know when the loading process is done.
 * 
 * @param script_list array containing the scripts links to load. Ex: ['/js/load_this.js', '/js/binder.js']
 * @param callback the function to call when loading of the scripts is done.
 */
var loaded_scripts = Array();
var loading_scripts = Array();
jQuery.fn.load_scripts = function(script_list, callback)
{
  var script;
  
  //check for already loaded scripts and so they're not loaded again
  for(s in script_list)
  {
    if(loaded_scripts.indexOf(script_list[s]) == -1)
      loading_scripts.push(script_list[s]);
  }
  
  //if all the requested scripts are already loaded, callback and return
  if(loading_scripts.length == 0)
  {
    callback();
    return;
  }
  
  for(s in loading_scripts)
  {
    script = loading_scripts[s];
    $.getScript(script,  function() {
      //when script is loaded, remove it from the loading scripts array.
      //if it's the last script on the array, it means we're done loading, so call the callback function.
      loading_scripts.splice(loading_scripts.indexOf(script), 1);
      loaded_scripts.push(script);
      if((loading_scripts.length == 0) && (callback !== undefined))
 callback();
    });
  }
}

Un ejemplo de uso es el siguiente:

$(window).load_scripts(['/js/load_this.js', '/js/binder.js'], function() {
    $('#contenedor').click(function(event){
        $("#contenedor").append("hola");
    });
});

Espero que la función les sirva, al menos como ejemplo, ya que por lo que vi es un problema recurrente en los foros. Si encuentran algún error en el código, me avisan en los comentarios ;)

Obtener información de Wikipedia a través de su API

noreply@blogger.com (V3kt0r) — Thu, 19 Dec 2013 20:14:00 -0300

Desde hace un tiempo me venía planteando la posibilidad de tomar información de Wikipedia para completar la información de ciertos ítems. Pensé, para qué reescribir información que ya existe de forma libre? mejor sería aportar y mejorar los artículos de Wikipedia.

Por programas como Amarok o Clementine (que uso a diario), sabía que Wikipedia tenía alguna especie de web service para tomar información. Buscando encontré que MediaWiki, el software detrás de Wikipedia, provee una API que permite realizar consultas de diversos tipos. Esta web service viene habilitado por defecto cuando instalan el software, y Wikipedia permite su uso de forma gratuita. La API no sólo permite consultar información, sino también modificar el contenido de los artículos en sus bases de datos.

Como la información provista en la descripción de la API me resultó algo escasa o muy desparramada, me pareció interesante explicar brevemente como realizar request de artículos.

Para empezar, necesitamos saber que la URL del web service es la siguiente:
http://@lc.wikipedia.org/w/api.php
donde @lc debe reemplazarse por el código del lenguaje del artículo que se desea obtener. Por ejemplo, si queremos el artículo de la Wikipedia en inglés, el código será 'en' (http://en.wikipedia.org/w/api.php), mientras que para el español, el código será 'es' (http://es.wikipedia.org/w/api.php).
A esta URL deben pasarse dos parámetros obligatorios, y estos parámetros fuerzan el uso de otros para especificar lo que se desea obtener. Existen muchos posibles parámetros y estos se encuentran documentados en MediaWiki - API:Properties.

Los parámetros obligatorios para obtener contenido son los siguientes:
- format: especifica en qué formato retornar el contenido. Los formatos disponibles actualmente son:
    - json: formato JSON. Soporta la opción callback que permite especificar una función javascript a llamar cuando la carga del contenido esté completa.
    - php: formato serialized de PHP.
    - wddx: formato WDDX.
    - xml
    - yaml
    - rawfm: formato JSON con elementos de debugging (HTML) y callback.
    - txt: PHP print_r().
    - dbg: PHP var_export().
    - dump: PHP var_dump().
    Si bien la API soporta múltiples formatos, tienen pensado removerlos y dejar sólo JSON. En el artículo me centraré sólo en el uso de JSON.
- action: especifica qué acción realizar. MediaWiki soporta más de 15 acciones, las cuales están descriptas aquí. La acción que nos ocupa en nuestro caso es 'query'. query es una de las acciones más importantes y está documentada aquí.

Hasta ahora contamos con la siguiente URL para obtener contenido, a la cual iremos agregando parámetros según lo que necesitemos:
http://en.wikipedia.org/w/api.php?format=json&action=query

Ahora bien, la acción 'query' requiere los siguientes parámetros adicionales para obtener contenido:
- titles, pageids, revids: es necesario utilizar uno de estos tres parámetros para especificar la página que deseamos, ya sea por el título de la misma (titles), su ID (pageids) o el ID de la revisión (revids). Cabe aclarar aca que cada página tiene múltiples revisiones, siendo la más actual la que se está mostrando. Estos parámetros soportan requests de múltiples páginas a la vez, separando el título/ID/revID de cada una utilizando el símbolo | (ejemplo: titles=PáginaA|PáginaB|PáginaC). MediaWiki aconseja solicitar múltiples páginas a la vez para ahorrar procesamiento y ancho de banda.
En caso de utilizar el título para obtener la página, es necesario normalizarlo antes. La normalización del título implica poner en mayúsculas la primer letra, reemplazar todos los espacios con underscore '_', y ajustar el nombre al lenguaje que se está solicitando.
- prop: se utiliza para obtener diversos datos acerca de la/s página/s especificadas con titles/pageids/revids. Cada propiedad conlleva el uso de otro parámetro para especificar información adicional sobre lo que se desea. Las propiedades se encuentran documentadas aquí, siendo las que más nos interesan en nuestro caso, las siguientes:
    - info: recupera información básica acerca de una página. Este valor de prop requiere un parámetro adicional, que puede ser inprop (propiedades a obtener, separadas con el símbolo '|'), intoken o incontinue.
    - revisions: retorna las revisiones de la página solicitada, o bien la última revisión de cada una de las páginas listadas (en caso de solicitar más de una página). Revisions cuenta con varios posibles parámetros, de los cuales los que más nos interesan en este artículo son:
      - rvprop: indica qué propiedad obtener de cada revisión. Existen diversas propiedades que se pueden obtener, siendo 'content' la que nos interesa, dado que es la que indica que deseamos obtener el contenido de la revisión. Si no se especifica otro parámetro, se retornará sólo la revisión actual de la página.
      - rvparse: indica que el contenido retornado debe ser parseado y convertido a HTML. Si no se especifica este comando, el contenido será retornado en formato wikitext.
    - imageinfo/ii: obtiene información de imágenes. Esta propiedad también cuenta con varios posibles parámetros, de los cuales nos interesa iiprop. iiprop permite obtener distintos atributos de una imagen, y de estos nos resultan interesantes 'url' y 'size', que permiten obtener la URL donde se encuentra la imágen y el tamaño de la misma.

Además de los listados, los siguientes dos parámetros también son de mucha utilidad:
- redirects: se puede utilizar en conjunto con titles, para que MediaWiki resuelva los redirects necesarios para llegar al contenido, en caso que el título solicitado realice un redirect.
- continue: en muchos casos, no se retorna todo el contenido en un sólo request. Cuando esto sucede, MediaWiki incluye la variable continue en su respuesta para indicar que hay más contenido por retornar. Para estos casos, se puede utilizar el parámetro continue (sin ningún valor) y así obtener la continuación del último request.

Ya con la teoría, ahora podemos ver como todo esto funciona en la práctica. Como comenté anteriormente, las URLs que armaremos buscan obtener información en formato json, por lo que los parámetros format=json y action=query estarán en ellas.

Como caso de ejemplo tomemos la wiki en español de Mahatma Gandhi. Como no sabemos el ID de la página, podemos buscar usar el título. Para empezar, debemos normalizar el título antes de poder utilizarlo en la query. En este caso, debemos reemplazar el espacio por el underscore, es decir, queda Mahatma_Gandhi.
La información que deseamos traer es la última revisión del artículo, así que elegimos la propiedad "revisions" y el parámetro rvprop=content, para que traiga el contenido:
http://es.wikipedia.org/w/api.php?format=json&action=query&titles=Mahatma_Gandhi&prop=revisions&rvprop=content

El formato del contenido retornado es el siguiente:
{
    "query": información y resultado de la consulta. Es un objeto compuesto por:
    {
      "normalized": título normalizado
      "pages": lista de páginas retornadas por la consulta. Es un arreglo asociativo cuyos índices son los IDs de las páginas. Cada elemento del arreglo está compuesto por:
      {
         "ns":
         "pageid": el ID de la página.
   "revisions": arreglo que contiene todas las revisiones de la página. Está ordenado de revisión más nueva a más antigua, siendo 0 la versión actual. Cada uno de estos arreglos. Este arreglo contiene un arreglo con un solo ítem cuyo índice es el símbolo '*', y es éste el que contiene el contenido de la revisión.
         "title": el título de la página.
      }
    }
    "warnings": contiene warnings que arroja el servidor. Por ejemplo, cuando un título no se encuentra, se retorna un warning en este objeto.
}
Según lo visto, el contenido de la revisión se puede acceder de la siguiente manera: respuesta.query.pages[].revisions[0]['*']. Si consultamos por una sola página, tendremos un sólo ID de página.

El contenido retornado es texto con formato wikitext. Wikitext es un lenguaje de marcado liviano, es decir, como HTML o LaTeX, pero mucho más simple. El mismo se encuentra descripto en Help:Wiki markup. Existen parsers para este lenguaje, programados en distintos lenguajes. Una lista de parsers se puede encontrar en MediaWiki - Alternative parsers.
En caso que deseen obtener texto formateado en HTML, pueden utilizar el parámetro rvparse de la siguiente manera:
http://es.wikipedia.org/w/api.php?format=json&action=query&titles=Mahatma_Gandhi&prop=revisions&rvprop=content&rvparse

Cuando vemos el contenido retornado en formato wikitext, observamos que las imágenes no tienen el link a donde se encuentran hosteadas, sino una referencia como "Archivo:Gandhi Nehru Indira.jpg". Si normalizamos el nombre del archivo y adherimos el contenido de lo anterior a un link de Wikipedia, encontramos que se obtiene la imagen en el sitio de Wikipedia: http://es.wikipedia.org/wiki/Archivo:Gandhi_Nehru_Indira.jpg. Pero si queremos embeber la imagen en nuestro site, debemos conocer la URL de la imagen. Para ello se utiliza la propiedad imageinfo, el parámetro iiprop=url|size y el nombre normalizado de la siguiente manera:
http://es.wikipedia.org/w/api.php?format=json&action=query&titles=Archivo:Gandhi_Nehru_Indira.jpg&prop=imageinfo&iiprop=url|size
La cual responde con un objeto similar al anterior, pero en este caso el arreglo "pages" contiene solo un ítem con índice "-1". Este ítem es un objeto que ahora contiene un atributo denominado imageinfo, que es un arreglo de imagenes. Como solicitamos sólo una imagen, tendrá un solo elemento. Cada elemento de este arreglo tiene el siguiente formato:
"size": el tamaño de la imagen.
"width": el ancho de la imagen.
"height": el alto.
"url": la URL donde la imagen se encuentra hosteada.
Es decir, la URL se puede obtener de la siguiente manera: respuesta.query.pages[-1].imageinfo[0].url

Bien, con esto ya podemos hacer consultas a Wikipedia y obtener tanto el texto como las imagenes. Formatear el texto obtenido, si lo obtienen en lenguaje wikitext, es otro tema. Estuve programando un parser en javascript, el cual interpreta parte del lenguaje, pero todo lo que se encuentra encerrado entre llaves "{}" tiene muchas variantes e interpretarlo todo no es tan simple. Algún día publicaré el código si es que lo termino. Entre los parsers que se encuentran en la página que cité, implementan parte de lenguaje, no se si hay alguno que interprete todo.

Espero que les resulte útil la información, ya que me costó un par de días interpretar e implementar lo básico de lo que provee esta API.

Herramientas de Seguridad (scanners, sniffers, spoofers, IDS, web hacking, auditoría, exploitation y más!)

noreply@blogger.com (V3kt0r) — Thu, 14 Nov 2013 05:02:00 -0300

Cuantos meses sin publicar nada! pero, aunque no lo crean, el blog sigue vivo!
Para compensar la prolongada ausencia y conmemorar que llegamos a los 200 posts, decidí postear algo groso, algo que venía prometiendo hace rato y que por fiaca de ponerme a editar, no publiqué antes: el listado de aplicaciones de seguridad.
Este listado es el resultado de 4 años de recopilación, trabajando en seguridad, y a ojo contiene más de 150 herramientas! Ahora que dejé la seguridad un poco de lado para concentrarme más en redes y comunicaciones, creo que es un buen momento para publicarlo.
Todas las herramientas están con sus respectivos links oficiales y una breve descripción.

Antes de pasar al listado, les dejo algunas aclaraciones:
- Hay muchas herramientas que nunca utilicé. Armé el listado a partir de leer muchos artículos y descripciones de programas, e incluí todos los que me parecían útiles para distintas tareas.
- Emiliano (quien publicó varios artículos en este blog) colaboró en su momento con varias entradas de la lista. Ahora Emi administra su propio blog denominado linuxito.com.ar
- Agrupé las herramientas en base a distintos criterios. Varias encajan en más de un criterio, pero obviamente no iba a repetirlas en cada uno, así que están en el que me parece las describe mejor.
- El orden en que se encuentran las herramientas no tienen ningún significado, se fueron agregando aleatoriamente. Si bien traté de dejar las más importantes en los primeros lugares, pueden aparecer en cualquier posición.
- Como el listado se empezó a armar hace 4 años, puede que algunos links estén rotos, o que la herramienta no tenga más soporte.
- Hay varias herramientas que no se vinculan directamente a seguridad, pero sirven para realizar tests de seguridad.
- La gran mayoría de las aplicaciones listadas son libres y para GNU/Linux, pero hay algunas que son cerradas y pagas, y algunas que funcionan sólo en Windows.
- El listado no es completo y existen muchas y muy importantes herramientas que no se encuentran en él.

Live-CDs/DVDs

- BackTrack Linux - Linux-based penetration testing arsenal that aids security professionals in the ability to perform assessments in a purely native environment dedicated to hacking

- Wifislax - distribución GNU/Linux (LiveCD) diseñada para la auditoría de seguridad del estándar 802.11. (WiFi, BlueTooth y RFID).

- DEFT - includes an excellent hardware detection and the best free and open source applications dedicated to Incident Response, Cyber Intelligence and Computer Forensics.

- Pentoo - un Live CD/USB desarrollado para llevar a cabo procesos de Test de Penetración y/o Ethical Hacking. Esta distribución está basada en Gentoo Linux (kernel 2.6.31.6), gestor de ventanas Enlightenment e incluye una amplia colección de herramientas debidamente organizadas por categorías.

- Security Onion - Security Onion is a Linux distro for IDS, NSM, and log management.

- VAST - a VIPER Lab live distribution that contains VIPER developed tools such as UCsniff, videojak, videosnarf and more. Along with VIPER tools and other essential VoIP security tools, it also contains tools penetration testers utilize such as Metasploit, Nmap, and Hydra.

- Network Security Toolkit - The main intent of developing this toolkit was to provide the network security administrator with a comprehensive set of Open Source Network Security Tools.

- Katana - includes distributions which focus on Penetration Testing, Auditing, Password Cracking, Forensics and Honey Pots. Katana comes with over 100 portable Windows applications such as Wireshark, HiJackThis, Unstoppable Copier, and OllyDBG.

- Matriux - fully featured security distribution consisting of a bunch of powerful, open source and free tools that can be used for various purposes including, but not limited to, penetration testing, ethical hacking, system and network administration, cyber forensics investigations, security testing, vulnerability analysis, and much more.

- Samurai - The Samurai Web Testing Framework is a live linux environment that has been pre-configured to function as a web pen-testing environment. The CD contains the best of the open source and free tools that focus on testing and attacking websites.

- REMnux - lightweight Linux distribution for assisting malware analysts in reverse-engineering malicious software.

- PlainSight - versatile computer forensics environment that allows inexperienced forensic practitioners perform common tasks using powerful open source tools.

- WeakNet Linux - designed primarily for penetration testing, forensic analysis and other security tasks.
The tools selected are those that the developer feels are used most often in pen-tests. A sample of those included are: BRuWRT-FORSSE v2.0, Easy-SSHd, Web-Hacking-Portal v2.0, Perlwd, Netgh0st v3.0, YouTube-Thief!, Netgh0st v2.2, DomainScan, ADtrace, Admin-Tool, Tartarus v0.1.

- Puck - GNU/Linux distribution distributed as a Live CD based on TinyCoreLinux. It contains top penetration testing tools.

- Metasploitable - an Ubuntu server install on a VMWare image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older mysql.

Scanners

- Nmap - free and open source utility for network discovery and security auditing. Many systems and network administrators also find it useful for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime.

- Netcat - networking utility which reads and writes data across network connections, using the TCP/IP protocol.

- hping - command-line oriented TCP/IP packet assembler/analyzer. The interface is inspired to the ping(8) unix command, but hping isn't only able to send ICMP echo requests. It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.

- haraldscan - Bluetooth discovery scanner.

- Natprobe - This little, but very usefull program, try to sends ICMP packet out the LAN, and detect all the host that allow it. Whit this you can find bugs in your (company?) network (or others), for example hosts that allow p2p connections.

- MSSQLScan - A small multi-threaded tool that scans for Microsoft SQL Servers. The tool does it’s discovery by using UDP and returns a list of all detected instances with there respective protocols and ports.

- hostmap - enumerate all hostnames and configured virtual hosts on an IP address.

- FindDomains - multithreaded search engine discovery tool that will be very useful for penetration testers dealing with discovering domain names/web sites/virtual hosts which are located on too many IP addresses.

- keimpx - It can be used to quickly check for the usefulness of credentials across a network over SMB. Credentials can be: Combination of user / plain-text password, Combination of user / NTLM hash, Combination of user / NTLM logon session token.

- StreamArmor - sophisticated tool for discovering hidden alternate data streams (ADS) as well as clean them completely from the system.

- Halberd - a tool aimed at discovering real servers behind virtual IPs.

- NSDECODER - automated website malware detection tools. It can be used to decode and analyze weather the URL exist malware. Also, NSDECODER will analyze which vulnerability been exploit and the original source address of malware.

- sslyze - Cross-platform tool to analyze the configuration of SSL servers.

Sniffers

- wireshark - world's foremost network protocol analyzer. It lets you see what's happening on your network at a microscopic level. It is the de facto (and often de jure) standard across many industries and educational institutions.

- tcpdump - prints out a description of the contents of packets on a network interface that match the boolean expression.

- arpwatch - thernet monitor program; for keeping track of ethernet/ip address pairings.

- ucsniff - VoIP & IP Video Security Assessment tool that integrates existing open source software into several useful features, allowing VoIP and IP Video owners and security professionals to rapidly test for the threat of unauthorized VoIP and Video Eavesdropping.

- webmitm - transparently proxies and sniffs HTTP / HTTPS traffic redirected by dnsspoof, capturing most "secure" SSL-encrypted webmail logins and form submissions.

- dsniff - collection of tools for network auditing and penetration testing. dsniff, filesnarf, mailsnarf, msgsnarf, urlsnarf, and webspy passively monitor a network for interesting data (passwords, e-mail, files, etc.). arpspoof, dnsspoof, and macof facilitate the interception of network traffic normally unavailable to an attacker (e.g, due to layer-2 switching). sshmitm and webmitm implement active monkey-in-the-middle attacks against redirected SSH and HTTPS sessions by exploiting weak bindings in ad-hoc PKI.

- RawCap - RawCap is a free command line network sniffer for Windows that uses raw sockets.

- Yamas - a tool that aims at facilitating mitm attacks by automating the whole process from setting up ip forwarding and modifying iptables, to the ARP cache poisoning

Spoofing

- arpspoof - may allow an attacker to sniff data frames on a local area network (LAN), modify the traffic, or stop the traffic altogether.

- dnsspoof - forges replies to arbitrary DNS address / pointer queries on the internal LAN. This is useful in bypassing host name based access controls, or in implementing a variety of efficient network controls.

IDS

- snort - open source network intrusion prevention and detection system (IDS/IPS).

- OSSEC - scalable, multi-platform, open source Host-based Intrusion Detection System (HIDS). It has a powerful correlation and analysis engine, integrating log analysis, file integrity checking, Windows registry monitoring, centralized policy enforcement, rootkit detection, real-time alerting and active response.

- Samhain - open source host-based intrusion detection system (HIDS) provides file integrity checking and logfile monitoring/analysis, as well as rootkit detection, port monitoring, detection of rogue SUID executables, and hidden processes.

- Nebula - network intrusion signature generator. It can help securing a network by automatically deriving and installing filter rules from attack traces. In a common setup, nebula runs as a daemon and receives attacks from honeypots. Signatures are currently published in Snort format.

- suricata - The Suricata Engine is an Open Source Next Generation Intrusion Detection and Prevention Engine. This engine is not intended to just replace or emulate the existing tools in the industry, but will bring new ideas and technologies to the field.

- Osiris - Host Integrity Monitoring System that periodically monitors one or more hosts for change. Osiris keeps an administrator apprised of possible attacks and/or nasty little trojans. The purpose here is to isolate changes that indicate a break-in or a compromised system.

- Sagan - multi-threaded, real time system and event log monitoring system, but with a twist. Sagan uses a "Snort" like rule set for detecting bad things happening on your network and/or computer systems. If Sagan detects a "bad thing" happening, that event can be stored to a Snort database (MySQL/PostgreSQL) and Sagan will attempt to correlate the event with your Snort Intrusion Detection/Intrusion Prevention (IDS/IPS) system.

- Snorby - new and modern Snort IDS front-end. The basic fundamental concepts behind snorby are simplicity and power.

- Smooth-sec - ready to-go IDS/IPS (Intrusion Detection/Prevention System) linux distribution based on the multi threaded Suricata IDS/IPS engine and Snorby, the top notch web application for network security monitoring.

- ArpON - portable handler daemon that make ARP secure in order to avoid the Man In The Middle (MITM) through ARP Spoofing/Poisoning attacks. It detects and blocks also derived attacks by it for more complex attacks, as: DHCP Spoofing, DNS Spoofing, WEB Spoofing, Session Hijacking and SSL/TLS Hijacking & co attacks.

Firewalls

- iQfire-wall - framework that implements a network firewall. It can be used in desktop systems and in simple network configurations, providing a friendly graphical interface and a simple installation procedure. Also unprivileged users can personalize.

- Firestarter - Open Source visual firewall program. The software aims to combine ease of use with powerful features, therefore serving both Linux desktop users and system administrators.

- IPCop - Linux firewall distribution.

- Firewall Builder - Firewall Builder is a GUI firewall configuration and management tool that supports iptables (netfilter), ipfilter, pf, ipfw, Cisco PIX (FWSM, ASA) and Cisco routers extended access lists.

- GreenSQL - Open Source database firewall used to protect databases from SQL injection attacks. GreenSQL works as a proxy and has built in support for MySQL. The logic is based on evaluation of SQL commands using a risk scoring matrix as well as blocking known db administrative commands (DROP, CREATE, etc). GreenSQL provides MySQL database security solution.

- Flint - examines firewalls, quickly computes the effect of all the configuration rules, and then spots problems so you can: CLEAN UP RUSTY CONFIGURATIONS that are crudded up with rules that can't match traffic; ERADICATE LATENT SECURITY PROBLEMS lurking in overly-permissive rules; SANITY CHECK CHANGES to see if new rules create problems.

Honeypots

- HoneyDrive - virtual hard disk drive (VMDK format) with Ubuntu Server. It contains various honeypot systems such as Kippo SSH honeypot, Dionaea malware honeypot and Honeyd. Additionally it includes useful scripts and utilities to analyze and visualize the data it captures. Lastly, other helpful tools like tshark (command-line Wireshark), pdftools, etc. are also present.

Auditory

- Nessus - vulnerability scanner. Provides patch, configuration, and compliance auditing; mobile, malware, and botnet discovery; sensitive data identification; and many other features.

- OpenVAS - Open Vulnerability Assessment System and is a network security scanner with associated tools like a graphical user front-end. The core component is a server with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications.

- SAINT - Vulnerability Scanning, Penetration Testing, Social Engineering, Configuration Assessments, Reporting.

- PenTBox - Security Suite with programs like Password Crackers, Denial of Service testing tools (DoS and DDoS), Secure Password Generators, Honeypots and much more.

- Seccubus - runs Nessus scans at regular intervals and compares the findings of the last scan with the findings of the previous scan. The delta of this scan is presented in a web GUI when findingscan be easily marked as either real findings or non-issues. Non issues get ignored untill they change. This causes a dramaticreduction a analysis time.

- GrokEVT - collection of scripts built for reading Windows® NT/2K/XP/2K3 event log files. GrokEVT is released under the GNU GPL, and is implemented in Python.

- Flawfinder - program that examines source code and reports possible security weaknesses (``flaws'') sorted by risk level. It's very useful for quickly finding and removing at least some potential security problems before a program is widely released to the public.

- KrbGuess - small and simple tool which can be used during security testing to guess valid usernames against a Kerberos environment.

- Webfwlog - flexible web-based firewall log analyzer and reporting tool. It supports standard system logs for linux, FreeBSD, OpenBSD, NetBSD, Solaris, Irix, OS X, etc. as well as Windows XP. Supported log file formats are netfilter, ipfilter, ipfw, ipchains and Windows XP. Webfwlog also supports logs saved in a database using the ULOGD target of the linux netfilter project.

- YASAT - (Yet Another Stupid Audit Tool) is a simple stupid audit tool. It do many tests for checking security configuration issue or others good practice.

- FireCAT (Firefox Catalog of Auditing exTension) - mindmap collection of the most efficient and useful firefox extensions oriented application security auditing and assessment.

- keimpx - keimpx is an open source tool, released under a modified version of Apache License 1.1. It can be used to quickly check for the usefulness of credentials across a network over SMB.

- Buck Security - collection of security checks for Linux. It was designed for Debian and Ubuntu servers, but can be useful for any Linux system.

- DllHijackAuditor - smart tool to Audit against the Dll Hijacking Vulnerability in any Windows application.

- Mantra - a collection of free and open source tools integrated into a web browser, which can become handy for students, penetration testers, web application developers, security professionals etc.

- MysqlPasswordAuditor - FREE Mysql password recovery and auditing software. Mysql is one of the popular and powerful database software used by most of the web based and server side applications.

PDFs

- origami - Ruby framework designed to parse, analyze, and forge PDF documents. This is NOT a PDF rendering library. It aims at providing a scripting tool to generate and analyze malicious PDF files. As well, it can be used to create on-the-fly customized PDFs, or to inject (evil) code into already existing documents.

- pdfinjector - Script to inject javascript code into existing pdf files.

- PDFResurrect - tool aimed at analyzing PDF documents. The PDF format allows for previous document changes to be retained in a more recent version of the document, thereby creating a running history of changes for the document.

File vulnerabilities checkers

- OfficeCat) - command line utility that can be used to process Microsoft Office Documents for the presence of potential exploit conditions in the file.

Exploitation

- Metasploit - penetration testing software. Helps verify vulnerabilities and manage security assessments.

- Weevely - stealth PHP web shell that provides a telnet-like console. It is an essential tool for web application post exploitation, and can be used as stealth backdoor or as a web shell to manage legit web accounts, even free hosted ones.

- XLSInjector - Injects meterpreter shell to excel xls files (Port 4444).

- Armitage - graphical cyber attack management tool for Metasploit that visualizes your targets, recommends exploits, and exposes the advanced capabilities of the framework.

- Canvas - Immunity's CANVAS makes available hundreds of exploits, an automated exploitation system, and a comprehensive, reliable exploit development framework to penetration testers and security professionals worldwide.

- Core Impact - the most comprehensive software solution for assessing the real-world security of: web applications, network systems, endpoint systems and email users, wireless networks, network devices.

Wireless

- inSSIDer - award-winning free Wi-Fi network scanner for Windows Vista and Windows XP.

- Kismet - an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and (with appropriate hardware) can sniff 802.11b, 802.11a, 802.11g, and 802.11n traffic.

- wifite - attack multiple WEP and WPA encrypted networks at the same time. this tool is customizable to be automated with only a few arguments. can be trusted to run without supervision.

Networking

- Yersinia - network tool designed to take advantage of some weakeness in different network protocols. It pretends to be a solid framework for analyzing and testing the deployed networks and systems.

- macof - flood a switched LAN with random MAC addresses

- PacketFence - a fully supported, trusted, Free and Open Source network access control (NAC) system.

- Eigrp-tools - custom EIGRP packet generator and sniffer combined. It was developed to test the security and overall operation quality of the EIGRP routing protocol.

- GNS3 - graphical network simulator that allows simulation of complex networks.

Vulnerabilidades Web

- Nikto - Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6500 potentially dangerous files/CGIs, checks for outdated versions of over 1250 servers, and version specific problems on over 270 servers.

- Wapiti - It performs "black-box" scans, i.e. it does not study the source code of the application but will scans the webpages of the deployed webapp, looking for scripts and forms where it can inject data.

- Tamperdata - Firefox add-on to view and modify HTTP/HTTPS headers and post parameters.

- Wfuzz - is a tool designed for bruteforcing Web Applications, it can be used for finding resources not linked (directories, servlets, scripts, etc), bruteforce GET and POST parameters for checking different kind of injections (SQL, XSS, LDAP,etc), bruteforce Forms parameters (User/Password), Fuzzing, etc.

- WebSlayer - tool designed for bruteforcing Web Applications, it can be used for finding not linked resources (directories, servlets, scripts, etc), bruteforce GET and POST parameters, bruteforce Forms parameters (User/Password), Fuzzing, etc. The tools has a payload generator and a easy and powerful results analyzer.

- Watir - drives browsers the same way people do. It clicks links, fills in forms, presses buttons. Watir also checks results, such as whether expected text appears on the page.

- Grendel-Scan - open-source web application security testing tool. It has automated testing module for detecting common web application vulnerabilities, and features geared at aiding manual penetration tests.

- uwss - web security scanner and used for testing security holes in web applications. It can act as a fuzzer whose objective is to probe the application with various crafted attack strings. uwss is built upon a modular concept.

- Doit - scripting tool and language for testing web applications that use forms. Doit can generate random or sequenced form fill-in information, report results (into a database, file, or stdout), filter HTML results, and compare results to previous results.

- BeEF - browser exploitation framework. A professional tool to demonstrate the real-time impact of browser vulnerabilities.

- httprint - Web server fingerprinting tool.

- Netcraft - Escanea servidores web, se utiliza para determinar qué sitios web aloja un servidor.

- curl - curl is a command line tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, LDAP, LDAPS and FILE. curl supports SSL certificates, HTTP POST, HTTP PUT, FTP uploading, HTTP form based upload, proxies, cookies, user+password authentication (Basic, Digest, NTLM, Negotiate, kerberos...), file transfer resume, proxy tunneling and a busload of other useful tricks.

- Burp Intruder - Burp Intruder is a tool for automating customised attacks against web applications. You can use Burp Intruder to perform many kinds of tasks, including enumerating identifiers, harvesting useful data, and fuzzing for vulnerabilities. It can be used to test for flaws such as SQL injection, cross-site scripting, buffer overflows and path traversal; perform brute force attacks against authentication schemes; manipulate request parameters; trawl for hidden content and functionality; exploit session token predictability; mine for interesting data; and perform concurrency attacks and application-layer denial-of-service attacks.

- Add N Edit Cookies - Firefox extension to edit cookies.

- CookieDigger - CookieDigger helps identify weak cookie generation and insecure implementations of session management by web applications.

- XSS-Proxy - XSS-Proxy is an advanced Cross-Site-Scripting (XSS) attack tool.

- ratproxy - Passive web application security audit tool.

- Hackvertor - Herramienta Web para convertir strings de texto a diferentes codificaciones, útil para inyectar código en las URLs.

- Backframe - Backframe is a full-featured attack console for exploiting WEB browsers, WEB users and WEB applications.

- WebSecurity Websecurify is a web and web2.0 security initiative specializing in researching security issues and building the next generation of tools to defeat and protect web technologies (viene para Win/Linux/Mac!).

- XSS Tunnelling - the tunnelling of HTTP traffic through an XSS Channel to use virtually any application that supports HTTP proxies.

- CeWL - ruby app which spiders a given url to a specified depth, optionally following external links, and returns a list of words which can then be used for password crackers such as John the Ripper.

- fimap - little python tool which can find, prepare, audit, exploit and even google automatically for local and remote file inclusion bugs in webapps.

- w3af - Web Application Attack and Audit Framework. The project's goal is to create a framework to find and exploit web application vulnerabilities that is easy to use and extend.

- WAFP - WAFP fetches the files given by the Finger Prints from a webserver and checks if the checksums of those files are matching to the given checksums from the Finger Prints. This way it is able to detect the detailed version and even the build number of a Web Application.

- Sahi - automation and testing tool for web applications, with the facility to record and playback scripts. Sahi runs on any modern browser which supports javascript.

- skipfish - A fully automated, active web application security reconnaissance tool.

- DAVTest - tests WebDAV enabled servers by uploading test executable files, and then (optionally) uploading files which allow for command execution or other actions directly on the target.

- iScanner - free open source tool lets you detect and remove malicious codes and web pages viruses from your Linux/Unix server easily and automatically.

- COMRaider - a tool designed to fuzz COM Object Interfaces (ActiveX).

- Arachni - feature-full and modular Ruby framework that allows penetration testers and administrators to evaluate the security of web applications. Arachni is smart, it trains itself with every HTTP response it receives during the audit process.

- sessionthief - performs HTTP session cloning by cookie stealing. It integrates automatically with Firefox, dynamically creating a temporary profile for each attack performed. The program will start a new instance of firefox for each session hacked, and let you control the login of all of them at once.

- XSSer - automatic tool for pentesting XSS attacks against different applications.

- sqlinject-finder - Simple python script that parses through a pcap and looks at the GET and POST request data for suspicious and possible SQL injects.

- DOMinator - Firefox based software for analysis and identification of DOM Based Cross Site Scripting issues (DOM XSS).

Fingerprinting and Web Frameworks Scanners

- Joomscan - Yet Another Joomla Vulnerability Scanner that can detects file inclusion, sql injection, command execution vulnerabilities of a target Joomla! web site.

- WPScan - black box WordPress Security Scanner written in Ruby which attempts to find known security weaknesses within WordPress installations.

- BlindElephant - The BlindElephant Web Application Fingerprinter attempts to discover the version of a (known) web application by comparing static files at known locations against precomputed hashes for versions of those files in all all available releases. The technique is fast, low-bandwidth, non-invasive, generic, and highly automatable.

- WPAF - Web Application Finger Printer written in ruby using a SQLite3 DB.

Web Shells

- JBoss Autopwn - This JBoss script deploys a JSP shell on the target JBoss AS server.

Proxies

- WebScarab - WebScarab is a framework for analysing applications that communicate using the HTTP and HTTPS protocols. It is written in Java, and is thus portable to many platforms. WebScarab has several modes of operation, implemented by a number of plugins. In its most common usage, WebScarab operates as an intercepting proxy, allowing the operator to review and modify requests created by the browser before they are sent to the server, and to review and modify responses returned from the server before they are received by the browser. WebScarab is able to intercept both HTTP and HTTPS communication. The operator can also review the conversations (requests and responses) that have passed through WebScarab.

- Burp proxy - Burp Proxy is an interactive HTTP/S proxy server for attacking and testing web applications. It operates as a man-in-the-middle between the end browser and the target web server, and allows the user to intercept, inspect and modify the raw traffic passing in both directions. Burp Proxy allows you to find and exploit application vulnerabilities by monitoring and manipulating critical parameters and other data transmitted by the application. By modifying browser requests in various malicious ways, Burp Proxy can be used to perform attacks such as SQL injection, cookie subversion, privilege escalation, session hijacking, directory traversal and buffer overflows.

- Paros Proxy - Through Paros's proxy nature, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified.

- Odysseus - proxy server, which acts as a man-in-the-middle during an HTTP session. A typical HTTP proxy will relay packets to and from a client browser and a web server. Odysseus will intercept an HTTP session's data in either direction and give the user the ability to alter the data before transmission.

- SPIKE Proxy - professional-grade tool for looking for application-level vulnerabilities in web applications. SPIKE Proxy covers the basics, such as SQL Injection and cross-site-scripting, but it's completely open Python infrastructure allows advanced users to customize it for web applications that other tools fall apart on.

- CAT (Context App Tool) - an application to facilitate manual web application penetration testing. CAT provides a richer feature set and greater performance, combined with a more intuitive user interface to aid a professional manual penetration tester.

- WATOBO - intended to enable security professionals to perform highly efficient (semi-automated ) web application security audits. WATOBO works like a local proxy, similar to Webscarab, Paros or BurpSuite.

- Mallory - transparent TCP and UDP proxy. It can be used to get at those hard to intercept network streams, assess those tricky mobile web applications, or maybe just pull a prank on your friend.

- ProxyStrike - an active Web Application Proxy, is a tool designed to find vulnerabilities while browsing an application.

- Zed Attack Proxy (ZAP) - an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing. ZAP provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

- Vega - open source platform to test the security of web applications. Vega can help you find and validate SQL Injections, Cross-Site Scripting (XSS), inadvertently disclosed sensitive information, and other vulnerabilities.

Pentesting

- MagicTree - MagicTree is a penetration tester productivity tool, it allows easy and straightforward data consolidation, querying, external command execution, and report generation.

- dradis - open source framework to enable effective information sharing.

- Inguma - penetration testing toolkit entirely written in python. The framework includes modules to discover hosts, gather information about, fuzz targets, brute force user names and passwords and, of course, exploits.

Flash

- SWFIntruder - SWFIntruder (pronounced Swiff Intruder) is the first tool specifically developed for analyzing and testing security of Flash applications at runtime.

- Flare - Flare is a free ActionScript decompiler. It decompiles SWFs produced by Macromedia Flash, including Flash MX 2004 and Flash 8.

- MTASC - MTASC is the first ActionScript 2 Open Source free compiler.

- Flasm - Flasm is a free command line assembler/disassembler of Flash ActionScript bytecode. It lets you make changes to any SWF. Flasm fully supports SWFs produced by Macromedia Flash 8 and earlier Flash versions.

- swfmill - swfmill is an xml2swf and swf2xml processor with import functionalities.

- swftools - Collection of utilities for SWF file manipulation/creation.

- SwfScan - HP SWFScan, a free tool developed by HP Web Security Research Group, will automatically find security vulnerabilities in applications built on the Flash platform.

Tracers

- Traceroute - computer network diagnostic tool for displaying the route (path) and measuring transit delays of packets across an Internet Protocol (IP) network.

- MTR - combines the functionality of the traceroute and ping programs in a single network diagnostic tool.

Cryptography

- KGpg - simple interface for GnuPG, a powerful encryption utility..

- FireGPG - Firefox extension under MPL that provides an integrated interface to apply GnuPG operations to the text of any web page, including encryption, decryption, signing, and signature verification..

- SSLDigger - SSLDigger v1.02 is a tool to assess the strength of SSL servers by testing the ciphers supported. Some of these ciphers are known to be insecure.

- THCSSLCheck - Windows tool that checks the remote ssl stack for supported ciphers and version.

- sslscan - queries SSL services, such as HTTPS, in order to determine the ciphers that are supported.

- SSLStrip - This tool provides a demonstration of the HTTPS stripping attacks that I presented at Black Hat DC 2009.

- TLSSLed - Linux shell script whose purpose is to evaluate the security of a target SSL/TLS (HTTPS) web server implementation.

Crackers

- John the Ripper - fast password cracker, currently available for many flavors of Unix, Windows, DOS, BeOS, and OpenVMS. Its primary purpose is to detect weak Unix passwords.

- Ophcrack - Windows password cracker based on rainbow tables.

- Hydra - very fast network logon cracker which support many different services.

- patator - multi-purpose brute-forcer, with a modular design and a flexible usage.

- Aircrack-ng - an 802.11 WEP and WPA-PSK keys cracking program that can recover keys once enough data packets have been captured.

- IKECrack - open source IKE/IPSec authentication crack tool. This tool is designed to bruteforce or dictionary attack the key/password used with Pre-Shared-Key [PSK] IKE authentication.

- Wophcrack - PHP based web frontend for Ophcrack

- Bruter - parallel network login brute-forcer on Win32. This tool is intended to demonstrate the importance of choosing strong passwords. The goal of Bruter is to support a variety of services that allow remote authentication.

- IGHASHGPU - Program to recover/crack SHA1, MD5 & MD4 hashes.

- Medusa - intended to be a speedy, massively parallel, modular, login brute-forcer. The goal is to support as many services which allow remote authentication as possible.

- Ncrack - high-speed network authentication cracking tool. It was built to help companies secure their networks by proactively testing all their hosts and networking devices for poor passwords.

- authforce - Authforce is an HTTP authentication brute forcer. Using various methods, it attempts brute force username and password pairs for a site.

- RSMangler - take a wordlist and perform various manipulations on it similar to those done by John the Ripper with a few extras.

- CmosPwd - decrypts password stored in cmos used to access BIOS SETUP.

Phishing

- Imposter - flexible framework to perform Browser Phishing attacks. Once the system running Imposter is configured as the DNS server to the victims, the internal DNS server of Imposter resolves all DNS queries to itself. When the victim tries to access any website the domain resolves to the system running Imposter and Imposter’s internal web server serves content to the victim.

- Social-Engineering Toolkit (SET) - python-driven suite of custom tools which solely focuses on attacking the human element of pentesting. It's main purpose is to augment and simulate social-engineering attacks and allow the tester to effectively test how a targeted attack may succeed.

Security Defense

- AppArmor - effective and easy-to-use Linux application security system. AppArmor proactively protects the operating system and applications from external or internal threats, even zero-day attacks, by enforcing good behavior and preventing even unknown application flaws from being exploited.

- Untangle Gateway - Debian-based network gateway with pluggable modules for network applications like spam blocking, web filtering, anti-virus, anti-spyware, intrusion prevention, VPN, SSL VPN, firewall, and more.

Network Administration

- Nagios - monitors your entire IT infrastructure to ensure systems, applications, services, and business processes are functioning properly. In the event of a failure, Nagios can alert technical staff of the problem, allowing them to begin remediation processes before outages affect business processes, end-users, or customers.

- ntop - network traffic probe that shows the network usage, similar to what the popular top Unix command does.

- nmblookup - NetBIOS over TCP/IP client used to lookup NetBIOS names.

- findsmb - list info about machines that respond to SMB name queries on a subnet.

- Corkscrew - tool for tunneling SSH through HTTP proxies

- snmpcheck - free open source utility to get information via SNMP protocols.

- snmpwalk - retrieve a subtree of management values using SNMP GETNEXT requests.

- IPTraf - console-based network statistics utility for Linux. It gathers a variety of figures such as TCP connection packet and byte counts, interface statistics and activity indicators, TCP/UDP traffic breakdowns, and LAN station packet and byte counts.

Databases

- Safe3 SQL Injector - one of the most powerful penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of back-end database servers.

- sqlcmd - herramienta para conexión a bases de datos Oracle, SQL Server, MySQL y Postgress

- sqlmap - open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of back-end database servers.

- SQLiX - SQL Injection scanner, able to crawl, detect SQL injection vectors, identify the back-end database and grab function call/UDF results (even execute system commands for MS-SQL).

- sqlninja - tool targeted to exploit SQL Injection vulnerabilities on a web application that uses Microsoft SQL Server as its back-end.

- MySqloit - SQL Injection takeover tool focused on LAMP (Linux, Apache,MySql,PHP) and WAMP (Windows, Apache,MySql,PHP) platforms. It has the ability to upload and execute metasploit shellcodes through the MySql SQL Injection vulnerabilities.

- TNS Listener tool - tnscmd can be used to speak, on a very simple level, with Oracle's TNS listener.

- SQLInjector - SQLInjector uses inference techniques to extract data and determine the backend database server.

- GreenSQL - designed to protect databases (PostgreSQL/MySQL) against SQL injection attacks and other unauthorised changes, in a similar fashion to a firewall protecting a network against TCP/IP outside attacks. The new version also provides a graphical user interface for monitoring the database firewall.

- FreeTDS - Microsoft SQL Server client.

- MSSQLScan - A small multi-threaded tool that scans for Microsoft SQL Servers.

- AppSentry Listener Security Check - Check the security configuration of the Oracle Database Listener and listeners for Oracle Applications 11i.

Code analyzers

- MS MiniFuzz - very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their current software development processes.

- MS BinScope - Microsoft verification tool that analyzes binaries on a project-wide level to ensure that they have been built in compliance with Microsoft’s Security Development Lifecycle (SDL) requirements and recommendations.

- MS FxCop - code analysis tool that checks .NET managed code assemblies for conformance to the Microsoft .NET Framework Design Guidelines.

- RATS - tool for scanning C, C++, Perl, PHP and Python source code and flagging common security related programming errors such as buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions.

- Graudit - simple script and signature sets that allows you to find potential security flaws in source code using the GNU utility grep. Graudit supports scanning code written in several languages; asp, jsp, perl, php and python.

DNS

- dnsmap - Subdomain bruteforce.

Forensics Analysis

- Digital Forensics Analysis - a simple but powerful open source tool with a flexible module system which will help you in your digital forensics works, including files recovery due to error or crash, evidence research and analysis, etc.

- EnCase Forensic Tool - From the simplest requirements to the most complex, EnCase Forensic is the premier computer forensic application on the market.

Bypass

- Pass-The-Hash - The Pass-The-Hash Toolkit contains utilities to manipulate the Windows Logon Sessions mantained by the LSA (Local Security Authority) component. These tools allow you to list the current logon sessions with its corresponding NTLM credentials (e.g.: users remotely logged in thru Remote Desktop/Terminal Services), and also change in runtime the current username, domain name, and NTLM hashes

Documentation

- Agnitio - A tool to help developers and security professionals conduct manual security code reviews in a consistent and repeatable way. Agnitio aims to replace the adhoc nature of manual security code review documentation, create an audit trail and reporting.

Educational

- Damn Vulnerable Web App (DVWA) - PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment.

- Mutillidae - Deliberately Vulnerable Set Of PHP Scripts That Implement The OWASP Top 10

- WebGoat - deliberately insecure J2EE web application maintained by OWASP designed to teach web application security lessons.

- moth - VMware image with a set of vulnerable Web Applications and scripts, that you may use for Testing Web Application Security Scanners, Testing Static Code Analysis tools (SCA) and Giving an introductory course to Web Application Security.

- Web Security Dojo - A free open-source self-contained training environment for Web Application Security penetration testing. Tools + Targets = Dojo

Programming

- JODE is a java package containing a decompiler and an optimizer for java

File Managers

- cadaver - is a command-line WebDAV client for Unix. It supports file upload, download, on-screen display, namespace operations (move/copy), collection creation and deletion, and locking operations.

NAT

- pwnat - pronounced "poe-nat", is a tool that allows any number of clients behind NATs to communicate with a server behind a separate NAT with *no* port forwarding and *no* DMZ setup on any routers in order to directly communicate with each other.

Tips (PHP): Escribir en la sesión de otro usuario

noreply@blogger.com (V3kt0r) — Wed, 10 Apr 2013 10:08:00 -0300

Mientras desarrollaba una nueva funcionalidad para el framework PHP en el que estoy trabajando, me encontré con la necesidad de realizar una acción no muy común: escribir valores en la sesión de otro usuario.

Como todo desarrollador PHP sabe (o debería...), es posible almacenar valores que persisten entre requests en una misma sesión, utilizando el arreglo súper global $_SESSION. Cada sesión se asocia a un usuario, por lo que los valores almacenados para un dado usuario son accesibles sólo para él. Ahora, y si desde la sesión de un usuario, deseamos acceder valores de la sesión de otro usuario?
Muchos se preguntarán, para qué querría hacer esto? Bueno, en mi caso particular me sirvió para actualizar la configuración de un usuario desde un usuario administrador, sin la necesidad que el primero se loguee nuevamente para ver los cambios. Por ejemplo, si un usuario administrador A cambia el theme de un usuario B que ya está logueado, quiero que B vea los cambios al instante. Podría hacer esto mismo almacenando un valor en la base de datos y chequeando desde la sesión de B el registro en cada acceso, pero esto me pareció muy ineficiente. Mi solución fue escribir un flag en el arreglo de sesión de B, y luego desde B chequear el valor en el arreglo para ver si hay cambios.
Como me resultó una funcionalidad interesante, decidí compartirla.

Para que el siguiente código funcione, es necesario almacenar los IDs de sesión de cada usuario logueado. Lo pueden hacer guardando los IDs en una tabla cada vez que un usuario se loguea en el sistema. Asumo que la función "get_user_session_id($user)" ya está implementada y me permite obtener el ID del usuario que le envío por parámetro; cada uno verá como almacenar y obtener el ID.
Traté de dejar el código lo más genérico posible, con lo que deberán cambiar sólo la línea que asigna el valor en la sesión del otro usuario, la cual marqué con el comentario "CAMBIAR AQUI!".
Espero que les resulte útil!

//guardar el session id actual para poder restaurarlo luego
$current_id = session_id();

if(($sid = user_get_session_id($user)) === FALSE)
{
  throw new Exception("user ID not found");
}

//guardar los valores de la sessión actual antes de cambiar de sessión
session_write_close();

//abrir la sessión del otro usuario
session_id($sid);
session_start();

//almacenar el valor deseado en la sessión del otro usuario
$_SESSION['some_value'] = $value;   // CAMBIAR AQUI!

//guardar los cambios hechos en la sessión del otro usuario
session_write_close();

//volver a la sessión del usuario actual
session_id($current_id);
session_start();

Shortcuts: comandos OpenSSL para generar claves, certificados y testear conexiones

noreply@blogger.com (V3kt0r) — Wed, 3 Apr 2013 09:02:00 -0300

OpenSSL es una herramienta extremadamente potente, la cual permite hacer todo tipo de manejos relacionados a TLS/SSL, desde creación de claves y certificados, realizar conexiones tipo telnet a servicios que se ejecutan sobre SSL, hasta generar hashes de archivos, entre otras cosas.
A continuación les dejo un listado de comandos útiles a realizar con OpenSSL. La mayoría se centran en la creación y manipulación de claves y certificados, algo que todo administrador ha tenido que hacer alguna vez.
Ya había escrito sobre la creación de certificados en el artículo Certificados Digitales, donde podrán encontrar una explicación más detallada sobre ello. En éste la idea es dejar un acceso rápido a comandos que nos serán muy útiles, además de proveer varios comandos adicionales a los descriptos anteriormente.
Cabe mencionar que muchos de estos comandos los aprendí gracias al artículo The Most Common OpenSSL Commands y los completé con el excelente OpenSSL Command-Line HOWTO y Creating an SSL Certificate of Authority.

Claves

Generar clave RSA de 4096 bits encriptada con 3des:
$ openssl genrsa -des3 -out superkey.key 4096

Desencriptar la clave privada
$ openssl rsa -in superkey.key -out super-decrypted.key

Extraer la clave privada de un archivo en formato PKCS#12:
$ openssl pkcs12 -in certificad.pfx -out clave.pem -nodes -nocerts

Verificar clave RSA:
$ openssl rsa -in interbankingtestmil-open.pkcs -check

Convertir formatos

Convertir clave de formato tradicional a pkcs8:
$ openssl pkcs8 -in key.pem -topk8 -out pkcskey.pkcs

Convertir un certificado PEM y una clave privada en un archivo formato PKCS#12 (.pfx o p12)
$ openssl pkcs12 -export -out certificado.pfx -inkey clave.pem -in certificado.crt -certfile certificadoCA.crt

Certificados

Crear una CA Propia con validez de 10 años y clave RSA de 4096 bits:
$ openssl req -new -x509 -days 3650 -extensions v3_ca -newkey rsa:4096 -keyout private/newca.pem -out newca.crt //-config /etc/ssl/openssl.cnf

Generar un request de certificado:
$ openssl req -new -key superkey.key -out certrequest.csr

Autofirmar request de certificado (CSR):
$ openssl x509 -req -days 3650 -in cert-request.csr -signkey ca.key -out certificado.crt

Firmar request con CA:
$ openssl ca -in cert-request.csr -out certificado.crt -days 3650

Crear clave y certificado autofirmado en un solo paso:
$ openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout privateKey.key -out certificate.crt

Extraer el certificado incluído en un contenedor PKCS#12:
$ openssl pkcs12 -in certificad.pfx -out certificado.crt -nodes -nokeys

Ver los campos de un request de certificado:
$ openssl req -noout -text -in certrequest.csr

Ver campos del certificado:
$ openssl x509 -in certificado.crt -text -noout

Ver campos de un contenedor PKCS#12:
$ openssl pkcs12 -info -in certificado.pfx

Otras utilidades

Conectar a un servicio que se ejecuta sobre SSL (por ejemplo HTTPS):
$ openssl s_client -connect servidor:443

Calcular el hash MD5, SHA1, SHA2, etc de un archivo y de un texto
$ openssl dgst [-md5|-md4|-md2|-sha1|-sha|-mdc2|-ripemd160|-dss1] archivo
$ echo "texto" | openssl dgst [-md5|-md4|-md2|-sha1|-sha|-mdc2|-ripemd160|-dss1]

Nagios: monitoreo remoto de dispositivos + agentes Linux + agentes Windows

noreply@blogger.com (V3kt0r) — Tue, 26 Mar 2013 12:05:00 -0300

Desde hace un par de semanas vengo trabajando con Nagios para tener, al instante, el estado de los
servicios de la red (i.e. monitoreo).
Existen varias herramientas para este tipo de trabajo, estando entre las mejores (según he leído y por recomendaciones) Cacti y Zabbix. Mi elección de Nagios se debe a su integración con OSSIM, y a que ya había trabajado con ella en otra ocasión y me resultó muy buena. Esto no implica que Nagios sea la mejor herramienta, pero sí una excelente. Una comparación interesante que encontré sobre herramientas de monitoreo libres es Tired of Nagios and Cacti? Try Zabbix, la cual, obviamente se enfoca en Zabbix, pero nombra los pro y los contra de cada herramienta.

Las características que encuentro más importantes en Nagios, son:
- Compatibilidad. Existen agentes tanto para Linux como para Windows que permiten monitorear una gran variedad de recursos.
- Flexibilidad. Se pueden definir comandos nuevos para chequeos que no estén incluidos, o para mejorar alguno existente.
- Extendibilidad. El protocolo de comunicación entre agentes y servidor es abierto y está documentado para que cualquiera pueda desarrollar sus propios agentes. Además, como veremos, es posible utilizar varios protocolos.
- Configuración a través de archivos de texto. Si bien algunos no les gusta, para mi es mucho más rápido definir hosts y servicios a chequear mediante simples archivos de texto, que haciendo muchos clicks en una interfaz web.
- Visualización del estado de la red en una sola pantalla. Es fácil y rápido detectar cuando algo anda mal.
- Intervalos para chequear un host/servicio configurables.
- Reporte de alertas por mail y SMSs.
- Sistema de detección de cambios de estado (flapping). Si un host se detecta caído, al minuto normal, al minuto caído, no está bueno recibir 300 alertas, dado que el host está en un estado inestable. Nagios detecta esto y previene futuras alertas hasta que se estabilice.
- Variedad de plugins predefinidos.
- Hay una gran comunidad detrás, así como mucha documentación.

What's all about?

La idea de este artículo no es hablar de las bondades o puntos bajos de Nagios, sino explicar la forma de armar una configuración básica que permita chequear el estado de hosts y servicios remotamente, así como chequear recursos mediante agentes tanto en Windows como en Linux.
Información de Nagios hay mucha, este artículo pretende aportar una explicación resumida del funcionamiento básico y una configuración que abarca la mayoría de los chequeos típicos. Añadir chequeos no debería ser mayor problema una vez conocida las bases.
Para completar esta información, recomiendo leer la documentación oficial en Nagios Core Documentation.

Definición de objetos

Nagios se configura mediante archivos de texto, los cuales deben tener la extensión .cfg. La configuración se basa en objetos, que son los elementos involucrados en la logística de monitoreo y notificación.
Los objetos básicos son:
- comandos: definen qué programas ejecutar.
- servicios: son los recursos a testear (CPU, disco, protocolos de red, etc)
- hosts: definen los hosts que se van a monitorear.
- contactos: son las personas a las que se va a notificar cuando ocurre una alerta.
- tiemeperiods: definen en qué horarios se puede chequear un host y en qué horarios se puede notificar a un contacto.
Estos objetos se pueden agrupar mediante los siguientes objetos:
- hostgroups: permiten agrupar hosts.
- servicegroups: agrupan servicios.
- contactgroups: agrupan contactos.

Como se puede observar en la sección de definición de objetos del manual de Nagios, cada objeto puede tener definidos varios atributos, aunque sólo unos pocos (sobre todo si utilizamos la herencia) son obligatorios. Los objetos se definen mediante la cláusula "define" y sus atributos se encierran entre llaves.
Los atributos que utilizaremos para cada tipo de objeto, y que les servirán para la gran mayoría de los casos, son los siguientes:
comandos:
- command_name: nombre del comando (por ej check_http)
- command_line: la línea de comando que se ejecutará para el chequeo (ejemplo: /usr/lib/nagios/plugins/check_http -I $HOSTADDRESS$ -p $ARG1$)

Como se puede observar en el ejemplo, existen variables predefinidas que se pueden utilizar como argumentos pasados al programa en la línea de comandos (Nagios las denomina macros). La lista completa de macros se encuentra aquí. En el ejemplo $HOSTADDRESS$ es la dirección del host que se está chequeando. También es posible utilizar variables cuyo valor será reemplazado cuando se llame el comando desde la definición de un servicio (o host), las cuales se denominan a partir de $ARG1$ hasta $ARGN$.

servicios:
- use: directiva que permite heredar atributos de servicios definidos previamente. Es posible definir un servicio base y luego extenderlo mediante esta directiva. En las definiciones de servicios, se suele heredar de "generic-service".
- service_description: una breve descripción del servicio.
- hostgroup_name/host_name: asigna el servicio a un grupo de hosts o a hosts específicos. No es mandatorio utilizar este parámetro, dado que se pueden asignar servicios a hosts desde la misma definición de los hosts. Es posible asignar más de un hostgroup o host separándolos con comas.
- check_command: el nombre del comando, previamente definido, que se utilizará para chequear el servicio. Algo a tener en cuenta es que cuando se llama al comando, los parámetros se pasan separados con signos de admiración. Estos luego se reemplazarán en $ARG1$... $ARGN$, según se definió en el comando.
Por ejemplo, en la definición de check_tcp encontramos que el comando ejecutado es el siguiente:
/usr/lib/nagios/plugins/check_tcp -H $HOSTADDRESS$ -p '$ARG1$' -4
donde $ARG1$ se reemplazará por el puerto TCP que se desea chequear cuando se llame el comando.
La forma de llamar el comando es la siguiente:
check_command check_tcp!50000
donde 50000 es el parámetro utilizado para el puerto.

NOTA: si no se hereda la definición de generic-service, deberán definirse otros atributos adicionales que son mandatorios (max_check_attempts, check_interval, retry_interval, check_period, notification_interval, notification_period, contacts, contact_groups).

hosts:
- use: al igual que en los servicios, esta directiva permite heredar los atributos de un host previamente definido. El caso más común es heredar la definición de "generic-host"
- host_name: es lo que el nombre indica, el hostname del host.
- address: dirección IP del host.
- alias: una breve descripción de la funcionalidad del host.
- hostgroups: listado de hostgroups a los que el host pertenece. Este atributo no es mandatorio, además es posible asignar los hosts a un hostgroup desde la misma definición del hostgroup.
- check_command: tiene la misma utilidad que cuando se define un servicio, con la diferencia que se utiliza para chequear si un host está online. Por defecto se utiliza ping (definido en generic-host) como chequeo, pero se puede reemplazar por otro si es que el host no admite pings.

NOTA: si no se hereda la definición de generic-host, deberán definirse otros atributos adicionales que son mandatorios (max_check_attempts, check_period, notification_interval, notification_period, contacts, contact_groups).

hostgroups:
- hostgroup_name: el nombre del hostgroup que estamos definiendo.
- alias: una breve descripción de la funcionalidad del hostgroup.
- members: listado de hosts, separados por coma, que pertenecen a este hostgroup. Este atributo es opcional.

contactos:
- contact_name: nombre del contacto.
- alias: un alias para el mismo.
- service_notification_period: indica en qué horarios se puede contactar en caso de caída de servicios.
- host_notification_period: indica en qué horarios se puede contactar en caso de caída del host.
- service_notification_options: listado de estados de servicio que deben reportarse. Los estados se definen con letras y se separan con comas: u (UNKNOWN), c (CRITICAL), r (RECOVERY - OK), f (FLAPPING), y n (NONE).
- host_notification_options: listado de estados de host que deben reportarse. También se definen con letras separadas por coma: d (DOWN), u (UNREACHABLE), r (RECOVERY - UP), f (FLAPPING), s (comienza el downtime programado), n (NONE).
- service_notification_commands: cómo notificar al contacto en caso de servicio caído (email, sms, etc).
host_notification_commands: cómo notificar al contacto en caso de host caído (email, sms, etc).
- email: dirección de email del contacto.
- contactgroups: grupo al que pertenece el contacto.

Agentes Nagios

Una gran parte del monitoreo se puede hacer remotamente. Todo servicio publicado en la red, se puede monitorear sin necesidad de instalar nada en el host monitoreado. Sin embargo hay recursos que no se pueden monitorear remotamente, como por ejemplo:
- espacio libre en disco
- memoria en uso
- carga de CPU
- servicios activos
- cantidad de usuarios logueados
Para ello es necesario instalar agentes. Estos agentes, mediante plugins, chequean el estado de los recursos y envían los datos al servidor Nagios. El tipo de conexión es pull, es decir, el servidor Nagios contacta cada cierto intervalo de tiempo a los agentes, les indica qué comandos ejecutar y obtiene los resultados.
Existen varios protocolos utilizados para la comunicación entre agentes y Nagios:
- NRPE - Nagios Remote plugin Executor. Es el protocolo más utilizado y recomendado por Nagios. Se accede mediante el plugin check_nrpe.
- NSCA - Nagios Service Check Acceptor.
- NSCP: protocolo nativo de NSClient++
- NRDP: reemplazo NSCA.
- Syslog: protocolo estándar para transmisión de logs en Unix.
- SNMP: Simple Network Management Protocol. Protocolo estándar para administración y monitoreo de dispositivos de red.

En este artículo se utilizará el protocolo NRPE, para lo cual se instalarán agentes en Linux y Windows que lo soporten.

Instalación del servidor

Instalar el servidor de Nagios es muy simple, está en los repositorios de la mayoría de las distribuciones.
Por ejemplo, en debian, basta con ejecutar:
# apt-get install nagios3 nagios-nrpe-plugin

La instalación en debian solicita que se introduzca una clave de administración web (usuario nagiosadmin). Pueden elegir no ingresar clave, e ingresarla después. Lo más cómodo es asignarla en esta instancia, aunque queda a elección. La autenticación de la interfaz web la realiza Apache, así que agregar o quitar usuarios se puede realizar con la utilidad htpasswd. También instalamos aquí los plugins para comunicarnos con los agentes mediante NRPE (ver más adelante).

El servicio de Nagios se ejecutará, por defecto, a nombre del usuario nagios y grupo nagios. Esto es para limitar los privilegios, dado que el sistema no necesita permisos de root para ejecutarse, y sería muy riesgoso.

Si utilizan debian, otros datos interesantes acerca de la instalación son:
- Los plugins default de Nagios (paquete nagios-plugins) se instalan en /usr/lib/nagios/plugins
- Los comandos (ver más adelante que son) default están definidos en /etc/nagios-plugins/config
- Por defecto, nagios carga toda la configuración incluida en /etc/nagios3/conf.d, así que lo más conveniente es incluir los archivos con las definiciones de hosts, servicios, comandos, etc, allí.
- El archivo de configuración de apache para la interfaz web de Nagios se encuentra en /etc/apache2/conf.d/nagios3.conf
- Por defecto la interfaz web se accede mediante la URL http:///nagios3. Este alias se puede cambiar en el archivo citado en el punto anterior.
- El archivo de autenticación para la interfaz se encuentra en /etc/nagios3/htpasswd.users

Arquitectura de ejemplo

Para poder explicar la configuración de Nagios de forma más didáctica, utilizaremos la siguiente arquitectura de red como ejemplo:

En esta simple estructura traté de cubrir los casos más frecuentes, al menos cubre todos los casos con los que me he topado. La red cuenta con:
- un servidor Nagios que monitoreará todo (192.168.0.100).
- un servidor Linux (linuxagent - 192.168.0.3) con el agente de Nagios instalado, que posee un servicio Web (puerto 80).
- un servidor Windows (winagent - 192.168.0.4) con el agente de Nagios instalado, que presta servicio de fileserver (CIFS puerto 445), y Web service en el puerto 81. En este servidor chequearemos que el servicio de Firewall de Windows esté iniciado (MpsSvc).
- un servidor al cual no se le instaló agente (noagent - 192.168.0.20), pero que presta un servicio no estándar en el puerto 4444.
- un servidor web colocado en internet (itfreekzone - 10.0.0.10, claro está que la IP no es una IP de internet válida, sólo se usa de ejemplo).
Los hosts de la red interna son alcanzables mediante ping, mientras que el servidor Web de internet no.

Si tienen algún caso que no entre en alguna de estos posibles, dejen su comentario y trato de añadirlo :)

Servidor Linux con agente

Arranquemos con la configuración del monitoreo de un servidor linux para el cual utilizamos un agente. Como se indicó anteriormente, NRPE es el protocolo elegido para la ejecución remota de comandos, así que el agente a instalar debe soportarlo. En debian existe un paquete denominado nagios-nrpe-server.

En el servidor Linux, instalaremos entonces los siguientes paquetes (buscar equivalentes en distribuciones no debian):
# apt-get --no-install-recommends install nagios-nrpe-server nagios-plugins-basic
El paquete nagios-plugins-basic provee el set básico de plugins para los chequeos.

La configuración del agente NRPE se realiza desde el archivo /etc/nagios/nrpe.cfg. Las variables a tener en cuenta en este archivo son:

server_port=5666 #define en qué puerto (TCP) escuchará el agente. Por defecto es el 5666, pero se puede setear cualquiera.

server_address=192.168.0.3 # indica en qué dirección IP escuchará el agente, en caso que el servidor posea más de una IP.

allowed_hosts=192.168.0.100 # define qué IPs tienen permitido conectarse al agente en busca de datos. Es un parámetro de seguridad mínimo para limitar desde qué máquinas se conectan al agente.

dont_blame_nrpe=0 # mi variable favorita (por su nombre, claro). Esta variable indica si se permite que el agente reciba comandos con parámetros (por ejemplo, en la ejecución "check_disk -w 20%" el parámetro es "-w 20%"). Es muy mala idea permitir que hosts remotos envíen al agente parámetros, dado que podrían utilizarse para explotar alguna vulnerabilidad (qué pasa si se recibe "check_disk -w <muchos bytes...="">" ???). Por ello, se recomienda crear alias de comandos, como por ejemplo "command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -x sda", donde el servidor sólo necesitará llamar "check_disk" (sin parámetros) para obtener los datos de espacio libre y alertas.

command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10 # alias check_user para obtener la cantidad de usuarios logueados y alertar si hay más de 5 logueados al mismo tiempo.
command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 #alias check_load para obtener la carga de CPU
command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -x sda #alias check_disk para obtener el espacio disponible en el disco /dev/sda y alertar si queda menos de 20% de espacio en alguna partición.

Como se ve, los alias son muy importantes, y se pueden agregar tantos como se desee. Estos definen un acceso a información con parámetros predefinidos, de modo que el servidor sólo debe llamar el comando sin parámetros, y disminuir el riesgo (el atributo lo dice, no le eches la culpa a NRPE si se te rompe todo por usar parámetros - dont_blame_nrpe). Sólo listé tres (check_disk, check_load, y check_users) pero podría haber creado todos los que quisiera.

Una vez configurado el agente, reiniciarlo para que tome los cambios:
# /etc/init.d/nagios-nrpe-server restart

Servidor Windows con Agente

Para monitorear recursos en Windows, existe el demonio NSClient++ (http://www.nsclient.org). El demonio soporta todos los protocolos mencionados anteriormente, pero como comenté, utilizaremos NRPE.
La instalación es muy simple, bajan la última versión del instalador y la ejecutan. Pueden elegir la instalación típica y dar todo next, sin chequear nada, dado que luego reemplazaremos el archivo nsclient.ini con la información que les dejo a continuación. Si desean utilizar las opciones del instalador, verán que permite habilitar algunas cosas, como si utilizar NSCP (check_nt) y/o NRPE (check_nrpe), un password de acceso para el caso de check_nt (el cual no utilizaremos), los hosts que tienen permitido acceder a la información (allowed_hosts), checks WMI, y los check plugins.

Toda la configuración se guarda en el archivo C:\Program Files\NSClient++\nsclient.ini (o C:\Archivos de Programas\NSClient++\nsclient.ini). Si no tildaron nada durante la instalación, verán que está vacío, a excepción de unos comentarios.
NSClient no utiliza el mismo formato de configuración que el visto en el host Linux, es más, varía bastante. Para empezar, la configuración se divide en secciones (formato estándar de los .ini). Por otra parte, los plugins se deben habilitar antes de ser utilizados. Además los plugins se llaman con ejecutables diferentes (CheckCpu. CheckDriveSize, etc), y los alias se definen de otra manera. Para estandarizar, en la configuración utilicé los mismos alias que en el host Linux, así es posible realizar grupos de hosts que incluyan tanto servidores Linux como Windows, y ejecutar los mismos comandos en ambos.
La configuración que utilizaremos será la siguiente:

[/modules]
; habilitamos el uso de NRPE
NRPEServer = 1

; habilitamos plugins a utilizar. Como se ve, los plugins se agrupan por tipo.
CheckSystem=1
CheckDisk=1
CheckExternalScripts=1

; creamos los mismos alias que en la definición del host Linux, y agregamos un alias para chequear servicios
[/settings/external scripts/alias]
check_load=CheckCpu MaxWarn=80 time=5m ; alias para chequear la carga de CPU. Si sobrepasa el 80% en un intervalo de 5 minutos, nos alertará.
check_disk=CheckDriveSize ShowAll MinWarnFree=10% MinCritFree=5% ; alias para chequear el espacio en todos los discos del servidor
check_firewall_service=CheckServiceState MpsSvc; alias para chequear el servicio del firewall de Windows (llamado MpsSvc).

[/settings/default]
; permitimos el acceso al servidor Nagios para las consultas.
allowed hosts = 192.168.0.100

Configuración de los checks en el servidor Nagios

Bien, con los agentes instalados y configurados, volvemos al servidor Nagios. Utilizamos el directorio /etc/nagios3/conf.d para poner nuestra configuración, tal vez adentro de un directorio nuevo, para que quede más ordenado y no se mezcle con el resto.

Observando el directorio conf.d encontramos varias definiciones, como las citadas generic-host y generic-service. También se agrega por defecto la definición de los servicios a chequear en localhost, algo que nos puede servir como ejemplo. En /etc/nagios-plugins/config encontramos la definición de varios comandos, que nos servirán para la mayoría de los casos, aunque habrá algunos que tendremos que definir nosotros.

Para comenzar, definimos un comando nuevo que utilice check_http, pero que nos permita chequear servicios Web en cualquier puerto. En /etc/nagios-plugins/config/http.cfg existen varios comandos predefinidos para llamar a check_http, pero no encontré ninguno que permita hacer un simple check a un puerto diferente al 80. Si quieren ser prolijos, podríamos incluir los comandos en un archivo commands.cfg dentro de nuestro directorio de configuración.
El comando se define de la siguiente manera:

define command {
command_name check_http_port
command_line /usr/lib/nagios/plugins/check_http -I $HOSTADDRESS$ -p $ARG1$
}

Cuando se llame el comando, deberá entregarse un puerto como argumento y realizará el chequeo HTTP.

A continuación me parece bien definir un grupo de hosts para agrupar los hosts que tienen instalado el agente, lo denominaremos remote-agent.

define hostgroup {
hostgroup_name remote-agent
alias Hosts que tienen el agente de Nagios instalado
}

De esta forma, podemos definir servicios que se chequeen en todos los host que tengan el agente instalado, tan solo agregando los hosts al grupo remote-agent y asignando los servicios al mismo.
Para los checks remotos, debemos utilizar el comando check_nrpe_1arg (/etc/nagios-plugins/config/check_nrpe.cfg), al cual se le entrega como parámetro el nombre del comando a ejecutar en el host remoto. El “1arg” indica que se le entrega un parámetro (el nombre del comando a ejecutar). Los comandos que llamaremos son los alias que definimos en cada host anteriormente.
En los hosts con el agente realizaremos checks de CPU y disco:

#checkear CPU
define service {
use generic-service # hereda los atributos de generic-service
hostgroup_name remote-agent # indicamos que se aplica al hostgroup remote-agent
service_description Load average # describimos lo que se testea
check_command check_nrpe_1arg!check_load #llamamos a check_nrpe_1arg y le indicamos que debe ejecutar check_load
}

#checkear discos
define service{
use generic-service # heredamos
hostgroup_name remote-agent # aplicamos al grupo remote-agent
service_description Disk Space # describimos lo que testeamos
check_command check_nrpe_1arg!check_disk # indicamos que debe ejecutarse el alias check_disk
}

Ya tenemos los checks genéricos que haremos en los hosts con agentes.
Dado que el resto de los servicios los chequearemos por host, pasemos a la definición de los hosts.

# host linux con agente
define host {
use generic-host
host_name linuxagent
alias Web Server Linux con agente instalado
address 192.168.0.3
hostgroups remote-agent,http-servers
}

Acá aparece el grupo predefinido http-servers. El mismo se encuentra definido en /etc/nagios3/conf.d/hostgroups_nagios2.cfg y nos permite chequear Web servers que escuchen en el puerto 80.

# host windows con agente
define host {
use generic-host
host_name winagent
alias Windows Server, File Server y Web service
address 192.168.0.4
hostgroups remote-agent
}

# host sin agente
define host {
use generic-host
host_name noagent
alias Servidor sin agente
address 192.168.0.20
}

# host en internet
define host {
use generic-host
host_name itfreekzone
alias Web server en internet
address 10.0.0.10
hostgroups http-servers
check_command check_http
check_interval 5
}

Nótese que en el servidor itfreekzone agregué el atributo check_command. Dado que el firewall no nos permite realizar pings a internet, es necesario encontrar una alternativa para detectar que el host está online, por ello utilicé check_http. También definí un nuevo intervalo de chequeos (por defecto era 1), para incrementar la distancia entre sucesivos checks y así no estar enviando requests continuamente a Internet.

La definición anterior ya nos alcanza para los chequeos en linuxagent e itfreekzone, pero todavía nos queda trabajo por hacer para monitorear al resto. Pasemos a definir los servicios que nos faltan.

Como comenté anteriormente, en winagent deseamos chequear que el servicio MpsSvc está levantado. Agregamos entonces la siguiente definición:

define service {
use generic-service
service_description Check Firewall Windows
check_command check_nrpe_1arg!check_firewall_service
host_name winagent
}

En la definición se ve que el servicio se aplica solamente al host winagent, y se llama el alias predefinido check_firewall_service.
Ahora, en el host windows, resta chequear CIFS y el Web Service:

define service {
use generic-service
service_description Check Web service en puerto 81
check_command check_http_port!81
host_name winagent
}

define service {
use generic-service
service_description Check CIFS
check_command check_tcp!445
host_name winagent
}

Como se observa, para chequear el web service utilizamos el comando que definimos anteriormente (check_http_port), mientras que para chequear CIFS, simplemente realizamos una conexión TCP al puerto 445. Existen plugins específicos para un chequeo más a fondo del servicio CIFS, pero para nuestro ejemplo alcanza.

Qué resta? chequear el serivicio NN en el host noagent. En este caso también utilizaremos check_tcp, nada mágico:

define service {
use generic-service
service_description Check Servicio NN
check_command check_tcp!4444
host_name noagent
}

Ok, tenemos los hosts y los servicios a chequear. Ahora, a quién y cómo enviamos las alertas?
Por defecto las alertas se envían al grupo admins (ver /etc/nagios3/conf.d/generic-host_nagios2.cfg), el cual las envía por mail al contacto root@localhost (ver /etc/nagios3/conf.d/contacts_nagios2.cfg). Definamos un nuevo contacto que pertenezca al grupo admins, pero al cual se le envíen solamente estados críticos y recoveries:

define contact {
contact_name demasiadovivo # mi nombre
alias d3m4s1@d0v1v0 # mi alias
service_notification_period 24x7 # indico que ante caída de servicios me notifique en cualquier momento de la semana
host_notification_period 24x7 # indico que ante caída del host me notifique en cualquier momento de la semana
service_notification_options c,r # solo notificarme servicios en estados críticos (c) y recoveries (r)
host_notification_options d,r # solo notificarme host caído (d) y recoveries (r)
service_notification_commands notify-service-by-email # notificarme cambios en los servicios por mail
host_notification_commands notify-host-by-email # notificarme cambios en el host por mail
email demasiadovivo@itfreekzone.com # mi dirección de mail
contactgroups admins # me agrego al grupo de contacto admins.
}

Con esto terminamos la definición. Un restart del servicio Nagios para que tome la nueva configuración y ya estamos:
# /etc/init.d/nagios3 restart

En caso que algo haya quedado mal definido, Nagios lo indicará con un error y el servicio no iniciará.

Fue difícil? bueno, hasta que aprendemos la terminología, la estructura de objetos y la forma de definir todo, puede que si. Luego es tan simple como agregar definiciones. Por suerte es bastante intuitivo =)

Referencias

- Nagios Core Documentation
- about NSClient++
- Using NSClient++ from nagios with check_nrpe
- Installing Nagios On Debian Lenny And Monitoring A Debian Lenny Server

Tips: recibir mensajes SMS online

noreply@blogger.com (V3kt0r) — Thu, 29 Nov 2012 09:15:00 -0300

Desde hace tiempo, la mayoría de los sites requieren una dirección de email válida para poder registrar un usuario, a la cual envían un código de confirmación para terminar la validación. Si bien esto sigue siendo igual en la mayoría de los casos, cada vez más sitios empiezan a requerir algo más... un número de celular. Estos sites envían al número ingresado un código de confirmación, el cual hay que ingresar para validar al usuario.

En diferentes sites el número de celular es opcional y permite autenticación de dos vías, lo cual refuerza el sistema de autenticación, pero en otros es mandatorio colocar el número.

Los paranoicos como yo (o los usuarios que todavía desean poseer un mínimo de privacidad), no deseamos colocar el condenado número para que después la página pueda, como mínimo, enviarnos SPAM. Por ello me puse a buscar alguna alternativa que me permita recibir mensajes en un número online. Así fue como llegué al excelente artículo How to receive SMS online to bypass SMS verification?

El artículo resume cuáles páginas permiten la recepción de SMSs online. Las mismas proveen una serie de números, controlados por ellos, los cuales están aptos para recibir SMSs internacionales. Cuando se recibe un mensaje, el mismo es agregado en la web para que pueda ser leído.

Las alternativas más simples de utilizar (digo simples porque no necesitan creación de usuario) son Receive-SMS-Online y ReceiveSMSOnline. De estas, la que a mi me funcionó es la primera, utilizando los números de Noruega. En el resto de los números no pude recibir mensajes. La ventaja adicional de la primera es que separa los SMS recibidos en cada número en páginas diferentes.

La tercer página citada en el artículo es Pinger, la cual pintaba bien en su descripción, pero tampoco pude recibir mensajes. La cuarta requiere justamente lo que no quería originalmente, un número de celular. No se por qué el autor colocó ésta en la lista, siendo que no es la idea del artículo. La última citada es para recibir faxes y mensajes de voz, ya alejandose de los SMS, así que no la probé.

Adicionalmente a las del articulo, encontré Receive-SMS, similar a ReceiveSMSOnline en la cual se muestran los mensajes de todos los números en una misma págna.

Estas páginas son de mucha utilidad, pero no siempre servirán, dado que los sites no son tontos (bueno, no todos) y muchos controlan los números de cel que ya validaron códigos y no permiten que sean utilizados nuevamente.

Me pareció interesante listar estas páginas porque, si bien existen cientos de páginas para el envío de mensajes online, no existen muchas para recibirlos.