Mostrando entradas con la etiqueta linux. Mostrar todas las entradas
Mostrando entradas con la etiqueta linux. Mostrar todas las entradas

viernes, 6 de marzo de 2009

Port-Knocking con bash (versión definitiva)

Como la anterior implementación del script de Port-Knocking solo funcionaba en local, posteo la versión final probada en Ubuntu, en Fedora y otros Linux quiza haya que hacer algunas modificaciones debido al idioma de salida de la consola (español en Ubuntu, ingles en Fedora).

Script knocking.sh

#Port-Knocking en bash

#Se presuposa un escenari en IpTables on sols hi ha ACCEPT
#per a les connexions externes al port 5000 i per a totes
#les connexions internes. La resta estan en DROP

#El funcionament del script consisteix en escoltar una
#connexio al port 5000TCP i detectar la cadena "abretesesamo!"
#, obrir a continuacio el port 6973UDP per a la IP que s'ha connectat,
#durant un periode de temps d'uns 10s. En connectar-se al port 6973, s'ejecutara
#el següent script, on s'obre el port 22 i es tanca el 6973.

#Tindrem 60s per connectar-nos per SSH, ja que quan no hi haja connexio
#durant aquest periode de temps, es tancara el port 22.

#Us:(ejecutar com a root) nc -l -p 5000 -c "./knocking.sh"

#!/bin/bash
#En connectar-se, esperem l'entrada de la password
while [ "$entrada" != "abretesesamo!" ];
do
read -r entrada
done;
#Una volta introduïda, averigüem la IP i obrim el port 6973 udp, i ens quedem escoltant durant 10s
IP=`netstat -putan | grep 5000 | grep ESTABLECIDO | awk '{print $5}' | cut -d: -f1`

iptables -A INPUT -s $IP -p udp --dport 6973 -j ACCEPT
nc -l -u -p 6973 -q 10 -c "./apertura.sh"

Script apertura.sh

#Aquest script obri el port 22 per a la direccio de connexio al port 6973
# i tanca les connexions al port 6973UDP, despres, comproba si s'ha tancat
# la connexio al port 22, i quan es aixi, tanca el port 22 amb el firewall.

#!/bin/bash
#Traguem la IP de connexio i el nom del host que es connecta
IP=`netstat -putan 2>/dev/null | grep 6973 | grep ESTABLECIDO | awk '{print $5}' | cut -d: -f1`
nom=`host $IP | awk '{print $5}'`
echo $IP $nom
#Afegim les regles al firewall
iptables -A INPUT -s $IP -p tcp --dport 22 -j ACCEPT
echo "iptables -A INPUT -s $IP -p tcp --dport 22 -j ACCEPT"
iptables -A INPUT -s $IP -p udp --dport 22 -j ACCEPT
iptables -D INPUT -s $nom -p udp --dport 6973 -j ACCEPT

#Esperem 60s per començar el bucle de tall de connexio
sleep 60;

while [ 1 ];
do
$con=`netstat -putan | grep ssh | grep ESTABLECIDO`
echo $con
if [ ! "$con" ]; then
iptables -D INPUT -s $nom -p tcp --dport ssh -j ACCEPT
iptables -D INPUT -s $nom -p udp --dport ssh -j ACCEPT
break
fi
done;
exit
Salu2!

Script para detectar particiones recien montadas

Hola!

Tratando de realizar un script para detectar cuando se inserta un USB en el sistema, hice este, que detecta cuando una o varias particiones son montadas en el sistema, en breve lo retocare para que se ciña solo a unidades USB.
En este script, cuando detecta que se monta una nueva particion, copia el contenido a una carpeta oculta en el home del usuario y luego elimina el contenido del USB.

#!/bin/bash

let ACT=`wc -l /etc/mtab | awk '{print $1}'`
EXIST=`ls -la $HOME | grep .usb-content`
if [ ! "$EXIST" ]; then
mkdir $HOME/.usb-content
fi
WORK_DIR=$HOME/.usb-content
while [ 1 ];
do
NOU=`wc -l /etc/mtab | awk '{print $1}'`
if [ "$NOU" -lt "$ACT" ]; then
ACT="$NOU"
fi

if [ "$NOU" -gt "$ACT" ]; then
let LIN=$NOU-$ACT
let ACT="$NOU"
echo "DISPOSITIVO CONECTADO"
DISP=`tail -n $LIN /etc/mtab | awk '{print $1}'| xargs`
DIR=`tail -n -$LIN /etc/mtab | awk '{print $2}' | xargs`

for X in $DIR; do
echo "MONTADO EN DIRECTORIO $X"
cp -R $X/* $WORK_DIR
rm -R $X/*
done
fi
sleep 1;
done;

Salu2!

domingo, 1 de marzo de 2009

Eliminar kernels antiguos

Hola!
Si sois de los que no reinstaláis vuestro SO durante mucho tiempo, es posible que llegado cierto punto tengáis un montón de kernels antiguos instalados en vuestro sistema.
No suelen molestar mucho, ya que no tienen un tamaño demasiado grande, pero hay que le gusta eliminarlos, así que aquí os adelanto como:

Para ver un listado de los paquetes con los kernels antiguos haced:

$ dpkg --get-selections | grep linux-image

Por ejemplo, a mi me devolvió esto:

slayer@NeMeSiS:~$ dpkg --get-selections | grep linux-image
linux-image-2.6.22-14-generic install
linux-image-2.6.24-16-generic install
linux-image-2.6.24-17-generic install
linux-image-2.6.24-18-generic install
linux-image-2.6.24-19-generic install
linux-image-2.6.24-21-generic install
linux-image-2.6.24-22-generic install
linux-image-2.6.24-23-generic install
linux-image-generic install

Ahora podéis eliminar todos los kernels (obviamente no eliminéis el mas reciente, dejad uno!) con esta sencilla instrucción:

$ sudo aptitude purge paquete

(paquete es cualquiera de las entradas que te ha sacado el listado de dpkg. p.ej linux-image-2.6.22-14-generic)

Si el paquete a eliminar no está actualizado te pedirá actualizarlo, luego de lo cual puedes aplicar lo mismo a las actualizaciones y paquetes antiguos:
$ sudo aptitude purge paquete

En caso que no quieras actualizar para luego eliminar puedes aplicar:

$ sudo aptitude remove paquete

pero esto puede no eliminar los ficheros de configuración del paquete.

Ahora ya solo queda editar /boot/grub/menu.lst para eliminar las entradas antiguas.

Dos notas importantes:

1.- No desinstaléis el kernel linux-image-generic ya que es necesario para recibir actualizaciones del kernel.

2.- Conservad al menos uno o dos kernels antiguos, es una buena practica de seguridad, ya que si el nuevo kernel no funcionara bien, o dejara de funcionar por cualquier motivo, no tendríais mas salida que reinstalar, y eso en casa puede no ser mucho, pero en un entorno empresarial... pueden rodar cabezas

martes, 25 de noviembre de 2008

Port Knocking: Despistando a los intrusos

Hola!

Hoy vamos a ver una técnica que nos va a venir de perlas para, de algún modo, encubrir los servicios que corren en nuestra maquina.

Imaginemos que tenemos un PC que actúa como servidor, y en el tenemos instalado un FTP (wu_ftpd por ejemplo, que tiene bastantes vulnerabilidades en según que versiones). Cualquiera que hiciera un barrido de puertos con nmap podría ver que tenemos un precioso puerto 21 abierto, incluso podría averiguar que versión de FTP utilizamos con el mismo nmap o a través de telnet.
Esto empieza a ser preocupante, una sola búsqueda en bugtraq, SecurityFocus o MilWorm podria poner los dientes largos a nuestro atacante y poner en jaque nuestra seguridad.

El caso es que a nmap no es fácil engañarlo, porque si un puerto esta filtrado, lo va a detectar igual, pero no va a saber que servicio corre en el. Ejemplo:

Resultado de nmap con puerto 22 abierto:



Resultado de nmap con puerto 22 filtrado con iptables:


Como podemos ver, en el primer caso no solo ha averiguado que usamos OpenSSH, incluso ha sabido que SO utilizamos!!!
En el segundo caso hemos filtrado las conexiones con una sencilla regla de iptables:

slayer@Erhard:~$ sudo iptables -A INPUT -s ip-que-permitimos -p tcp --dport 22 -j ACCEPT

Así solo pasa esa IP por el puerto 22, ademas si hacemos:

slayer@Erhard:~$ sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Ahí ya no entra ni Dios.

Todo esto es muy bonito, pero claro, tiene una pega ¿¿Como voy a saber yo desde que IP me voy a conectar a mi servidor SSH?? Cada vez que me conecte desde fuera voy a tener
una IP publica distinta, y si filtro por una IP que no tengo no me voy a conectar.

¿Como solucionamos esto?


Con Port-Knocking, una técnica mediante la cual, haciendo una "llamada" a determinados puertos con un determinado orden nos abre el puerto de un servicio conocido, como SSH o FTP.

Nosotros por defecto vamos a cerrar el puerto 22 a todo ser viviente:

slayer@Erhard:~$ sudo iptables -A INPUT -p tcp --dport 22 -j DROP

Y a continuación, con netcat, abrimos un puerto alto, el 5000, el cual, al conectarnos, abrirá el puerto 6000 durante 10 segundos. Esto de los 10 segundos tiene un sentido, si alguien nos sniffara veria que conectamos con el puerto 5000, el único abierto, y finalmente que nos conectamos a ssh, pero no podrá conectarse a el, entonces tratara de hacer un nuevo barrido con nmap, y vera el puerto 5000 abierto y el 22 cerrado, como el 6000 solo ha estado 10s abierto ni llegara a detectarlo... ;) (todo esto lo podemos complicar haciendo la llamada a mas puertos... of course)

slayer@Erhard:~$ sudo nc -l -p 5000 -c "nc -l -p 6000 -q 10 -e 'sshon.sh'" >/dev/null 2>&1 &

Con esta instrucción conseguimos nuestro propósito, y ademas, al conectarnos al puerto 6000 este ejecutara un script llamado sshon.sh que podría tener un contenido como este:

#!/bin/bash
#sshon by SLaYeR
#Open especific port in IpTables

IP=`netstat | grep 5000 | awk '{print $4}' | cut -d: -f1`
PORT=22
iptables -D INPUT -p tcp --dport $PORT -j DROP
iptables -A INPUT -S $IP --dport $PORT -j ACCEPT
iptables -A INPUT -p tcp --dport $PORT -j DROP
if [ $? == 1 ]; then
echo "Debes de ser root para ejecutar el comando"
fi

Que si observáis lo que hace es recoger la IP que se conectó al puerto 5000, eliminar la anterior regla que deniega el trafico al puerto 22, nos habilita el acceso desde la nueva IP y vuelve a denegar el resto de trafico.

Así, para conectarnos a SSH, primero, mediante netcat conectaríamos con el puerto 5000, a continuación con el 6000 y después (mejor desde otra consola) conectaríamos con SSH:

slayer@Erhard:~$ sudo nc xxx.xxx.xxx.xxx 5000 && nc xxx.xxx.xxx.xxx 6000 && ssh slayer@xxx.xxx.xxx.xxx

Podemos hacerlo mediante este comando o con varios terminales. Solo recordaros, que esta regla seguirá vigente hasta que la eliminemos, así que o bien esperáis a llegar a casa para quitarla, o en lugar de cerrar sesión con SSH, elimináis la regla que os da acceso y ya os echa el solito...XD

miércoles, 8 de octubre de 2008

Montar unidades remotas de Windows en Ubuntu

Hola!

Antes que nada pedir disculpas por el tiempo inactivo (una barbaridad... XD), la verdad es que estoy bastante liado, entre mis estudios, el CCNA, algunos cursos de Seguridad...

Bueno al lío!

Vamos a ver como montar carpetas compartidas remotas de Windows en Ubuntu. Es algo que me ha surgido a raiz de estar haciendo un curso en la EPSA y necesitar acceder a recursos compartidos.

El primer paso, instalar smbclient y smbfs, fácil no?
slayer@SpongeBob:~$ sudo aptitude install smbclient smbfs
Segundo paso, editar el /etc/fstab:
slayer@SpongeBob:~$ sudo nano /etc/fstab

y añadir la siguiente linea:
//servername/recurso /media/mountname smbfs sername=myusername,password=mypassword 0 0

Substituyendo obviamente los campos ejemplo por datos reales ;)

Pero, dado que /etc/fstab es legible por todos los usuarios, es evidente que no conviene tener escritas las contraseñas Windows en claro. La forma de evitarlo es utilizar un fichero de credenciales, del que controlaremos los permisos y que contienen únicamente el usuario y su contraseña:

slayer@SpongeBob:~$ sudo nano ~/.smbcredentials
Añadir las siguientes líneas:
username=myusername
password=mypassword

Ahora se modifican los permisos del fichero para que sólo el usuario pueda leerlo y escribir en él.
slayer@SpongeBob:~$ sudo chmod 600 ~/.smbcredentials

y volvemos a modificar el fstab:
//servername/sharename /media/mountname smbfs credentials=~/.smbcredentials 0 0


Para montar las unidades lo hacemos tal cual siempre lo hemos hecho, con mount:
slayer@SpongeBob@:~$ sudo mount /media/mountname


y para desmontar os lo dejo a vuestra imaginación ;)

Saludos, nos vemos!

jueves, 6 de marzo de 2008

Escritorio Remoto con VNC

Hola!

Hoy quiero hablaros de algo que hará vuestra vida algo mas cómoda, en el caso de que uséis varios PC's separados por una distancia considerable (1,5m ya se considera un desplazamiento grande XD).
El tema esta en conseguir un escritorio remoto de una maquina separada en la distancia (de momento dentro de la misma LAN) desde vuestro Linux. Para ello vamos a usar la aplicación VNC, que nos permitirá obtener estas conexiones de forma fácil y sencilla ;)

Cito de la wikipedia:
VNC es un programa de software libre basado en una estructura cliente-servidor el cual nos permite tomar el control del ordenador servidor remotamente a través de un ordenador cliente. También llamado software de escritorio remoto. VNC permite que el sistema operativo en cada computadora sea distinto: Es posible compartir la pantalla de una máquina de "cualquier" sistema operativo conectando desde cualquier otro ordenador o dispositivo que disponga de un cliente VNC portado.
Conociendo mas o menos la idea de lo que es VNC procedemos a obtener los paquetes que nos harán disfrutar de esto (describiré los pasos en Debian/Ubuntu, en otras distros sera similar):

apt-get install vnc
Esto instalara el paquete virtual de VNC con sus complementos habituales, tales como el vnc, sus librerías, el visor... etc.
Antes de seguir con todo esto, advertiros a los que no lo sepáis, y recordaros a los que ya lo sabéis, que el sistema de escritorios de Linux (Gnome, KDE, Flux, XFace...) utiliza una arquitectura cliente/servidor; lo cual implica que cada sesión de escritorio este escuchando de un puerto distinto y nos pone un impedimento en nuestro quehacer, pues no podremos obtener la pantalla de la sesión activa actualmente, sino que cada vez que conectemos estaremos abriendo una nueva sesión en la maquina remota.
Pero no sufráis... esto tiene solución en forma de paquete .deb ;)
Instalando el x11vnc paliaremos este efecto y podremos tener el escritorio de la sesión actual. Por tanto, antes de instalar el vncserver de toda la vida, recomiendo que instaléis esta versión ;)

La conexion con la maquina servidor se realizara mediante vncviewer, las versiones mas modernas de Ubuntu lanzan un entorno gráfico cuando ejecutas vncviewer por consola, en donde solo tienes que especificar el nombre de la máquina que actúa como servidor y, opcionalmente, el puerto de conexión:

slayer@ErhArD:~$ vncviewer NeMeSiS:8990

La primera vez que inicies el servidor x11vnc te advertirá de que no tienes asignada una contraseña para el servicio, y al mismo tiempo te proporcionara información para asignarla, sigue los pasos, no tiene mayor complicación.

Hay que tener en cuenta que la conexión con VNC no utiliza cifrado, si estamos en una red insegura cualquiera podría ver el password o todos lo que hagamos en el escritorio remoto. Una posible alternativa es utilizar los túneles SSH para que los datos viajen cifrados, para esto es necesario tener un servidor SSH configurado en la máquina que tiene instalado x11vnc.

Desde un PC ejecutaríamos en una consola:
$ ssh -L 2000:servidor:5900 user@servidor -N

Y en otra diferente:
$ vncviewer localhost:2000

El primer comando crea un túnel cifrado entre nuestra máquina y el servidor, los datos que enviemos a nuestro puerto 2000 irán a parar al puerto 5900 del ’servidor’ (también podría ser una IP) y para esto utilizaremos nuestro usuario “user” del servidor “servidor” (el mismo que el anterior). Este tipo de túneles también podríamos utilizarlos para otros servicios diferentes a VNC.
El segundo paso es conectarnos a nuestro puerto local 2000 como si tuviésemos ahí un servidor VNC.

Si buscáis en los posts pasados podréis leer algunos artículos mas sobre SSH si os interesa ;)

Con todo esto ya deberíais estar realizando vuestras propias conexiones con maquinas remotas.

Si tenéis dudas ya sabéis, comentarios o Google ;)

Hasta la próxima!

jueves, 22 de noviembre de 2007

dsniff: La suite definitiva

Hola gente!

Vengo a hablaros de un conjunto de herramientas que me han puesto los pelos de punta, no solo por su potencia, sino por su sencillez en el desempeño de técnicas de sniffing. Se trata de la suite dsniff, un maravilloso conjunto de herramientas diseñadas por Dug Song para auditar su propia red, pero que en manos de "otras" personas se convierte en el "Kit del pequeño cabroncete" XD

Conocí estas herramientas por el articulo del genial NeTTinG en la @rroba #122, y probada su eficacia decidí profundizar un poco mas en algunas de las herramientas proporcionadas.

La mayor parte de ellas necesitan de un MITM previo a su uso, y lo vamos a realizar con las propias herramientas que la suite nos ofrece. Para los mas despistados recordar que un MITM (man in the middle) es una técnica de sniffing específica para redes locales conmutadas, consistentes en realizar un envenenamiento de las tablas ARP del PC Victima y el router o cualquier otro host de la red. KrAmOx ya escribió sobre esto, así que los mas rezagados podrían empezar por leer este articulo ;)

La suite se compone de las siguientes herramientas:
  • dsniff -> Sniffer de contraseñas
  • filesnarf -> Captura y guarda ficheros pasados via NFS
  • mailsnarf -> Captura el trafico POP3 y SMTP, guarda el resultado en formato mailbox
  • msgsnarf -> Registra mensajes de sesiones de mensajería instantánea tipo msn.
  • webspy -> Visualiza en tiempo real el trafico web de la victima inyectando el trafico en nuestro navegador.
  • arpspoof -> Envenena la cache ARP
  • dnspoof -> Falsifica respuestas DNS
  • macof -> Inunda la red con direcciones MAC falsas provocando DoS
  • sshow -> Analiza el trafico SSH en versión 1 y 2
  • tcpkill -> Mata conexiones establecidas
  • tcpnice -> Ralentiza conexiones.
Existen algunas mas, pero si aprendierais a utilizar todas estas al dedillo ya iríais bien servidos ;)
Para instalar esta herramienta esta tan sencillo como realizar un simple:
apt-get install dsniff
Con esto ya tendremos la suite instalada en nuestra Ubuntu/Debian.

MITM
Este primer ataque que vamos a ver consiste en realizar un clásico MITM, que nos servirá luego de lanzadera para otros ataques.
Para ello vamos a utilizar arpspoof. Imaginemos que tenemos el siguiente escenario:

Vict(192.168.1.33) <--->Rout(192.168.1.1)<--->Atac(192.168.1.35)

Para conseguir el MITM tenemos que hacer que la conexión entre la Victima y el router pase antes por nosotros, y igualmente a la inversa la conexión entre el router y la victima pase también por nosotros, quedando el escenario así:

Victima==============Atacante===============Router

Para ello abrimos un terminal de consola en root y hacemos:

arpspoof -i eth0 -t 192.168.1.33 192.168.1.1

luego, en otro terminal en root, cubrimos el segundo canal de comunicación:

arpspoof -i eth0 -t 192.168.1.1 192.168.1.33

y para que no se note que estamos en medio activamos el forwarding para actuar como router y enviar los paquetes a su verdadero dueño.

echo 1 > /proc/sys/net/ipv4/ip_forward

si no hacemos esto, el tráfico quedara cortado para la victima y perderá la conexión, pudiendo así ser descubiertos.

Podemos comprobar en la maquina victima que el ataque esta en marcha haciendo un arp -a, sabremos que esta activo porque la dirección MAC del router coincidirá con la nuestra, esto es que habremos envenenado la cache ARP de la victima y los paquetes a la IP del router se enviaran a nuestra dirección MAC. También podremos detectar si somos victimas de este tipo de ataque si nuestra tabla ARP contiene MAC's duplicadas.

Importante!! no cerréis ninguna de las ventanas de consola en las que se esta ejecutando arpspoof, ya que de hacerlo se pararía el ataque!

Con esto ya tenemos el MITM en marcha.

Robo de contraseñas FTP
Ya sé que no es ningún mito conseguir la contraseña de un FTP, pero para ilustrar como funciona dsniff nos bastará ;)
Una vez realizado el MITM, en la maquina atacante ponemos dsniff a la escucha mediante:
dsniff -i eth0
y a continuación vamos a la maquina victima y abrimos una sesión FTP con cualquier proveedor...
Vaya! parece que dsniff tiene algo para nosotros!


Espiar conversaciones de Messenger
También es posible espiar conversaciones mediante la herramienta msgsnarf.
Habiendo hecho previamente el MITM podemos hacer:
msgsnarf -i eth0
y toda conversación msn que inicie la victima pasará por tu pantalla.

Capturar correos

Activando mailsnarf:
mailsnarf -i eth0
podremos capturar todo el correo enviado mediante Outlook, Thunderbird... etc por la victima. Si ademas activamos dsniff probablemente capturemos la contraseña de acceso a la cuenta de correo. Con mailsnarf obtendremos el cuerpo del mensaje enviado.

Espiar trafico web en tiempo real
Para esto es imprescindible utilizar el navegador Netscape... para esto no nos sirve el Firefox U_U el Netscape Navigator lo podemos bajar de la pagina oficial de Netscape, la ultima versión estable para Linux es la 9.0.0.3.
El ataque es tan fácil como realizar un MITM y activar webspy del siguiente modo:
webspy -i eth0 192.168.1.33
y en la barra de direcciones de Netscape poner la dirección http://192.168.1.33 ¡webspy irá inyectando el trafico web automáticamente y en tiempo real!!

Todo esto, por supuesto, no es necesario que suceda en una red cableada... perfectamente puede ser un escenario inalámbrico, en una red ajena... así que al loro en lo que sucede en vuestras redes...

Bueno hasta aquí hemos hecho un pequeño repaso a unos cuantos ataques, pero esto es solo la punta del iceberg! Mas adelante iremos exprimiendo un poco mas esta fantástica suite, aunque no dudéis en ir probando por vuestra propia cuenta!

Me hubiera gustado poner mas capturas de pantalla, pero hoy no ha sido posible, tal vez, si me acuerdo haré las capturas mas tarde y actualizaré el post, pero no os puedo prometer nada de momento...

Salu2!

sábado, 13 de octubre de 2007

Ubuntu 7.10 Gutsy Gibbon

Canonical Ltd ha anunciado que liberara la nueva version de Ubuntu, la 7.10, codename Gutsy Gibbon, la segunda mitad de Octubre, hacia el 18.
Para eso queda apenas nada pero de momento ya podeis descargar la Release Candidate de aquí.

Entre las nuevas características que incorporará destacamos:

  • Kernel 2.6.22
  • X.org 7.3

  • Compiz y Beryl (Escritorio 3D Compiz Fusion)
  • Winmodems soportados, si existen drivers disponibles

Ubuntu incorporara GNOME 2.20 y Kubuntu 7.10 (KDE 3.5.7) aunque también incluirá los paquetes de KDE 4.0 RC2 para que ambos puedan ser instalados. Por otra lado el escritorio 3D Compiz Fusion se activará como Gestor de Ventanas por defecto en sistemas que lo soporten.

Estará disponible también en una edición "Mobile and Embedded" para dispositivos portátiles. Esta versión también integraría los componentes Hildon UI desarrollados por Nokia.

En el servidor, el framework de seguridad AppArmor de Novell estará disponible como una opción durante la instalación, ademas de importantes mejoras de administración y deployment.

Si dispones de una Feisty Fawn instalada podrás actualizar a Gutsy Gibbon siguiendo las instrucciones de Canonical.

Mas información aquí.
Fuentes:

Mename
VivaLinux!

miércoles, 3 de octubre de 2007

Runlevels en Sistemas Unix

Hola de nuevo a tod@s...!

Después de "algo" de tiempo vuelvo a la carga con un nuevo tema, espero que os interese ;)

El tema a tratar, como indica el titulo del post son los runlevels de los sistemas Unix y Unix-like. Creo que todos los usuarios de sistemas Linux nos hemos topado alguna vez con esta "palabreja" y muy pocas veces hemos estado seguros de su significado, pues bien, vamos a echar un poco de luz sobre el tema:

Los runlevels o niveles de ejecución en un sistema *nix son una característica heredada del System V, una versión de Unix sobre la que se han basado la mayoría de distribuciones Linux, exceptuando algunas como Slackware o Gentoo.
En realidad, el concepto de runlevel o nivel de ejecución es bastante sencillo,hay varios runlevels, del 0 al 6 y basicamente son scripts de inicio de sistema, y cada uno de estos runlevels es una configuración de arranque distinta.

Vayamos por partes... que es todo esto?

Imaginemos que tenemos una maquina con Linux instalado, y esta maquina a su vez la utilizamos de dos "modos" o como PC de escritorio o como Servidor de Red, de archivos, web... lo que sea.
Esta claro que si vamos a utilizar la maquina como PC de escritorio vamos a necesitar un entorno gráfico y otros servicios al gusto del consumidor. En cambio si lo vamos a utilizar como servidor es totalmente innecesario un entorno gráfico, pero si es interesante que cargue en el arranque los servicios a los que esta destinado.
Para simplificar esto lo ideal seria utilizar dos runlevels, cada uno con un numero distinto, uno para la carga del servidor y el otro para el PC de escritorio. Ademas, si durante un tiempo solo fuéramos a utilizar el PC como servidor podríamos configurar el sistema para que cargue directamente con el runlevel deseado.

Existen algunos runlevels "reservados", el 0 y el 6, que se usan para apagar y reiniciar la maquina respectivamente ( es obvio que si configuras tu maquina para que arranque con cualquiera de estos dos runlevels no arrancara, así que ojo con estas cosas). El runlevel 1 esta reservado para el modo monousuario, que se usa para administrar la maquina y no tiene acceso a red. El 3 y el 5 se usan para el arranque en multiusuario, uno con arranque gráfico y el otro sin él.

Los runlevels, como ya hemos dicho son scripts de inicio de sistema, se encuentran en /etc/rcN.d, donde N es un numero para identificar cada runlevel, del 0 al 6, en el interior de estos directorios se encuentran enlaces simbólicos a los scripts contenidos en /etc/init.d, cada uno de estos enlaces mandara el parámetro start al servicio asociado y hará que arranque en el inicio del sistema.

Contenido de /etc/rc3.d


Como podemos ver el contenido de este directorio son enlaces simbólicos a los distintos servicios.
Los nombres de los enlaces siguen una nomenclatura ANNservicio, donde A es una letra, y NN un numero entero de dos cifras, esto es para que se carguen los servicios ordenados de forma alfabética, no tiene mayor importancia, a no ser que un servicio dependa de otro, en ese caso hay que tenerlo en cuenta.

Llegados a este punto tenemos una buena base sobre lo que son los runlevels en sistemas *nix, y para ir un poco mas alla, hablaremos sobre como configurar la maquina para que arranque en un determinado runlevel.

El primer proceso que se carga en un sistema *nix despues de la carga del kernel en memoria es el llamado proceso init, contenido en /sbin/init, este proceso (entre otras cosas) lee el archivo /etc/inittab, y de ahi determina en que runlevel arrancar.


Contenido de /etc/inittab

En la imagen vemos un extracto de mi inittab, en él he resaltado en blanco la linea en la que podemos modificar el runlevel de arranque, en mi caso, al tratarse de un sistema Debian el runlevel por defecto es el 2, equivalente al runlevel 5 anteriormente citado (multiusuario con arranque gráfico).
En rojo he resaltado una linea que me ha parecido interesante, y es que esta linea indica al sistema que hará en caso de arrancar en modo monousuario. En este caso indica que se ejecutar sulogin, para autenticar al usuario root, imaginaos lo que se puede hacer en una maquina con la que tengas acceso fisico a ella y una LiveCD... ;) y es que como una vez me dijo alguien... una maquina solo es segura si se encuentra aislada en una habitacion, sin que nadie mas que el administrador tenga acceso.

Por supuesto, el inittab tiene mucha mas chicha, que vosotros mismos podréis descubrir con un man inittab o con el gran Google.

Por ultimo ya, si quereis cambiar el runlevel sobre la marcha...

# telinit -t SEC NUM

Siendo SEC el numero de segundos que se esperara a un proceso antes de matarlo, por defecto es 5 segundos, y NUM, por supuesto, el numero de runlevel al que se desea cambiar. Esto solo lo podrán hacer usuarios con permisos, puesto que claro esta, no podran matar un proceso si no les pertenece... ;)

En fin, espero que hayáis disfrutado leyendo tanto como yo escribiendo, solo ya animaros a que mireis mas a fondo las posibilidades del fichero inittab y posteeis todas vuestras dudas... sin nada mas que decir...

Nos vemos en el proximo post!



lunes, 17 de septiembre de 2007

El sistema de archivos /proc

Muchos serán los que ven en su sistema raíz un montón de carpetas, con nombres un tanto extraños, las cuales no se saben para que se utilizan. Dentro de esta categoría estaría la carpeta /proc. Vamos a ponerle un poco de luz a esta oscura carpeta que muy pocas veces visitamos y que puede sernos de gran utilidad.Todo sistema debería ofrecer un servicio para saber que esta ocurriendo dentro del propio sistema, así como fijar algunos parámetros operacionales. En MS Windows tenemos el registro del sistema que hasta cierto punto cumple con dichas expectativas. Pero en el sistema GNU\Linux tenemos una potente sistema de archivos virtuales que es sistema /proc. Como sabemos en linux todo son archivos y procesos. Todo se guarda en archivos. Los mas comunes son los archivos de texto y los binarios, pero el sistema /proc entra en otro grupo de archivos que se denominan archivos virtuales (mas adelante veremos porque es esto así). Es por eso que decimos que /proc es un sistema de archivos virtuales.

Como sabemos el núcleo de Linux es el elemento clave del sistema, por lo tanto es importante que exista un método para intercambiar información con el. Debido a esto se creo el sistema de fichero /proc, que mejoraba la comunicación entre los usuarios y el núcleo de Linux.
En principio este sistema fue diseñado para permitir un fácil acceso a la información sobre procesos (de aquí viene su nombre), pero ahora es utilizado por cualquier elemento del núcleo que tiene algo interesante que informar.
Dentro de este directorio /proc podemos encontrar una gran cantidad de información, con muchos detalles (mas de los que nos esperaríamos), sobre el hardware del sistema y también sobre casi cualquier proceso que se esté ejecutando actualmente. Por ejemplo en /proc/modules encontraremos la lista de los módulos que tenemos instalados, mientras que en /proc/cpuinfo encontraremos información acerca del micro.
El directorio /proc/ tiene una jerarquía de fácil lectura para porder encontrar fácilmente la información que buscamos. Además, todos los archivos que contienen información referente a temas semejantes están agrupados juntos. Algunos de los archivos interesantes que aparecen dentro de este sistema de archivos son:

  • /proc/meminfo tiene estadísticas de uso de la memoria
  • /proc/cpuinfo contiene información sobre el procesador
  • /proc/sys/net/ipv4 nos muestran información sobre la pila del sistema
  • /proc/interrupts Uso de IRQ de su sistema
  • /proc/iomem Mapa actual de la memoria del sistema para diversos dispositivos.
  • /proc/pci Dispositivos PCI conocidos en el sistema
  • /proc/version Nos muestra la version del núcleo que esta instalado, así como la hora y la fecha en la que compilo
  • /proc/dev/net Info acerca de los dispositivos de red
  • /proc/net/arp Tabla ARP del sistema
  • /proc/sys/net/ipv4 parámetros de la pila TCP/IP
  • /proc/modules Muestra los módulos que tenemos instalados
  • /proc/ide/ información de los dispositivos IDE
  • /proc/scsi/ información de los dispositivos SCSI

Puede que muchos hayáis observado que existen algunos archivos de 0 bytes. Esto es debido a lo que habíamos dicho al principio: el sistema de archivos /proc es virtual, no existe realmente en el disco. Por ejemplo cuando hacemos un cat para leer un archivo en /proc/cpuinfo este es de 0 bytes. El contenido de ese archivo se genera de forma dinámica por medio de un programa que se encuentra en el núcleo y se nos muestra a nosotros por pantalla. Cabe destacar que el sistema de archivos /proc al ser un sistema virtual, los cambios que hagamos a los ajustes predeterminados no sobreviven a los reinicios. Para hacer que los cambios permanezcan al reinicio deberíamos de modificar los scripts de inicio o utilizar una herramienta que haga esto por nosotros, como podría ser sysctl (que ajusta parámetros que están bajo el directorio /proc/sys).
Además de la posibilidad de que el sistema nos de información a nosotros, nosotros también podemos pasarle información al núcleo. Si hemos sido observadores, habremos visto que alguno archivos son de solo lectura, mientras que otros son de lectura/escritura (por ejemplo en /proc/sys/net/ipv4). En este caso podremos modificar algunos de los datos al vuelo. Es bien conocida la modificación del fichero /proc/sys/net/ipv4/ip_forward para que nuestro ordenador haga de enrutador.Por ultimo decir que el sistema /proc (también llamado procfs) se monta generalmente en el sistema raiz (/proc) durante el arranque del equipo. Si vamos al fichero /etc/fstab veremos como en la primera línea se monta el sistema virtual. En caso de que no existiera tal línea habría que agregarla para que el sistema monte de forma automática el sistema cada vez que se inicie el sistema. De todas formas el procfs viene configurado actualmente en la mayoría de los núcleos por omisión. Si no tienes el procfs en su núcleo, al intentar montarlo obtendrá un mensaje como este: mount: "fs type procfs not supported by kernel". Si nos apareciera dicho mensaje habría que recompilar en kernel añadiendo el soporte para el sistema de archivos procfs.

Espero que este pequeño manual os sirva de ayuda.
Un saludo!

viernes, 31 de agosto de 2007

Script definitivo para ipw3945

Si como yo, eres de los pocos tontos que aún no han inyectado con su ipw3945... aquí llega el script de divide el cual espero que se incluya en la proxima versión de WifiSlax y Wifiway.

Si no te funciona esto, ya nada lo hara! XD es sumamente fácil de utilizar y eficaz, aunque inicialmente esta desarrollado para Wifiway yo no estoy teniendo ningún problema con WifiSlax.

Mas información aquí.

martes, 14 de agosto de 2007

WifiSlax 3.0... rizando el rizo


Llega la versión mas depurada de la famosa distro para auditorias wireless y bluetooth, WifiSlax 3.0.

Totalmente en castellano y con las facilidades a las que ya nos tiene acostumbrados, añade las siguientes caracteristicas:

  • Soporte de inyección para chip wireless Zydas
  • Soporte para inyección para las tarjetas wireless centrino ipw3945 (se me saltan las lágrimas ;)) y otros chipset como rt73, etc..
  • Entorno gráfico KDE (no comments)
  • Administradores de inicio grub y lilo
  • aircrack 0.9 con soporte para la tecnica del aircrack-ptw (Crackeo de redes wifi mas rapido)
  • Soporte para graficas Nvidia
  • Kernel 2.6.21
  • Escritura y lectura de particiones Windows ntfs con ntfs-3g
  • Airoscript para facilitar la auditoria wireless
También destacar las aplicaciones de Bluetooth que ya aparecieron en la v2.0, algunas de ellas desarrolladas por el gran Gospel.

A todo esto añadirle el arsenal de herramientas de Backtrack (la distro madre de WifiSlax) y tenemos una potente herramienta de auditoria en forma de LiveCD

DynDNS, tu ip fija (o casi)

Este resumen no está disponible. Haz clic en este enlace para ver la entrada.

martes, 7 de agosto de 2007

Crea una distribución linux a tu medida

Los chicos de euronode nos permite crear, a partir de un sistema debian base, nuestro propio sistema Linux. Entrando en la web y a golpe de ratón nos permiten elegir las opciones que queremos para crear nuestra propia distribución.
Para que queremos un sistema GNU\Linux con todas las opciones que tiene si nuestra maquina es un Pentium166 (este es mi caso ;)) donde no vamos necesitar ni las X ni muchos otros paquetes que trabajan sobre el?
Eso mismo debieron de pensar los autores de este proyecto.

Para crear nuestra propia distro, tendremos que ir a la pagina web de euronode (https://euronode.com/) registrarnos y a partir de ahí ya podemos empezar a construir nuestro sistema. Tendremos un asistente donde podremos configurar las opciones de nuestro server (en caso de que el sistema sea para este uso) .Además elegiremos los paquetes y las aplicaciones que queremos que se incluyan en nuestro cd hasta crear un sistema a nuestra medida. Que no queremos un sistema tenga las X? Pues no incluimos el paquete en nuestro cd. Así de fácil.
La web también proporciona tutoriales que te explica, por ejemplo, como crear un servidor LAMP a tu medida.
El sistema por razones obvias no podrá superar los 700mb (un cd-rom).

Al final de todo el proceso podemos adquirir nuestro sistema por un módico precio. Lo podremos bajar directamente de la web (en formato ISO) para quemarla posteriormente en un cd.

Esta es la dirección: https://euronode.com/

viernes, 3 de agosto de 2007

Instalando SSH en el servidor

Seguimos dándole vidilla al viejo Pentium II de KrAmOx…

Una vez instalado el FTP nos queda algo por hacer. Necesitamos un sistema mediante el cual poder acceder al shell del servidor, para ello, Linux cuenta con diversas propuestas tales como rlogin, telnet… etc.

Todos estos protocolos y aplicaciones tienen un inconveniente en común: La información mandada fluye sin cifrar, lo cual pone en bandeja a cualquier posible atacante con un sniffer y dos dedos de frente meter las narices donde no debe.

Pero no solo el cifrado resulta atractivo en SSH, otro aspecto que lo hace interesante es su capacidad para redirigir el tráfico de las X, pudiendo ejecutar aplicaciones graficas en un cliente aprovechando la potencia de cálculo de un servidor… casi na!

Pero como es de mala educación hablar de alguien sin presentarlo… allá voy:

SSH (Secure SHell) es un protocolo y una aplicación utilizados básicamente para la interconexión de equipos remotos. La primera versión, desarrollada por el finlandés Tatu Ylönen, fue libre en sus anales, así como la aplicación, pero poco a poco fue apareciendo la SSH Communications Security, que ofrecería gratuitamente la aplicación para uso domestico y académico, pero que exigía el pago a otras empresas.

Pero como siempre, dos años después de todo esto ya estaba lista la primera versión libre de SSH, OpenSSH.

Actualmente existes dos versiones estables, SSH1 y SSH2. Se recomienda utilizar la SSH2 por cuestiones de seguridad, ya que la primera versión solo se mantiene por cuestiones de compatibilidad en maquinas antiguas.

Otra característica interesante, sobre todo para los amantes de la criptografía, es la posibilidad de manejar claves RSA para las sesiones con SSH, para, de esta forma, evitar el proceso de login entre maquinas. Para conseguir esto basta con que tengas tu llave publica almacenada en el servidor SSH y tu llave privada en la maquina desde la que te vas a conectar.

Finalmente, también es destacable el uso que se hace de SSH para tunelizar conexiones no seguras, para de este modo, cifrar el contenido de las mismas. Esto se suele realizar con Terminal Server y otras aplicaciones, ya que SSH es un protocolo disponible tanto para Linux como para Windows, de la misma forma que existen clientes y servers para ambas plataformas.

La instalación en sistemas Linux, que es la que nos atañe, es harto sencilla:

apt-get install ssh

y todo esto en el caso de que no venga instalada por defecto, algo nada raro en distribuciones Linux.

Para sistemas Windows podemos encontrar gran variedad de aplicaciones de F-Secure o de la misma SSH Communications Security.

Por supuesto, el funcionamiento, a pesar de la complejidad de la aplicación, es sumamente sencillo. Para conectar con una maquina remota simplemente debemos hacer:

slayer@erhard$ ssh usuario@ip_servidor
Password: ********

Y ya tendremos nuestra sesión en el servidor, aunque solo habremos accedido a shell, si pretendemos ejecutar una aplicación nada mas establecer la conexión podéis probar con:

slayer@erhard$ ssh usuario@ip_servidor mplayer /home/slayer/mp3/*mp3
Password: ********

De esta forma reproduciría todos los emepetreses que tuviera en la carpeta, siempre y cuando el mplayer estuviera instalado en el servidor claro, recordad que la aplicación se ejecuta en la maquina remota, aunque la salida se recogida por el cliente.

Mediante el parámetro –t conseguiremos abrir aplicaciones de forma interactiva, por ejemplo:

slayer@erhard$ ssh –t usuario@ip_servidor ‘nano /tmp/algo’
Password: ********

….sesión con nano

slayer@erhard$ ssh usuario@ip_servidor ’cat /tmp/algo’

…veremos lo que hemos escrito.

Interesante no? Pues no acaba la cosa ahí, también podemos redirigir igualmente el tráfico X mediante el parámetro –X (obvio no?) pero para ello debemos configurar antes el archivo /etc/ssh/sshd_config concretamente la línea:

X11Forwarding yes

Además el cliente debe de tener instalado xauth y ser accesible, pero eso ya es otra historia…

Otra herramienta incluida en SSH es scp, o lo que es lo mismo Secure CoPy.

Mediante esta pequeña aplicación podemos realizar copias de archivos de forma remota y segura. Ejemplo:

scp ArchivoOrigen usuario@host:directorio/ArchivoDestino
scp usuario@host:directorio/ArchivoOrigen ArchivoDestino

Por ultimo en este post (pienso seguir hablando de SSH como mínimo un post más) hablaremos de la generación de claves para evitar ir tecleando passwords cada dos por tres:

slayer@erhard$ ssh-keygen -t slayer

Con esto generamos una clave publica y privada para el user slayer guardadas en

~/.ssh/id_slayer.pub y en ~/.ssh/id_slayer respectivamente

La próxima vez que nos logueemos en la maquina remota simplemente deberemos ejecutar:

ssh-add ~/.ssh/id_slayer


Y ya no tendremos que loguearnos nunca mas… ;)

En fin, no os durmáis que seguiremos hablando del tema…

Salu2!

Montando un servidor FTP en linux

Después de la primera entrega "Resucitando a mi pentium" (http://imstrangeandilikeit.blogspot.com/2007/07/resucitando-mi-pentium.html), donde nos enseñaba como darle cierta usabilidad a un ordenador viejo, en esta segunda entrega vamos a instalar un servicio en nuestra máquina, más concretamente instalaremos un servidor FTP en nuestro sistema linux.

El servidor FTP escogido es el proftpd, aunque bien hubiera podido ser vsftpd, wu-ftpd o cualquiera que exista para el sistema GNU\linux.

He elegido este servidor por ser un servidor seguro y fácil de utilizar. He aquí algunas de las características más reseñables de este demonio: es altamente configurable, soporta servidores virtuales de ftp, puede tener múltiples servidores brindando servicio de ftp anónimo, es modular (lo que permite extender su funcionalidad ampliamente), un usuario con acceso por ftp únicamente no requiere de una configuración especial, y su código es libre (esta licenciado bajo GPL).

Lo primero que tenemos que hacer es descagar el software con la "magnifica" instrucción "apt-get install proftpd". Una vez bajado e instalado el software se nos preguntará si queremos configurarlo como parte de inetd o stadalone. Instalarlo como parte de inted implica que el servidor FTP se ejecutara junto con un conjunto de procesos de red (telnet,tftp, IMAP...), siendo el inetd el supervisor de todos ellos (me comprometo a escribir un articulo aclarando que eso del inetd :)). Si lo instalamos como standalone lo instalamos como un proceso normal independiente a inetd. Yo personalmente probe la opción de instalarlo como parte de inetd y no me funcionó (una mala configuración por mi parte?, puede ser ;)). Así que os recomiendo que lo instales como standalone. Una vez instalado tenemos un bonito archivo de configuración en /etc/proftpd/proftpd.conf
Dentro de este archivo de configuración las opciones mas destacables son:
  • "ServerName" nombre del servidor que aparecerá cuando alguien se conecte
  • "ServerType" aquí podemos escoger entre inetd o standalone como hemos dicho mas arriba
  • "ShowSymlinks" mostrar enlaces simbólicos
  • "Port" puerto donde se realizará la conexión
  • "PassivePorts" define el rango para las conexiones pasivas con el servidor
  • "MaxInstances" Numero máximo de peticiones que el servidor atenderá. Dependiendo de la potencia del ordenador debería de ponerse un valor u otro.
  • "Umask" máscara para la creación de ficheros
  • "AllowOverwrite" permite la sobrescritura de ficheros
  • "User" y "Group" permisos sobre los que se ejecutara el servidor ftp. Dadle pocos permisos por si alguna vez sufris un ataque, que se ejecute una shell con permisos muy bajos
  • Podemos declarar directorios con sus respectivas opciones al estilo apache con la sintaxis
  • "MaxInstances" define el numero máximo de usuarios que pueden acceder al servidor.
  • "TransferLog" y "SistemLog" realiza los registros tanto de las transacciones como de las autentificaciones
  • Permite la entrada de usuarios antónimos.
  • podemos definir que usuarios podrán acceder al sistema y cuales no.
  • "DefaultRoot" definimos el directorio chroot
  • Y muchas opciones mas http://www.proftpd.org/docs/directives/linked/by-name.html
Estas son solo algunas opciones que yo he utilizado pero hay muchas más. Para verlas solo hay que entrar en la pagina del proyecto (http://www.proftpd.org/) y buscar la documentación asociada.

Recordad que para que surtan efecto los cambios debemos reiniciar el demonio con la siguiente orden:
/etc/init.d/proftpd restart

Otro tema a recalcar es el acceso a las carpetas y archivos. Estos siguen la política de permisos de GNU\Linux, es decir el sistema determina si un usuario o grupo tiene acceso o no a los archivos mediante la tripleta, ya conocida, -rwxrwxrwx. De esta manera se puede negar o permitir el acceso al usuario a cualquier recurso del sistema. El servidor FTP no utiliza un sistema adicional para gestionar los permisos y accesos.

Por último, decir que además de todo esto que hemos estado viendo, proftp tiene muchísimas cosas más como servidores virtuales (que yo personalmente todavía no he tocado).

En esta segunda entrega hemos instalado y configurado un potente servidor FTP. En la próxima entrega conectaremos este servidor la red exterior (Internet) mediante servicios gratuitos como DynDNS que nos facilitan la administración del dominio (vía web) y permiten asociar nuestra ip dicho domino. De esta forma tendréis vuestro servidor conectado a internet y accesible desde cualquier punto mediante un subdominio de la forma (dominio.dyndns.org).

Hasta la próxima entrega :)
Nos os olvidéis de visitar la pagina web del proyecto: http://www.proftpd.org/

sábado, 28 de julio de 2007

Las X y ese mundo tan confuso

Esta pequeña guia es una recopilación tanto de mis conocimientos, como de la magnifica información que he encontrado en algunos lugares de la red.
Intentaré tener una nomenclatura clara y llamar a las cosas por su nombre, para intentar que se queden los conceptos claros y no halla lugar a duda alguna, ni ha ambigüedades.

Mucha gente, entre la que yo me encluyo hasta hace poco, se pregutanban que eran eso de las X (o si tenian una pequeña concepcion, habian muchos cabos sueltos sin resolver y un tremendo lio de conceptos) que utiliza linux y los distintos tipos gestor de ventanas.
El problema de este tremendo lio es debido a que desde la aparicion del sistema operativo Ms-Windows, estamos acostumbrados a enchufar el ordenador y ver ya las llamativas ventanitas (lo que se le denomina el entorno de escritorio) que por defecto las distintas versiones de windows lo incluyen como parte de sus sistema. Pero en el mundo de GNU/Linux todo eso cambia ya que el sistema de ventanas no entrar como parte integral de su sistema y entran en juego conceptos como "el servidor de las X" y entornos de escritorio. Pues bien, vamos a ir poco a poco viendo que significa cada cosa.

En los sistemas GNU/Linux la infraestructura GUI no se incluye en el kernel (a diferencia de Windows) sino que es un programa a parte con el nombre “El Sistema de Ventanas X”, es lo que vulgarmente se le conoce como "las X". Aquí empeiza la primera diferencia clara entre los sistemas GNU/Linux y Windows, una cosa son las X (como podrian ser por ejemplo XFree o Xorg) y otra es el GUI (fluxbox,kwin o metacity) y entorno de escritorio (como podrian ser KDE o gnome).Las X es la infraestructura que un GUI utiliza para hacer su trabajo. Por ejemplo, un GUI maneja los botones, las listas desplegables, ventanas, etc., mientras que X maneja el dibujo a bajo nivel de las fuentes, líneas e imágenes en la pantalla y lee las entradas por teclado y ratón así como la comunicación entre programas de éstos. También puede manejar la distribución de la red de usuarios y sesiones remotas. Vamos a ir entrando en detalle y afinando poco a poco.

Qué es realmente el sistema de ventanas X? Segun la definicion de la wiquipedia: "El sistema de ventanas X fue desarrollado para dotar de una interfaz gráfica a los sistemas Unix. Este protocolo permite la interacción gráfica en red entre un usuario y una o más computadoras haciendo transparente la red para éste.
X es el encargado de mostrar la información gráfica y es totalmente independiente del sistema operativo. El sistema de ventanas X distribuye el procesamiento de aplicaciones especificando enlaces cliente-servidor. El servidor provee servicios para acceder a la pantalla, teclado y ratón, mientras que los clientes son las aplicaciones que utilizan estos recursos para interacción con el usuario. De este modo mientras el servidor se ejecuta de manera local, las aplicaciones pueden ejecutarse remotamente desde otras máquinas, proporcionando así el concepto de transparencia de red."
Como todo en el mundo de GNU\Linux existen diversas implementaciones del sistema X Windows System. Por un lado tenemos XFree (que va por la version 4.6) que hasta la fecha habia sido la mas popular y la que se instalaba en casi todos los sistemas. Pero en Febrero de 2004,un cambio de licencia producido a partir de la versión 4.4.0 (anteriormente se distribuía bajo la licencia MIT) provocó la creación de la bifurcación X.Org, apoyada por empresas y desarrolladores descontentos con presuntas incompatibilidades con la popular licencia GPL (esto ha provocado una caída en la popularidad de XFree86, siendo reemplazado por X.Org en algunas distribuciones de GNU/Linux, como debian por ejemplo y en algunos sistemas BSD). Con lo que ahora tenemos dos versiones de sistema X windows: XFree y Xorg.

Hablando del sistema de ventanas x entra en juego un nuevo concepto, el de cliente/servidor. En referencia al sistema de ventanas X (ya que el concepto de cliente y servidor se extiende en muchos campos) el servdidor X es la pantalla, el teclado y el raton mientras que el cliente X es un programa que abre y usa sus ventanas, como por ejemplo un editor de texto, navegador, o en general qualquier tipo de aplicacion que estamos acostumbrados a utilizar en modo grafico.
Un servidor X es una máquina en una red donde existe un programa de “hacer ventanas” y otras máquinas, o clientes X, se conectan a ella para crear ventanas, escribir o mostrar texto, imágenes o lo que sea, en la ventana y puede leer cualquier entrada que el usuario haga sobre esa ventana. Los clientes X a menudo corren en la misma máquina, pero a veces no. Lo que un servidor X sirve es ventanas y tu entrada.
Un ejemplo claro para ver que es el sistema de ventanas X, es cuando instalas un sistema base (por ejemplo una debian) y luego decides instalar el servidor X (apt-get install x-window-system). Si ejecutas "startx" desde la linia de comando veras como arranca el servidor X que tengas instalado. Te aparecera una pantalla negra con una consola. Veras que puedes escribir en el terminal y mover el raton (recordemos que las funcionalidades del servidor X son basicamente servicios para acceder a la pantalla, teclado y ratón), pero el aspecto es bastante pobre y con poca funcionalidad.
Ahora lo que nos falta es un entorno agradable y util, para poder explotar al máximo nuestras maquinas. Es lo que se conoce por entorno de escritorio, y son los archiconocido gnome y kde (sin olvidarme de otros como xfce). Segun la deficion de la wiquipedia entendemos por entorno de escritorio: "Un entorno de escritorio (en inglés, Desktop Environment) es un conjunto de software para ofrecer al usuario de un ordenador un ambiente amigable y cómodo. El software es una solución completa de interfaz gráfica de usuario o GUI, ofrece iconos, barras de herramientas, programas e integración entre aplicaciones con habilidades como, arrastrar y soltar (drag&drop)."
No se si os habreis fijado en un pequeño detalle en la frase:"El software es una solución completa de interfaz gráfica de usuario o GUI". Y que es eso de la GUI? La GUI o interfaz grafica de usuario "es el artefacto tecnológico de un sistema interactivo que posibilita, a través del uso y la representación del lenguaje visual, una interacción amigable con un sistema informático." Es decir que en realidad lo que sucede es que un cliente X, llamado gestor de ventanas, se conecta al servidor y nos permite manipular ventanas (interactuando de la manera a la que estamos acostumbrados). Estos gestores de ventanas, como kwin (gestor de ventanas de kde) o fluxbox o metacity (gestor de gnome) son, como vemos, la base de los entornos de escritorios. Así nos lo confirma su definicion: "Un gestor de ventanas o en inglés window manager, es un programa que controla la ubicación y apariencia de las aplicaciones bajo el sistema X Window."
Por lo visto ya tenemos el puzle montando: tenemos un servidor X que sirve ventanas, a un cliente X llamado gestor de ventanas que este a su vez es la base del entorno de escritorio que es al final lo que vemos nostros.
Ademas como sabemos, GNU\Linux en vez de forzarte a usar un determinado gestor de ventanas como en Windows, puedes elegir entre los muchos disponibles para los sistemas X.

viernes, 20 de julio de 2007

CHROOT: enjaulando aplicaciones

Hola gente!

Llevaba un tiempo sin actualizar y os quiero compensar con algo que me parece de bastante interés. La mayoría ya lo conoceréis (no es ningún secreto), pero puede que no lo hayáis puesto en practica nunca, y la verdad es que es algo bastante útil sobre todo hablando de temas de seguridad.
Como bien podéis leer en el titulo el tema de hoy es chroot. Como dicen sus siglas (CHange ROOT) el proceso es "simple", solo consiste en cambiar la raiz del sistema de ficheros teniendo así dos raíces.

Me explico: es como tener en el mismo sistema operativo dos / en una de las cuales (normalmente) instalaremos algun servicio como Apache o alguna distribución testing como Sid para no comprometer el sistema estable.

Y diréis: y lo de enjaular? a que viene?

Muy simple desde el nuevo sistema de ficheros creado no podremos acceder a nada que este fuera de el. Por tanto, si creamos un nuevo / y en ese mismo sistema instalamos Apache, tendremos un shadow con solo el password del usuario de Apache, los logs accesibles seran solo los de Apache y, ojo al dato, los ejecutables disponibles en /bin serán solo los necesarios para que funcione Apache.

Que significa esto?
Significa que aunque un atacante consiguiera acceder al sistema de ficheros del servidor Apache, solo podría acceder a los ejecutables y a los ficheros contenidos en ese sistema de ficheros, lo cual es mas bien poco, y al mismo tiempo tendría vetado el acceso al sistema de ficheros raiz orignal que contiene toda la "chicha"... en resumen: estaría enjaulado.

El único inconveniente respecto a esto es conseguir que todo funcione correctamente a la primera, ya que según la aplicación que vayas a chrootear, tendrás que conocer al dedillo los ficheros que necesita para funcionar y sus ubicaciones, redirigir el syslogd para que guarde los logs en el lugar adecuado... etc. Aunque con la practica seguro que seréis capaces de generar vuestros propios scripts para automatizar la tarea.

Por supuesto podéis enjaular cualquier tipo de aplicación, especialmente las que tengan toma de contacto con el exterior (por eso el ejemplo de Apache), para asi proteger vuestro servidor de intrusos indeseados.

Por mi parte nada mas, solo deciros que busquéis mas información sobre esto en la red, encontrareis abundante información, y si sois lectores de @rroba, hace algunos números Yorkshire publico un articulo sobre jaulas chroot en Apache (o fue okahei? esta memoria me va a matar ;) ....)

Salu2!

martes, 17 de julio de 2007

Damn Vulnerable linux una distro para .... el aprendizaje de la seguridad!


Si si lo dicho. Damn vulnerable es una distribución (en formato live-cd) basada en Dam Small Linux que utiliza el kernel 2.4 (que lo hace mas vulnerable que el kernel 2.6) donde se incluye multitud de elementos vulnerables. Esto no significa que esta distro no se tiene que instalar, sino todo lo contrario, es una magnífica plataforma para el aprendizaje de técnicas de seguridad. Incluye versiones viejas los servicios mas conocidos (apache, ftp...) así como bastantes herramientas para trabajar con estos servicios y explotar sus vulnerabilidades (IT-security tools). Los servidores antes mencionados están perfectamente instalados y listos para usar y explotar. Además tiene varios tutoriales, exploits, y un conjunto de retos con diferentes niveles de dificultad que deberemos superar (una opción muy interesante para saber realmente hasta donde llega nuestro potencial :)). Toda esta información proporcionada nos permitirá que nosotros mismos vallamos aprendiendo técnicas de seguridad (aunque la información esta en ingles). También decir que si eres un novato en linux vale la pena no instalar este sistema, ya que se requieren unos conocimientos mínimos sobre las distintas ordenes y comandos.
Mas información en:
http://damnvulnerablelinux.org/

A disfrutar! y aprender!

miércoles, 11 de julio de 2007

Knoppix 5.1.1 + Beryl es la solucion!


Muchos han sido los que han pasado agonías instalando Beryl en su ordenador. Pues una solución rápida y elegante ya esta aquí!

La nueva distribución de Knoppix 5.1.1 incorpora Beryl. Tan solo hay que arrancar el live-cd y cuando nos sale el boot poner: knoppix desktop=beryl.

Por desgracia mi tarjeta todavía no es compatible, así que aun no la he podido probar.

Una pequeña anotacion del moderador: una vez comprobado (y puesto el dedo en la llaga como Santo Tomas) que vuestro ordenador funciona con beryl (ohhhhhhhhh), dejaros de live-cd e instalaros una distro (yo recomiendo debian) e instalad beryl por vosotros mismos. Así es como verdaderamente se aprende! :)

PD: creo que en la ultima distribución de ubuntu ya se puede instalar beryl desde la instalación.