epespad

Asegurando el sistema con hosts.deny/allow

Seguridad con TCP Wrappers


El sistema de control de acceso a nivel de host, permite controlar el acceso a los servicios de red, particularizando las acciones que se deben realizar para diferentes clientes en función del sistema que envía la solicitud de conexión y del servicio solicitado se permite acceso o no.


La gestión de acceso se realiza mediante dos ficheros:



Para permitir accesos

/etc/hosts.allow



Asegurando el sistema con hosts.deny/allow






Para negar accesos

/etc/hosts.deny


redes




Por defecto estos archivos (de existir) vienen completamente comentados con algunos ejemplos como se puede apreciar.


Atención, no confundir lo anterior con el archivo hosts (/etc/hosts) ya que este archivo es uno de los diferentes métodos que usa el sistema operativo para resolver nombres de dominios (DNS).







Ventajas del TCP Wrapper


Transparencia para el cliente del host y el servicio de red.
El cliente que se está conectando así como también el servicio de red wrapped no están al tanto de que están en uso los wrappers TCP
Los usuarios legítimos son registrados y conectados al servicio solicitado mientras que las conexiones desde clientes prohibidos fallan.
Administración centralizada de protocolos múltiples.
Los wrappers TCP operan separadamente de los servicios de red que ellos protegen, permitiendo a muchas aplicaciones de servidor compartir un conjunto común de archivos de configuración para una administración más sencilla.

Los Ficheros /etc/hosts.allow y /etc/hosts.deny especifican pares de servicio/cliente la forma de operar es:


servicio : host



GNU







Observaciones


Lo siguiente son puntos muy importantes a considerar cuando se usen wrappers TCP para proteger servicios de red:

Sólo puede tener una regla por servicio en hosts.allow y hosts.deny.

Puesto que las reglas de acceso en hosts.allow son aplicadas primero, ellas toman precedencia sobre las reglas en hosts.deny. Por lo tanto, si se permite el acceso a un servicio en hosts.allow, una regla negando el acceso al mismo servicio en hosts.deny es ignorada.

Si no se encuentra ninguna regla para el servicio en ninguno de los archivos, o si no existe ninguno de los archivos, se concede el acceso al servicio.

Los servicios wrapped TCP no hacen caché de las reglas desde los archivos acceso de host, por lo tanto cualquier cambio a hosts.allow o a hosts.deny tomarán efecto de inmediato sin tener que reiniciar el servicio de red.

Si la última línea de un archivo de acceso a host no es un caracter de nueva línea (creado al presionar la tecla [ Intro ]), la última regla en el archivo fallará y se registrará un error bien sea en /var/log/messages o a /var/log/secure. Este es también el caso para reglas que se expanden en múltiples líneas sin usar la barra oblicua. El ejemplo siguiente ilustra la porción relevante del mensaje registrado por una falla de una regla debido a alguna de estas circunstancias:


warning: /etc/hosts.allow, line 20: missing newline or line too long








Formatear reglas de acceso


Los formatos para /etc/hosts.allow y /etc/hosts.deny son idénticos. Cualquier línea en blanco que comience con un símbolo de numeral o almohadilla (#) será ignorada, y cada regla debe estar en su propia línea.



Formato del fichero:

lista_servicios : lista_clientes [: ordenes]

servicios: lista (delimitada por comas) de los servicios a los que se aplica la regla
clientes: lista de nombres o IPs de los clientes afectados por la regla
ordenes: (opcional) ordenes adicionales que se ejecutan cuando se cumple la regla






Ejemplos:


La configuración más segura es tener ALL: ALL por defecto en /etc/hosts.deny para después dar permiso específicamente a aquellos servicios y hosts que se desee en /etc/hosts.allow
Esta modificación la debe realizar un usuario con privilegios administrativos, dependiendo de su sistema puede usar su o sudo.



nano -wB /etc/hosts.deny


# Desautorizo todo
ALL : ALL



consola






Podemos comprobar que ya no podemos conectarnos al servidor.

Linux




Entonces tendremos que habilitar los servicios que nosotros creamos necesarios:


nano -wB /etc/host.allow

# Permitir correo
sendmail : ALL
# Permitir SSH solo a una ip
sshd : 192.168.0.101
# ftp y finger sólo a host en mi dominio
# y una máquina específica
in.ftpd,in.fingerd : LOCAL, mihost.encasa.com
# Permito telnet para los host listados en un fichero
# y la red 192.168.
in.telnetd : /etc/telnet.hosts, 192.168.


seguridad





Y verificamos que el servicio ya está habilitado

hostsdeny








Comodines

Los comodines permiten a los wrappers TCP coincidir más fácilmente grupos de demonios o hosts. Son usados con mayor frecuencia en el campo de lista de cliente de las reglas de acceso.



Se pueden utilizar los siguientes comodines:



ALL - Corresponde con cualquier host
LOCAL - Hace corresponder todos los nombres de máquinas que no contengan un punto (.), tal como localhost.
PARANOID - Corresponde con cualquier nombre que no se corresponda con su dirección IP (name spoofing)
KNOWN - Hace corresponder todas las máquinas cuyos nombres y direcciones son conocidos o donde el usuario es conocido.
UNKNOWN - Hace corresponder todas las máquinas cuyos nombres y direcciones sean desconocidas o en el caso en el que se desconozca el usuario.



Los comodines KNOWN, UNKNOWN y PARANOID tienen que usarse con cuidado porque si se utilizan de una manera incorrecta los usuarios que sí tengan acceso a un determinado servicio pueden perderlo.




Operadores


Actualmente, las reglas de control de acceso aceptan un operador, EXCEPT. Se puede usar tanto en la lista de demonios como en la lista de cliente de una regla.

El operador EXCEPT permite excepciones específicas a coincidencias más amplias dentro de la misma regla.

En el siguiente ejemplo desde un archivo hosts.allow, clientes desde la red 192.168.0.x pueden conectarse a todos los servicios excepto la IP 192.168.0.101:

ALL: 192.168.0. EXCEPT 192.168.0.101


hostsallow






En este ejemplo desde un archivo hosts.allow, clientes desde la red 192.168.0.x pueden usar todos los servicios excepto para FTP:

ALL EXCEPT vsftpd: 192.168.0.



Para efectos prácticos es más fácil evitar el uso de operadores EXCEPT. Esto permite a otros administradores escanear rápidamente los archivos adecuados para ver qué hosts deberían tener o no acceso a los servicios, sin tener que revisar varios operadores EXCEPT.





Patrones


Los patrones se pueden utilizar en el campo de lista de cliente de las reglas de acceso para especificar de forma más precisa grupos de host clientes.

La siguiente es una lista de los patrones más comúnmente aceptados para una entrada de lista de cliente:


Nombre de host comenzando con un punto (.)


Al colocar un punto al comienzo de un nombre de host, se hace coincidir todos los hosts compartiendo los componentes listados del nombre. El ejemplo siguiente aplicaría a cualquier host dentro del dominio ejemplo.com:

ALL : .ejemplo.com





Dirección IP que termina con un punto (.)

Al colocar un punto al final de una dirección IP hace corresponder todos los hosts compartiendo el grupo numérico inicial de una dirección IP. El ejemplo siguiente aplicará a cualquier host dentro de la red 192.168.x.x:

ALL : 192.168.





Dirección IP/máscara

Las expresiones de máscaras de red también pueden ser usadas como un patrón de control de acceso a un grupo particular de direcciones IP. El ejemplo siguiente aplicaría a cualquier host con una dirección de 192.168.0.0 hasta 192.168.0.254:

ALL : 192.168.0.0/255.255.255.0




El asterisco (*)

Los asteríscos pueden ser usados para coincidir grupos completos de nombres de host o direcciones IP, siempre y cuando no se mezclen en la lista de cliente conteniendo otros tipos de patrones. El ejemplo siguiente aplicaría a cualquier host dentro del dominio ejemplo.com:

ALL : *.ejemplo.com




La barra oblicua (/)

Si una lista de cliente con una barra, es tratado como un nombre de archivo. Esto en muy útil si es necesario reglas especificando un gran número de hosts. El ejemplo siguiente se refiere a wrappers TCP en el archivo /etc/telnet.hosts para todas las conexiones de Telnet:

in.telnetd : /etc/telnet.hosts





Ordenes

Camino completo hasta una orden que debería ser ejecutada cada vez que se cumpla la regla
Por ejemplo ejecutar una instrucción que envía un mensaje de correo u otro tipo de alerta a un administrador de sistema avisando de que alguien intenta conectar

Hay cierto número de expansiones que podríamos incluir (p.e. %h se expande al nombre de la máquina que se conecta , %d demonio que está siendo llamado...)


Ejemplo:

sshd : .redinterna.net  
: spawn echo "acceso negado a %c %a $(date)" >> /var/log/sshd.log 
: deny


Note que cada campo de opción está precedido por una barra oblicua invertida (). Use la barra para prevenir que falle la regla debido al largo de la misma.


Asegurando el sistema con hosts.deny/allow




Esta regla de ejemplo indica que si una conexión al demonio SSH (sshd) se intenta desde un host en el dominio redinterna.net, ejecute el comando echo (lo cual registrará el intento a un archivo especial) y rechace la conexión. Puesto que se usa la directiva opcional deny, esta línea rechazará el acceso aún si aparece en el archivo hosts.allow.

La directiva spawn ejecuta cualquier comando del shell, incluso scripts, y la directiva deny rechaza el acceso aunque aparezca en hosts.allow


Verificamos que no se puede acceder.

redes




Revisamos el log en el servidor donde acusa el intento de conexión.

GNU





Lista de posibles expansiones

%a La dirección IP del cliente
%A La dirección IP del servidor
%c Proporciona información variada sobre el cliente, como el nombre de usuario y el de la máquina o el nombre del usuario y la dirección IP
%d El nombre del proceso demonio
%h El nombre de la máquina del cliente (o la direccción IP, si el nombre de la máquina no está disponible)
%H El nombre de la máquina del servidor (o la dirección IP si el nombre de la máquina no está disponible)
%n El nombre de la máquina del cliente: si no está disponible aparecerá unknown; si el nombre de la máquina y la dirección de la máquina no se corresponden, aparecerá paranoid
%N El nombre de la máquina del servidor: si no está disponible aparecerá unknown; si el nombre de la máquina y la dirección de la máquina no coinciden, aparecerá paranoid
%p El ID del proceso demonio
%s Información varia del servidor como el proceso demonio y la máquina o la dirección IP del servidor






Otras utilidades

tcpdchk: chequea la configuración de hosts.allow y hosts.deny
tcpdmatch: predice como se comportarían las reglas ante una petición determinada





Resumiendo:


El Uso de TCP Wrapper contribuye a la seguridad de nuestro sistema.

Otro aspecto adicional a considerar es utilizar un cortafuegos para controlar y limitar accesos seria más que recomendable.







Fuentes de conocimiento:

http://www.ac.usc.es/docencia/ASRII/Tema_2html/node8.html
http://www.pedroventura.com/linux/firewall-basico-en-linux-para-bloquear-ips-a-servicios-con-hosts-allow-y-hosts-deny/
http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-es-4/s1-tcpwrappers-access.html
http://jamalahmed.wordpress.com/2010/03/19/using-etchosts-allow-and-etchosts-deny-to-secure-unix/
http://rm-rf.es/seguridad-unix-con-tcp-wrappers/
http://www.brighthub.com/computing/linux/articles/20184.aspx




_____________________________________________________________________

17 comentarios - Asegurando el sistema con hosts.deny/allow

metallitico +2
siempre con aportes utiles e interesantes, gracias!!
alband
Gracias a vos por valorar mis aportes!!
josejp2424 +1
muy buen aporte. van puntos
alband
Muchas gracias amigo
chapitalmala
Muy bueno, interesantìsimo. Cada día me gustan más las redes.
pilo12 +2
Seguridad y libertad ante todo, +10
alband
Gracias por comentar, y por los puntos!!
piruo7 +1
Buen aporte amigo...
ElMagno90 +1
Como siempre, excelente +10
Rulestime +1
Excelente aporte!. Siempre es bueno tener esto a mano!
+10!
alband
La verdad que si compañero!
mfurones +1
un grande, me siento como neo cuando le insertan los manuales de aprendizaje pero leyendo tus post!
+10 y reco!
alband
Muchas gracias por pasar amigo, me alegra que sea comprensible lo que posteo.
dikei78
Se ve que sabes mucho de estos temas , en mi caso no lo se pero aun asi te dejo 10 puntos por tu informacion