jueves 27 de septiembre de 2007

Memoria flash encriptada

A propósito de que talvez algunos deseen tener la seguridad de que mueven sus datos de forma segura y de que en caso de robo del dispositivo de almacenamiento extraíble los datos no sean revelados, acá unos pocos comandos en GNU/Linux para configurar el encriptado de la memoria flash.

Primero, prepare el dispositivo para el encriptado. Perderá todos los datos que se encuentren en él.

# cryptsetup luksFormat /dev/sdb -y

Luego, abra el dispositivo para formatearlo con el sistema de ficheros que desee usar

# cryptsetup luksOpen /dev/sdb ENCRIPTADO

Formatéelo

# mkfs.xfs -L ENCRIPTADO /dev/mapper/ENCRIPTADO

Ahora, creamos el punto de montaje:

# mkdir -p /mnt/ENCRIPTADO

Asignamos el propietario del punto de montaje. Esto es para hacer más fácil la vida a la persona que usare el dispositivo de almacenamiento extraíble encriptado:

# chown -R jorge:jorge /mnt/ENCRIPTADO

Montamos el sistema de ficheros encriptado:

# mount -t xfs,o=rw /dev/mapper/ENCRIPTADO \
/mnt/ENCRIPTADO

Puede ver el estado del dispositivo mediante:

# cryptsetup status ENCRIPTADO

Una vez que está hecha la configuración puede escribir los archivos que desee hacia el directorio /mnt/ENCRIPTADO.

Cuando finalice de trabajar, desmonté el sistema de ficheros

# umount /mnt/ENCRIPTADO

Cierra el dispositivo encriptado:

# cryptsetup luksClose ENCRIPTADO

Para automatizar el proceso de abrir/cerrar la memoria flash para trabajar sobre ella:


#!/bin/bash

case "$1" in
abrir)

cryptsetup luksOpen /dev/sdb ENCRIPTADO
mount -t
xfs,o=rw /dev/mapper/ENCRIPTADO /mnt/ENCRIPTADO

RETVAL=$?
;;
cerrar)
umount
/mnt/ENCRIPTADO

cryptsetup luksClose ENCRIPTADO
RETVAL=$?
;;
*)
echo
$"Uso: $0 {abrircerrar}"
exit
1
;;
esac
exit $RETVAL


Espero le sea de ayuda a alguno que esté preocupado por el uso de estos dispositivos.

miércoles 19 de septiembre de 2007

Algunas reglas para protegerse de tráfico sospechoso

En nuestro país es común el uso de GNU/Linux para proveer servicios de Internet en muchas empresas (grandes, medianas, pequeñas) pero también es común que los muros de fuego de los servidores en Internet no se configuren de tal forma que identifiquen el tráfico de red que podría signficar un ataque a la pila tcp de los servidores públicamente expuestos.

Por ejemplo, un ataque común es enviar pings de difusión a las redes directamente alcanzables por el atacante. Desde un equipo GNU/Linux es muy sencillo enviar pings de difusión

debian-1:~# ping -b -i 5 -p 1024 172.16.45.255
PATTERN: 0x1024
WARNING: pinging broadcast address
PING 172.16.45.255 (172.16.45.255) 56(84) bytes of data.


En ese ejemplo se está enviando tráfico icmp a la dirección de difusión 172.16.45.255. El tamaño de los datos es 1024 bytes y se solicita una respuesta cada 5 segundos. Bien, enviar tráfico de difusión implica un incremento exponencial del tráfico de red porque todas aquellas estaciones que no estén "explícitamente" configuradas para no responder enviarán tráfico. Luego de cierto intervalo de tiempo, la red podría colapsar por o los equipos podrían no establecer más conexiones tcp.

Este es tráfico capturado en mi estación de trabajo al tráfico icmp generado localmente (el ping de difusión).

IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:14:2a:68:e9:fe:08:00 SRC=172.
16.45.7 DST=255.255.255.255 LEN=43 TOS=0x10 PREC=0x00 TTL=128 ID=50812 PROTO=UDP SPT=2000 DPT=2001 LEN=23


Como puede verse, el destino (DST) en la entrada de registro, se ha cambiado a 255.255.255.255 lo que implicaría tráfico a todas la redes directamente alcanzables.

Para protegerse de inundaciones por pings de difusión podría colocar una regla como esta:

iptables -t mangle -A PREROUTING -d 255.255.255.255 \
-p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec \
-j LOG --log-prefix "Ping de difusion: "

iptables -t mangle -A PREROUTING -d 255.255.255.255 \
-p icmp -m icmp --icmp-type 8 -j DROP

La primera regla es para registrar el origen del ataque, la segunda para no permitir ese tipo de tráfico en particular.

Por supuesto, hay muchos tipos de ataques que representan ataques a la pila tcp, a los recursos del servidor como CPU, memoria RAM o disco duro que provienen del tráfico malintencionado generado contra los servidores públicamente expuestos.

sábado 15 de septiembre de 2007

netfilter workshop 2007

Las conferencias de la última reunión de desarrolladores de netfilter/iptables se realizó del 11 al 14 de septiembre.

Acá un enlace que podría ser de interés para aquellos administrando servidores de alta demanda.

lunes 10 de septiembre de 2007

Muro de fuego en GNU/Linux


La configuración del muro de fuego en GNU/Linux es la configuración de iptables para definir cómo se manejará el tráfico de las conexiones hacia los servidores bajo nuestra administración.

Pueden mencionarse dos filosofías para la implementación de muros de fuegos:

  1. Permitir todo y cerrar explícitamente el tráfico que no queremos recibir
  2. Denegar todo y abrir explícitamente el tráfico que queremos permitir que llegue a nuestros servidores.

En lo personal, soy devoto de la segunda filosofía.

Así, pueden definirse las políticas de cadena para las cadenas INPUT y OUTPUT cómo:

iptables -P INPUT DROP
iptables -P OUTPUT DROP


Para seguir ejemplificando, deseamos permitir hacia nuestro servidor el tráfico en respuesta a conexiones originadas desde dentro de nuestra red:

iptables -A INPUT -p tcp -m state --state ESTABLISHED,RELATED


También, deseamos permitir permitir el tráfico entrante a los servicios que ofrecemos:

# Puerto 25/tcp | smtp
iptables -A INPUT -p tcp -s 0/0 --dport 25 \
-m state --state NEW -j ACCEPT

# Puerto 53/tcp | transferencias de zona dns
iptables -A INPUT -p tcp --dport 53 -s $ip_servidor_dns \
-m state --state NEW -j ACCEPT

# Puerto 80/tcp | http
iptables -A INPUT -p tcp -s 0/0 --dport 80 \
-m state --state NEW -j ACCEPT

# Puerto 110/tcp | pop3
iptables -A INPUT -p tcp -s 0/0 --dport 110 \
-m state --statet NEW -j ACCEPT

# Puerto 53/udp | consultas DNS
iptables -A INPUT -p udp -s 0/0 --dport 53 -j ACCEPT


Como se ha establecido la política en la cadena OUTPUT a DROP, debemos abrir paso explícitamente en ella para el tráfico saliente

iptables -A OUTPUT -p tcp -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp -s 0/0 --dport 25 -j ACCEPT
iptables -A OUTPUT -p tcp -s 0/0 --dport 80 -j ACCEPT
iptables -A OUTPUT -p tcp -s 0/0 --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp -s 0/0 --dport 110 -j ACCEPT


Esta configuración es una configuración mínima. No está considerada para servidores en producción y solo es una referencia para mostrar la facilidad con que puede ser configurado el muro de fuego en GNU/Linux y no está considerado, en esta configuración, que el dispositivo que hace de muro de fuego también actúe como enrutador.

lunes 3 de septiembre de 2007

Sobre ataques al CSE

Primero que nada, gracias Noel por la aclaración publicada en

http://list2.enicaragua.org.ni/pipermail/softwarelibre/2007-September/003805.html
http://list2.enicaragua.org.ni/pipermail/softwarelibre/2007-September/003806.html

Por otro lado, contribuyendo a la discusión, podemos diseccionar el problema en más detalle (atendiendo al análisis de la supuesta inyección SQL para obtener el padrón electoral).

Es un secreto a voces acá que el padrón circula entre la población, por otro lado, para analizar la inyección SQL, dividamos el problema en


(1) Servidor web
|
|
(2) módulos del servidor web para el lenguaje
|
|
(3) programas del lado del servidor
|
|
(4) driver de la base de datos
|
|
(5) BD


El servidor web es donde el navegador "golpea" primero al entrar en contacto con el sitio web remoto y puede ser objeto de ataques (el navegador) no necesariamente provenientes del servidor web como se muestra en este excelente documento

Luego (1) podría ser explotado por una vulnerabilidad en el núcleo del servidor web que implicaría una violación de seguridad para todos los sitios web alojados por el servidor y para el sistema operativo en que descansa. Los servidores y servicios expuestos públicamente deben ser constantemente examinados en busca de vulnerabilidades (con una frecuencia al menos diaria) y una vez localizada la vulnerabilidad, debe procederse a estudiar la solución, planificarse para no interrumpir abruptamente a los usuarios que hacen uso de los servicios y ejecutar la solución a la vulnerabilidad encontrada.

Por otra parte, (2) muchos administradores dejan al servidor web con todos los módulos habilitados. No es necesario dejar habilitado un módulo cuya funcionalidad no será usada porque ello implica otro punto de ataque. Incluso, es bueno eliminar del servidor web las configuraciones que atañen también a los lenguajes en que se espera servir los documentos HTML (por ejemplo, ruso).

Además, (3) los programas creados también deben ser auditados en búsqueda de inconsistencias que impliquen violaciones de seguridad que conlleven a la pérdida, alteración o revelación de datos.

Como sabemos, el lenguaje en el servidor supuestamente "hackeado" es php. En php, las consultas SQL están embebidas dentro del código del lenguaje. Una vez realizada la consulta, el propio programa php debe "saber" qué hacer con los resultados de la consulta. Es decir, aunque se logre inyectar una consulta SQL, es necesario un programa del lado servidor capaz de manipular los datos obtenidos de la consulta. Ello implica, si se logra, colocar un programa alterado, una violación al sistema de ficheros del servidor web, es decir, escalada de privilegios más allá de una inyección SQL.

Igual, (4) el driver de la BD pudo ser alterado o (5) se pudo alterar la BD.

La noticia, tal como fue colocada en el sitio web del Nuevo Diario, no hace referencia o no da ningún indicio que nos ayude a analizar o comprender la naturaleza del ataque.

De nuevo, gracias Noel por la aclaración.