Conocer el proceso que escucha en un puerto

A modo de análisis de un servidor Linux, en ocasiones es útil disponer de un listado de servicios que están a la escucha en distintos puertos.

Mediante el comando netstat se puede obtener esta información. Veamos un ejemplo:

Integrar Latch en Python

Espero que conozcáis Latch, y si no estáis tardando. Es un excelente método para proteger nuestras cuentas de accesos no autorizados. Se puede implementar en una web, en una aplicación de escritorio, en el propio proceso de logado de usuarios de algunos sistemas operativos, y en general es aplicable a cualquier sistema que ideemos y que sea susceptible de proteger ante eventuales ataques.

Una buena fuente para aprender sobre Latch y seguridad en general es el blog Un informático en el lado del mal.

Como para otros muchos lenguajes y plataformas, Latch tiene una librería para poderse usar desde Python. Con tan solo descargar el fichero latch.py e importarlo en nuestra aplicación Python, podemos usarlo.

Lo primero de todo es darse de alta en la web de Latch como desarrollador. Se hace de forma gratuita. Obtendremos una Latch APP ID y un Latch Secret.

Parear una cuenta de usuario con nuestra aplicación

El proceso de parear un usuario con una aplicación se inicia generando un código aleatorio por parte del usuario, mediante la aplicación para móvil de Latch. En nuestro ejemplo será 92Us26.

El siguiente script Python corresponde al proceso de emparejar un usuario con nuestra aplicación:

# -*- coding: latin-1 -*-

import sys, latch

LATCH_APP_ID = '55HAbMdwQRRS6421AAxZ'
LATCH_SECRET = 'EDadxfiyuyjgfdferRG43658HGEWTRtZ3254VMhE'

usuario = sys.argv[1]
codigo  = sys.argv[2]

latcheo = latch.Latch(LATCH_APP_ID, LATCH_SECRET)
response = latcheo.pair(codigo)
cuenta_latch = str(response.get_data()['accountId'])

print cuenta_latch

La ejecución del script anterior sería de este modo:

$ python parear.py user01 92Us26
ebbcf87d97174f0e397e3a42b2a86ca0e34627e5345f817446eefba348550a82

Como se aprecia, tras el pareo nuestra aplicación se queda con el ID del pestillo que se acaba de crear. En este caso, a modo de ejemplo, se imprime por pantalla. Lo ideal es que nuestra aplicación almacene en una base de datos que el usuario user01 tiene como ID del pestillo de inicio de sesión ebbcf87d97174f0e397e3a42b2a86ca0e34627e5345f817446eefba348550a82.

Comprobar el estado del pestillo de un usuario

Una vez que se ha creado el pestillo, el siguiente paso es conocer la forma de consultar su estado (abierto o cerrado). De esta forma, cuando el usuario (o un atacante) introduzca ese login y su contraseña correcta, la aplicación consultará el estado del pestillo. Si está abierto, la aplicación logará al usuario con normalidad. Si está cerrado, la aplicación devolverá el mensaje de usuario o contraseña incorrectos.

A continuación se muestra un pequeño script para consultar el estado del pestillo (en la práctica lo suyo es obtenerlos de la base de datos):

# -*- coding: latin-1 -*-

import sys, latch

LATCH_APP_ID = '55HAbMdwQRRS6421AAxZ'
LATCH_SECRET = 'EDadxfiyuyjgfdferRG43658HGEWTRtZ3254VMhE'

latchuserid  = sys.argv[1]

latcheo = latch.Latch(LATCH_APP_ID, LATCH_SECRET)
response = latcheo.status(latchuserid)
if response.get_data()['operations'][LATCH_APP_ID]['status'] == 'on':
    print 'Acceso permitido'
else:
    print 'Acceso denegado'

La ejecución del script sería:

$ python comprobar.py
ebbcf87d97174f0e397e3a42b2a86ca0e34627e5345f817446eefba348550a82
Acceso denegado

¿Cómo has usado Latch en tu aplicación? ¿Qué usos le has dado? ¡Deja tu comentario!

Comandos útiles para pgpool-II

Pgpool-II es un middleware entre clientes y servidores PostgreSQL que permite montar un sistema de réplica. Si no lo conocéis os aconsejo que le echéis un vistazo. Es muy interesante y cubre necesidades que otros métodos de réplica sobre PostgreSQL no abordan.

Un aspecto negativo de este proyecto es que no hay demasiada documentación. A continuación indico algunos comandos que facilitan la administración del cluster y permiten conocer el estado de pgpool-II:

Conocer el número de conexiones disponibles

Es necesario saber cuántas conexiones hay disponibles para los clientes con el propósito de anticiparse a un 100% de uso y por tanto a no aceptar nuevas conexiones.

# ps -ef | grep "wait for connection request" | grep -v grep | grep -v PCP | wc -l
3030

Conocer el número de conexiones usadas por un equipo

Cuando se usan librerías de terceros para conectar una aplicación a una base de datos, como Hibernate, no se sabe a ciencia cierta cuántas conexiones abre contra pgpool-II. Esta métrica permite conocer mejor el uso que hacen estas librerías de las conexiones y posibilita saber cuántos clientes podemos tener conectados al mismo tiempo.

# ps -ef | grep -E "pgpool: .*192.168.46.6" | grep -v grep | wc -l

Ver el estado de los nodos configurados en el cluster

En pgpool-II cada nodo PostgreSQL añadido al cluster puede estar en uno de estos tres estados:

1. Nodo marcado como válido y sobre el que pgpool no ha escrito desde que se marcó con este estado.
2. Nodo marcado como válido y sobre el que pgpool ya ha realizado escrituras.
3. Nodo fuera de servicio, bien porque esa máquina está apagada, no tiene PostgreSQL en ejecución o sí lo está pero no tiene sus datos sincronizados con el resto de servidores válidos.

Dado que el log de pgpool-II tiene bastante verbosidad, la mejor forma de ver el estado de los servidores es el siguiente:

# tail -f /var/log/pgpool.log | grep "DB node"


Poco a poco iré poniendo más trucos sobre Pgpool-II, pues pueden resultar muy útiles para los que se inician en este mundo.

Enlace a blog de José Linares

Hace poco descubrí un estupendo blog sobre temas relacionados a los que escribo en este blog: bash, programación de scripts, administración de sistemas... Su autor es José Linares y aquí os dejo su blog: jose-linares.com.

A disfrutarlo y aprender muchas cosas interesantes y útiles.

Enviar mensajes por Hangouts desde consola

Necesitaba enviar mensajes por Hangouts desde linea de comandos, para hacerlo de manera automática con scripts. Tras probar distintas aplicaciones, algunas que funcionaban pero con un entorno interactivo con ncurses, y otras que directamente fallaban, encontré la solución. Sencilla y elegante:


1. Instalar la librería XMPP para Python:

# aptitude install python-xmpp

2. Crear el script Python que enviará los Hangout. Llamémoslo sendHangouts.py:

#!/usr/bin/python

# -*- coding: latin-1 -*-

# 1er parametro: cuenta del destinatario

# 2o parametro: mensaje a enviar

import sys, xmpp

jid = xmpp.protocol.JID('cuenta.desde.la.que.envio.el.hangout@gmail.com')

cl=xmpp.Client(jid.getDomain(),debug=[])

cl.connect()

cl.auth(jid.getNode(),'contraseña.de.la.cuenta')

cl.send(xmpp.protocol.Message(sys.argv[1],sys.argv[2], typ='chat'))

3. Asignar permisos de ejecución al script:

# chmod +x sendHangouts.py

4. Para que cuenta.desde.la.que.envio.el.hangout@gmail.com pueda mandar un hangouts a mi.cuenta.destinataria@gmail.com, el emisor tendrá que tener al destinatario en su agenda de contactos. Valdría con que cuenta.desde.la.que.envio.el.hangout@gmail.com enviase un email a mi.cuenta.destinataria@gmail.com.

5. Y listo para enviar mensajes:

# ./sendHangouts.py mi.cuenta.destinataria@gmail.com Hola
# ./sendHangouts.py mi.cuenta.destinataria@gmail.com "Alarma crítica en servidor de base de datos"

6. A inventar posibles usos.

grep y cat sobre un fichero comprimido con gzip

En relación a la entrada anterior, registro de logados mediante ssh, es posible que necesitemos hacer un grep sobre un fichero de texto plano comprimido con gzip. Hay muchos logs que van rotando y los ficheros antiguos son comprimidos automáticamente con este formato.

Por tanto, si queremos realizar un grep sobre el fichero /var/log/auth.log.2.gz ejecutaremos:

# zgrep Accepted /var/log/auth.log.2.gz

Por defecto, el comando grep colorea las palabras que encajan con el patrón buscado, pero zgrep no. Para que las coloree:

# zgrep --color Accepted /var/log/auth.log.2.gz

De la misma forma, zcat realiza un cat sobre un fichero de texto plano comprimido con gzip.

Registro de logados mediante SSH

Es un buen hábito revisar de vez en cuando el registro de logados mediante SSH, para detectar así posibles accesos no autorizados.

La forma de obtener el registro de accesos es mediante el siguiente comando:

# grep Accepted /var/log/auth.log
Feb 18 08:20:21 myserver sshd[27373]: Accepted publickey for nagios from 192.168.44.8 port 56032 ssh2
Feb 19 10:22:52 myserver sshd[17224]: Accepted password for root from 192.168.44.2 port 55073 ssh2

Indicar que dicho fichero de registro, auth.log , va rotando por lo que es posible que haga falta revisar el fichero auth.log.1, auth.log.2.gz, ...

Interpretar la salida de load average

Los valores de "load average", o de carga media del sistema, nos los tropezamos continuamente en el día a día en el terminal de Linux. Un ejemplo de ello es el resumen del sistema que se muestra al acceder vía SSH:

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/

  System information as of Tue Feb 11 21:20:14 CET 2014

  System load:  0.0               Processes:           100
  Usage of /:   52.9% of 3.71GB   Users logged in:     0
  Memory usage: 27%               IP address for eth0: 192.168.1.1
  Swap usage:   3%

  Graph this data and manage this system at https://landscape.canonical.com/

O con el comando uptime:

 21:20:14 up 220 days,  5:43,  1 user,  load average: 0.00, 0.03, 0.09

O con el comando top:

top - 20:27:40 up 220 days,  5:43,  1 user,  load average: 0.00, 0.03, 0.09
Tasks: 108 total,   1 running, 107 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.4%us,  1.7%sy,  0.7%ni, 97.0%id,  0.2%wa,  0.1%hi,  0.1%si,  0.0%st
Mem:    120920k total,    81356k used,    39564k free,    16740k buffers
Swap:   238584k total,     9412k used,   229172k free,    29316k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1 root      20   0  2656  596  312 S  0.0  0.5  31:31.18 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.02 kthreadd
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0

Sin embargo, no todo el mundo entiende qué representan estos valores.

Básicamente representan la carga media del sistema en el último minuto, los últimos 5 minutos y los últimos 15 minutos. Un 100% de carga del sistema lo representaría el valor obtenido por:

# grep 'model name' /proc/cpuinfo | wc -l

Es decir, si tenemos un procesador con 2 núcleos, un valor de 2.0 representaría una carga del 100% del sistema.

Os recomiendo la lectura de este artículo, que explica muy bien y de manera bastante gráfica el concepto de carga del sistema.