Si has instalado la versión de Ubuntu con idioma inglés de Estados Unidos, seguro que el día inicial de la semana es el Domingo, en vez del Lunes, en el applet de calendario. No existe ninguna opción desde donde esto se pueda modificar fácilmente, y hay muchos usuarios (como yo) que están acostumbrados a ver el calendario empezando en Lunes. Esta pequeña guía muestra cómo cambiarlo paso a paso.
Guarda los cambios y sal del editor. Con esas opciones, Ubuntu mostrará el formato de fecha en la variante europea del inglés, establecerá el tamaño del papel por defecto en A4 y las medidas en formato métrico.
Para poder disfrutar de la nueva configuración hay que reiniciar el gestor gráfico. Para hacerlo escribe:
Ten cuidado! Al ejecutar el último comando, se reiniciará el demonio gdm, y cerrará todas las aplicaciones. Así que asegúrate de haber guardado tus documentos abiertos antes de hacerlo
If you have installed the United States language version of Ubuntu, for sure you have your start week day set to Sunday, instead of Monday, at your calendar applet. There isn’t an option where the user can change this in an user-friendly way, and there are a lot of non-US users (like me) who are used to see the week starting by Monday. This little HOW-TO will show you the way to change it step by step.
Save the file and exit the editor. With these options, Ubuntu will display the time format in the english european variant, set the default paper size to A4 and set metrics for use with measurements.
In order to start using the new configuration you should restart your graphic desktop manager. Just type this:
Take care! Executing the last command will restart your gdm, and will close all running applications. So please, be sure to save your work before doing this.
Hace ya algunos días que estoy usando Ubuntu 11.04, aunque es una versión beta, funciona muy bien… sólo hay dos cosas que me han hecho perder algo de tiempo mirando por internet cómo solucionarlo. Una de ellas, es un pequeño warning muy molesto que aparece cada vez que lanzo una aplicación gráfica desde el terminal. El error es el siguiente:
pedro@pedro-laptop:~$ ./cualquier-aplicacion
(process:10945): Gtk-WARNING **: Locale not supported by C library.
Using the fallback ‘C’ locale.
Esto me ha pasado por haber instalado el sistema operativo en inglés en_US, utilizando un teclado en español es_ES. Así que me puse a investigar cómo solucionarlo y siguiendo los siguientes pasos, he conseguido resolverlo:
Lo primero de todo, abrimos un terminal, nos hacemos root y vamos al directorio /var/lib/locales/supported.d/.
pedro@pedro-laptop:~$ sudo su
root@pedro-laptop:/home/pedro# cd /var/lib/locales/supported.d/
root@pedro-laptop:/var/lib/locales/supported.d# ls -lah
drwxr−xr−x 2 root root 4,0K 2011-04-25 20:00 .
drwxr−xr−x 3 root root 4,0K 2011-04-13 12:48 ..
−rw−r−−r−− 1 root root 270 2011-04-10 15:16 en
−rw−r−−r−− 1 root root 36 2011-04-25 20:09 local
Allí, en mi caso, existe un archivo llamado en y otro llamado local. Vamos a añadir manualmente el locale es_ES en un archivo llamado es, de la siguiente manera:
root@pedro-laptop:/var/lib/locales/supported.d# echo ‘es_ES.UTF-8 UTF-8’ > es
Comprobamos que se ha añadido bien haciendo un cat:
root@pedro-laptop:/var/lib/locales/supported.d# cat es
es_ES.UTF-8 UTF-8
Ahora añadiremos al locale es_ES en el fichero de locales por defecto. Para ello sólo tenemos que editar el archivo local y poner en la primera línea el locale que nos interesa, de modo que en mi caso queda de la siguiente manera:
root@pedro-laptop:/var/lib/locales/supported.d$ cat local es_ES.UTF-8 UTF-8
en_US.UTF-8 UTF-8
Y ya está, ahora solo tenemos que reconfigurar el paquete de locales, para que lo reconozca:
La fragmentación IP es una técnica utilizada para dividir los datagramas IP en fragmentos de menor tamaño. Ésto es necesario ya que cuando los datagramas IP viajan de un lugar a otro, éstos pueden atravesar diferentes tipos de redes y el tamaño máximo -llamado MTU– de estos paquetes puede variar dependiendo del medio físico utilizado para la transmisión.
El valor máximo que técnicamente puede utilizarse para un datagrama IP es de 65536 bytes, aunque en la práctica se utilizan otros tamaños mucho más pequeños:
Veamos cómo funciona esta técnica con más detalle. La cabecera IP, que suele tener un tamaño de 20 bytes, contendrá la siguiente información:
Identificador de fragmento. Cada Fragmento debe asociarse con un único identificador para que el reensamblaje en destino pueda realizarse correctamente.
Información sobre la posición en el paquete final.
Información sobre el tamaño de los datos que se transportan en el fragmento.
Cada fragmento debe contener el bit MF (More Fragments) para saber si el fragmento actual es el último o no.
Así que la figura de un paquete de máximo tamaño que no necesite fragmentación en una red típica Ethernet sería algo así:
Paquete de 1500 bytes
Si sumamos la cabecera y los datos encapsulados, tenemos que en total hacen 1500 bytes, por lo que al viajar por una red Ethernet, no sería necesaria su fragmentación.
Los datos encapsulados pueden ser tanto un protocolo IP como TCP, UDP o ICMP. Veamos un ejemplo en el que se tenga que utilizar la fragmentación. Este es un ejemplo anormalmente grande, pero en el que podremos ver cómo se realiza el proceso de fragmentación. Se trata de una petición echo que pasa por una red Ethernet con MTU de 1500 bytes.
Proceso de fragmentación de un paquete de 4028 bytes
En el paquete original, la suma de las cabeceras y los datos ICMP suman 4028 bytes. Este paquete al ser transmitido en una red Ethernet deberá ser fragmentado, generandose así 3 paquetes de 1500 bytes o menos. Cada fragmento llevará obligatoriamente al menos la cabecera IP (necesaria para saber hacia dónde se dirige el fragmento), que en este caso ocupa 20 bytes, así que tendremos realmente 1480 bytes útiles.
El primer fragmento contendrá la Cabecera IP + la cabecera ICMP + la información restante para llegar a 1500 bytes, en este caso 1472 bytes. Puesto que es el primer fragmento, el valor de Offset valdrá 0 y el bit MF valdrá 1 ya que hay más paquetes.
El segundo fragmento contendrá la Cabecera IP + la información restante para llegar a 1500 bytes, en este caso 1480. Ahora el valor de Offset valdrá 1480, ya que es la posición que debe ocupar al ensamblar el fragmento (recordemos que el primer fragmento tenía 8+1472 = 1480). El bit MF valdrá 1 ya que no es el último paquete.
El tercer fragmento contendrá la Cabecera IP + la información restante, en este caso 1048 bytes (ya no hay más bytes). El valor de Offset valdrá 2960, ya que el primer y segundo fragmento ocupaban 1480 cada uno. El bit MF se establece a 0 porque es el último fragmento del paquete.
El campo Protocol sólo indica a qué tipo de protocolo corresponde el paquete original. ID fragmento indica un identificador que será igual para todos los fragmentos del paquete original, así se podrá reconstruir en destino sin confusión. El bit MF (more fragments) se establecerá a 1 siempre, excepto para el último paquete, que será 0. El Offset nos indica la posición que ocupa cada fragmento dentro del paquete original. El campo Tamaño, simplemente registra el tamaño del fragmento actual sin contar la Cabecera IP.
Una vez conocemos a grosso modo cómo funciona esto de la fragmentación, explicaré por encima, cómo un usuario malintencionado puede utilizar este procedimiento para realizar un ataque.
El ataque más conocido que explota la fragmentación IP se llama Teardrop. Este ataque usará información falseada en los fragmentos para poder confundir el reensamblaje en destino y colapsar así el sistema.
Imaginemos que tenemos un MTU de 512 bytes y un paquete que necesita ser dividido en N fragmentos y utilizamos los campos Tamaño y Offset de la siguiente manera:
Offset
Tamaño
Fragmento 1
0
512
Fragmento 2
500
512
…
…
…
Fragmento N
10
100
Al reconstruir el paquete en destino se producirá un error de desbordamiento de buffer (buffer overrun), ya que el fragmento N apunta a un lugar en el que ya se había escrito previamente y obliga a sobreescribirse.
Otro ataque interesante es enviar cientos o miles de fragmentos manipulados con diferentes ID de fragmento contra la máquina que se desea atacar, de manera que agotemos los recursos de reensamblaje del equipo atacado; acabaremos colmando la pila en la que reconstruye estos paquetes, y no aceptará ninguno más, generando así un ataque de Denegación de Servicio (DoS).
Afortunadamente, a dia de hoy, este tipo de ataques no suelen ser efectivos. Los sistemas operativos vulnerables son Windows 3.1x, Windows 95, Windows NT y las versiones inferiores a Linux 2.0.32, así como la 2.1.63.
La herramienta hping es un analizador/ensamblador de paquetes TCP/IP de uso en modo consola. Está inspirado en el comando ping de unix, aunque a diferencia de éste, hping no solo es capaz de enviar paquetes ICMP sino que además también puede enviar paquetes TCP, UDP, y RAW-IP.
Todo esto quiere decir, que con esta herramienta, podemos generar paquetes TCP/IP a medida, que contengan la información que queramos. Esto puede resultar muy interesante para poder efectuar auditorías de red y poder así prevenir ataques malintencionados.
Descarga e instalación
La instalación de esta herramienta, al menos en Ubuntu, es realmente sencilla, como la mayoría de aplicaciones. Tan sólo hay que abrir una consola y escribir como root:
root@laptop:/home/root# apt-get install hping3
Para más información puedes consultar la web oficial aquí.
Diferentes usos y su sintaxis
El uso más sencillo que podemos darle es como sustituto de la herramienta ping, aunque veremos que la información que nos aporta es algo diferente. Vamos a comparar ambas herramientas:
root@laptop:/home/root# ping localhost
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.016 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.017 ms
64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.023 ms
^C
— localhost ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 2997ms
rtt min/avg/max/mdev = 0.016/0.019/0.023/0.002 ms
root@laptop:/home/root# hping3 localhost
HPING localhost (lo 127.0.0.1): NO FLAGS are set, 40 headers + 0 data bytes
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=0 win=0 rtt=0.1 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=1 win=0 rtt=0.1 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=2 win=0 rtt=0.0 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=0 flags=RA seq=3 win=0 rtt=0.0 ms
^C
— localhost hping statistic —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.1 ms
En ambos casos, la información que nos proporciona es muy similar, salvo algún pequeño matiz como el campo de flags, que a continuación veremos de qué se trata.
También podemos utilizarlo como scanner de puertos, utilizando el método idle scan (por cierto, método ideado por Salvatore Sanfilipo, el mismo creador de hping), la sintaxis es la siguiente:
root@laptop:/home/root# hping3 -S localhost -p 9091
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=9091 flags=SA seq=0 win=32792 rtt=0.1 ms
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=9091 flags=SA seq=1 win=32792 rtt=0.1 ms
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=9091 flags=SA seq=2 win=32792 rtt=0.1 ms
len=44 ip=127.0.0.1 ttl=64 DF id=0 sport=9091 flags=SA seq=3 win=32792 rtt=0.0 ms
^C
— localhost hping statistic —
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.1/0.1 ms
Si nos fijamos en el valor del flag, veremos que pone SA, que quiere decir SYN/ACK, que a grosso modo es el mensaje que un servidor responde cuando tiene un puerto abierto (en mi caso tengo un pequeño servidor web en el puerto 9091). Si hubiera estado cerrado, nos habría respondido con el flag RA, que quiere decir RST/ACK, o lo que es lo mismo, que tiene el puerto cerrado; veámoslo utilizando otro puerto distinto:
root@laptop:/home/root# hping3 -S localhost -p 9092
HPING localhost (lo 127.0.0.1): S set, 40 headers + 0 data bytes
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=9092 flags=RA seq=0 win=0 rtt=0.0 ms
len=40 ip=127.0.0.1 ttl=64 DF id=0 sport=9092 flags=RA seq=1 win=0 rtt=0.1 ms
^C
— localhost hping statistic —
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.0/0.0/0.1 ms
En este caso nos responde con un RST/ACK, lo que nos indica que el puerto 9092 está cerrado.
Otro uso que podemos darle es como herramienta traceroute, aunque para este uso, prefiero tcptraceroute, veamos cómo hacerlo con hping:
root@laptop:/home/root# hping3 pedrocarrasco.org -t 1 −−traceroute
HPING pedrocarrasco.org (wlan0 174.132.157.133): NO FLAGS are set, 40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=10.109.8.1 name=UNKNOWN
hop=1 hoprtt=0.9 ms
El campo ip=10.109.8.1, hace referencia a la IP del primer salto que realiza para llegar al dominio especificado. Ésto lo hemos especificado poniendo -t 1 (también podemos utilizar el comando -z en vez de -t, e incrementar el TTL cuanto queramos de uno en uno presionando Ctrl+Z).
Además podemos «firmar» los paquetes que enviemos, con el contenido que queramos. Aunque este ejemplo es inocuo, utilizándolo (in)debidamente podríamos causar diversas alteraciones en la máquina destino. Veámos el ejemplo:
root@laptop:/home/root# cat firma.txt
esto es solo un ejemplo
root@laptop:/home/root# hping3 -2 -p 7 localhost -d 50 -E firma.txt
HPING localhost (lo 127.0.0.1): udp mode set, 28 headers + 50 data bytes
[main] memlockall(): Success
Warning: can’t disable memory paging!
ICMP Port Unreachable from ip=127.0.0.1 name=localhost
status=0 port=1963 seq=0
Estableciendo la opción -2 enviamos paquetes UDP, con la opción -d 50 indicamos la longitud del mensaje y con la opción -E indicamos que lea del archivo firma.txt. Podemos ver lo que hemos enviado si capturamos con cualquier sniffer (yo he usado wireshark) el tráfico de la red.
Firmar paquetes con hping
Otra interesante habilidad de hping es poder enviar archivos a través de la red. Para esto, necesitamos una máquina que envíe algún archivo, y otra que esté a la escucha para recibirlo. Primero, preparamos la máquina que permanecerá a la escucha, para ello utilizaremos el parámetro −−listen en el que especificaremos el texto que nos servirá de indicador de inicio de mensaje (en este caso utilizo signature), el protocolo que usaremos es ICMP y lo establecemos utilizando el parámetro −−icmp (también puede usarse UDP o TCP). Al ejecutarlo veremos algo así:
Ahora toca preparar por otro lado el comando que nos servirá para enviar el fichero que queramos.
root@laptop:/home/root# hping3 localhost −−icmp -d 50 −−sign signature −−file firma.txt
HPING localhost (lo 127.0.0.1): icmp mode set, 28 headers + 50 data bytes
[main] memlockall(): Success
Warning: can’t disable memory paging!
len=78 ip=127.0.0.1 ttl=64 id=5268 icmp_seq=0 rtt=0.1 ms
len=78 ip=127.0.0.1 ttl=64 id=5287 icmp_seq=1 rtt=0.1 ms
len=78 ip=127.0.0.1 ttl=64 id=5289 icmp_seq=2 rtt=0.1 ms
len=78 ip=127.0.0.1 ttl=64 id=5291 icmp_seq=3 rtt=0.1 ms
len=78 ip=127.0.0.1 ttl=64 id=5293 icmp_seq=4 rtt=0.1 ms
len=78 ip=127.0.0.1 ttl=64 id=5295 icmp_seq=5 rtt=0.1 ms
len=78 ip=127.0.0.1 ttl=64 id=5297 icmp_seq=6 rtt=0.1 ms
El resultado es que en el lado en que estábamos esperando recibir algo, empieza a verse lo siguiente:
root@laptop:/home/root# hping3 localhost −−listen signature −−safe −−icmp
Warning: Unable to guess the output interface
hping3 listen mode
[main] memlockall(): Success
Warning: can’t disable memory paging! esto es solo un ejemplo
esto es solo un ejemplo
esto es solo un ejemplo
esto es solo un ejemplo
esto es solo un ejemplo
esto es solo un ejemplo
Conociendo este último uso, y con un poco de imaginación podremos utilizar hping como si de un troyano se tratase. Aunque mas que para ser usado como troyano, esta herramienta es perfecta para realizar ataques de DoS, spoof o flood. Acabaremos el artículo viendo un sencillo ejemplo de ataque flooding:
root@laptop:/home/root# hping3 −−rand-source −−flood localhost
HPING localhost (lo 127.0.0.1): NO FLAGS are set, 40 headers + 0 data bytes
hping in flood mode, no replies will be shown
^C
— localhost hping statistic — 189742 packets transmitted, 0 packets received, 100% packet loss
round-trip min/avg/max = 0.0/0.0/0.0 ms
Podemos ver que en tan solo unos segundos, hemos inundado la red con casi doscientos mil paquetes transmitidos de forma ininterrumpida. Esto puede (suele) causar que la red se colapse, impidiendo a otros usuarios poder utilizarla, ya que hping no deja espacio (entre paquete y paquete) para que otras máquinas transmitan ningún tipo de información. El parámetro −−rand-source hace que cada paquete tenga un origen distinto y aleatorio, y −−flood no deja espacio entre paquete y paquete. Si tenemos wireshark a la escucha, podemos ver cual es el resultado:
hping-flood
Ahora os toca practicar con hping para aprender más sobre el protocolo TCP/IP y sus debilidades. No creo que haga falta decirlo, pero por si acaso aviso de que el uso malintencionado de esta herramienta puede ser ilegal, así que utilizad esta información de un modo educativo o para auditar vuestra propia red.
