Navegando entre bits
Sistemas operativos, seguridad, redes, programación, robótica y astronomía
Distribución del espacio en linux
10 mar 2010
Sabemos de la importancia que tiene el tener el sistema de archivos organizado en varias particiones, a ser posibles que estén en discos diferentes por cuestiones de rendimiento. Por ejemplo tener /home en una partición nos permitirá mantener nuestros datos personales, configuraciones. Otro ejemplo es /usr que es donde se instalan la mayoría de los programas. De esta forma podemos separar sistema de programas, permitiendo las lecturas y escrituras en paralelo tanto del sistema operativo como de las aplicaciones.
Hasta aquí más o menos todos coincidimos, el problema viene a la hora de decidir el espacio a dedicarle a cada partición. Si asignamos demasiado desperdiciaremos espacio, y si nos quedamos cortos el problema será peor. El programa de instalación de cada distribución de linux suele hacer una propuesta al particionar el disco, pero los valores aconsejados distan mucho de la realidad. Para tener una orientación en futuras instalaciones he decidido obtener estadísticas de ocupación de cada una de las carpetas importantes del sistema. Para ello he utilizado la aplicación baobab (presente en casi todas las distribuciones) que realiza muy bien este cometido.
El sistema sobre el cual he obtenido las estadísticas es un sistema de escritorio Ubuntu Karmic 9.10 con algunas aplicaciones extra instaladas que suelo utilizar frecuentemente. La distribución del espacio es la siguiente:
Como podemos apreciar las carpetas de mayor tamaño son /usr, /home, /opt y /var. Esto puede variar considerablemente dependiendo del uso que se le de a /home. En mi caso no suelo guardar archivos de gran tamaño ahí. Para eso suelo tener otra partición dedicada exclusivamente a datos.
Las conclusiones que he llegado, sin contar con la partición de datos y sin la partición de swap, es que es conveniente tener al menos 4 particiones con los siguientes tamaños en porcentajes respecto del total de espacio disponible:
- /usr entre un 35% y un 40%. Como he dicho esto puede variar en función del uso que se le de a /home
- /home con un 30% aproximadamente. Si no se tiene una partición de datos el tamaño deberá ser mayor.
- /var con un 8%
- Y otra partición que contendrá el resto de carpetas del sistema
Como he comentado no se ha tenido en cuenta la partición de swap, una regla que solía seguirse era tener el doble de swap que de memoria RAM. Actualmente con las cantidades de memoria que suelen tener los equipos está un poco desfasada. Con 1GB para swap debería ser más que suficiente para cualquier sistema de escritorio.
Incrementado la seguridad en SSH
6 mar 2010
SSH (Secure SHell, en español: intérprete de órdenes segura) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.
Cuando instalamos un servidor de ssh, por ejemplo OpenSSH (sudo aptitude install ssh), en ocasiones solemos dejarlo con las opciones de configuración que vienen por defecto, sobre todo en entornos domésticos, asumiendo que como ssh es un shell seguro, no necesitamos realizar más ajustes que los que vienen por defecto. Nada más lejos de la realidad. Vamos a ver algunas de las opciones del archivo de configuración (/etc/ssh/sshd_config) que nos pueden ayudar a comprender mejor como funciona ssh y lo expuestos que podemos estar frente a ataques basados en diccionario si no se toman las medidas oportunas.
Para editar el archivo necesitamos permisos de administrador:
sudo gedit /etc/ssh/sshd_config
Al editarlo podremos observar hay multitud de opciones de configuración, pero sólo nos vamos a centrar en las siguientes:
Port 20022 Protocol 2 LoginGraceTime 30 PermitRootLogin no MaxAuthTries 2 MaxStartups 1 AllowUsers pepito AllowUsers juanito@80.25.14.14
Veámos el significado de ellas:
- Port 20022 indica el puerto de escucha de ssh, es decir, donde estará esperando conexiones el servicio de ssh. El puerto por defecto es el 22 y es importante cambiarlo, ya que muchos scripts de ataques están dirigidos a este puerto. Cambiar de puerto no garantiza que no pueda ser localizado por dichos scripts, pero desde luego se lo ponemos más complicado. ¿Piensas que no es necesario cambiar el puerto? ¿Por qué no le hechas un vistazo a los registros de log de autentificación en /var/log/auth.log? ¿Sorprendido? Si tienes una máquina conectada a Internet, con el puerto 22 abierto y redirigido a una máquina con acceso ssh, seguro que tienes mucho que mirar en dicho fichero, como por ejemplo intentos de conexión fallidos. Por ejemplo, unas cuantas líneas como estas:
Feb 28 11:57:04 distantsuns sshd[25055]: Invalid user kid from 220.108.89.55
Feb 28 11:57:13 distantsuns sshd[25111]: Failed password for root from 220.108.89.55 port 44336 ssh2
Feb 28 11:58:25 distantsuns sshd[25775]: Failed password for invalid user kes from 220.108.89.55 port 48097 ssh2
Mi recomendación es que utilicéis un puerto alto, por encima del 10000. La mayoría de los escaners de puertos buscan por defecto en los puertos bien conocidos (hasta el 1024) y algunos puertos por encima, pero no los revisan todos.
Evidentemente, cambiar el puerto no nos asegura nada, pero pone las cosas un poco más difíciles a los scripts automáticos. - Protocol 2 existen 2 versiones de ssh, versión 1 y versión 2. La primera se mantiene sólo por compatibilidad y no debería ser usada ya que está obsoleta y tiene algunas vulnerabilidades bien conocidas.
- LoginGraceTime 30 indica el número de segundos que estará disponible la pantalla de login. Pasados los segundos la conexión se cerrará. De esta forma evitamos que alguien esté intentando acceder mediante un script varias veces para adivinar un usuario y contraseña. El valor por defecto de este campo es 130, demasiado tiempo en mi opinión, se pueden realizar muchas pruebas automáticas en ese tiempo. Para cualquier ser humano con 30 segundos debería ser más que suficiente.
- PermitRootLogin no muy importante no permitir conexiones remotas con el usuario root. Todos los ataques basados en diccionario saben que en los sistemas en UNIX, existe un usuario en el sistema llamado root. Por tanto una parte de la combinación usuario-contraseña ya la tendrían y no sólo eso, sino con acceso de administrador. Sorprendentemente esta opción estaba por defecto en mi máquina con el valor yes. Desde luego es un agujero de seguridad tremendo. Si necesitamos acceder vía ssh con permisos de administrador, podemos entrar al sistema con cualquier usuario estándar y una vez dentro cambiamos a root con el comando su.
- MaxAuthTries 2 indica la cantidad de veces que podemos equivocarnos al validarnos como usuario, en este caso después de dos intentos, se perderá o cerrará la conexión. Si se diera el caso podemos volver a intentarlo, pero de esta forma evitamos ataques basados en la persistencia de la conexión.
- MaxStartups 1 indica la cantidad de conexiones simultáneas de login que permitirá el sshd por ip que intente conectarse. Muchos de los ataques dividen su esfuerzo abriendo múltiples pantallas de login, llegando incluso a saturar el sistema. Es decir, el ataque se divide en una gran cantidad de logins, aumentando las posibilidades de obtener un usuario y contraseña más rápidamente. Tener este parámetro con el valor 1 no significa que no podamos tener varios shells remotos abiertos, simplemente cuenta pantallas de login. Una vez validados, podemos abrir otro shell sin problemas.
- AllowUsers indica los usuarios que tienen permiso para acceder por ssh al sistema. Muy útil cuando tenemos muchos usuarios en el sistema y no podemos tener un control sobre la seguridad de las contraseñas que se hayan puesto dichos usuarios. Por tanto sólo daremos permiso a aquellos usuarios que sepamos que tienen una combinación de usuario y contraseña fuertes. Con esta opción también podemos indicar desde que máquinas permitimos el acceso. Por ejemplo podríamos hacer que el usuario juanito sólo pudiése acceder desde la ip 80.25.14.14 añadiendo la siguiente línea:
AllowUsers juanito@80.25.14.14
También podemos usar comodines para indicar que se permite acceso desde una red entera. Por ejemplo supongamos que nuestra red privada utiliza direcciones ip privadas de clase C del tipo 192.168.0.X (máscara por defecto 255.255.255.0). Podríamos añadir la siguiente línea para indicar que se permite el acceso al usuario alicia únicamente desde la red privada:
AllowUsers alicia@192.168.0.*
Con este mini tutorial sobre la configuración podremos tener un sistema más seguro que unido al tutorial de verificación de rootkits, nos permite estar un poco más tranquilos.
Terminales virtuales con Screen
23 feb 2010
Imagínate que eres un administrador de sistemas Linux que trabaja desde un equipo Windows y usas Putty para conectarte a los servidores Linux, y dejas una terminal descargando esa nueva y fantástica distro, y esto va a tomar varias horas. En la tarde que ya te vas a casa, solo llevas un avance de un 20% digamos, en el transcurso de la noche terminará la descarga, asi que no apagas tu equipo Windows porque al apagarlo se pierde la terminal y la descarga. Te vas muy confiado, pero resulta que tu acomedido compañero al ver que dejaste la computadora prendida, la apague, y ni hablar, al otro día volver a iniciar la descarga donde se quedó.
Es un ejemplo sin importancia, porque pudo ser algo grave, como la ejecucción de un respaldo, la réplica de una base de datos, una comprobación del sistema de archivos, etc.
Al rescate llega screen que es una utilería que permite multiplexar una terminal, crear una terminal virtual a partir de una existente y después esta terminal virtual ser “llamada” desde otras terminales o desde el servidor junto con el programa que se este ejecutando.
Lo anterior quiere decir, siguiendo con el ejemplo, que te conectas via putty al servidor, desde la terminal ejecutas screen, que abrirá otro shell, desde este shell ejecutas la descarga (o el programa que quieras), te sales de screen y te sales de putty, apagas la computadora, y al otro día te reconectas a la terminal virtual, y listo, tendrás de nuevo la terminal donde esta se encuentre ejecutándose en ese momento, como si nunca la hubieras cerrado.
Su uso es muy fácil, estando en la línea de comandos o shell de cualquier terminal local o remota, teclea:
$ screen
Con este comando creamos un nuevo shell virtual donde podemos ejecutar algún proceso largo y cerrar completamente esa terminal sin miedo a que se interrumpa el proceso que dejamos en funcionamiento.
Ahora desde una nueva terminal ejecuta lo siguiente para observar la lista de terminales virtuales:
$ screen -ls There is a screen on: 21432.pts-2.g3xlap (Attached) 1 socket in /var/run/screen/S-root.
Lo que nos indica que tenemos una terminal virtual ejecutándose. Cada terminal virtual recibe un número, por lo que entonces desde cualquier otro equipo o en el mismo servidor, a través de una terminal (telnet, ssh, local), será posible invocar de nuevo estas terminales virtuales, tan solo basta la opción -r:
$ screen -r 21432
Sólo basta indicar el número asignado de la terminal virtual, si no hubiera más que una sola terminal virtual bastaría con indicar la opción -r sin número.
Y básicamente es todo, una vez en la terminal virtual puedes seguir trabajando en ella. Esta herramienta es extremadamente útil y puede salvarnos de situaciones como las citadas al principio del post.
Vía: http://www.linuxtotal.com.mx por Sergio González Durán.
Configurar servidor DHCP en Ubuntu y Debian
20 feb 2010
Que es DHCP ?
Un servidor Dynamic Host Configuration Protocol (DHCP) asigna dinámicamente las direcciones IP y otras configuraciones de una red determinada a otros ordenadores clientes que estan conectados a la red. Esto simplifica la administración de la red y hace que la conexión de nuevos equipos a la red sea mucho más fácil.
Todas las direcciones IP de todos los equipos se almacenan en una base de datos que reside en un servidor.
Un servidor DHCP puede proporcionar los ajustes de configuración utilizando dos métodos
Rango de Direcciónes
Este método se basa en la definición de un grupo de las direcciones IP para los clientes DHCP (tambien llamado IP address pool) que suministran sus propiedades de configuración de forma dinámica segun lo soliciten los ordenadores cliente. Cuando un cliente DHCP ya no está en la red durante un período determinado, la configuración vence y la direccion ip del poll es puesta en libertad el uso de otros clientes DHCP.
Dirección MAC
Este método se basa en utilizar el protocolo DHCP para identificar la dirección de hardware única de cada tarjeta de red conectada a la red y luego es asignada una configuracion constante asi como la misma direccion IP cada vez que la configuración de DHCP del cliente realiza una petición al servidor DHCP desde el mismo dispositivo de red.
Instalar un servicio DHCP en Ubuntu y Debian
Para instalar el servidor de asignacion automatica de direccion IP ejecutamos el comando:
sudo apt-get install dhcp3-server
Este sencillo paso instala el servidor en nuestro linux.
Configurando el servidor DHCP
En el caso que tengan dos interfaces de red (NIC) en su servidor Linux tienen que seleccionar cual van a utilizar para escuchar las peticiones DHCP. Para configurar el servicio, editamos el archivo /etc/default/dhcp3-server, y cambiamos INTERFACES=”eth0″ por la tarjeta de red interna.
Es necesario hacer una copia de seguridad del archivo de configuracion:
cp /etc/dhcp3/dhcpd.conf /etc/dhcp3/dhcpd.conf.back
Configurar utilizando el metodo de rango de direcciones (IP pool)
Editamos la configuracion tecleando:
sudo vi /etc/dhcp3/dhcpd.conf
Y en este archivo cambiamos las siguientes secciones
default-lease-time 600; max-lease-time 7200;
option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.1; option domain-name-servers 192.168.1.9, 192.168.1.10; option domain-name “guatewireless.org”;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.200;
}
Guardamos y salimos del archivo. El texto anterior configura el servidor DHCP con los siguientes parametros:
- Asignacion a los clientes direcciones IPs del rango de 192.168.1.10 hasta 192.168.1.200
- Prestara la direccion IP por un minimo de 600 segundos, y como maximo permitido de 7200 segundos.
- Determina la mascara de subred a 255.255.255.0
- Direccion de broadcast de 192.168.1.255
- Como gateway/pasarela de red/router la direccion 192.168.1.1
- Y los servidores 192.168.1.9 y 10 como sus servidores DNS
Configurar utilizando el metodo de direcciones MAC
Con este metodo se puede reservar algunas o todas las direcciones IP de nuestra red para determinadas maquinas. Como podran ver la configuracion es muy parecida a la anterior, con la salvedad que para reservar la asignacion de una IP a una determinada NIC (network card interface) debemos de utilizar la etiqueta host
default-lease-time 600; max-lease-time 7200;
option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.1; option domain-name-servers 192.168.1.9, 192.168.1.10; option domain-name “guatewireless.org”;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.10 192.168.1.200;
}
host oracle{
hardware ethernet 00:03:47:31:e1:7f;
fixed-address 192.168.1.20;
}
host printer {
hardware ethernet 00:03:47:31:e1:b0;
fixed-address 192.168.1.21;
}
Ahora reiniciamos el servidor dhcp ejecutando el siguiente comando:
sudo /etc/init.d/dhcp3-server restart
Configurar el cliente DHCP en Linux Ubuntu
Si dean configurar un escritorio o maquina con linux como cliente DHCP seguimos los siguientes pasos:
- Editamos el archivo de interfaces de red
sudo vi /etc/network/interfaces
- Debemos de tener las siguientes lineas, tomando en cuenta que eth0 es un ejemplo
auto lo eth0 iface eth0 inet dhcp iface lo inet loopback
- Salvamos y salimos del archivo
- Reiniciamos los servicios de red de Linux Ubuntu
sudo /etc/init.d/networking restart
Para poder conocer las direcciones asignadas a las maquinas clientes
tail -n 15 /var/lib/dhcp3/dhclient.*.leases Fuente: http://www.guatewireless.org
Red local Ubuntu virtualizado con Virtualbox
22 ene 2010
Uno de los problemas que me encontré al cambiar de Vmware a Virtualbox es poder comunicar los Guest con la red Local. Con Vmware el puente se crea de forma automática pero con Virtualbox hay que realizarlo de forma manual. El sistema que utiliza Virtualbox por defecto para utilizar la tarjeta de red virtualizada es NAT, que en principio nos puede ir bien si lo único que queremos es tener acceso a Internet desde el Guest virtualizado. El problema si disponemos de un red de área local y queremos que el Guest pueda comunicarse con los demás equipos de la red.
Buscando en Internet he visto varias soluciones pero la única que me ha funcionado realmente bien es la que detallo a continuación:
- Host (Windows Vista)
- Guest (GNU/Linux Ubuntu 9.10)
Configuración de la red en el Host
No hay que tocar absolutamente nada. He visto en muchos sitios que hablan de crear un puente entre la tarjeta de red y el Virtualbox host-only, pero a mi no me ha funcionado nada de esto. Por tanto, lo dicho, no cambiar nada.
Configuración de la red en el Guest.
- Iniciar Virtualbox y seleccionar la Máquina Virtual que deseamos que se pueda comunicar con nuestra red local.
- Una vez seleccionada ir al menú Máquina –> Configuración. Aparecerá una pantalla como esta:
- En la pantalla que se abre seleccionar la opción red.
- Seleccionar Adaptador 1 y habilitar el adaptador de red en caso de que no lo estuviera.
- En la opción Conectado a seleccionar Adaptador puente
- En la siguiente opción Nombre veremos que hay varias opciones, tenemos que seleccionar el nombre de nuestro adaptador de red, que en mi caso el adaptador de la tarjeta Wifi. Tiene que quedarnos algo parecido a la siguiente imagen.
- Donde pone Avanzadas recomiendan utilizar en Tipo de Adaptador el Intel PRO/1000 MT Desktop, pero a mi me funciona perfectamente con el que sale por defecto PC-NET Fast III.
- Una vez realizados los pasos anteriores aceptamos e iniciamos la máquina virtual.
- Por último, hacemos login y configuramos la red con los mismos parámetros que nuestra red local, es decir, una dirección ip libre que esté dentro del rango de nuestra red con la misma máscara y el mismo Gateway y servidor DNS.
Llegados a este punto recomiendo desactivar y volver a activar la red para que lea la nueva configuración ya que en alguna ocasión me ha dado problemas. Ahora deberíamos poder comunicarnos con cualquier equipo de la red. Para comprobarlo podemos realizar un ping a cualquiera de los equipos o al mismo router.
Red SOStenible
12 ene 2010
Consideramos imprescindible la retirada de la disposición final primera de la Ley de Economía Sostenible por los siguientes motivos:
1 -Viola los derechos constitucionales en los que se ha de basar un estado democrático en especial la presunción de inocencia, libertad de expresión, privacidad, inviolabilidad domiciliaria, tutela judicial efectiva, libertad de mercado, protección de consumidoras y consumidores, entre otros.
2 – Genera para la Internet un estado de excepción en el cual la ciudadanía será tratada mediante procedimientos administrativos sumarísimos reservados por la Audiencia Nacional a narcotraficantes y terroristas.
3 – Establece un procedimiento punitivo “a la carta” para casos en los que los tribunales ya han manifestado que no constituían delito, implicando incluso la necesidad de modificar al menos 4 leyes, una de ellas orgánica. Esto conlleva un cambio radical en el sistema jurídico y una fuente de inseguridad para el sector de las TIC (Tecnología de la Información y la Comunicación). Recordamos, en este sentido, que el intercambio de conocimiento y cultura en la red es unmotor económico importante para salir de la crisis como se ha demostrado ampliamente.
4 – Los mecanismos preventivos urgentes de los que dispone la ley y la judicatura son para proteger a toda ciudadanía frente a riesgos tan graves como los que afectan a la salud pública. El gobierno pretende utilizar estos mismos mecanismos de protección global para beneficiar intereses particulares frente a la ciudadanía. Además la normativa introducirá el concepto de “lucro indirecto”, es decir: a mí me pueden cerrrar el blog porque “promociono” a uno que “promociona” a otro que linka a un tercero que hace negocios presuntamente ilícitos
5 – Recordamos que la propiedad intelectual no es un derecho fundamental contrariamente a las declaraciones del Ministro de Justicia, Francisco Caamaño. Lo que es un derecho fundamental es el derecho a la producción literaria y artística.
6 – De acuerdo con las declaraciones de la Ministra de Cultura, esta disposición se utilizará exclusivamente para cerrar 200 webs que presuntamente están atentando contra los derechos de autor. Entendemos que si éste es el objetivo de la disposición, no es necesaria, ya que con la legislación actual existen procedimientos que permiten actuar contra webs, incluso con medidas cautelares, cuando presuntamente se esté incumpliendo la legalidad. Por lo que no queda sino recelar de las verdaderas intenciones que la motivan ya que lo único que añade a la legislación actual es el hecho de dejar la ciudadanía en una situación de grave indefensión jurídica en el entorno digital.
7 – Finalmente consideramos que la propuesta del gobierno no sólo es un despilfarro de recursos sino que será absolutamente ineficaz en sus presuntos propósitos y deja patente la absoluta incapacidad por parte del ejecutivo de entender los tiempos y motores de la Era Digital.
La disposición es una concesión más a la vieja industria del entretenimiento en detrimento de los derechos fundamentales de la ciudadanía en la era digital.
La ciudadanía no puede permitir de ninguna manera que sigan los intentos de vulnerar derechos fundamentales de las personas, sin la debida tutela judicial efectiva, para proteger derechos de menor rango como la propiedad intelectual. Dicha circunstancia ya fué aclarada con el dictado de inconstitucionalidad de la ley Corcuera (o ley de patada en la puerta). El Manifiesto en defensa de los derechos fundamentales en Internet, respaldado por más de 200 000 personas, ya avanzó la reacción y demandas de la ciudadanía antes la perspectiva inaceptable del gobierno.
Para impulsar un definitivo cambio de rumbo y coordinar una respuesta conjunta, el 9 de enero se ha constituido la “Red SOStenible” una plataforma representativa de todos los sectores sociedad civil afectados. El objetivo es iniciar una ofensiva para garantizar una regulación del entorno digital que permita expresar todo el potencial de la Red y de la creación cultural respetando las libertades fundamentales.
En este sentido, reconocemos como referencia para el desarrollo de la era digital, la Carta para la innovación, la creatividad y el acceso al conocimiento, un documento de síntesis elaborado por más de 100 expertos de 20 países que recoge los principios legales fundamentales que deben inspirar este nuevo horizonte.
En particular, consideramos que en estos momentos es especialmente urgentes la implementación por parte de gobiernos e instituciones competentes, de los siguientes aspectos recogidos en la Carta:
1 – Las/os artistas como todos los trabajadores tienen que poder vivir de su trabajo (referencia punto 2 “Demandas legales“, párrafo B. “Estímulo de la creatividad y la innovación”, de la Carta);
2 – La sociedad necesita para su desarrollo de una red abierta y libre (referencia punto 2 “Demandas legales“, párrafo D “Acceso a las infraestructuras tecnológicas”, de la Carta);
3 – El derecho a cita y el derecho a compartir tienen que ser potenciado y no limitado como fundamento de toda posibilidad de información y constitutivo de todo conocimiento (referencia punto 2 “Demandas legales“, párrafo A “Derechos en un contexto digital”, de la Carta);
4 – La ciudadanía debe poder disfrutar libremente de los derechos exclusivos de los bienes públicos que se pagan con su dinero, con el dinero publico (referencia punto 2 “Demandas legales“, párrafo C “Conocimiento común y dominio público”, de la Carta);
5 -Consideramos necesaria una reforma en profundidad del sistema de las entidades de gestión y la abolición del canon digital (referencia punto 2 “Demandas legales“, párrafo B. “Estímulo de la creatividad y la innovación”, de laCarta).
Por todo ello hoy se inicia la campaña INTERNET NO SERA OTRA TELE y se llevarán a cabo diversas acciones ciudadanas durante todo el periodo de la presidencia española de la UE.
Consideramos particularmente importantes en el calendario de la presidencia de turno española el II Congreso de Economía de la Cultura (29 y 30 de marzo en Barcelona), Reunión Informal de ministros de Cultura (30 y 31 de marzo en Barcelona) y la reunión de ministros de Telecomunicaciones (18 a 20 de abril en Granada).
La Red tiene previsto reunirse con representantes nacionales e internacionales de partidos políticos, representantes de la cultura y legaciones diplomáticas.
Firmado Red SOStenible
Verificar Linux contra rootkits con rkhunter y chkrootkit
9 ene 2010
De acuerdo a la definición en wikipedia un rootkit es una herramienta, o un grupo de ellas que tiene como finalidad esconderse a sí misma y esconder otros programas, procesos, archivos, directorios, llaves de registro, y puertos que permiten al intruso mantener el acceso a un sistema para remotamente comandar acciones o extraer información sensible, a menudo con fines maliciosos o destructivos.
De hecho que un hacker (black hat) te instale un root kit en tu equipo Linux es la máxima intrusión a la que estarías expuesto. Recuerda que en GNU/Linux el peligro no son virus como en el mundo Windows sino las vulnerabilidades que se descubren a diario en los muy distintos programas que usa el sistema. Por eso la importancia de verificar y actualizar lo más continuo posible el sistema en su totalidad.
Se presentan dos utilerías que te permitirán verificar tu equipo por posibles cambios en los archivos y programas más comunes, ya que ha menudo los rootkits se disfrazan como programas de uso muy comun como ls o ps, incluso conservan la misma funcionalidad (que es el objetivo, que el usuario no se entere que ya ha sido hackeado con un rootkit) pero a la vez de manera furtiva realizan su trabajo de ejecutar comandos remotos, abrir puertos, realizar ataques DoS, instalar servidores Web ocultos, utilizar ancho de banda para transferencia de archivos, monitorear con keylogers, etc., etc.
chkrootkit
chkrootkit muy popular checador de rootkits, verifica localmente por señales de estos. Es una buena opción para equipos Desktop, laptops, incluso para servidores como un complemento más de este tipo de programas.
Para instalarlo (en Ubuntu):
sudo aptitude install chkrootkit
Se ejecuta sin argumentos de la siguiente manera:
$ chkrootkit ROOTDIR is `/' Checking `amd'... not found Checking `basename'... not infected Checking `biff'... not found Checking `chfn'... not infected Checking `chsh'... not infected Checking `cron'... not infected Checking `crontab'... not infected Checking `date'... not infected Checking `du'... not infected Checking `dirname'... not infected Checking `echo'... not infected Checking `egrep'... not infected Checking `env'... not infected Checking `find'... not infected ...
Es posible ver la lista de pruebas que chkrootkit puede realizar mediante la opción -l y ejecutar solo una o varias a la vez:
rkhunter
rkhunter es un checador de rootkits mucho más completo y potente que chkrootkit, es ideal para ser usado en servidores. En su página de descarga sostiene (a modo de broma) que verifica en eun 99.9% que estás libre de indeseables rootkits, es decir, realmente se trata de una capa más de seguridad. rkhunter verifica el sistema por:
- Comparación de hashes MD5
- Busca por archivos comunes usados por rootkits
- Permisos equivocados para binarios
- Busca por cadenas de texto sospechosoas en módulos LKM (Loadable Kernel Modules) y KLD (Kernel Loadable Device)
- Busca por archivos ocultos
- Opciones de escaneo dentro de archivos binarios y planos
Para instalarlo (en Ubuntu):
$ sudo aptitude install rkhunter
Una vez instalado, la manera más básica de ejecutar rkhunter es asi:
$ rkhunter -c
[ Rootkit Hunter version 1.3.2 ]
Checking system commands...
Performing 'strings' command checks
Checking 'strings' command [ OK ]
Performing 'shared libraries' checks
Checking for preloading variables [ None found ]
Checking for preload file [ Not found ]
Checking LD_LIBRARY_PATH variable [ Not found ]
Performing file properties checks
Checking for prerequisites [ OK ]
/bin/awk [ OK ]
/bin/basename [ OK ]
/bin/bash [ OK ]
/bin/cat [ OK ]
/bin/chmod [ OK ]
/bin/chown [ OK ]
/bin/cp [ OK ]
/bin/csh [ OK ]
/bin/cut [ OK ]
/bin/date [ OK ]
/bin/df [ OK ]
.... (varias líneas más)
rkhunter con la opción -c realiza un escaneo muy completo del sistema, no es posible apreciarlo aquí, pero en cada sección del escaneo la salida se interrumpe como para poder analizarlo, y hasta que no se presiones ‘Enter’ continua. Puedes deshacerte de este comportamiento interactivo con la opción –sk, por cierto, la lista de opciones o ayuda, la obtienes invocando rkhunter sin ningún argumento.
Si hubiera algo que reportar, el archivo /var/log/rkhunter.log, pero puedes cambiar la salida del archivo a otro que tu desees:
$ rkhunter -c --sk --logfile /root/rkhunter20100109.txt
Lo anterior enviará toda la salida al archivo indicado y sin hacer pausas para continuar. También es posible realizar pruebas personalizadas y no todas a la vez.
$ rkhunter --list (lista de pruebas posibles) Available test names: additional_rkts all apps attributes deleted_files filesystem group_accounts group_changes hashes hidden_procs immutable known_rkts local_host malware network none os_specific other_malware packet_cap_apps passwd_changes ports possible_rkt_files possible_rkts possible_rkt_strings promisc properties rootkits running_procs scripts shared_libs shared_libs_path startup_files startup_malware strings suspscan system_commands system_configs trojans Grouped test names: additional_rkts => possible_rkt_files possible_rkt_strings group_accounts => group_changes passwd_changes local_host => filesystem group_changes passwd_changes startup_malware system_configs malware => deleted_files hidden_procs other_malware running_procs suspscan ... (varias líneas más) $ rkhunter --enable hidden_procs,system_commands (se ejecutan solo las pruebas deseadas) $ rkhunter --disable system_commands (lo contrario, se ejecutan todas las pruebas menos la indicada(s))
Como ya se mencionó previamente, es conveniente que se ejecute periódicamente a través de un cron y con un control por fechas de los reportes que se generan, asi se teendrá una bitacora muy completa de cuando pudieron ocurrir cambios en el sistema.
También, recuerda que estos anti-rootkits son solo una medida de seguridad más para la protección de tu sistema, hay que actualizar continuamente, apagar los servicios que no se usen, configurar adecuadamente ssh, apache, servidores de correo, etc.