La mayor parte de las veces son mujeres: Te dejan un CPU o Laptop para reparación y nunca te avisan: «La contraseña de ingreso a windows es tal o cual«.

En este punto surgen dos posibilidades:

  1. Llamar por teléfono a la cliente y preguntar: ¿Cual es el password?
  2. Usar ERD Commander y su Locksmith para blanquear la contraseña de la cuenta.

Muy poco profesionales ambas, sobre todo si le cambias la contraseña a su usuario para mas tarde «olvidarte» –intencionalmente o no– de avisarle cuando se lleva el equipo.

Por otro lado, si se trata de una fémina y tu aspecto físico se parece al de Brad Pitt no va a tener problemas en recibir una llamada de tu parte, aunque mas no sea para que le preguntes cual es la contraseña de acceso a su sistema, pero: ¿Qué técnico de PC se parece a Brad Pitt?

Llevo casi 15 años en esto de la informática y no conozco ninguno que se separe del prototipo de Nerd lo suficiente como para destacarse entre la jauría de hombres hambrientos, así que si este es tu caso, o peor, si sos morocho, petizo y feo como el enano del señor de los anillos, tu porca miseria ha llegado a su fin:

Kon-Boot – Accede a windows y Linux sin necesidad de conocer la contraseña

Kon-Boot es un software prototipo de esos para sacarse el sombrero. Una obra maestra, una perlita de las que te encontrás cada tanto entre tanta mierda que hay en la web, y me lo encontré por pura casualidad.

Kon-Boot está totalmente programado en assembler, se carga en memoria antes que el sistema operativo y permite hackear el kernel del mismo en tiempo real obteniendo:

  • Acceso a todas las cuentas del sistema sin conocer el password
  • Escalado de privilegios. La cuenta accedida siempre es Administrador o Root
  • Funcionamiento por igual en sistemas operativos de 32 o de 64 bits
  • Acceso a  todos los windows y supuestamente a todos los Linux con kernel de la rama 2.6.*

Lo he puesto en mi servidor PXE y ya me ha evitado la bochornosa llamada en un par de oportunidades, con lo que puedo afirmar que funciona en windows 7, windows XP y windows vista. No lo he probado en mis Linux todavía.

Para bootear Kon-Boot con PXE, a mi Grub le agregé una entrada en el menu.lst que dice:

title La KON de la Boot
map –mem (pd)/img/konboot.img (fd0)
map –hook
rootnoverify (fd0)
chainloader +1

Nada del otro mundo.

En caso de que hayas perdido el Link a la página web oficial del autor que puse mas arriba, va de nuevo: http://www.piotrbania.com/all/kon-boot/

* La palabra windows ha sido intencionalmente escrita en minúsculas en todas las oportunidades

Como ya he mencionado en otras oportunidades, arranco desde la red usando PXE prácticamente de todo. Imágenes de CD y DVD, Imágenes de diskette, algunas distribuciones de Linux, etc…

Por masoquismo elección personal, mi única distribución de Linux instalada en todas mis PC es Gentoo así que tenía como asignatura pendiente poder arrancar una instalación de Gentoo desde la red, cosa que de por sí no es nada facil ya que si por algo se caracteriza Gentoo es por su capacidad de personalización en función del hardware.

Como hace unos días me hice con una PC que voy a usar como mediacenter se me ocurrió: ¿Por que no hacerla arrancar desde la red y aprovechar el 100% del disco rígido de la misma para almacenamiento multimedia?

Así que me hice con la guía de Gentoo para terminales diskless y me puse dedos a la obra.

Al menos dos horas estuve dándole cabezasos a la pantalla. El sistema se negaba sistemáticamente a montar la partición raíz en modo R/W (lectura y escritura).

Al no poder montar en modo R/W la partición raíz, la gran mayoría de los servicios quedaban sin iniciarse. Esto me llevó a revisar toda la configuración de punta a punta, a googlear hasta los rincones mas recónditos, a buscar y remilbuscar en los foros de Gentoo y por último a probar soluciones de esas que no tienen ninguna lógica, de las que rayan en lo esotérico.

¿Cual fué la solución?

Pasarle al kernel durante el arranque la opción rw.

Suena lógico, ¿No?

No, no tiene ninguna lógica. La línea de grub que me permitió por último dar con un sistema funcional que cargue / en modo R/W es esta:

kernel /gentoo-2.6.32 ip=dhcp rw root=/dev/nfs nfsroot=192.168.0.1:/diskless/mediacenter

Noten la posición de la opción rw. Esto no está documentado en ningún lugar, lo dejo por aquí para quien pueda necesitarlo el día de mañana con la esperanza de que –google de por medio– alguien llegue hasta este blog y se ahorre un dolor de cabeza.

Viene de la parte 1: [HowTo] Recibir logs remotos usando Syslog

Logo de phpsyslogngUsando phpsyslogng se pueden controlar los logs de cualquier PC que corra Linux y Syslog-NG de forma mucho mas visual e intuitiva.

Phpsyslogng provee  además de interesantes gráficos estadísticos y un potente sistema de filtrado por host, aplicación, prioridad y facility.

Ejemplo de gráfico de phpsyslogng

Para que todo esto funcione es necesario contar con una instalación preexistente de Apache con PHP y MySQL. No voy a entrar en detalles acerca de la instalación y configuración de cada uno de estos servicios por que está fuera del alcance de esta guía.

Instalación:

Usando el gestor de paquetes de su distribución preferida, instalar phpsyslogng. En Gentoo:

echo «app-admin/phpsyslogng mysql» >> /etc/portage/package.use

emerge  phpsyslogng

Opcional, si el servidor Apache está configurado para usar hosts virtuales, se puede instalar solo en uno de estos vhost habilitando la use flag correspondiente.

Una vez instalado, crear la base de datos correspondiente:

mysql> create database syslog;

Query OK, 1 row affected (0.18 sec)

El nombre de la base de datos (syslog) es arbitrario, pero es el que se sugiere por defecto durante la instalación.

Configuración de phpsyslogng:

Para que se rellene la base de datos con las tablas correspondientes basta con apuntar el browser a http://host.dominio.com/phpsyslogng, esto iniciará el asistente para finalizar la configuración en donde se solicitarán el nombre de usuario y contraseña de acceso, parámetros de la base de datos, etc.

Ejemplo de instalación de phpsyslogng

Configurando Syslog-NG:

El paso siguiente es configurar Syslog-NG para que pueda convertir los logs a un formato que permita su inserción en la base de datos MySQL, para lo cual basta con editar /etc/syslog-ng/syslog-ng.conf y agregar lo siguiente:

destination d_mysql {
pipe(«/var/log/mysql.pipe»
template(«INSERT INTO logs
(host, facility, priority, level, tag, datetime, program, msg)
VALUES ( ‘$HOST’, ‘$FACILITY’, ‘$PRIORITY’, ‘$LEVEL’, ‘$TAG’, ‘$YEAR-$MON$
‘$PROGRAM’, ‘$MSG’ );\n») template-escape(yes));
};

log {
source(src);
destination(d_mysql);
};

Como ven, todos los logs se envían al archivo /var/log/mysql.pipe que será el encargado de parsearlos y insertarlos en la base de datos, por lo cual, el próximo paso es generar este archivo.

Creando el pipe /var/log/mysql.pipe

Crear un archivo nuevo de nombre arbitrario y con permisos de ejecución:

touch /usr/bin/syslogasql.sh

chmod +x  /usr/bin/syslogasql.sh

Dentro de ese archivo copiar las siguientes líneas:

if [ ! -e /var/log/mysql.pipe ]
then
mkfifo /var/log/mysql.pipe
fi
while [ -e /var/log/mysql.pipe ]
do
mysql -u aqui_tu_usuario –password=aqui_tu_password syslog < /var/log/mysql.pipe >/dev/null
done

Este archivo ejecutable será el encargado de crear el archivo de tubería que rellene la base de datos con la información obtenida desde los logs del sistema. Tiene que estar en constante ejecución por lo que es conveniente que se ejecute al inicio del sistema. En Gentoo esto se logra agregando el nombre del archivo a /etc/conf.d/local.start:

echo «/usr/bin/syslogasql.sh» >> /etc/conf.d/local.start

Es importante que este archivo no se ejecute antes de que se haya iniciado el servidor MySQL.

¡Y eso es todo!

Mientras syslogasql.sh se mantenga en ejecución, toda la salida de syslog será cargada en la base de datos y podrá ser consultada desde phpsyslogng.

Una vez terminada la instalación, un poco de seguridad:

Borrar el directorio de instalación:

rm -fr /var/www/localhost/htdocs/phpsyslogng/install

Evitar accesos ilegítimos a directorios comprometedores agregando las siguientes directivas al archivo de configuración de Apache:

<Directory «/var/www/phpsyslogng/scripts»>
Deny from all
</Directory>
<Directory «/var/www/phpsyslogng/includes»>
Deny from all
</Directory>
<Directory «/var/www/phpsyslogng/config»>
Deny from all
</Directory>

Al que como yo se encuentre en un punto en donde se le vuelve tedioso ir servidor por servidor, dispositivo por dispositivo revisando los archivos de bitácora (logs) de cada uno, esto le resultará de utilidad.

syslog es un estándar de facto para el envío de mensajes de registro en una red informática IP. Por syslog se conoce tanto al protocolo de red como a la aplicación o biblioteca que envía los mensajes de registro.

Un mensaje de registro suele tener información sobre la seguridad del sistema, aunque puede contener cualquier información. Junto con cada mensaje se incluye la fecha y hora del envío.

Recibir los logs de otros servidores en un servidor Linux:

En mi caso, mi servidor central corre Syslog-NG, pretendo recibir en este servidor todos los logs que generan otros servidores corriendo Linux y Windows, cámaras de seguridad, routers y puntos de acceso inalámbricos que controlo.

Syslog puede enviar información sobre TCP o UDP indistintamente. Por convención se usa el puerto 514 UDP. La mayoría de los dispositivos del tipo access points wireless o cámaras de seguridad no permiten especificar puerto o protocolo así que lo mejor es crear una regla en el firewall que reenvíe todo el tráfico del puerto 514 UDP que es la configuración por defecto a nuestro Syslog server:

iptables -A PREROUTING -t nat -i eth0 -p udp –dport 514 -j DNAT –to 192.168.1.150

Una vez hecho esto, habilitar Syslog-NG para que reciba tráfico por UDP editando el archivo /etc/syslog-ng/syslog-ng.conf:

source src {
unix-stream(«/dev/log» max-connections(256));
internal();
file(«/proc/kmsg»);
udp();
};

Con eso ya tenemos suficiente como para recibir todos los logs de otros servidores y dispositivos en la red o desde internet en nuestro servidor central syslog.

Consultando los Logs:

Todos estos logs se pueden consultar en diferido usando:

less /var/log/messages

O verlos en tiempo real desde una consola:

tail -f /var/log/messages

O traerlos desde tty12 a la tty1 para una cómoda visualización nuevamente editando /etc/syslog-ng/syslog-ng.conf:

# By default messages are logged to tty12…
destination console_all { file(«/dev/tty1«); };

Trayendo logs remotos hasta nuestro servidor syslog:

El paso siguiente es traer todos los logs remotos a nuestro servidor central para poder administrarlos con mas comodidad. A continuación algunos ejemplos para diferentes escenarios.

Windows:

En el caso de servidores que corren windows, bastará con instalar NTsyslog (requiere .NET 2.0 y windows installer 3.0) y configurarlo para que envíe los logs hasta nuestro syslogserver usando el número de IP o el nombre de dominio del mismo.

Captura del programa NTsyslog

Linux:

Cuando el servidor remoto corre syslog-ng, agregar en el archivo de configuración:

destination remote { udp(«mi.servidor.com» port(514)); };

Cuando el servidor remoto corre rsyslog o similares, agregar en /etc/rsyslog.conf:

*.*     @mi.servidor.com

Otros dispositivos:

Dependerá del caso pero la gran mayoría de equipamiento de red de calidad permite el reenvío de logs a otros dispositivos, solo es cuestión de acceder a la página web de administración de los mismos y configurarlos según corresponda.

Por último, la frutillita del postre, acceder a estos logs usando un cliente web usando phpsyslogng, (requiere Apache/PHP/MySQL), eso lo dejo para la próxima entrada, que por hoy se me acabó el tiempo:

Ejemplo de phpsyslogng
Sigue en la parte 2: [HowTo] Controlar los logs generados por syslog desde una página web