Xnoccio.com

Acabo de comprobar que Google no lo sabe todo. Uno de los fallos más habituales de Ubuntu 6.10 es cambiar el monitor respecto al usado en el proceso de instalación. Como el XServer fue configurado para el otro monitor el rango de resoluciones y frecuencias no coincide y el invento casca.

Una primera solución es editar a mano el fichero /etc/X11/xorg.conf y limitar las resoluciones y Hz. Mala solución. Ubuntu cree que todos los rangos de frecuencia son aptos a todas las resoluciones, con lo cuál tienes que limitar la frecuencia a la resolución más alta:

Section "Monitor"
	Identifier	"AOC"
	Option		"DPMS"
	HorizSync	30-96
        VertRefresh	50-60    <--- Refresco limitado a la resolución más alta
EndSection

Si buscamos en google siempre dan la misma solución: reconfigurar xserver con sudo dpkg-reconfigure xserver-xorg. Esto es matar moscas a cañonazos, pues el Xserver está bien, es solo el monitor.

¿Solución entonces? Dejar que el monitor ponga los modos, no Linux, y como me recomendó mi hermano vamos a imitar a Windows. Toca el xorg.conf comentando (o borrando) la configuración manual del monitor, tal que:

Section "Monitor"
	Identifier	"AOC"
	Option		"DPMS"
#	HorizSync	30-96
#	VertRefresh	50-60
EndSection

De este modo delegamos en el monitor la responsabilidad de establecer los modos, que los enviará al ordenador mediante DPMS. Windows usa este procedimiento hace siglos, Ubuntu alguna vez lo descubrirá, o descubrirá que no es necesario sobreescribir manualmente la configuración DPMS porque quién mejor que el propio monitor para decirnos lo que puede y no puede hacer.

Si acabas de instalar Ubuntu 6.10 lo más probable es que estos 2 programas los tengas en inglés. Para resolverlo pon desde consola de comandos:


sudo aptitude install mozilla-firefox-locale-es-es
sudo aptitude install thunderbird-locale-es-es


Y ale, a disfrutar en la lengua de Cervantes. No he probado con Synaptic o Apt pero debe funcionar igual.

Después del artículo anterior sobre port knocking vamos con algo totalmente básico: los permisos en Linux. Hablar de seguridad es hablar de permisos y para ello tenemos el comando chmod de linux.

Anda el lumbreras este, viene a hablarnos de chmod. Pues no, para eso existen tutoriales muy buenos, empezando por poner un ‘man chmod’ . Solo quiero aconsejar que los ficheros críticos de tu sistema no tengan más permisos de los debidos. Por ejemplo en (casi) toda instalación de Linux los siguientes ficheros vienen con permisos de lectura:
/etc/inittab
/etc/group
/etc/passwd
/etc/shadow (este quizás no)

Y digo yo, ¿qué necesidad tienen los usuarios de leer esos ficheros? Un chmod 700 a cal y canto y aquí pan y después gloria.

Puede parecer una tontería pero ¿sabías que la contraseña de Administrador de Windows puede romperse en menos de 30 segundos? ¿o que un Linux es vulnerable durante el propio proceso de arranque? Pues eso, toda precaución es poca.

P.D.: no dejes de leer el post de abajo.

Una de las principales vulnerabilidades en un sistema es el hecho de tener que dejar abiertos los puertos cuyos servicios desea proporcionar. Si bien servicios como el http o el smtp deben permanecer abiertos para ser funcionales, es posible hacer que los servicios neurálgicos de nuestro sistema solo sean accesibles cuando verdaderamente son necesarios.

- ¿A qué nos referimos? A la posibilidad de ofrecer un servicio sobre un puerto cerrado.
- ¿Mande? Dime qué has fumado que yo también quiero…
- No he fumado nada incrédulo, hablo de la estrategia del port knocking.
- Em, ¿me lo explica?
- Desde luego.

El port knocking es una estrategia que permite a un usuario solicitar la apertura de un puerto para disponer de un servicio inicialmente cerrado. Esta solicitud tiene la forma de secuencia de paquetes de autenticación enviados a puertos cerrados. Es posible enviar información a través de puertos cerrados y en ausencia de otro servicio de red, ya que nuestro cortafuegos y otras utilidades como tcpdump pueden configurarse para observar todos los paquetes que llegan sin importar si luego serán entregados a un servicio. La gran potencia del port knocking radica en el hecho de trabajar siempre con puertos cerrados, lo cuál no deja resquicios de seguridad.

Una forma de limitar los usuarios entrantes es por filtrado de IP, pero esta ténica tiene muchas debilidades: puertos abiertos, suplantación física, imposibilidad de movilidad de los usuarios… Port Knocking resuelve todos estos problemas y además aporta más seguridad.

El port knocking fue descrito por primera vez en la revista SysAdmin. Existen diversas formas de implementarlo, una bastante popular es doorman, aunque aquí haremos una implementación muy sencilla basada en tcpdump y en tan solo 4 pasos.

Paso 1: cerrar todo. Lo primero es usar una configuración muy restrictiva en nuestro iptables: lo cerramos todo. Un ejemplo simple sería:

#!/bin/sh
#firewall.sh
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP

Cabe destacar el uso de DROP, nunca de REJECT en nuestra política de rechazo ya que debe producirse una denegación silenciosa del servicio que no provoque respuesta al supuesto intruso. Esta configuración no permite nuevas conexiones sobre puertos cerrados pero sí permite continuar aquellas iniciadas.

Paso 2: apertura de puerto. Diseñamos un script que durante abra durante 10 segundos por ejemplo el puerto solicitado si recibe un paquete cuyo “santo y seña” es correcto.

#!/bin/bash
# guard.sh
# acepta los paquetes entrantes
/sbin/iptables -I INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2
sleep 10
# rechaza los paquetes entrantes
/sbin/iptables -D INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2

A los 10 segundos el puerto se cierra, pero nosotros ya hemos iniciado la conexión (SSH, FTP, etc) y el firewall permite continuar conexiones iniciadas. ¡Estamos trabajando sobre un puerto cerrado!

Paso 3: escucha activa. El port knocking se asemeja a las famosos santo y seña de las películas de espionaje donde abrimos una puerta llamando con “2 toques largos, 3 cortos y uno largo”. En nuestro caso la contraseña correcta podría ser que el paquete recibido tuviera una cabecera de valor 17. Debemos diseñar un script que permanezca a la escucha e identifique la llamada correcta. Cuando ésta se produzca lanzará guard.sh lo que abrirá el puerto durante 10 segundos, tiempo suficiente para entrar.

tcpdump -l -O "tcp[2:2]>=1000 and tcp[2:2]<=10999 and tcp[4:4]=17 and tcp[tcpflags] & tcp-syn!=0" | sed -u 's/.*IP \([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\).*\.10*\([0-9]*\): S.*/\1 \2/' | xargs -t -l -i bash -c "/root/guard.sh {} &"

tcpdump no permite especificar intervalos de puertos, cosa que suplimos con la sintaxis tcp[2:2] que indica un campo de 2 bytes en la cabecera TCP a partir del byte 2 (tcp[inicio:longitud]). Nuestra estrategia de implementación en esta ocasión consiste en eliminar la cabecera de 2 bytes y abrir el puerto resultante. Así por ejemplo con 1022 abriríamos el puerto 22 (SSH).

Paso 4: llamada. Nuestro sistema permanece atento, vamos a hacer la llamada correcta:

# Sintaxis:
# sendip ip_origen puerto_origen ip_destino puerto_destino
# 1000 < puerto_destino <=10999
sendip -p ipv4 -p tcp -is $1 -ts $2 -td $3 -tfs 1 -tn 17 $4

La contraseña 17 es correcta y solicitamos la apertura del puerto para nuestra IP.

Con estos sencillos pasos conseguimos que servicios tan útiles como el FTP, de los cuáles los administradores siempre son recelosos, puedan ofrecerse con riesgo nulo. El ataque de un intruso es prácticamente imposible.

Si deseas profundizar en el uso de port knocking recomiendo que te documentes sobre Doorman, de Bruce Ward, que se caracteriza por su original y elegante enfoque del port knocking.

Hasta la próxima entrega.

En vista que el señor dbejar nos está dejando en evidencia va siendo hora que los demás contemos algo. En esta ocasión voy a tirar hacia sistemas y voy a escribir el primero de una serie de artículos relacionados con seguridad que iré publicando en sucesivas entregas.

Como es la primera empecemos despacito para ir calentando motores. Lo leí en un libro bastante bueno (a ver si lo encuentro, solo conservo unos apuntes) y el punto se titula, como vuestras mentes lúcidas habrán deducido, “Las 14 principales vulnerabilidades de seguridad”. En ella repasamos los principales puntos por los que un hacker podría atacar nuestro sistema. Contempla tanto sistemas Windows como Linux, es un “vuelo rasante”. Vamos al turrón:

1) Control de acceso inadecuado al router: un ACL del router que se haya configurado erróneamente puede permitir la filtración a través de ICMP (Protocolo de Control de Mensajes de Internet), IP NetBIOS y permitir accesos no autorizados a determinados servicios en sus servidores DMZ (Zona DesMilitarizada).

2) Los puntos de acceso remoto no seguros y no vigilados proporcionan uno de los modos más sencillos de acceder a nuestra red. Es conveniente no exponer nuestros archivos sensibles.

3) La filtración de información puede proporcionar al atacante información sobre la versión de nuestro sistema operativo, aplicaciones, usuarios, grupos, servicios compartidos, información DNS a través de transferencias de zona y servicios en ejecución tales como SNMP, finger, SMTP, telnet, rusers, rcpinfo, NetBios…

4) Los host que ejecutan servicios innecesarios tales como RCP, FTP, DNS, SMTP, etc son una fuente innecesaria de puertos vulnerables.

5) Contraseñas reutilizadas, sencillas o fácilmente adivinables a nivel de estación de trabajo. Caer ante un ataque de diccionario es uno de los errores más frecuentes en un sistema si no se educa adecuadamente a sus usuarios.

6) Cuentas de usuarios con privilegios excesivos. En combinación con 5 es bajarse los pantalones ante el resto del mundo.

7) Sevidores de internet mal configurados, especialmente archivos de comandos CGI en servidores web y FTP anónimos con permisos de escritura.

Si un servidor DMZ queda comprometido un ACL mal configurado en el router puede dar acceso al intruso a la zona interna de nuestra red.

9) Aplicaciones que no estén convenientemente actualizadas con sus correspondientes parches de seguridad.

10) Excesivos controles de acceso en los recursos compartidos de NT y exportaciones mediante NFS en Unix.

11) Contar con excesivas relaciones de confianza tales como los Dominios de Confianza en NT y los archivos .rhost y hosts.equiv de UNIX puede orientar al atacante un acceso a sistemas sensibles.

12) Servicios no autenticados tales como X-Windows que permiten a los usuarios capturar pulsaciones de tecla realizadas de forma remota.

13) Capacidades de registro, detección y vigilancia inadecuadas, sin cruzar la frontera que puede suponer invadir la privacidad de los trabajadores.

14) Carencia de directivas, procedimientos, normativas y directrices de seguridad aceptadas y convenientemente elaboradas.

Y si me apuraís añadiría la 15, El arma más eficaz del hacker: la ingeniería social.

Bueno, ¿y todo este tostón para qué? Pues en principio solo para que te hagas preguntas sobre tu sistema. En próximos artículos iremos al grano con soluciones prácticas para cada apartado con la idea de amargar la vida al más perseverante de los hackers.

Sed buenos.

Si te gusta el desarrollo amateur de videojuegos puedes visitar esta página:

Technoworks

No esperes nada espectacular, su único cometido es colgar el material terminado, más bien poco pues la mayoría de los códigos se quedan en pruebas.

Actualmente está parada, así que las fechas que pudiera haber no se deben tener en cuenta pues todos los proyectos están congelados.