Bloquear el acceso a Gtalk pero no a Gmail con Squid

Hace algunos días me tope con el siguiente inconveniente configurar un proxy Squid (no transparente) en el cual debía permitir solo el acceso a los correos de Gmail y no al resto de las aplicaciones como por ejemplo el chat, lo hice de la siguiente manera y funciono si alguien tiene una forma mejor que lo postee ;)

Primero que nada agregar las siguientes lineas en el squid.conf

acl cl_congmail src "/etc/squid3/acl/cl_congmail.txt"
acl gmail url_regex "/etc/squid3/acl/gmail.txt"
acl urlmalos url_regex "/etc/squid3/acl/urlmalos.txt"

http_access deny urlmalos
http_access allow gmail cl_congmail

- En el archivo cl_congmail.txt van todas las ips que queremos que tengan gmail por ej:
192.168.1.1
192.168.1.2


- En el archivo gmail.txt puse lo siguiente
.gmail.com
.mail.google.com
.google.com:443

- En el archivo urlmalos si queremos bloquear Gtalk puse la siguiente url
^http://chatenabled.mail.google.com

Registrando los eventos de la funcion mail() en PHP

Pasando revista por los blog que leo diariamente, me encontré con un articulo de las mejoras de PHP 5.3.0 que esta por salir. Entre ellas se agregan dos facilidades para la funcion mail() muy útiles para los administradores de sistemas.

Uno de los problemas mas comunes en un servidor de hosting con muchos dominios es la de encontrar quien esta abusando de la funcion mail() y esta enviando correos, tarea que a partir de la version 5.3.0 de PHP va a ser mas que simple, ya que se agregan dos nuevos parametros de configuracion.

El primero es el mail.add_x_header que, de habilitarlo desde el php.ini o desde un php_value, le agrega a los mail una cabecera X-PHP-Originating-Script con el nombre del script que esta generando el correo y el UID que lo esta ejecutando. Algo muy útil si tenemos algún retorno de los mail que se envian.

El otro parametro, por ahi un poco mas util, es mail.log que nos permite habilitar el registro de envios de los correos, guardando en un archivo local los script que llaman a la funcion mail() y algunos campos adicionales como los destinatarios de los mail.

Con estas dos nuevas facilidades, se reducirá bastante el tiempo que se pierde en rastrear todos eso correos basura que se disparan aprovechando vulnerabilidades de algunos sitios web.

Lo bueno de esto, es que buscando un poco mas de informacion sobre estas mejoras es que al caer al blog de Ilia Alshanetsky (el desarrollador de esta funcionalidad) podemos encontrar un parche que le podemos aplicar a las versiones actuales de PHP para poder tener estas caracteristicas, por lo que no hace falta esperar mucho para poder empezar a utilizar estas caracteristicas.

Una vieja historia Zen

Hoy charlando con una amiga, me hizo acordar de una vieja historia Zen que alguna vez lei, y que mas alla de su contenido filosófico sobre los ciclos, la vida, la muerte y demas:

Después de tomar el té, mientras que un estudiante de zen lavaba su taza y la de su maestro, la taza del maestro se le resbaló de entre las manos, cayó al suelo y se rompió. El estudiante se quedó muy preocupado y se lo comunicó a sus compañeros, que lejos de quitarle importancia al asunto, lo asustaron más diciéndole:

"La taza que has roto, era reverenciada por el maestro. Era muy antigua y de gran valor"

El estudiante no sabía cómo contárselo a su maestro sin ser castigado, por lo que se le ocurrió dirigirse a su maestro y decirle lo siguiente:

"Maestro, ¿por qué hay que morir?"

A lo que el maestro le respondió:

"Es lo natural, después de la vida, viene la muerte"

Entonces el discípulo repuso:

"Pero Maestro, ¿no puede algo durar eternamente?"

A lo que el maestro dijo de nuevo:

"Todo tiene su ciclo, las cosas empiezan y luego acaban. Todo lo que nace muere"

En ese momento el discípulo sacó los trozos de la taza rota y se la mostró al maestro diciéndole:

"Maestro, a la taza, le había llegado su tiempo"

Siempre me causo gracia por como el alumno sabiendo la respuesta, hizo la pregunta para que el maestro al responder estuviera preparado para lo que venia, entonces... quien fue el alumno y quien el maestro ??

Ejecutando comandos en multiples servidores

Uno de los problemas con los que me he encontrado en estas ultimas semanas es la de trabajar de manera sistemática ejecutando el mimo comando sobre varios servidores (un poco menos 200 servidores).

Debido a que esto es mas que molesto (sobre todo por lo rutinario), entonces recordando el viejo comando "expect" empecé a buscar algún script para poder automatizar un poco este tipo de tarea.

Así es como me encontré con los el repositorio de script de nixCraft, de donde rescate un simpático script para poder ingresar a un servidor ssh pasando de parametro la clave, el servidor y el comando a ejecutar.

Despues de unas modificaciones al script el mismo quedo algo mas o menos asi:

#!/usr/bin/expect -f
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# For use:
# ./sshlogin.exp password server command arg1
#
# ----------------------------------------------------------------------
# Basado en http://bash.cyberciti.biz/security/expect-ssh-login-script/
# ----------------------------------------------------------------------

# set Variables
set password [lrange $argv 0 0]
set ipaddr [lrange $argv 1 1]
set scriptname [lrange $argv 2 2]
set arg1 [lrange $argv 3 3]
set timeout -1

# now connect to remote UNIX box (ipaddr) with given script to execute
spawn -noecho ssh -o "ConnectTimeout 10" root@$ipaddr $scriptname $arg1
match_max 100000

expect {
# first time
"*continue connecting*" { send -- "yes\r"; exp_continue }

# for passphase key
"*passphrase*" { send -- "$password\r"; exp_continue }

# for password
"*assword*" { send -- "$password\r"; exp_continue }

# for timeout
"timeout" { exit }
}


Con ese script podemos, por ejemplo saber cuanto tiempo lleva encendido alguno de nuestros servidores:

./sshlogin.exp la_clave el_server uptime

Con esto, solo hemos resuelto la mitad del problema, que es poder ejecutar el comando sin tener que esperar a que nos pida la clave. Pero la segunda parte es la mas facil.

Vamos a partir generando un archivo con los servidores y sus claves, algo asi como:

servidor_1:clave_1
servidor_2:clave_2
servidor_3:clave_3

Y con un simple script como el siguiente, podemos recorrer el listado de servidores y claves y ejecutar el comando en todos ellos:

#!/bin/bash
mkdir -p log
for linea in `cat server.lst`
do
server=`echo $linea |awk -F":" '{ print $1 }'`
clave=`echo $linea |awk -F":" '{ print $2 }'`

./sshlogin.exp $clave $server "(wget -q -O - http://miservidorweb.com/inventario.sh|bash)" > log/$server
done

Con esto podemos descargar un script de un servidor y ejecutarlo en el servidor remoto y guardar el resultado en la maquina local.