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

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

El gigante con pies de barro

Segun informan desde Hispasec, se ha detectado una nueva y importante vulnerabilidad en el protocolo IP. Es la tercer gran fallo que se descubre año sobre el diseño de internet y alguien deberia ya tomar cartas en el asunto antes de que las consecuencias puedan ser peores.
Aquí dejo la noticia, tal cual esta en la web de hispasec.

02/10/2008 Supuesta vulnerabilidad en el protocolo IP pone (de nuevo) en riesgo a toda la Red

Una empresa finlandesa llamada Outpost 24 dice haber descubierto un fallo en el Internet Protocol (IP) que puede provocar una denegación de servicio en todo dispositivo que lo use. Teniendo en cuenta que es la base sobre la que se sustenta toda Internet, es equivalente a decir que se puede provocar la caída de cualquier aparato con comunicación en la Red. Es la tercera "gran alerta" del año. ¿Necesita Internet una puesta a punto?
En realidad ni siquiera se podría llamar "denegación de servicio" tal y como lo conocemos hoy en día. Más bien se trataría de una especie de (mítico) "ping de la muerte" en el que, con muy poco tráfico (10 paquetes por segundo) se podría llegar a colapsar cualquier dispositivo que implemente la especificación del protocolo base. Al parecer se trataría de uno de los mayores problemas detectados en la Red que la volvería insostenible de forma relativamente sencilla.
No se han ofrecido por tanto muchos más detalles. Parece que el problema surgió durante el escaneo de varios millones de sitios en Internet. Alguno de estos tests (realizados con la herramienta Unicornscan) hacía que los sistemas dejaran de responder, y tras una investigación se concluyó que existía un problema en todas las implementaciones de la pila TCP/IP. Aunque afecta de distinta manera, se supone que todas son vulnerables y que todavía no han encontrado ningún dispositivo que no puedan bloquear.
Los investigadores han conocido este problema desde 2005. Según dicen, no han podido encontrar por el momento una solución válida, pero tampoco quieren difundir los detalles por el peligro que supondría el conocimiento público. Advierten que, incluso con IPv6 el problema podría ser incluso más grave.
Darán más detalles sobre el problema el 17 de octubre, durante una conferencia en Helsinki. Afirman tener una herramienta llamada sockstress capaz de "tumbar" cualquier dispositivo. Aunque la información es confusa (y habría que tomarla con cautela mientras no se tengan detalles), parece que el problema está directamente relacionado con la técnica de las "SYN cookies". Se utilizan precisamente para evitar que un atacante pueda realizar una inundación de paquetes SYN. Básicamente se "recuerda" con esta cookie a quien ha realizado la conexión y se evita que se falsee la dirección y se perpetre el conocido ataque (abriendo conexiones a medio realizar que consumen memoria y agotando los recursos del dispositivo).
Es la tercera gran vulnerabilidad del año que pone en peligro a toda la Red. En primer lugar fue Kaminsky con su problema DNS. El 8 de julio todos los grandes y pequeños fabricantes parcheaban sus sistemas DNS. Kaminsky había descubierto meses antes un fallo que permitía falsificar cualquier IP asociada a un dominio. Poco después en agosto, durante la Black Hat, se habla de nuevo de la mayor vulnerabilidad de Internet, cuando Tony Kapela y Alex Pilosov demostraron una nueva técnica que permite interceptar el tráfico de Internet a una escala global. Cualquiera con un router BGP podría interceptar el tráfico de cualquier gran nodo y devolverlo (modificado o no) de forma transparente.
Y vuelve a ocurrir, repitiendo prácticamente el mismo escenario. En los tres casos se trata de un problema de diseño de un protocolo creado muchos años antes. En los tres casos parece haber una demostración empírica de un problema conocido pero cuyas posibilidades o puesta en práctica se suponía imposible hasta la fecha... Incluso el hecho de revelar detalles en una conferencia posterior con la que se crea una gran expectación. Como le ocurrió a Kamisky, es posible que todos los detalles del problema salgan a la luz antes de lo esperado si algún investigador decide juntar todas las pistas ofrecidas por Outpost 24.
Es más que posible que aunque los detalles fueran conocidos desde hace 3 años, haya sido precisamente lo ocurrido con el fallo DNS y con BGP lo que haya animado a los investigadores a darle publicidad precisamente ahora. Kaminsky demostró que se puede realizar una actualización masiva y coordinada entre todos los grandes fabricantes y mantener en secreto los detalles de un grave problema (siempre que no se divulgue su existencia).
Nos encontramos posiblemente también ante una nueva era en la Red en la que, a través de estos graves errores puestos sobre la mesa, estamos cuestionando su sostenibilidad tal y como la conocemos. Usamos protocolos diseñados, cuando menos, hace 20 y 30 años. Los ingenieros estaban mucho más sorprendidos por el hecho de que la Red simplemente funcionase que preocupados por la seguridad. Hacer que un trozo concreto de información digital concreta llegase de un punto a otro del planeta era algo demasiado fantástico como para complicarlo previniendo si alguien la iba a podía modificar, alterar u obtener de forma ilegítima. Posteriormente, sobre estos débiles pilares, se ha construido algo muchísimo más complejo y unido millones de personas y dispositivos con muy distintas motivaciones. Para abarcar toda esta explosión, se ha ido parcheando sobre la marcha un monstruo gigante con pies de barro que, a la vista de estos tres recientes acontecimientos (y de otras preocupaciones de largo recorrido, como el malware ganando la batalla a los antivirus), necesita una clara revisión y puesta a punto.