Para determinar si una m�quina cliente tiene permitido conectarse a un servicio, los wrappers TCP referencian los siguientes dos archivos, los cuales se conocen com�nmente como archivos de acceso a host:
/etc/hosts.allow
/etc/hosts.deny
Cuando una solicitud de un cliente es recibida por un servicio wrapped TCP, sigue los pasos siguientes:
Referencias a /etc/hosts.allow. — El servicio wrapped TCP analiza secuencialmente el archivo /etc/hosts.allow y aplica la primera regla especificada para ese servicio. Si encuentra una regla que coincide, permite la conexi�n. Si no, se va al pr�ximo paso.
Referencias /etc/hosts.deny. — El servicio wrapped TCP analiza secuencialmente el archivo /etc/hosts.deny. Si encuentra una regla que coincide, rechaza la conexi�n. Si no, se concede acceso al servicio.
Lo siguiente son puntos muy importantes a considerar cuando se usen wrappers TCP para proteger servicios de red:
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.
Las reglas en cada archivo son le�das de arriba hacia abajo y la primera regla que coincida para un servicio dado es la �nica aplicada. Por lo tanto el orden de las reglas es extremadamente importante.
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 sevicios 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.
Aviso
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 a /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
17.2.1. 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.
Las reglas se tienen que formatear de la siguiente manera:
<daemon list> — Una lista separada por comas de los nombres de procesos (no de los nombres de servicios) o el comod�nALL (consulte Secci�n 17.2.1.1). La lista de demonios tambi�n acepta operadores (consulte la Secci�n 17.2.1.4) para permitir mayor flexibilidad.
<client list> — Una lista separada por comas de nombres de host, direcciones IP, patrones especiales (consulte la Secci�n 17.2.1.2), o comodines especiales (consulte la Secci�n 17.2.1.1) la cual identifica los hosts afectados por la regla. La lista de clientes tambi�n acepta operadores listados en la Secci�n 17.2.1.4 para permitir mayor flexibilidad.
<option> — Una acci�n opcional o una lista separada con puntos y comas de acciones realizadas cuando la regla es activada. Los campos de opciones soportan expansiones (consulte la Secci�n 17.2.2.4), lanzan comandos desde el shell, otorgan o prohiben el acceso y alteran el comportamiento de la conexi�n (consulte la Secci�n 17.2.2).
A continuaci�n una muestra b�sica de una regla de acceso:
vsftpd : .example.com
Esta regla instruye a los wrappers TCP a que est�n atentos por conexiones al demonio FTP (vsftpd) desde cualquier host en el dominio example.com. Si esta regla aparece en hosts.allow, la conexi�n ser� aceptada. Si esta regla aparece en hosts.deny, la conexi�n ser� rechazada.
El pr�ximo ejemplo de regla de acceso es un poco m�s compleja y utiliza dos campos de opciones:
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.
Esta regla de ejemplo indica que si una conexi�n al demonio SSH (sshd) se intenta desde un host en el dominio example.com, 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. Para m�s detalles sobre las opciones disponibles, consulte la Secci�n 17.2.2.
17.2.1.1. 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 — Hace corresponder todo. Se puede usar para la lista de demonios o en la lista de clientes.
LOCAL — Hace corresponder todos los nombres de m�quinas que no contengan un punto (.), tal como localhost.
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.
PARANOID — Hace corresponder todas las m�quinas cuyo nombre no se corresponda con la direcci�n.
Atenci�n
Los comodines KNOWN, UNKNOWN y PARANOID tienen que usarse con cuidado porque si se utilizan de una manera incorrecta los usuarios que s� que tengan acceso a un determinado servicio pueden perderlo.
17.2.1.2. 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 example.com:
ALL : .example.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.
Par 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.1.255:
ALL : 192.168.0.0/255.255.254.0
Importante
Cuando se est� trabajando en el espacio de direcciones de IPv4, no se soporta el largo del par direcci�n/prefijo (prefixlen). S�lo las reglas IPv6 pueden utilizar este formato.
Par [Direcci�n IPv6]/prefixlen — Los pares [net]/prefixlen tambi�n pueden ser usadas como un patr�n de control de acceso a un grupo particular de direcciones IPv6. El ejemplo siguiente aplicar�a a cualquier host con una direcci�n de 3ffe:505:2:1:: hasta 3ffe:505:2:1:ffff:ffff:ffff:ffff:
ALL : [3ffe:505:2:1::]/64
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 example.com:
ALL : *.example.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
Otros patrones menos usados son tambi�n aceptados por los wrappers TCP. Vea la p�gina de manual 5 de hosts_access para mayor informaci�n.
Aviso
Tenga mucho cuidado cuando utilice nombres de host y de dominio.Los invasores pueden usar una variedad trucos para burlar las resoluci�n de nombres.Adem�s, cualquier interrupci�n en el servicio DNS podr�a impedir el acceso a servicios incluso a la usuarios que tienen el permiso.
Por lo tanto, lo mejor es usar direcciones IP siempre que sea posible.
17.2.1.3. Portmap y Wrappers TCP
Cuando se crean reglas de control de acceso para portmap, no utilice nombres de host pues la implementaci�n de wrappers TCP de portmap no soporta las b�squeda por host. Por esta raz�n, s�lo utilice direcciones IP o la palabra clave ALL cuando especifique hosts en hosts.allow o en hosts.deny.
Adem�s, cambios a las reglas de control de acceso portmap pueden que no tomen efecto de inmediato si no se reinicia el servicio portmap.
Los servicios ampliamente usados, tales como NIS y NFS, dependen de portmap para funcionar, por lo tanto este consciente de estas limitaciones.
17.2.1.4. 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 ejemplo siguiente desde un archivo hosts.allow, todos los hosts de example.com pueden conectarse a todos los servicios excepto cracker.example.com:
ALL: .example.com EXCEPT cracker.example.com
En el otro 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.
Nota
Organizacionalmente, a menudo 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.
17.2.2. Campos de opciones
Adem�s de las reglas b�sicas para permitir o prohibir el acceso, la implementaci�n de Red Hat Enterprise Linux de wrappers TCP soporta extensiones al lenguaje de control de acceso a trav�s de los campos de opciones. Mediante el uso de campos de opciones dentro de las reglas de acceso al host, los administradores pueden llevar a cabo una gran variedad de tareas tales como alterar el comportamiento del registro, consolidar el control de acceso y lanzar comandos del shell.
17.2.2.1. Registro
Los campos de opciones le permiten a los administradores cambiar f�cilmente la facilidad de conexi�n y el nivel de prioridad para una regla usando la directiva severity.
En el ejemplo siguiente, las conexiones al demonio SSH desde cualquier host en el dominio example.com son registrados a la facilidad por defecto authprivsyslog (debido a que no se especifica un valor de facilidad) con una prioridad de emerg:
sshd : .example.com : severity emerg
Es tambi�n posible especificar una facilidad utilizando la opci�n severity. El ejemplo siguiente registra cualquier intento de conexi�n SSH por cualquier hosts desde el dominio example.com a la facilidad local0 con una prioridad de alert:
sshd : .example.com : severity local0.alert
Nota
En pr�ctica, este ejemplo no funcionar� hasta que el demonio syslog (syslogd) sea configurado para registrar a la facilidad local0. Consulte la p�gina del manual de syslog.conf para informaci�n sobre la configuraci�n de las facilidades de registro personalizadas.
17.2.2.2. Control de acceso
Los campos de opciones tambi�n le permiten a los administradores expl�citamente otorgar o prohibir el acceso de m�quinas en un sola regla, a�adiendo la directiva allow o deny al final de la opci�n.
Por ejemplo, las dos reglas siguientes permiten conexiones SSH desde client-1.example.com, pero prohiben conexiones desde client-2.example.com:
Al permitir el control de acceso por regla, el campo de opciones permite a los administradores consolidar todas las reglas de acceso en un s�lo archivo: bien sea hosts.allow o hosts.deny. Algunos consideran que esta es una forma m�s f�cil de organizar reglas de acceso.
17.2.2.3. Comandos de la Shell
Los campos de opciones permiten a las reglas de acceso lanzar comandos de la shell a trav�s de las directivas siguientes:
spawn — Lanza un comando de la shell como un proceso hijo. Esta directiva de opci�n puede realizar tareas como el uso de /usr/sbin/safe_finger para obtener m�s informaci�n sobre el cliente solicitante o la creaci�n de archivos de registro especiales usando el comando echo.
En el ejemplo siguiente, los clientes intentando accesar servicios Telnet desde el dominio example.com son registrados discretamente a un archivo especial:
twist — Reemplaza el servicio solicitado con el comando especificado. Esta directriz se utiliza a menudo para colocar trampas para intrusos (tambi�n llamados "potes de miel"). Tambi�n se puede utilizar para enviar mensajes a los clientes que se estan conectando. La directriz twist debe estar al final de la l�nea de la regla.
En el ejemplo siguiente, los clientes intentando accesar servicios FTP desde el dominio example.com se les env�a un mensaje a trav�s del comando echo:
vsftpd : .example.com \
: twist /bin/echo "421 Bad hacker, go away!"
Para m�s informaci�n sobre las opciones de comando de la shell, consulte la p�gina del manual de hosts_options.
17.2.2.4. Expansiones
Las expansiones, cuando se utilizan en conjunto con las directrices spawn y twist, proporcionan informaci�n sobre el cliente, servidor y los procesos relacionados.
Abajo se encuentra una lista de las expansiones soportadas:
%a — Suministra la direcci�n IP del cliente.
%A — Suministra 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 — Proporciona el nombre del proceso demonio.
%h — Suministra el nombre de la m�quina del cliente (o la direccci�n IP, si el nombre de la m�quina no est� disponible).
%H — Suministra el nombre de la m�quina del servidor (o la direcci�n IP si el nombre de la m�quina no est� disponible).
%n — Proporciona 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 — Proporciona el nombre de la m�quina del servidor. Si no est� disponible aparecer� unknown. Si el nombre de la m�quina y su direcci�n no coinciden, aparecer� paranoid.
%p — Suministra el ID del proceso demonio.
%s — Suministra informaci�n varia del servidor como el proceso demonio y la m�quina o la direcci�n IP del servidor.
%u — Proporciona el nombre de usuario del cliente. Si no est� disponible aparecer� unknown.
El ejemplo siguiente usa una expansi�n en conjunto con el comando spawn para identificar el host cliente en un archivo de registro personalizado.
Cuando se intentan conexiones al demonio SSH (sshd) desde un host en el dominio example.com, ejecute el comando echo para registrar el intento, incluyendo el nombre del host cliente (usando la expansi�n %h), a un archivo especial:
De forma similar, las expansiones se pueden utilizar para personalizar mensajes de vuelta al cliente. En el ejemplo siguiente, los clientes intentando accesar servicios FTP desde el dominio example.com son informados que se les ha prohibido acceder al servidor:
vsftpd : .example.com \
: twist /bin/echo "421 %h has been banned from this server!"
Para una explicaci�n completa de las expansiones disponibles, as� como tambi�n opciones de control de acceso adicionales, revise la secci�n 5 de la p�gina man para hosts_access (man 5 hosts_access) y la p�gina man de hosts_options.
Para informaci�n adicional sobre los TCP wrappers, refi�rase a la Secci�n 17.5. Para m�s informaci�n sobre c�mo asegurar los TCP wrappers, consulte el cap�tulo llamado Seguridad del Servidor en el Manual de seguridad de Red Hat Enterprise Linux.
