la ferrata de IT

que hacer para que nadie entre en el dominio

Antes de migrar un Samba 3.3 a una versión 3.4/3.5 hay que tener bien claro que parámetros cambian de una versión a otra. Parámetros que creíamos por default al cambiar de versión ya no lo son.

Esto me ha pasado al migrar de la 3.3 a la 3.4 con el efecto que nadie podía logearse en el sistema. En la versión 3.3 el parámetros “passdb backend = smbpasswd” pasa a ser por defecto “passdb backend = tdbsam”. Dado que son valores por defecto es muy complicado encontrar cual es problema ya que no se produce ningún error en el Samba (salvo un Access denied).

Para obtener todos los parámetros ya sean escritos en tú smb.conf como por defecto es dicha versión podemos hacer un: testpam –v –s > smb33.conf.bak Luego podemos comparar la versión de nuestra smb.conf cuando estaba en versión 3.3 con el smb.conf al migrar a la 3.4.

Más información:
+ http://lists.samba.org/archive/samba/2010-May/156135.html
+ http://samba.2283325.n4.nabble.com/problems-after-upgrade-from-3-3-2-to-3-4-0-td2440950.html

validar usuario y contraseña en una linea

Estoy creando un script PHP para cambiar la contraseña de un usuario creado en un sistema Linux. Previamente a cambiarla debe poner su anterior contraseña y para ello necesito validar un usuario y su contraseña. Es decir, necesito saber si un nombre de usuario y contraseña son válidos. Para ello básicamente cifro la contraseña del usuario y la comparo con el /etc/shadow de mi sistema Linux.

#!/bin/bash

# por Alejandro Moreno (Kernpharma) - julio 2011
# Utilizar en "--method=" el metodo de cifrado deseado (SHA-512, MD5, etc)
# Instalar la utilidad mkpasswd (http://pkgs.org/ubuntu-10.04/ubuntu-universe-i386/mkpasswd_5.0.0ubuntu3_i386.deb.html)

if test $# -lt 2 ;
then
   echo "Error de parametros."
   echo
   echo "Sintaxis:"
   echo "   # ./validatepwd.sh <username> <password>"
   exit 3
fi

username=$1
password=$2

contrl=`cat /etc/passwd | grep $username`

if [ "$contrl" != "" ]
then

   encrypt=`cat /etc/shadow | grep $username | cut -d: -f2 | cut -d$ -f 2`
   salt=`cat /etc/shadow | grep $username | cut -d: -f2 | cut -d$ -f 3`
   contrl=`mkpasswd --method=SHA-512 $password --salt=$salt`

   if [ "$contrl" = "`cat /etc/shadow | grep $username | cut -d: -f2`" ]
   then
      echo "Validacion OK."
      RETVAL=0
   else
      echo "ERROR de validacion."
      RETVAL=1
   fi
else
   RETVAL=2
fi

exit $RETVAL

cuando se cae todo, buena cara

nagios gadget para windows 7

El siguiente gadget para Windows permite monitorizar tus servidores y avisarte de las caidas. Ataca directamente a la URL de tú Nagios: http://servidor/nagios/cgi-bin/nagxmlstatus.cgi.


Para ello deberás copiar el siguiente script nagxmlstatus.cgi en tú carpeta de /opt/local/nagios/sbin (o donde apunte tú cgi-bin). Hay que darle permisos de ejecución e instalar los requisitos y librerias necesarias para ejecutar este script en Pearl:

# apt-get install libxml2 libxml2-dev
# perl -MCPAN -e "install XML::LibXML"
# perl -MCPAN -e "install CGI"

Finalmete podrás instalarte el gadget en todas las maquinas Windows que quieras.

Más información:
+ Nagstatus gadget 1.5.3
+ nagxmlstatus.cgi

agente nagios para linux

Si tenemos Nagios, podemos monitorizar maquinas remotas utilizando el agente de Nagios para Linux o para Windows.
Si la maquina remota es un Windows, podemos instalar el NSClient++. Si la maquina es un Linux, podemos instalar el NRPE. Explicaré cómo se instala el NRPE y cómo se configura Nagios para hacer consultas a esta maquina remota.

Tenemos que tener presente dos tipos de maquinas: la maquina con Nagios Server (por ejemplo 192.168.1.2) y la maquina remota (por ejemplo 192.168.1.3). El funcionamiento es el siguiente: en los dos extremos hay que instalar un NRPE de forma que el daemon de la maquina remota ejecutará los comandos que nosotros definamos, por ejemplo check_disck, check_swap, check_users, check_oracle, etc.

En la maquina remota hacemos:

# wget http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-plugins-1.4.15.tar.gz
# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz

# useradd nagios
# passwd nagios

Nota: recomiendo editar el /etc/passwd y ponerle un Shell /bin/false a este usuario para que no pueda hacer Login en el sistema.

# tar -xzvf nagios-plugins-1.4.15.tar.gz
# cd nagios-plugins-1.4.15
# export LDFLAGS=-ldl
# ./configure --with-nagios-user=nagios --with-nagios-group=nagios
# make
# make install 
# chown nagios.nagios /usr/local/nagios
# chown -R nagios.nagios /usr/local/nagios/libexec/

# apt-get install xinetd libssl-dev
# tar xvfz nrpe-2.12.tar.gz
# cd nrpe-2.12

# ./configure
# make all
# make install-plugin
# make install-daemon
# make install-daemon-config
# make install-xinetd

Editar /etc/xinetd.d/nrpe para aceptar peticiones solo de nuestro Nagios Server:

only_from       = 127.0.0.1 192.168.1.2

La IP 192.168.1.2 es la de nuestra maquina Nagios Server.

# /etc/init.d/xinetd restart

Pruebas de funcionamiento:

# netstat -ant | grep 5666
tcp        0      0 0.0.0.0:5666            0.0.0.0:*               LISTEN  
# /usr/local/nagios/libexec/check_nrpe -H localhost
NRPE V2.12

Modificar los comandos disponibles para nuestra maquina remota. Editar el /usr/local/nagios/etc/nrpe.cfg y modificar los comandos a nuestro gusto. Yo he creado una consulta llamada check_disk que me dirá el estado de disco /dev/sda1:

command[check_disk]=/usr/local/nagios/libexec/check_disk -w 20% -c 10% -p /dev/sda1

En la maquina Nagios Server hacemos:

# wget http://prdownloads.sourceforge.net/sourceforge/nagios/nrpe-2.12.tar.gz
# apt-get install libssl-dev
# cd nrpe-2.1.2
# ./configure
# make all
# make install-plugin

Prueba de funcionamiento:

# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3
NRPE V2.12
# /usr/local/nagios/libexec/check_nrpe -H 192.168.1.3 -c check_disk
DISK OK - free space: / 33010 MB (96% inode=97%);| /=1126MB;28771;32367;0;35964

Ahora solo queda configurar nuestro Nagios Server para que utilice el comando check_nrpe:

define service{
   use generic-service
   host_name remotehost
   service_description Current Users
   check_command check_nrpe!check_disk
}

Más informacion:
+ http://nagios.sourceforge.net/docs/nrpe/NRPE.pdf

caida ldap

Hoy se ha ido la luz y nos ha echado abajo el servidor de Samba. Como consecuencia al reiniciar el servidor se ha quedado corrupto el LDAP con el siguiente error:

[root@fileserver]# /etc/init.d/ldap start
Checking configuration files for slapd: bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
bdb_db_open: Database cannot be opened, err 13. Restore from backup!
bdb(dc=XXXXXX,dc=com): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem
backend_startup_one: bi_db_open failed! (13)
slap_startup failed (test would succeed using the -u switch)
[FAILED]
stale lock files may be present in /var/lib/ldap [WARNING]

Antes de restaurar el backup hemos probado un: http://www.blogger.com/img/blank.gif

[root@fileserver]# /usr/sbin/slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 1 offset 5315883
Recovery starting from [1][5315755]
Recovery complete at Sun Jul 30 11:31:56 2006
Maximum transaction ID 8000040d Recovery checkpoint [1][5315883]

Para restauraciones más críticas podemos hacer un backup en texto de tú arbol LDAP, corregir los errores y volver a recrear el arbol de LDAP. En este post hay un buen ejemplo: http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

envolviendo el vsftp

Al intentar poner un servicio público en Internet, te das cuenta de la cantidad de intentos de acceso que hay al cabo de un día. Al final, te queda la duda de si pueden o no llevar buen puerto.
Si eres de esos de que leen los Logs cada día o de lo que reciben su Logwatch oportuno, te darás cuenta de estos intentos:

--------------------- pam_unix Begin ------------------------ 
 vsftpd:
    Unknown Entries:
       check pass; user unknown: 168 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrator rhost=thirdeyemedia.net : 82 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=administrador rhost=thirdeyemedia.net : 59 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=anonymous rhost=host217-40-235-141.in-addr.btopenworld.com : 17 Time(s)
       authentication failure; logname= uid=0 euid=0 tty=ftp ruser=Administrator rhost=113.107.101.249 : 168 Time(s)
       check pass; user unknown: 168 Time(s)

Para bannear estas IPs, lo puedes realizar de dos formas diferentes: o las cierras directamente en tú firewall perimetral, o lo cierras en el firewall del propio servidor o lo cierras con tcpwrappers.

El concepto de tcpwrappers consiste en envolver tú daemon TCP/UDP en un envoltorio el cual analiza el paquete de red antes de enviárselo a tú daemon. Tcpwrapper permite controlar los accesos a los servicios ofrecidos por el sistema ya sea por máquina, por servicio o por combinaciones de ambos. Para ello el daemon de tcpwrapper llamado “tcpd” lee los archivos de configuración /etc/hosts.allow y /etc/hosts.deny. El primer archivo contie las reglas que especifican las máquinas y servicios que están autorizados y el segundo las maquinas y servicios que no están autorizados.
Personalmente me gusta este sistema porque es posible denegar estas conexiones por un administrador que no tiene acceso a su Firewall porque este está administrador por otro conjunto de personas y además no es necesario rebotar nigún servicio.


En este ejemplo real vamos a denegar los accesos de 113.107.101.249, 217.40.235.141 y 64.40.107.210, que corresponden a diferentes ataque al servicio FTP. Primero de todo verificaremos que el servicio de FTP está compilidado para poder utilizar TCPWrappers:

# whereis vsftpd
vsftpd: /usr/sbin/vsftpd /etc/vsftpd /usr/share/man/man8/vsftpd.8.gz
# ldd /usr/sbin/vsftpd | grep libwrap
        libwrap.so.0 => /lib/libwrap.so.0 (0x0046c000)

Una vez vemos que la librería está cargada, podemos editar el /etc/hosts.deny y meter todas las IP necesarias:

vsftpd: 113.107.101.249, 217.40.235.141, 64.40.107.210

Podemos bloquear también por rangos o por subredes:

vsftpd: 113.107.101.0/255.255.255.0

Podemos denegar todos los accessos a cualquier servicio:

ALL: 113.107.101.0/255.255.255.0

O incluso podemos dejar un mensajito:

vsftpd : .elhacker.net \
: twist /bin/echo "421 %h has been banned from this server!"

Si queremos ver todos los servicios TCP que están compilados para utilizar TCPWrappers, podemos hacer:

# strings -f /usr/sbin/* | grep hosts_access
/usr/sbin/rpc.mountd: hosts_access
/usr/sbin/sshd: hosts_access
/usr/sbin/stunnel: hosts_access
/usr/sbin/stunnel: See hosts_access(5) manual for details
/usr/sbin/tcpd: hosts_access_verbose
/usr/sbin/vsftpd: hosts_access

Más información:
+ http://linux.web.cern.ch/linux/scientific4/docs/rhel-rg-en-4/s1-tcpwrappers-access.html

migrando a mpls

cuantas visitas tendre

Acabo de leer un artículo muy interesante sobre las tendencias de las personas al hacer click sobre los resultados aparecidos en Google al realizar una búsqueda.

La Universidad de Cornell ha realizado un estudio llamado "Eye-Tracking Analysis of User Behavior in WWW Search" en el cual se concluye que si tú pagina aparece en la primera posición del buscador tendrás un 56% de posibilidades que finalmente esa persona clique sobre tú Web. Para cualquier SEO este estudio puede ser muy interesante porque le puede ayudar a que un cliente comprenda cuantas visitas puede llegar a recibir si se encuentra bien situado en las búsquedas de Google.

En la siguiente imagen se muestra cómo mira el ojo humano la pagina de Google tras realizar un búsqueda:

La siguiente muestra el % de clicks que se llevaría una pagina si el usuario escogiera esa opción.

Pongamos un ejemplo. Supongamos que mi pagina Web es www.amperisblog.com y que he escrito un articulo que explica cómo bloquear el programa Ultrasurf. Supongamos también que con mi estudio de SEO y con varios meses de trabajo he conseguido posicionar mi página para que aparezca en las primeras posiciones cuando la gente realiza la busqueda “bloquear ultrasurf”. Cómo veis mí pagina aparece en tercera opción (aun me queda un duro trabajo de SEO para posicionarme más arriba).


Ahora veamos desde la utilidad Google Adwords (Herramientas para palabras clave) que la busqueda “bloquear ultrasurf” se realiza 2.400 veces al mes en todo el mundo.


Por tanto: (2400 * 9,82) / 100 = 235 visitas.

Es decir, que cada mes mí página recibirá (aproximadamente) 235 visitas por aparecer en la tercera opción.

Ahora supongamos que soy el dueño de la Web www.softonic.com (creo nadie la cononoce ¿no?). Supongamos que con mi estudio de SEO me he podido posicionar en primera opción cuando alguien busca “descargar software gratis”.
Si miramos en Google Adword, vemos que esta búsqueda se hace un millón de veces al mes.

Por tanto: (1000000 * 56,36) / 100 = 563600 visitas.

Cada mes, Softonic recibe una media de 560.000 visitas cuando la gente busca el termino “descargar software gratis”.