2015-04-12

Cómo consolidar logs de contenedores Docker



Una manera muy fácil de consolidar los logs de los contenedores Docker de un mismo servidor físico es utilizando rsyslog. Aunque este método no funciona cuando los contenedores Docker están distribuídos en distintos servidores, tiene la ventaja de ser muy sencillo y no requiere la instalación de nuevos servicios.

Nota: el artículo fue escrito antes del release de Docker 1.6; una de las novedades de dicha versión es "logging drivers", que facilita y estandariza el procesamiento de logs.

El objetivo es consolidar los logs propios del servidor, y de los contenedores Docker, en el archivo /var/log/messages, y lograr que cada mensaje esté correctamente prefijado con un identificador, para poder diferenciar el origin el mismo; por ejemplo:

Apr 9 11:22:01 app1.docker ansible-command: Invoked with (...)
Apr 9 11:22:05 app1.docker ansible-service: Invoked with (...)
Apr 9 11:23:02 anfitrion su: (to postgres) (...)
Apr 9 11:23:25 app2.docker ansible-service: (…)

Primero debemos crear (en el host/anfitrion) la configuración para rsyslog, en /etc/rsyslog.d:

user@anfitrion$ sudo vim /etc/rsyslog.d/sockets-for-docker.conf

con el siguiente contenido:

$InputUnixListenSocketHostName app1.docker
$AddUnixListenSocket /dev/log-app1

$InputUnixListenSocketHostName app2.docker
$AddUnixListenSocket /dev/log-app2

Además debemos mapear (usando volumenes de Docker) el archivo /dev/log de cada contenedor al socket correspondiente del host/anfitrión, por ejemplo:

$ docker run -v /dev/log-app1:/dev/log ···
$ docker run -v /dev/log-app2:/dev/log ···

De esta manera, los servicios en los contenedores loguearán a /dev/log, que en realidad está mapeado a /dev/log-appX. El servicio rsyslog estará configurado para obtener los mensajes de dichos sockets y veremos esos mensajes en /var/log/messages.


Nota: los paths y configuración de este artículo corresponden a un servidor host/anfitrión Amazon Linux AMI 2014.09. Queda para investigar la manera de configurar rsyslog para permitir consolidar logs de contenedores corriendo en otros servidores enviando los mensajes por red.


2014-02-25

Integrando Python y Websocket / Socket.IO usando Node.JS y Redis

He publicado una aplicación muy simple, pero es un ejemplo funcional de cómo se podría integrar Socket.IO a aplicaciones web Python utilizando para tal fin Node.JS y Redis.

La aplicacion es muy simple, pero cumple (o al menos, lo intenta) con todas las características necesarias como para utilizarlo en aplicaciones reales, incluyendo el uso de Nginx como frontend (gracias a que soporte WebSocket)

El repositorio GitHub es https://github.com/data-tsunami/NodeJS-SocketIO-Redis-Python-Nginx.



2014-01-26

Proxy reverso SSL/SSL con Apache



Como parte de un proyecto de segurización de servicios, he instalado un proxy reverso que recibe peticiones SSL, en donde el servidor interno también utiliza SSL. Para lograr esto, hace falta utilizar SSLProxyEngine. La configuración para Apache que utilicé es algo así:


<VirtualHost *:443>
    DocumentRoot /var/www/empty
    ServerName intranet.data-tsunami.com
    ErrorLog logs/intranet.data-tsunami.com-error_log
    CustomLog logs/intranet.data-tsunami.com-access_log common

    SSLEngine on
    SSLProtocol all -SSLv2
    SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
    SSLCertificateFile /etc/pki/tls/certs/intranet.data-tsunami.com.crt
    SSLCertificateKeyFile /etc/pki/tls/private/intranet.data-tsunami.com.key
    SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
    SetEnvIf User-Agent ".*MSIE.*" \
    nokeepalive ssl-unclean-shutdown \
    downgrade-1.0 force-response-1.0

    SSLProxyEngine on

    ProxyRequests Off
    ProxyPass / https://intranet.data-tsunami.com:443/
    ProxyPassReverse / https://intranet.data-tsunami.com:443/
</VirtualHost>

2014-01-20

PSAD 2.2.1 en CentOS 6.5

Update: ya ha sido liberada la versión 2.2.2 de PSAD, que quizá incorpore el FIX al problema que originó este post (todavía no lo he probado)

Un cliente me solicitó instalar PSAD en unos servidores CentOS, tarea que parecía trivial pero resultó con un par de sorpresas. Como primer paso, bajé el SRPM (específicamente psad-2.2.1-1.src.rpm) desde http://cipherdyne.org/psad/download/
  • $ wget http://cipherdyne.org/psad/download/psad-2.2.1-1.src.rpm

También necesité instalar las herramientas de desarrollo:
  • $ sudo yum install rpm-build make perl-ExtUtils-MakeMaker
  • $ mkdir -p ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}
  • $ echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros

Forma rápida y fácil (no funciona con v2.2.1-1)

La forma más rápida y fácil sería realizar el build desde SRPM, y luego instalar el RPM:
  • $ rpmbuild --rebuild psad-2.2.1-1.src.rpm
  • $ sudo rpm -iv psad-2.2.1-1.x86_64.rpm

Luego seguir las instrucciones para configuración desde http://krystianekb.blogspot.com.ar/2013/01/ubuntu-port-scan-detection-tools-psad.html, y finalmente, iniciar el servicio:
$ service psad start
Starting psad: [*] Could not open /etc/psad/protocols: No such file or directory at /usr/sbin/psad line 9056.
                                                           [FAILED]

Error! El problema es conocido, y está reportado en http://comments.gmane.org/gmane.comp.security.firewalls.psad.general/141.

Instalar SRPM y compilar con otro specfile

Tomando información de http://wiki.centos.org/HowTos/RebuildSRPM, hace falta instalar el SRPM:
  • $ rpm -ivh psad-2.2.1-1.src.rpm

Luego, sobrescribir el specfile erróneo con el que bajamos:

Y luego compilar:
  • $ cd ~/rpmbuild/SPECS/
  • $ rpmbuild -ba psad.spec

Y ahora lo instalamos (nuevamente):
sudo rpm -vih --replacepkgs ~/rpmbuild/RPMS/x86_64/psad-2.2.1-1.x86_64.rpm
Preparing...                ###########################################



Otro problema que me surgió fue que no existía el directorio "/etc/psad/archive", y eso causaba que el servicio no iniciara correctamente:
[root@centos6 psad]# service psad startStarting psad: [*] Could not mkdir /etc/psad/archive: Permission denied at /usr/sbin/psad line 9814.                                                           [FAILED]


Lo que se puede solucionar ejecutando:
  • $ sudo mkdir /etc/psad/archive